Bien, para poneros en antecedentes os comentaré que hace tiempo (más de 4 años) ya expresé públicamente lo que pensaba acerca de “cierta política” de recuperación de dominios de amen.es. Por lo que en este caso, llueve sobre mojado.
Para no dispersaros mucho de vuestra multitarea, que sé como es el tema, os lo resumiré lo que más pueda pero prefiero documentar un poco los pasos para que os pongáis escena. Esto le ha sucedido a un colega con un servidor dedicado en el que yo he realizado algunas tareas de administración y optimización, el nombre no viene al caso, quizás alguno sabéis de quien hablo pero lo importante es saber con que empresa trata uno en casos como este.
Está claro que no se puede generalizar y que la gente de Amen no hará todo mal, también sé muy bien que la administración de sistemas no es una tarea fácil y que hay muchos puntos críticos o que sean susceptibles de fallar más que otros pero hablaré de lo que he visto en todo este proceso de la forma más objetiva posible.
Máquina, un servidor dedicado con tiempo ya, un Dual Xeón con mucho trote y descatalogado de la oferta actual de Amen, 150 Gb de disco duro, 2 Gb de Ram y una distribución de Fedora Linux junto a uno de esos imagino “males necesarios” que son los paneles de administración vía web, (tema del que hablé), en este caso Direct Admin.
Esto sucedió un Viernes, me llega un mail de mi colega “Dabo, el servidor ha petado, me dicen que hay muchos errores en el disco los de Amen y que me ponen el servidor en modo recuperación”, ellos lo llaman “Recovery mode” que no es otra cosa que un arranque de la maquina en cuestión vía un Live CD de Ubuntu en este caso (que supongo será una imagen vía red que tendrán preparada).
Más datos sobre el detalle del recovery mode famoso, una salida del comando uname -a (con -r da menos info);
root@wpc:~# uname -a
Linux wpc___.amenworld.com 2.6.24.2-live #1 SMP Tue Apr 22 16:13:55 UTC 2008 i686 GNU/Linux
Para saber la versión exacta del S.O, suelo usar “lsb”, concretamente lsb_release -a (hay otras formas);
root@wpc:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy
Viernes noche / Sábado, bien, a partir de ahí entro vía SSH al servidor en modo “rescate” y veo como efectivamente la salida del comando fsck (usadlo sólo sin estar montadas las unidades) reporta un montón de errores en el disco, había un sistema Raid por software con una forma de petar muy extraña pero eso es otra historia.
Previamente había estado haciendo algunas que otras comprobaciones con la ayuda de mi colega “AJ”, al final después de unos cuantos reinicios en “modo normal” desde el panel web de Amen a ver si arrancaba el sistema y viendo que no había forma de poder ya levantar todo normalmente y que ni conectaba vía SSH, ya descarté seguir en esa máquina y la prioridad para mi fue recuperar todo el contenido de /home (donde estaban las webs) y de /var/lib/mysql, donde estaban las bases de datos en el momento de petar…
Como sabéis, el comando fsck que tiene varios parámetros para ejecutarse, una vez que hace las comprobaciones de disco, envía los archivos recuperados al directorio “Lost+Found”, había muchos material para recuperar en este caso, una vez finalizadas todas las operaciones en el disco, vía rsync hubo que colocarlos en su lugar original, para después, dejar montada una partición de disco con /home y /var con todo el contenido original con la idea de enviarlo después vía rsync al nuevo servidor…
Esta parte de la recuperación la resumo mucho porque llevó unas 5 o 6 horas recuperando, reiniciando, desmontando y montando unidades, Raids y la madre que le parió al disco duro… (se haría muy largo el post, os lo aseguro).
A todo esto ¿Qué le decía a su cliente o más bien hacía Amen? nada de nada, Viernes tarde y claro, como para ponerse con un “pancho” como este…toma soporte 24 x 7 x 365 (otra cosa como veis de la que ya escribí) y ojo, no cobran mal no, unos 50 eur la hora y no digamos lo que se gastó mi colega llamando a algún número 807…”Lo estamos mirando”.
Para colmo de la mala suerte, el cliente tenía contratado un servicio de backups para las bases de datos hacia otra máquina que falló, el problema es que no es ni mucho menos seguro que funcionen las bases de datos en un caso de “petazo” volviendo a poner las antiguas como estaban en el nuevo servidor, lo digo porque están como si fuera vía una “copia en caliente” o con el comando cp, no con un mysqldump que es lo suyo, pero se puede intentar hacer ese volcado en otro server o localmente y luego revertir el volcado y esperar a que funcione y si no chuta, a intentar reparar vía mysqlcheck o myisamchk las bases pero eso ya es otra historia…
¿Y dónde estaba Amen el Sábado y el Domingo? no sé, fuera de servicio (y de juego…)
Al final, llamaron el Lunes a las 10 am y llegaron a un acuerdo con mi colega para que le cambiaran a otro servidor más potente, un Core2 Duo y le dijeron que se ponían con la instalación del sistema…Le dieron varias opciones, todas con Plesk como panel de administración vía web y le aconsejé lógicamente que le metieran Debian GNU/Linux.
“Nos ponemos con la instalación”
Le llaman otra vez por teléfono;
“Sr cliente, hay un problema con el script de instalación, no podemos instalar Debian pero podemos ofrecerle Ubuntu o Fedora”
Me lo cuenta y yo alucino y le digo que a una mala meta Ubuntu pero que no transija fácilmente y que si tiene que esperar que lo hiciera. Después le llamaron y le dijeron que lo habían solventado…WTF !
Se tiran todo el Lunes out y el sistema sin instalar hasta el Martes, día en el que por fin quedó todo listo. Me manda el password del root, entro y zas !, la primera en la frente, el esquema de particiones brillando por su ausencia o más bien por su escasez…Todo montado en la raíz /. No les da la cabeza para meter en particiones diferentes el home, var (ya no digo /var/log y var/lib/mysql), /tmp o las webs /www pero es algo que no sólo lo hace Amen.
No os cuento nada de la configuracion por defecto del S.O, Apache o mysql…
No os enrollo más porque no acabaría dando detalles y más detalles ¿Cómo acabó la historia?, al final tuve suerte con la recuperación / restauración y más o menos todo está funcionando bajo Debian y Plesk 8 (El Plesk y estos paneles de administración vía web digo que son un “mal necesario” por la cantidad de porquería que meten en el sistema y como se medio apoderan de el, pero algo muy útil para usuarios que no sepan de sistemas) con algún tema que está dando guerra.
Viendo el resultado final, lo mínimo para lo que podía haber sido, todas las bases estan chutando y los 60 gigas de datos replicados al nuevo servidor. Quedan cosas por afinar, servicios por asegurar etc, pero de verdad, desde luego que no será porque Amen se ha molestado por su cliente...
De todos modos, en una ocasión ya opiné sobre los peligro de un servidor web dedicado mal administrado vía Plesk, Cpanel, DirectAdmin o similar sin meterte vía SSH a actualizar-monitorizar-optimizar el sistema. Lo siento por Amen, pero van dos y puede que alguno de vosotros haya pasado por lo mismo e imagino que te puede hacer de todo menos gracia.
Se me olvidaba, ese servidor para mi colega es su medio de trabajo...No se ha ido de Amen porque en Enero firmó un contrato hasta el mismo mes de 2.010. Está bien dar una segunda oportunidad a la gente, ya que como he dicho en el comienzo del post, no todo será malo pero creo que es bueno saber con lo que puedes contar llegado ese momento que por cierto, tarde o temprano, nos puede sobrevenir a todos.
Pero creo que lo peor fue en una situación como esta, no recibir una verdadera opinión – actuación profesional por parte de una empresa que se entiende y de hecho asi es, sabe de todo esto mucho más que yo.
Tags: Amen, Cpanel, Debian, GNU/Linux, hosting, ISP, MySQL, Plesk, Software, SSH, Ubuntu
En el libro “Seguridad por niveles” (Con licencia Copyleft) se da un excelente repaso a lo que alguien interesado en redes o seguridad informática puede necesitar, desde las capas más bajas del sistema (Modelos OSI, DARPA, etc) a las más altas, desgranando el protocolo TCP-IP, pasando por el análisis de tráfico de red (algo que hace muy bien nuestro gran colaborador y redactor de Daboweb Alfon de “Seguridad y Redes“) con herramientas como Wireshark, tcpdump, etc además de introducirnos en el mundo de los “sniffers”. Hablando de estos temas, puedes ver el gran trabajo que está realizando Alfon en Daboweb desde este enlace con su saga “Análisis de capturas de Red“.
Lo primero que os recomiendo antes de empezar a leer esta entrada, es dar un vistazo (los asiduos a DaboBlog ya lo conoceréis) a 
Alguna vez tengo que conectarme a un host remoto 
Viendo la lista de correo de Security Focus, me he encontrado con esta información muy interesante sobre el análisis de los intentos de ataque a SSH a un servidor.
