Introducción

Existen muchos escenarios donde es posible que tenga que mover los datos y los requisitos operativos de un servidor a otro. Es posible que deba implementar sus soluciones en un nuevo centro de datos, actualizar a una computadora más grande o realizar la transición a un nuevo hardware a un nuevo proveedor de servidor.

Sean cuales sean sus razones, hay muchas consideraciones diferentes que debe hacer al pasar de un sistema a otro. Conseguir configuraciones funcionalmente equivalentes puede ser difícil si no está operando con una solución de administración de configuración como Chef, Puppet o Ansible. No sólo debe transferir datos, sino también configurar sus servicios para que operen de la misma manera en una computadora nueva.

En nuestro último tutorial, hablamos sobre la transferencia de datos con rsync y migrar su base de datos . Continuaremos con la migración en este tetorial migrando usuarios, grupos, correo, crontabs y otras configuraciones.

Migrar Usuarios y Grupos

Aunque su principal preocupación puede ser por sus servicios y programas, tenemos que prestar atención a los usuarios y grupos también.

La mayoría de los servicios que necesitan usuarios específicos pueden creará estos usuarios y grupos en la instalación. Sin embargo, esto todavía deja a los usuarios y grupos que se han creado manualmente a través de otros métodos.

Afortunadamente, toda la información para usuarios y grupos está contenida en unos pocos archivos. Los archivos principales que necesitamos mirar son:

• / Etc / passwd : Este archivo define nuestros usuarios y atributos básicos. A pesar de su nombre, este archivo ya no contiene ninguna información de contraseña. En su lugar, se centra en nombre de usuario, usuario y números de grupo principal, directorios de inicio y shells predeterminados.

• / Etc / shadow : Este archivo contiene la información real sobre las contraseñas de cada usuario. Debe contener una línea para cada uno de los usuarios definidos en el archivo passwd, junto con un hash de su contraseña y alguna información sobre las políticas de contraseñas.

• / Etc / group : Este archivo define cada grupo disponible en su sistema. Básicamente, esto sólo contiene el nombre del grupo y el número de grupo asociado, junto con los nombres de usuario que usan esto como un grupo suplementario.

• / Etc / gshadow : Este archivo contiene una línea para cada grupo en el sistema. Básicamente lista el grupo, una contraseña que puede ser utilizada por miembros que no son del grupo para acceder al grupo, una lista de administradores y no administradores.

Si bien puede parecer una buena idea simplemente copiar estos archivos directamente desde el sistema de origen en el nuevo sistema, esto puede causar complicaciones y no se recomienda.

Uno de los principales problemas que pueden surgir es el grupo en conflicto y los números de identificación del usuario. Si el software que crea sus propios usuarios y grupos se instala en un orden diferente entre los sistemas, los números de usuario y de grupo pueden ser diferentes, causando conflictos.

En su lugar es mejor dejar la mayoría de estos archivos solos y sólo ajustar los valores que necesitamos. Podemos hacer esto de varias maneras.

Creación de Archivos de Migración

Independientemente del método que desee utilizar para añadir usuarios a nuestro nuevo sistema, debemos generar una lista de usuarios, grupos, etc. que se deben transferir y agregar.

Un método que ha estado flotando en Internet por un tiempo se menciona a continuación:

Crearemos un archivo asociado con cada uno de los archivos anteriores que debemos modificar. Contendrán toda la información de transferencia apropiada.

En primer lugar, averiguar cuál es el límite de ID entre usuarios regulares y del sistema en su computadora. Esto es típicamente 500 o 1000 dependiendo de su sistema. Si tiene un usuario normal, una manera fácil de averiguar es inspeccionar el /etc/passwd y ver dónde comienzan las cuentas de usuario regulares:

less /etc/passwd

Posteriormente, podemos usar este número (el primer número de ID de usuario regular, en la tercera columna) para establecer el límite en nuestro comando. No vamos a exportar usuarios o grupos por debajo de este límite. También se excluirá la cuenta "nobody" a la que se le da el identificador de usuario "65534".

Podemos crear un archivo de sincronización para nuestro archivo /etc/passwd escribiendo esto. Sustituya el número de límite # por el número de usuario regular más bajo que haya encontrado en el /etc/passwd :

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync

