Diferencias

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

--- servidores:general:actualizando_etch_a_wheezy [2013/05/20 17:30]
fmolinuevo [Actualizando Debian Etch a Wheezy]
+++ servidores:general:actualizando_etch_a_wheezy [2013/05/23 10:21] (actual)
fmolinuevo [Bibliografía]
@@ 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]]. Y siempre utilizando [[http://www.sysresccd.org/|SystemRescueCD]].
@@ Línea 137: / Línea 137: @@
 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 =====
@@ Línea 145: / Línea 160: @@
   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 =====
@@ Línea 161: / Línea 177: @@
-===== Listado de paquetes a reconfigurar =====
+===== 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 168: / Línea 185: @@
   - shorewall
   - apache2
+  - php5
   - cyrus
   - postfix
-  - php5
   - 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