Migración de arquitectura en 20 minutos

Me he quedado muy sorprendido cuando en menos de 20 minutos he conseguido sustituir un servidor por otro manteniendo absolutamente todo el contenido y servicios del primero en el segundo…

Este tipo de maniobras es una de las “magias” que se pueden realizar con un sistema Linux con un Kernel y módulos suficientemente actualizados como para que se pongan en marcha todos los dispositivos (tarjetas de red…) del nuevo servidor.

El es cenario es el siguiente: Equipo antiguo (Pention II 350, con 64Mb de Ram y 8 Gb de disco) a sustituir por uno no muy nuevo pero que le supera con creces.

Hay que decir que el nuevo servidor ya lo tenía “preparado”, es decir, tenía el disco particionado y con el gestor de arranque Grub cargado y configurado para que en la primera partición residiera un sistema bootable. De todas formas aunque no lo hubiese tenido así, lanzar un fdisk sobre el nuevo disoco, e instalar el grub tampoco cuesta mucho.

Con estas premisas ha bastado con “pinchar” el disco viejo como maestro del IDE 1 en el nuevo servidor, el disco nuevo como maestro del IDE2 y con un comando tan sencillo (y eficaz) como dd realizar una copia del contenido de la partición antigua a la nueva:

dd if=/dev/hda1 of=/dev/hdc1

Esperar 15 minutos a que se transfiera el contenido, y posteriormente ejecutar una pequeña comprobación sobre la partición destino:

fsck.ext3 /dev/hdc1

Tras esto, pongo el disco nuevo como maestro del IDE1 y saco el disco viejo. Arranco y a funcionar!!!

No cabe duda de que lo que ahora toca es cierta labor de tuning (e incluso alguna recompilación y actualización) para aprovechar al máximo la nueva arquitectura…

Anuncios

Encontrar texto en ficheros linux: find, xargs, grep

Lo cierto es que muchas veces resulta necesario realizar búsquedas de ciertas cadenas en diferentes ficheros, y tener un listado de los ficheros que contienen dicha cadena.

Por ejemplo: sabemos que tenemos que tocar una clave de configuración (sabemos qué variable o qué valor), dentro de algún fichero en /etc, pero de los cientos de ficheros, no recordamos exactamente en cuál se encuentra. Basta que busquemos esa cadena y nos diga qué ficheros la contienen para que acotemos nuestra búsqueda.

Para realizarlo utilizaremos los comandos find, xargs y grep.

find busca ficheros en el disco, xargs es capaz de pasar una lista como argumentos en llamadas repetidas a otro programa y grep realiza búsquedas de cadenas dentro de ficheros.

El comando en cuestión es:

find . |xargs grep ‘cadena’

y su explicación:

find . realiza un listado de ficheros desde la ruta actual

| es el pipe es decir, la salida del comando anterior la pasa al siguiente

xargs toma la lista resutlado de find y la va pasando como llamadas consecutivas a grep

grep busca ‘cadena’ dentro de los ficherso que le pasa xargs, buscados a su vez por find.

La verdad es que esta es la forma más simple que podemos ir depurando. Por ejemplo, si queremos restringir la búsqueda a ficheros con una extensión concreta, basta con que utilicemos parámetros para el find: find . -name ‘*.txt’ , si por ejemplo queremos obtener únicamente el listado de los ficheros para almacenarlos en algún lugar, o para pasar a su vez ese listado a otro comando (por ejemplo realizar una copia de dichos ficheros a otro lugar) bastaría con lo siguiente: find . -type f -name ‘*.conf’ |xargs grep -Hn ‘eth0’ | cut -d: -f1

y así sucesivamente…

SCREEN o cómo conservar aplicaciones en segundo plano tras cerrar la consola linux remota

Hace ya bastante tiempo me ocurrió que necesitaba mantener aplicaciones funcionando en segundo plano después de haber lanzado éstas desde un terminal remoto (conexión ssh o similar) y tener que cerrar dicha conexión. Además, necesitaba poder recuperar esas aplicaciones tal y como quedaban en segundo plano.

Tras preguntarle a nuestro amigo google, encontré una herramienta de nombre SCREEN que se ha comvertido en poco tiempo en el comando más lanzado en mi servidor Linux.