Después, podemos hacer lo mismo para crear un archivo de sincronización de grupo:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync

Podemos usar los nombres de usuario dentro del rango que nos interesa desde nuestro /etc/passwd para obtener los valores que queremos de nuestro archivo de sombra:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync

Para el /etc/gshadow , haremos una operación similar:

awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync

Una vez que conozcamos los comandos que queremos ejecutar, podemos agregarlos a nuestro script después de un comando SSH regular y luego rsync ellos, así:

ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync"
rsync 111.222.333.444:/root/passwd.sync /root/
rsync 111.222.333.444:/root/group.sync /root/
rsync 111.222.333.444:/root/shadow.sync /root/
rsync 111.222.333.444:/root/gshadow.sync /root/

Agregar Usuarios Manualmente

Si queremos simplemente agregar un comentario a nuestro archivo de script y hacerlo manualmente, se recomiendan los comandos vipw y vigr , porque bloquean los archivos mientras se edita y protegen contra la corrupción. Puede editar los archivos manualmente escribiendo:

vipw

Pasar el indicador -s modifica el fichero shadow asociado y pasar el indicador -g edita el fichero de grupo.

Usted puede ser tentado a añadir las líneas de los archivos directamente en el final del archivo asociado en el nuevo sistema como este:

cat /root/passwd.sync >> /etc/passwd

Si decide ir a esta ruta, debe tener en cuenta que puede haber conflictos de ID si el ID ya lo ha tomado otro usuario en el nuevo sistema.

También puede agregar cada nombre de usuario utilizando las herramientas disponibles en el sistema después de obtener una lista del equipo de origen. El comando useradd puede permitirle crear rápidamente cuentas de usuario para que coincidan con el equipo de origen:

useradd -s /path/to/shell -m -d /home/username -p password -G supplementary_groups

Puede utilizar los archivos *.sync como referencia y agregarlos de esta manera.

Agregar Usuarios Automáticamente

Si en cambio queremos guiar las adiciones de usuarios y grupos dentro de nuestro archivo, también podemos hacerlo fácilmente. Sin embargo, queremos comentar esto después de la primera ejecución exitosa, porque el script intentará crear usuarios / grupos varias veces de lo contrario.

Hay un comando llamado newusers que puede agregar usuarios a granel de un archivo. Esto es perfecto para nosotros, pero queremos modificar nuestros archivos primero para eliminar los ID de usuario y de grupo. El comando generará los siguientes usuarios y grupos disponibles para el nuevo sistema.

Podemos quitar el grupo y los ID de usuario del archivo passwd como esto:

awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' /root/passwd.sync > /root/passwd.sync.mod

Podemos aplicar este nuevo archivo modificado como este:

newusers /root/passwd.sync.mod

Esto agregará todos los usuarios del archivo al archivo local /etc/passwd . También creará automáticamente el grupo de usuarios asociado. Tendrá que agregar manualmente grupos adicionales que no estén asociados con un usuario al /etc/group . Utilice sus archivos de migración para editar los archivos apropiados.

Para el /etc/shadow , puede copiar la segunda columna del archivo shadow.sync en la segunda columna de la cuenta asociada en el nuevo sistema. Esto transferirá las contraseñas de sus cuentas al nuevo sistema.

Puede intentar realizar una secuencia de comandos de estos cambios, pero este puede ser un caso en el que es más fácil hacerlo a mano. Recuerde comentar cualquier línea de usuario o grupo después de configurar los usuarios y grupos.

Transferencia de Correo y Trabajos a un Nuevo Sistema

Ahora que los usuarios se transfieren desde el sistema anterior y tienen los directorios de inicio del usuario llenos por los comandos rsync que se han ejecutado, también puede migrar el correo de cada usuario. Queremos replicar los trabajos cron también.

Podemos empezar haciendo otro comando rsync para el directorio spool. En el directorio de spool de nuestro sistema de origen, normalmente podemos ver algunos archivos importantes:

ls /var/spool

anacron   cron   mail   plymouth   rsyslog

Queremos transferir el directorio de correo a nuestro servidor de destino, por lo que podemos agregar una línea rsync que se vea así a nuestro script de migración:

