Diferencias

Muestra las diferencias entre dos versiones de la página.

--- servidores:general:actualizando_etch_a_wheezy [2013/05/18 10:22]
fmolinuevo
+++ servidores:general:actualizando_etch_a_wheezy [2013/05/23 10:21] (actual)
fmolinuevo [Bibliografía]
@@ Línea 1: / Línea 1: @@
-======  Actualizando Debian Etch a Wheezy ======
+======  Actualizando Debian Etch a Wheezy y otras aventuras ======
 ===== Introducción =====
@@ Línea 17: / Línea 17: @@
   * Correo electrónico con Postfix/Cyrus/Amavis/SpamAssassin/ClamAV
   * RAID5 por software con mdadm y tres discos
+  * Nagios
+  * SNMPd
   * Gran cantidad de archivos y correo-e (unos 600GB)
@@ Línea 68: / Línea 70: @@
   apt-get remove linux-image-2.6-686
-  apt-get install 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.
-Continuará también apareciendo el error de initramfs-tools, pero ahora, con el nuevo kernel creamos el archivo initrd:
+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.
-  mkinitrd -o /boot/initrd-2.6.32-5-686 2.6.32-5-686
-Y actualizamos GRUB:
+Y actualizamos GRUB, migrando al mismo tiempo a grub-pc:
+  apt-get install grub
   update-grub
@@ Línea 84: / Línea 85: @@
   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.
+===== Inconvenientes no relacionados con la migración =====
+En la unidad md3 (usr) se encontraron fallas en el sistema de archivos, por lo que, empleando [[http://www.sysresccd.org/|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 [[https://doc.fmsistemas.com/servidores:raid|procedimientos de recuperación de desastres RAID]]. Y siempre utilizando [[http://www.sysresccd.org/|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.
+==== Otra unidad MD dañada ====
+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.
+===== Actualización a Wheezy =====
+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.
+===== Cyrus no funciona =====
+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
+===== Listado de paquetes y scripts a reconfigurar =====
+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
+  - samba
+  - saslauthd
+  - shorewall
+  - apache2
+  - php5
+  - cyrus
+  - postfix
+  - backups varios (sole, discovery)
+===== Conclusiones =====
+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.
 ===== Bibliografía =====
   * https://doc.fmsistemas.com/servidores:general:actualizando_lenny_a_squeeze
+  * https://doc.fmsistemas.com/servidores:raid
   * https://doc.fmsistemas.com/servidores:general:wheezy_cambiando_arquitectura

AXR Informática: documentación

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página