Diferencias

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

--- servidores:general:actualizando_etch_a_wheezy [2013/05/19 19:20]
fmolinuevo [Inconvenientes no relacionados con la migración]
+++ 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 107: / Línea 107: @@
 ===== Inconvenientes no relacionados con la migración =====
-En la unidad md3 (usr) se encontraron fallas en el sistema de archivos, por lo que se ejecutó:
+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
@@ Línea 114: / Línea 114: @@
 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.
+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]].
+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 partió de un /usr de Squeeze existente en otro servidor, y se reinstalaron todos los paquetes del servidor dañado.
+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
@@ Línea 127: / Línea 127: @@
   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.
@@ Línea 133: / Línea 135: @@
   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.
-===== Listado de paquetes a reconfigurar =====
+==== 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
@@ Línea 142: / Línea 186: @@
   - 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