Antes de entrar empezar con la chicha, por si aún queda algún despistado, el sistema de ficheros ReiserFS ya no tiene soporte técnico por lo que es recomendable que los sistemas nuevos que se vayan a instalar no utilicen este sistema. El motivo es que su principal desarrollador, Hans Reiser, está cumpliendo condena por el asesinato de su mujer en la cárcel de San Quintín a la que asesinó en el año 2006.

El caso que nos ocupa, es que hace unos días uno de los servidores con los que trabajo empezó a hacer cosas realmente extrañas. El primer síntoma en mi caso, fue que el sistema no me permitía crear más de un subdirectorio dentro de un directorio concreto, mostrándome un mensaje como si ya existiera (y obviamente, comprobando que no era el caso).

Resultó increíblemente extraño y errático el hecho de que dependía de cuántas veces intentase esa operación, algunas me permitía y otras (la mayoría) me daba un mensaje de error como si ya existiese el fichero. Llegamos incluso a pensar si sería cosa del nombre de los subdirectorios, si sería de la cabina de almacenamiento o incluso (y sí, me avergüenza admitirlo) si podría ser por algún tipo de límite de subdirectorios en el propio ReiserFS.

Finalmente optamos por lo que era más evidente… lanzar un chequeo con la unidad desmontada, momento en que la gente de almacenamiento nos comunicó que ese mismo espacio lo estaba usando otro servidor, y es que resultó que una mente pensante con permisos de root (por lo que parece, aquí es lo normal) tenía la misma LUN montada en otro servidor.

Al hacer el chequeo con un fsck.reiserfs del dispositivo, obtuvimos el siguiente mensaje:

Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.
Fatal corruptions were found, Semantic pass skipped
2 found corruptions can be fixed only when running with --rebuild-tree

Finalmente y siguiendo las indicaciones, decidimos que lo mejor era hacer un backup (fiándonos de los datos que había antes) y jugárnosla a que ese –rebuild-tree no nos dejase un agujero considerable.

Destacar que el proceso de rebuild-tree consta de cinco pasos,  y que en hacer el rebuild de aproximadamente 600GB tardó más o menos 40 minutos.

Por unas historias que nos han surgido hoy en el trabajo y que explicaré en otro post, he necesitado regenerar las claves RSA del servidor OpenSSH y me he visto un poco apurado al no ser una Debian. En su lugar el servidor es una VM en la que corre una OpenBSD 4.5 así que dejo aquí el tip por si alguien más se ve en la misma situación… (hay que ver que mal acostumbrados estamos!)

Lo primero que debemos hacer es detener el demonio sshd. Aunque tampoco estoy demasiado seguro que este paso sea necesario, nunca está de más ya que así tampoco permitimos conexiones remotas a la máquina mientras hacemos nuestras labores (comentarios permitidos):

kill `cat /var/run/sshd.pid`


El anterior comando es el que he usado yo en OpenBSD… si estáis usando una distribución de Linux o Solaris, cada uno deberá emplear el sistema que corresponda. Una vez hayamos matado el proceso, lo siguiente será eliminar las claves públicas y privadas:

rm /etc/ssh/ssh_host_*


Ahora es cuando generamos las nuevas claves RSA y DSA:

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

En caso de que sólo vayamos a emplear SSH2 sería suficiente. Si por el contrario planeamos usar SSH1 deberíamos incluir también:

ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1


La explicación para dedicar una entrada a esta operación, es que al buscar en Google los términos generate, rsa, ssh, keys, etc… me salían mil páginas dedicadas a poner a Debian a caer de un burro por lo que todos sabemos (o deberíamos), y a explicar cómo subsanar el error, pero en Debian.

Mil gracias a Denis Gervalle y el site de OpenSSH.