Allí estaremos !! brindando una charla acerca del caso de éxito de Postres Balcarce S.A. y su migración a software libre.
Aplicable a: Redhat/CentOS/Fedora.
Los archivos y directorios que referencian a los usuarios son los siguientes:
/etc/passwd – Información de las cuentas de usuario del sistema.
/etc/shadow – Contraseñas encriptadas para cada usuario.
/etc/group – Grupos a los cuales pertenecen los usuarios.
/etc/gshadow – Archivo shadow de los grupos.
/home – Archivos de los usuarios.
Ojo: En el servidor destino no deben existir cuentas de usuario.
En el servidor de origen de las cuentas, creamos un directorio para ir guardando los datos:
# mkdir /root/backuser
Para extraer los usuarios del passwd vamos a usar el gran awk:
# awk -F: ‘($3>=500) && ($3!=65534)’ /etc/passwd > /root/backuser/passwd
El -F es para decirle que el field separator es el “:”.
Luego filtra que $3 (posición 3 en el passwd) sea >=500 y != de 65534. En toda la línea Redhat, los UID y los GID arrancan en el 500.
El resultado lo redirigimos ( > ) al nuevo archivo /root/backuser/passwd
Ahora extraemos los grupos:
awk -F: ‘($3>=500) && ($3!=65534)’ /etc/group > /root/backuser/group
Con el shadow hacemos algo parecido, pero en el awk debemos obtener el nombre de usuario, dado que en el shadow ese es el campo clave:
# awk -F: ‘($3>=500) && ($3!=65534) {print $1}’ /etc/passwd | tee – | egrep -f – /etc/shadow > /root/backuser/shadow
Si existe el gshadow, lo copiamos directamente:
# cp /etc/gshadow /root/backuser
Copiamos estos archivos con scp u otro medio al servidor destino. Es decir, a donde queremos migrar los usuarios:
# scp /root/backuser/passwd root@destino:/root/passwd.bak
# scp /root/backuser/group root@destino:/root/group.bak
# scp /root/backuser/shadow root@destino:/root/shadow.bak
# scp /root/backuser/gshadow root@destino:/root/gshadow.bak
Luego, en el servidor destino, previo backup de los archivos originales en el /etc, “cateamos” los archivos obtenidos con el awk dentro de los del sistema:
# cat /root/passwd.bak >> /etc/passwd
# cat /root/shadow.bak >> /etc/shadow
# cat /root/group.bak >> /etc/group
# cat /root/gshadow.bak >> /etc/gshadow
Con esto tendríamos los usuarios migrados. Ahora nos falta migrar la data contenida en los home’s:
Para esto, lo mas práctico es hacer un rsync, por ejemplo:
# /usr/bin/rsync -vah root@serverorigen:/home/ /home/
Ahora crucen los dedos y reinicien…
Resulta que me encuentro con un gran tema: como pasar un servidor (linux por supuesto) de físico a virtual sin tener que reinstalarlo por completo.
Un opción que evalúe fué: http://www.mondorescue.org/ (gracias Mauro) esta aplicación (excelente por cierto) permite realizar un backup completo del sistema operativo y lo almacena en archivos .ISO, uno o varios, del tamaño que le indiquemos.
Esta opción no debe descartarse para esta taréa, aunque merece que sea evaluada en otro post.
La opción que hoy nos interesa es la del rsync.
(Vale la aclaración de que hay cientos de maneras de hacer esta taréa. Yo les planteo la que se me ocurrió a mi y dió resultado.)
Para pasar un equipo fisico a virtual con rsync, lo que hice fué lo siguiente:
Crear la maquina virtual destino con los parámetros adecuados, e instalando el mismo sistema operativo base que el servidor físico (en mi caso un CentOS 5.5).
Para que? Para que el filesystem sea lo mas parecido entre el orígen y el destino.
En el equipo físico realice un rsync como el siguiente:
# rsync -vah –exclude-from=excludes.cfg / root@equipo-virtual:/
En el excludes.cfg puse lo siguiente:
/proc/
/tmp/
/mnt/
/mirror/
/etc/fstab
/etc/grub/
/etc/sysconfig/network-scripts/ifcfg-eth0
En el equipo virtual necesito que el fstab mantenga la configuración original, al igual que la placa de red y el grub. Es por eso que están en la exclusión.
Una vez realizado el rsync, y verificado que se hayan copiado todos los directorios, en la maquina virtual, necesitamos bootear con el CD de intalación en modo rescate “linux rescue” para hacer la reinstalación del grub:
# grub-install /dev/hdc
Si el grub-install nos da el error:
“/dev/hdc does not have any corresponding BIOS drive”
Lo resolvemos agregando la siguiente línea en el /boot/grub/device.map:
(hd2) /dev/hdc
Un detalle muy importante:
Va a ser necesario generar una nueva imagen de los módulos del kernel dado que el initrd del equipo fisico, tiene una entrada (init) donde guarda los nombres de los dispositivos de disco en uso (sda, sdb, etc) y por mas que hayamos guardado el fstab de la máquina virtual, en el momento de booteo va a buscar estos dispositivos definidos en el initrd.
Para crear un nuevo initrd que se utilizará en el booteo hagamos lo siguiente:
Hacemos un backup primero del actual en uso:
# cp initrd-$(uname -r).img initrd-$(uname -r).img.back
Compilamos uno nuevo:
# mkinitrd initrd-$(uname -r).img $(uname -r)
Con esto, la máquina virtual debería reinicar correctamente y deberíamos tener el sistema operativo funcionando igual que en el equipo físico.
La migración de sistemas de plataformas Windows a plataformas Linux surge de la necesidad lisa y llana de abaratar costos. Este es un resumen (muy resumido) de mis experiencias:
Escenario: Tenía una serie de servidores Windows, en su mayoría W2003R2, brindando los siguientes servicios:
– File Server, Mail Server, Proxy, Antivirus, Active Directory, Sql Server.
La cuestión es que de a poco y con paciencia es posible migrarlos a todos…, o casi todos a Linux.
– El Active Directory + el File Server se puede configurar directamente en un Linux con Samba + Ldap. El ldap (openldap) nos va a dar la funcionalidad de autenticación de usuarios mientras que el samba nos va a brindar los recursos compartidos necesarios para trabajar con archivos en la red.
– Con Squid reemplazamos cualquier proxy.
– Respecto del servidor de mail, he sido bastante masoquista al respecto (eso dicen ja, ja). Me he dedicado a instalar un servidor QMail con listas RBL que para instalarlo, me ha llevado unas cuántas horas de “plática” con él.
– Respecto de la base de datos, la mejor manera de reemplazar el SQL server es migrando los datos y el código a Mysql o Postgres.
El tema es el siguiente: los datos son fáciles de migrar. Inclusive hay herramientas que realizan dicha taréa. Pero en mi caso, tengo cientos de Stored Procedures… éstos si o sí requieren un análisis y traducción de código que no he visto que realice ninguna herramienta, con lo cuál, en mi caso, el costo de migración es sumamente alto.
Otro tema a evaluar en el caso de la base de datos es la aplicación que hace uso de dicha base. Es posible migrar su enlace a la base?
– Respecto del antivirus, no he encontrado un reemplazo realmente eficiente para el Symantec Corporate Server. Este antivirus, trabaja una base de virus centralizada y hace un deploy a todos los clientes windows conectados.
Creo que la mejor solución para este reemplazo va a surgir cuando pueda reemplazar todos los clientes windows por clientes Linux !!!
Hernan Vivani's Blog 