Esta aventura es sobre la migración de un servidor corriendo Debian Etch a la última versión, Wheezy. Primero se hará una migración a Squeeze, debido a que en ella se introdujo una nueva versión de udev y podría llegar a complicar las cosas; luego se migrará a Wheezy. Además, posee arquitectura i386, pero el microprocesador es un Xeon de 64 bit, por lo que también se realizará el procedimiento de migración a arquitectura amd64.
El servidor es relativamente complejo dado que brinda varios servicios a una empresa cliente nuestro, a saber:
No se brindará un gran detalle del procedimiento de migración, debido a que ha sido documentado ya en los artículos que figuran en la bibliografía. Sin embargo, se notarán aquí los inconvenientes encontrados, o los procedimientos realizados en particular para esta migración.
Por otra parte, es obvio, justo y necesario, nuestro deber y salvación, realizar un backup antes. Además, resguardamos por separado el directorio /etc para tener acceso a las configuraciones originales en caso de emergencia.
El trabajo se realizó en laboratorio, dada su sensibilidad y la posibilidad de complicaciones diversas. Además, simplifica el backup a través de la red en nuestros servidores de backup. Todo el proceso se realizará bajando los paquetes desde un servidor mirror de Debian.
Una ventaja en este caso, es que al ser un servidor no tiene interfaz gráfica, con lo que las complicaciones de dependencias de paquetes se reducen mucho.
Aviso muy importante: es necesario entender que saltar versiones NO se recomienda en lo absoluto. Nosotros lo hacemos porque confiamos y sabemos que Debian GNU/Linux es el mejor sistema operativo en la historia de la Humanidad, y que de alguna manera u otra queda siempre funcionando a la perfección.
Lo primero será convertir los discos virtuales VMWare a archivos monolíticos que luego puedan ser convertidos a imágenes RAW o QCOW2 utilizables por KVM:
vmware-vdiskmanager -r vmware-vm.vmdk -t 0 vmware-vm-monolitico.vmdk
A continuación, se actualizará APT:
apt-get install apt dpkg aptitude -V
Esto provocó un error de dpkg, referido al uso de “breaks” lo cual no está soportado por la versión de Etch de dpkg. Así que continuaremos instalando esos paquetes de Lenny primero, pero evitando actualizar todo el sistema.
Luego de cambiar el sources.list y realizar un apt-get update, continuamos:
apt-get install apt dpkg aptitude -V
Las versiones de Lenny se instalaron correctamente, así como otros paquetes actualizados. Por lo tanto, se volverá a cambiar las fuentes por las de Squeeze, y se continuará la migración comenzando con la instalación de esos tres paquetes, versión Squeeze.
aptitude install dpkg aptitude apt -V
Para resolver un mensaje de error de apt:
apt-get install zlib1g
Luego continuamos actualizando lo más importante:
apt-get upgrade -V
Aparecerá un error de archivos existentes en otros paquetes (util-linux de Etch vs. coreutils de Squeeze)
dpkg -i --force-all /var/cache/apt/archives/coreutils_8.5-1_i386.deb
Debido a que estamos haciendo una actualización de software de versiones muy viejas, se debe prestar mucha atención a las modificaciones en los archivos de configuración. Por ejemplo, en este caso MySQL introduce varias modificaciones en el archivo my.cnf, que aceptamos para tratar de dejar el sistema lo más ajustado posible a las versiones de Squeeze. Finalizada la migración, volveremos a introducir los cambios de configuración necesarios para que los servicios funcionen como es necesario.
En otras palabras: cuando apt-get nos pregunte si deseamos conservar la versión original o la del paquete nuevo, siempre revisaremos qué modificaciones hay, y elegiremos instalar la versión nueva, realizando más tarde las modificaciones en forma manual.
Ahora ocurrirá un error en initramfs-tools. Para resolverlo, desinstalamos linux-image-2.6-686 y lo volvimos a instalar, lo que provocó una nueva serie de actualizaciones, incluyendo el nuevo kernel 2.6.32:
apt-get remove linux-image-2.6-686 apt-get install linux-image-2.6-686 udev
Aquí aparecerá un aviso de cambio de nombres de dispositivos. Obviamente se debe revisar que fstab quede correctamente configurado para que los sistemas de archivos se monten correctamente al iniciar el sistema.
Con esto se actualizará también udev, el cual es incompatible con el kernel de Etch, 2.6.18. Por ello, una vez generados los archivos initrd y actualizado GRUB, se debe revisar que la configuración de inicio haya quedado correcta así podremos reiniciar.
Y actualizamos GRUB, migrando al mismo tiempo a grub-pc:
apt-get install grub update-grub
E instalamos algunos paquetes de utilitarios que además actualizarán las librerías libc:
apt-get install mc screen ccze
Llegado a este punto, se reiniciará el sistema con el nuevo kernel 2.6.32 en runlevel 1, utilizando GRUB2 mediante su opción “Chainloading GRUB2”.
Ahora se terminará la actualización a Squeeze:
apt-get dist-upgrade -V
Como habitualmente al migrar a Squeeze, aparecerá una advertencia al migrar al nuevo sistema de arranque basado en dependencias, al instalar sysv-rc. Para migrar a dicho nuevo sistema, se debe seguir los pasos habituales.
También fallará la actualización por la instalación de libcups2. Primero se debe continuar la misma con:
dpkg --configure -a
Se instalarán muchos paquetes más, hasta fallar nuevamente por ese paquete. Para forzar su instalación:
dpkg -i --force-all /var/cache/apt/archives/libcups2_1.4.4-7+squeeze3_i386.deb dpkg --configure -a
Aquí se termina la actualización a Squeeze, por lo que volvemos a reiniciar en runlevel 1.
En la unidad md3 (usr) se encontraron fallas en el sistema de archivos, por lo que, empleando SystemRescueCD se procedió a la resolución de las mismas:
reiserfsck /dev/md3 reiserfsck --rebuild-tree /dev/md3
El –rebuild-tree finalizó luego de largo rato con un error, debido a que uno de los discos se apagó por completo, y terminó de destruir el sistema de archivos, generando también la salida de servicio del disco en el resto de las unidades RAID.
Se cambiaron dos discos, sospechados de estar funcionando mal, reemplazándolos por discos idénticos nuevos. Uno de ellos, aún funcionando, fue copiado con dd_rescue a uno de los nuevos. Mientras que con el otro disco no fue posible.
Para toda esta parte del trabajo, lenta, tediosa y aburridísima de explicar, se siguieron los procedimientos de recuperación de desastres RAID. Y siempre utilizando SystemRescueCD.
Hecho el recambio de discos, hubo que reconstruir el árbol de directorios y archivos de la unidad md3, correspondiente a /usr
Para ello, se copió todo /usr de Squeeze existente en otro servidor en el directorio /usr del servidor dañado, y se reinstalaron todos los paquetes en éste. Siempre desde un SystemRescueCD se trabajó dentro de un chroot:
dpkg -S /usr > reinstalar sed -i -e"s/,//g" reinstalar sed -i -e"s/: \/usr//g" reinstalar for i in `cat reinstalar` ; do echo "---> $i " 2>&1 >> reinstallog.log ; apt-get install --reinstall $i 2>&1 >> reinstallog.log ; done
La primer línea busca en la base de datos de APT todos los paquetes que han grabado archivos en /usr y los almacena en un archivo “reinstalar”. Las dos siguientes preparan ese archivo sacando las comas y otros caracteres no deseados, para que esté listo para ser usado en el for. Se contó la cantidad de paquetes con “wc -w reinstalar” dando unos 787.
Este tedioso procedimiento deberá ser monitoreado con un tail, y cada vez que aparezca un error, se deberá resolverlo. Por ejemplo, al reinstalar Samba, faltaron las librerías libwbclient.so.0 y libtalloc.so.2.
Con dpkg -S libwbclient.so.0 se podrá ver a qué paquete corresponde, y reinstalarlo antes del paquete samba:
apt-get install --reinstall libwbclient0 libtalloc2
Así ocurrió otras veces. Esto se debe a que los paquetes instalados en el servidor desde donde se tomó /usr no son exactamente los mismos que los que estaban instalados en el servidor que se está reparando.
A lo largo del trabajo, se descubrió que también la unidad md4, montada en /var y con 68GB de datos, tenía errores graves del sistemas de archivos, por lo que se ejecutó otro –rebuild-tree en runlevel 1:
reiserfsck --rebuild-tree /dev/md4
Esto reconstruyó perfectamente el árbol de archivos, pero varios nodos quedaron conectados a lost+found, especialmente archivos relacionados con la base de datos de archivos de APT. Por ello, al trabajar con apt-get ocurrían algunos errores de “falta de información sobre algún paquete, por lo que se considera no instalado”. Para resolverlo, se reinstalaron los paquetes en cuestión:
aptitude reinstall python-debian cpio insserv lzop ispell libtasn1-3-bin unrar libgnome2-common pppconfig gconf2-common perl-modules libtie-ixhash-perl debianutils
Y se realizó otro chequeo de disco:
reiserfsck /dev/md4
que ya no arrojó errores. El reinstall resolvió los inconvenientes en la base de datos de paquetes, y de entonces en adelante el servidor quedó operacional.
Una vez que se revisó que todo funcione correctamente, que fueron sincronizados las unidades RAID, y que se eliminaron paquetes innecesarios y errores varios, se procedió a actualizar a Wheezy siguiendo el procedimiento estándar.
sed -i -e"s/squeeze/wheezy/g" /etc/apt/sources.list apt-get update apt-get install apt dpkg aptitude -V apt-get dist-upgrade -V
El procedimiento de actualización también incluye eliminar kernels viejos, revisar archivos de configuración cambiados, y eliminar paquetes obsoletos, tareas ya documentadas en otros instructivos.
Al actualizar Cyrus apareció un nuevo error, por lo que debemos reconstruir las bases de datos de Cyrus:
su - cyrus cd /var/lib/cyrus rm db/* rm db.backup?/* rm deliver.db rm tls_sessions.db /usr/lib/cyrus/bin/ctl_mboxlist -d > mailboxes.txt mv mailboxes.db mailboxes.db.old /usr/lib/cyrus/bin/ctl_mboxlist -u < mailboxes.txt
El siguiente listado muestra aquellos componentes cuya configuración tuvo que ser revisada por diversos inconvenientes. En parte se debe a las diferencias de configuración entre los paquetes de Etch y los de Wheezy, y en parte al daño ocurrido en los sistemas de archivos
Finalmente no hubo tiempo de migrar de arquitectura, así que el servidor quedó con i386. Ello no es un inconveniente grave en este caso, por lo que quedará para otra ocasión.
Lo interesante de destacar es la facilidad con que Linux, y en particular Debian, permite recuperar los desastres más terribles. No hay otro sistema operativo que brinde semejante comodidad al administrador.
También es de destacar, respecto a Debian, la consistencia entre las distintas versiones, lo cual permite que los equipos sean migrados con mínimos inconvenientes entre una versión y otra, y queden perfectamente funcionales otra vez en poco tiempo.
En esta ocasión el proceso llevó mucho más tiempo del esperado debido a los errores en discos, y en especial a los daños en las unidades RAID. Pero también es de agradecer la potencia y confiabilidad de mdadm, que permite restaurar unidades de una u otra forma, a pesar de las fallas aparentemente terribles en el hardware.