rsync -avz --progress 111.222.333.444:/var/spool/mail/* /var/spool/mail/

Otro directorio dentro del directorio /var/spool que queremos prestar atención es el directorio cron . Este directorio mantiene cron y en los trabajos, que se utilizan para la programación. El directorio crontabs contiene el crontab del usuario individual se utiliza para programar trabajos.

Queremos preservar las tareas automatizadas que nuestros usuarios han asignado. Podemos hacer esto con otro comando rsync:

rsync -avz --progress 111.222.333.444:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*

Esto obtendrá crontabs de usuario individual en nuestro nuevo sistema. Sin embargo, hay otros crontabs que necesitamos mover. Dentro del directorio /etc , hay un crontab y un número de otros directorios que contienen cron info.

ls /etc | grep cron

anacrontab
cron.d
cron.daily
cron.hourly
cron.monthly
crontab
cron.weekly

El archivo crontab contiene detalles de cron en todo el sistema. Los otros elementos son directorios que contienen otra información de cron. Mire en ellos y decida si contienen cualquier información que usted necesita.

Una vez más, utilice rsync para transferir la información cron relevante al nuevo sistema.

rsync -avz --progress 111.222.333.444:/etc/crontab /etc/crontab

Una vez que tenga su información cron en su nuevo sistema, debe verificar que funciona. Este es un paso manual, por lo que tendrá que hacer esto al final.

La única manera de hacerlo correctamente es iniciar sesión como cada usuario individual y ejecutar los comandos en la crontab de cada usuario manualmente. Esto se asegurará de que no hay problemas de permisos o rutas de archivo que faltan que impiden que estos comandos silenciosamente fallan cuando se ejecuta automáticamente.

Servicios de Reinicio

Al final de la secuencia de comandos de migración, debe asegurarse de que todos los servicios apropiados se reinician, se vuelven a cargar, se enjuagan, etc. Debe hacer esto utilizando los mecanismos apropiados para el sistema operativo que está utilizando.

Por ejemplo, si estamos migrando un paquete LAMP en Ubuntu, podemos reiniciar los procesos importantes escribiendo:

service mysql restart
service apache2 restart
service php5-fpm restart

Puede agregarlos al final de su script de migración tal como está, y deben funcionar como se esperaba.

Sitios y Servicios de Prueba

Una vez que haya terminado el script de migración y lo haya ejecutado con todas las sincronizaciones y modificaciones, además de haber realizado todos los pasos manuales necesarios, debe probar el nuevo sistema.

Hay bastantes áreas que usted querrá comprobar. Preste atención a cualquier archivo de registro asociado mientras prueba para ver si aparecen problemas.

En primer lugar, desee probar los tamaños de directorio después de que haya transferido. Por ejemplo, si tiene una partición de /data que ha sincronizado, deseará ir a ese directorio tanto en los equipos de origen como de destino y ejecutar el comando du :

cd /data
du -hs

471M    .

Compruebe que los tamaños están cerca de la misma. Puede haber pequeñas diferencias entre el original y el nuevo sistema, pero deben estar cerca. Si hay una gran disparidad, debe investigar por qué.

A continuación, puede comprobar los procesos que se ejecutan en cada servidor. Puede hacerlo buscando información importante en la salida ps :

ps auxw

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  27024  2844 ?        Ss   Feb26   0:00 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Feb26   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Feb26   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    Feb26   0:00 [kworker/0:0]
root         5  0.0  0.0      0     0 ?        S<   Feb26   0:00 [kworker/0:0H]
. . .

También puede replicar algunas de las comprobaciones que hizo inicialmente en su computadora de origen para ver si ha emulado el entorno en la nueva computadora:

netstat -nlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1564/dnsmasq    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      2886/cupsd      
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      752/smbd        
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      752/
. . .

Una vez más, otra opción es:

lsof -nPi

COMMAND     PID        USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
smbd        752        root   26u  IPv6    9705      0t0  TCP *:445 (LISTEN)
smbd        752        root   27u  IPv6    9706      0t0  TCP *:139 (LISTEN)
smbd        752        root   28u  IPv4    9707      0t0  TCP *:445 (LISTEN)
smbd        752        root   29u  IPv4    9708      0t0  TCP *:139 (LISTEN)
. . .

Debería revisar las versiones de sus servicios importantes, como lo hicimos en el primer artículo, para verificar si coincidía con la versión de paquetes importantes. La forma de hacerlo dependerá del sistema.

Si transfirió un servidor web o un paquete LAMP, debería probar definitivamente sus sitios en el nuevo servidor.

Puede hacerlo fácilmente modificando su archivo hosts (en su computadora local) para apuntar a su nuevo servidor en lugar del antiguo. A continuación, puede comprobar si su servidor acepta correctamente las solicitudes y si todos los componentes funcionan de forma correcta.

La forma en que modifica el archivo de los local hosts varía en función del sistema operativo que esté utilizando. Si está utilizando un sistema operativo con diseño basado en * nix, como OS X o Linux, puede modificar el archivo hosts en su sistema local de la siguiente manera:

sudo nano /etc/hosts

En el interior, es necesario agregar una entrada para señalar su nombre de dominio a la dirección IP de su nuevo servidor, para que el equipo intercepte la solicitud y lo enruta a la nueva ubicación para la prueba.

Las líneas que puede agregar pueden verse algo como esto:

111.222.333.444     www.domain.com
111.222.333.444     domain.com

Agregue también cualquier subdominio que se utilice en la configuración de su sitio (images.domain.com, files.domain.com, etc.). Una vez que haya agregado las líneas de host, guarde y cierre el archivo.

Si está en OS X, tendrá que vaciar el archivo hosts de su computadora para ver el nuevo contenido:

sudo lookupd -flushcache

En Linux, esto debería funcionar automáticamente.

En Windows, tendrá que editar el archivo C:\Windows\Wystem32\Drivers\etc\hosts como administrador. Agregue las líneas de la misma manera que hicimos anteriormente para las versiones * nix.

Después de que su archivo de hosts se edite en su estación de trabajo local, debería poder acceder al servidor de prueba dirigiéndose a su nombre de dominio. Pruebe todo lo que pueda y asegúrese de que todos los componentes puedan comunicarse entre sí y responder de la manera correcta.

Una vez que haya completado la prueba, recuerde volver a abrir el archivo hosts y eliminar las líneas que agregó.

Migrar Reglas de Firewall

Recuerde que necesita migrar sus reglas de Firewall a su nuevo servidor. Para aprender a hacer esto, siga este tutorial: migrar reglas de Firewall de Iptables a un servidor nuevo .

Tenga en cuenta que, antes de cargar las reglas en su nuevo servidor, tendrá que revisarlas para cualquier cosa que deba actualizarse, como direcciones IP modificadas o rangos.

Cambiar la Configuración de DNS

Cuando hayas probado a fondo tu nuevo servidor, mira a través de tu script de migración y asegúrate de que ninguna parte del mismo va a revertir las modificaciones que hayas hecho.

Después, ejecute el script una vez más para obtener los datos más recientes de su servidor de origen.

Una vez que tenga todos los datos más recientes en su servidor de destino, puede modificar los servidores DNS de su dominio para que apunten a su nuevo servidor. Asegúrese de que cada referencia a la IP del servidor antiguo se reemplaza con la información del nuevo servidor.

Los servidores DNS tardarán algún tiempo en actualizarse. Después de que todos los servidores DNS hayan recibido sus nuevos cambios, es posible que deba ejecutar el script de migración una última vez para asegurarse de que se transfieran las solicitudes extravagantes que todavía estaban en su servidor original.

Mire atentamente sus comandos de MySQL para asegurarse de que no está tirando o sobrescribiendo datos que se han escrito en los servidores antiguos o nuevos.

Conclusión

Si todo ha ido bien, su nuevo servidor ahora debe estar en funcionamiento, aceptando solicitudes y manejando todos los datos que estaban en su servidor anterior. Usted debe seguir vigilando de cerca la situación y estar pendiente sobre cualquier anomalía que pueda surgir.

Las migraciones, cuando se hace correctamente, no son triviales, y muchos problemas pueden surgir. La mejor oportunidad de migrar con éxito un servidor en vivo es entender su sistema lo mejor que pueda antes de comenzar. Cada sistema es diferente y cada vez, usted tendrá que trabajar alrededor de nuevas ediciones. No intente migrar si no tiene tiempo para solucionar problemas que puedan surgir.