La herramienta screen te permite tener un pool de tareas ejecutándose y recuperarlas pase lo que pase: perdamos la conexión, tengamos que cerrarla, etc.

basta con descargar el paquete correspondiente e instalarlo, y después para ejecutar el comando:

screen –> nos abre una nueva sesión screen, que nos permitirá comenzar a lanzar aplicaciones.

screen -list –> nos muestra las sesiones que están en segundo plano

screen -r –> recupera una sesión de segundo plano

screen -wipe –> limpia sesiones perdidas (cuando matamos procesos screen)

Cuando ejecutamos screen nos aparece algo similar a esto:

Pulsamos espacio y ya estamos dentro de la aplicación. A partir de ahora puede comenzar a lanzar comandos, como por ejemplo un cliente texto bittorrent…

Screen se maneja mediante comandos precedidos de Ctrl +A.

Ctrl + A — d –> deja la sesión screen en segundo plano y nos devuelve a nuestra consola original. Para volver a Screen debemos ejecutar screen -r .

Ctrl + A — c –> crea una nueva ventana screen en la sesión screen.

Ctrl + A — n –> pasamos a la siguiente ventan screen creada.

Para cerrar una ventan screen basta con teclear exit. Automáticamente pasaremos a la ventana screen siguiente y si no la hay cerrará la sesión screen.

Espero que la herramienta os sea útil.

Copias de seguridad en MySQL, /etc y Linux

La realización y programación de copias de seguridad (simples) de las bases de datos de nuestros servidores, así como de los principales archivos de configuración, supone aproximadamente 2 minutos de trabajo y una línea de código. Por eso no entiendo como hay gran cantidad de personas que tal vez por no darle importancia suficiente no han invertido ese tiempo en asegurar por ejemplo… el contenido de su blog.

El mecanismo más sencillo de recuperación de desastres para mysql consiste en utilizar la fabulosa herramienta mysqldump y programar mediante cron un pequeño script con esta pinta:

#!/bin/sh
#
/usr/bin/mysqldump –user=sa –password=pwd –all-databases > /destino/backup-mysql.sql

El usuario (–user) ha de ser un usuario con permisos sobre todas las bases de datos, por lo que el script que generemos y depositemos en /etc/cron.daily (por ejemplo para una copia diaria) ha de tener permisos solo para root (chmod 700)

El script anterior realiza copias simples que cada día se carga la del anterior (a mi me sirve porque mi sistema de recolección lo contempla). También podríamos crear el fichero con el nombre del día en cuestión, e ir realizando rotación… pero eso son ya tres minutos.

Para que indique el día:

#!/bin/sh
#
/usr/bin/mysqldump –user=sa –password=pwd–all-databases > /root/backup-mysql`date +%d%m%y`.sql

Siguiendo el mismo esquema, podemos programar un backup mensual de los archivos de configuración con el script:

#!/bin/sh
#
/bin/tar cvf /root/backups/backup-etc`date +%d%m%y`.tar /etc/*
/bin/gzip /root/backups/backup-etc`date +%d%m%y`.tar

este lo podemos alojar en el /etc/cron.monthly/

cliente NTP en debian

La verdad es que esto es algo muy sencillote, vamos una chorrada, pero como a mi server se le ha acabado la pila y no lleva bien eso de mantener la hora (vamos que se le adelanta el reloj) he tenido que montarle el cliente NTP. Recordar que es muy importante tener la hora bien sincronizada para enterarse de cuándo pasan las cosas (logs…).

Para instalar el cliente NTP en Linux, basta con buscar el paquetito compilado correspondiente (ntpdate), lo descargamos e instalamos:

apt-get install ntpdate

Y finalmente lo programamos: dos opciones en Debian, creamos la entrada en el crontab, o utilizamos el mecanismo run-parts incluido en el propio crontab, de forma que solo tenemos que dejar un script en la carpeta correspondiente (/etc/cron.daily) si lo queremos una vez al día.

En mi caso dejo el script:

vi /etc/cron.daily/ntp
#!/bin/sh
#
/usr/sbin/ntpdate ntp.upv.es

No hará falta decir que debemos garnatizar los permisos de ejecución correspondientes…