El servidor estaba vivo, pero no contestaba

Un servidor puede pasarse meses sin pedirte absolutamente nada. Arranca, sirve, actualiza, rota los registros y no dice ni buenos días.

Estoy fuera. Y hoy, precisamente hoy, uno de los que administro decide que necesita una placa base nueva.

No una actualización. No un reinicio. Una placa base. De las que hay que cambiar con las manos.

Así que saco el portátil, que me acompaña vaya donde vaya precisamente por esto: no por trabajar de vacaciones, sino porque un fuego como este se apaga desde cualquier sitio con una conexión decente y sin él no se apaga desde ninguno.

Aquí vive la historia entera. Los puertos de red van soldados a la placa, y en las pegatinas blancas de la derecha viene impresa su MAC: cuando se cambia la placa, se cambian con ella. No es el servidor del artículo, es una Supermicro X10SLM+-LN4F. Foto: Phiarc, CC BY-SA 4.0, vía Wikimedia Commons; imagen recortada y disponible bajo la misma licencia.

Lo que hace el proveedor

El aviso es de OVHcloud y es de los buenos: han detectado un problema de hardware en la placa base y van a intervenir físicamente en la máquina.

Lo que hacen es exactamente lo que uno querría que hicieran:

• Sustituyen la placa base.
• Actualizan el firmware.
• Como consecuencia del cambio de placa, cambian las direcciones MAC de las interfaces de red.
• Dejan el servidor arrancado en Rescue Mode.
• Y me avisan de que, antes de volver al arranque normal, tengo que actualizar las MAC en el sistema.

Ese último punto es el que convierte una intervención de hardware en un trabajo mío. El proveedor ha hecho su parte: la máquina física está sana. Lo que hay dentro del disco es asunto de quien lo puso ahí.

Y lo que hay dentro del disco, esta vez, tenía una opinión muy concreta sobre qué tarjeta de red debía existir.

Una nota breve sobre Murphy, y sigo

Esto inaugura una serie, así que toca presentar al personaje. Poco, que tampoco es un documental.

Edward A. Murphy Jr. era capitán e ingeniero aeronáutico de la Fuerza Aérea estadounidense y hacia 1949 pasó por el proyecto MX981, en la base de Muroc —hoy Edwards—: un trineo cohete con el que se medía cuánta deceleración aguanta un cuerpo humano. Unos sensores dieron lectura cero porque estaban cableados del revés. Y Murphy dijo algo.

Qué dijo exactamente es cosa discutida, y conviene decirlo. Según George E. Nichols, que estaba allí, fue un reproche a su ayudante: «si ese tipo tiene alguna manera de equivocarse, se equivocará». Según el hijo de Murphy, que niega esa versión, fue otra cosa: «si hay más de una forma de hacer un trabajo y una de ellas acaba en desastre, la hará así». No hay rastro documental conocido del término antes de 1951, así que conviene desconfiar de las versiones que lo presentan entrecomillado, con fecha exacta y como si no hubiera discusión.

Lo que sí está claro es cómo se hizo famosa. John Paul Stapp, el médico militar que dirigía el proyecto y que se subía él mismo al trineo, contestó en una rueda de prensa a por qué nadie se había hecho daño de gravedad: porque siempre tenían en cuenta la ley de Murphy. Es decir, porque se paraban a pensar de antemano todo lo que podía salir mal y actuaban en consecuencia. Un principio de diseño, no una queja.

De ahí a «si algo puede salir mal, saldrá mal» hay un buen trecho. Yo me quedo con la versión de Stapp, que además es la única útil, aunque para el título de una serie la fatalista funcione mejor.

Porque la serie va exactamente de esto: de las cosas que esperan a que me haya ido.

Primera pregunta: ¿siguen ahí los datos?

Entro en Rescue Mode. Que, para quien no lo haya usado nunca, es un Linux mínimo que el proveedor arranca por red, sin tocar tus discos. Tienes un sistema vivo desde el que mirar tu sistema muerto. Es la diferencia entre una avería y una catástrofe.

Y lo primero no es arreglar nada. Lo primero es saber qué ha sobrevivido, porque el orden en que uno se hace las preguntas determina lo nervioso que va a pasar la siguiente media hora.

La red física primero:

ip addr

La interfaz nueva está ahí, está UP y tiene una MAC que no había visto en mi vida. Perfecto: eso es exactamente lo que el proveedor me había anticipado. El hardware está donde tiene que estar.

Los discos después:

lsblk -f
cat /proc/mdstat

Los dos NVMe aparecen. Y el RAID —RAID 1 por software, los dos discos con el mismo contenido— dice lo único que quería leer:

[2/2] [UU]

Dos de dos. Las dos U son las dos mitades del espejo, y ambas están up. Ningún disco perdido, ningún array degradado, ninguna reconstrucción en marcha.

Primera buena noticia, y la grande: los discos están bien, el RAID está bien y los datos siguen ahí.

Con eso descartado, la pregunta que queda es la que de verdad tenía delante: si los discos y el sistema están sanos, ¿qué hay que cambiar aquí dentro antes de atreverse a devolver la máquina al arranque normal?

Montar y mirar

El siguiente paso es montar el sistema instalado desde el Rescue para poder leerlo. Y montarlo en solo lectura, que es una manía que recomiendo mucho: mientras no sepas qué está pasando, no le des al sistema ninguna oportunidad de cambiar.

mount -o ro /dev/md3 /mnt
cat /mnt/etc/os-release

Ahí está: Ubuntu 22.04 LTS. Su /etc, su /var, sus servicios, su Plesk. Todo intacto.

La red en Ubuntu 22.04 la gobierna Netplan, que no configura nada por sí mismo: lee unos YAML de /etc/netplan/ y a partir de ellos genera la configuración de quien sí la aplica, que en este caso es systemd-networkd. Es un traductor, no un demonio.

ls /mnt/etc/netplan/

Dos archivos:

10-plesk.yaml
50-cloud-init.yaml

Que haya dos no es raro: Netplan combina los YAML del directorio en orden lexicográfico, así que distintos ficheros pueden aportar partes de la configuración de una misma interfaz. Uno lo dejó Plesk y otro cloud-init, el mecanismo que configura la máquina la primera vez que arranca a partir de lo que le cuenta el proveedor.

Y en el de cloud-init estaba el asunto:

match:
    macaddress: XX:XX:XX:XX:XX:01

Esa MAC era la de la placa vieja. La tarjeta integrada de la placa nueva tenía otra:

XX:XX:XX:XX:XX:02

Un dígito de diferencia en un fichero de texto. Ahí estaba todo.

Vivo y, sin embargo, incomunicado

Esta es la parte que me interesa de verdad del artículo, más que los comandos.

Vamos a repasar el estado real de la máquina en ese momento. La placa era nueva y funcionaba. Los dos NVMe respondían. El RAID estaba sano. Ubuntu estaba instalado y entero. Los servicios seguían configurados. Los datos, todos.

Y aun así, devuelta al arranque normal tal cual, esa máquina habría parecido muerta desde fuera.

Porque una MAC es —simplificando— el identificador de una interfaz de red concreta. Normalmente viene grabado de fábrica en el propio hardware, aunque no es sagrado ni inmutable: se puede cambiar por software y hay motivos legítimos para hacerlo. Lo que importa aquí es de dónde viene: de la pieza. Y la pieza la habían cambiado.

Cuando le dices a Linux «esta configuración de red es para la tarjeta que tenga esta MAC», le estás dando una condición. Si esa condición deja de cumplirse, no ocurre un error escandaloso: simplemente no se aplica esa configuración. No falla nada, no se queja nadie; el bloque que describía cómo tenía que llegar esa máquina a Internet, sencillamente, ya no le correspondía a ninguna tarjeta.

Y ese es el resumen: Ubuntu podía arrancar, pero no con la red que necesitaba para que yo pudiera llegar hasta él.

El servidor habría arrancado estupendamente. Habría arrancado a un sitio donde no había nadie mirando.

Un sistema puede estar funcionando a la perfección y ser, al mismo tiempo, completamente inaccesible. Desde fuera las dos cosas se ven exactamente igual.

Y es un fallo especialmente incómodo de diagnosticar en frío, porque invita a suponer. Ante un aviso de intervención en el hardware, lo natural es imaginarse lo peor —un disco muerto, un sistema de ficheros roto, un arranque que no llega— y ponerse a arreglar eso. De suponer en vez de comprobar ya escribí hace unos días, y aquí la lección es la misma: los dos comandos que descartaron la catástrofe costaron treinta segundos y cambiaron por completo qué estaba buscando.

El arreglo

Con el diagnóstico hecho, el arreglo es corto. Pero conviene hacerlo despacio, porque estamos editando la configuración de red de una máquina a la que, si la dejamos mal, volveremos a acceder solo por Rescue Mode. La red no perdona los arreglos a medias: es la rama sobre la que estás sentado.

Primero, remontar en lectura/escritura y hacer una copia del YAML antes de tocarlo:

mount -o remount,rw /mnt
cp /mnt/etc/netplan/50-cloud-init.yaml /mnt/etc/netplan/50-cloud-init.yaml.bak

Después, sustituir exclusivamente la MAC antigua por la nueva. Nada más. No es momento de reordenar el YAML, ni de limpiar lo que sobra, ni de aprovechar el viaje.

Y luego comprobar que no queda ninguna otra referencia suelta a la MAC vieja:

grep -ri 'XX:XX:XX:XX:XX:01' /mnt/etc/

La única que quedaba era la de mi propia copia de seguridad, que es justo lo que esperaba. Netplan solo lee los ficheros *.yaml del directorio, así que un .yaml.bak le resulta invisible —aunque, puestos a ser ordenados, la copia está mejor fuera de /etc/netplan que dentro.

Entrar en el sistema instalado

Para que Netplan haga su trabajo hay que hablarle desde dentro del Ubuntu instalado, no desde el Rescue. Eso es un chroot: cambiar la raíz del sistema de ficheros para que, a partir de ese momento, / sea el disco del servidor. Antes hay que prestarle al inquilino cuatro directorios que no viven en el disco sino en el núcleo en marcha:

for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash

El /run no es opcional ni un adorno: es justo donde Netplan escribe lo que genera.

netplan generate, y el desvío de los permisos

Dentro ya:

netplan generate

generate es el comando correcto aquí, y la distinción importa. netplan apply intentaría aplicar la configuración a la red en marcha, y dentro de un chroot eso no tiene ningún sentido: la red que hay levantada es la del Rescue. generate se limita a traducir los YAML a ficheros de systemd-networkd y a decirte si tu configuración es válida. Es exactamente lo que quiero: validar ahora, aplicar al arrancar.

Y aquí apareció un desvío que no tenía nada que ver con la avería. Netplan se quejó:

Permissions for /etc/netplan/... are too open.

Los YAML estaban en 644, es decir, legibles por cualquier usuario del sistema. Que en un fichero de red no es una catástrofe, pero tampoco hace ninguna falta: ahí puede acabar habiendo credenciales de wifi o de túneles.

Esto no era la causa de nada. El servidor no se iba a quedar sin red por unos permisos; se iba a quedar sin red por la MAC. Pero ya que estaba allí:

chmod 600 /etc/netplan/*.yaml
netplan generate

Segunda pasada, sin errores y sin avisos. Uno de esos arreglos de treinta segundos que llevaban meses pendientes y que nunca haces porque nunca estás mirando ese directorio.

Comprobar antes de reiniciar

Lo último dentro del chroot es leer lo que Netplan ha escrito de verdad, que es lo único que va a leer systemd-networkd al arrancar:

cat /run/systemd/network/10-netplan-*.link

Y ahí estaba eno1 asociado a la MAC nueva. Detalle bonito: el nombre de la interfaz no había cambiado. En esta máquina el sistema le puso a la tarjeta de la placa nueva exactamente el mismo nombre que a la de la vieja, así que lo único que se movió fue la MAC. Por eso el fallo era tan silencioso: no había desaparecido nada ni cambiado de nombre nada, simplemente una condición había dejado de cumplirse.

Salir del chroot y desmontar en orden inverso —primero los prestados, luego el disco—, que es la parte aburrida y la que nadie cuenta:

exit
for d in run sys proc dev; do umount /mnt/$d; done
umount /mnt

Y el servidor listo para volver a arrancar desde disco.

Si alguna vez te pasa

Resumen práctico, tanto si el proveedor te ha dejado la máquina en Rescue con un aviso como si ya la has reiniciado y no responde:

1. Mira qué hardware ve realmente el sistema. ip addr desde el Rescue: qué interfaces hay, cómo se llaman y qué MAC tienen ahora.
2. Comprueba discos y RAID antes de dar nada por perdido. lsblk -f y cat /proc/mdstat. Saber que los datos están intactos cambia por completo cómo afrontas la siguiente hora.
3. Monta el sistema instalado en solo lectura. Mirar primero, escribir después.
4. Busca las referencias a la MAC antigua. Un grep -ri sobre /etc te dice si hay una o si hay cinco.
5. Cambia solo lo necesario. Copia de seguridad del fichero, sustitución de la MAC y nada más. No aproveches el viaje.
6. Valida antes de reiniciar. chroot y netplan generate; lee los ficheros generados y confirma que la interfaz queda asociada a la MAC nueva.
7. Y luego arranca, sabiendo que si algo sale mal vuelves al Rescue, que sigue estando ahí.

Con dos advertencias.

La primera: esto es mi caso concreto —Ubuntu 22.04 con Netplan y systemd-networkd, en un dedicado de OVHcloud—. Otras distribuciones gestionan la red de otra manera, y una configuración anclada a la MAC puede estar en un fichero de NetworkManager, en una regla udev de nombres persistentes o en el propio arranque por red. Lo que se traslada no es el comando, es la pregunta: ¿hay algo aquí dentro que apunte a una pieza que ya no existe?

La segunda, y esta vale la pena mirarla aunque no te haya pasado: si el fichero que ancla la MAC es de cloud-init, conviene comprobar si cloud-init va a volver a generarlo por su cuenta en el siguiente arranque. Sería bastante desmoralizante arreglarlo a mano y que reapareciera solo.

Y de vuelta al principio

El servidor quedó preparado para volver a arrancar desde disco. Los datos estaban donde los había dejado, que era lo único que de verdad importaba, y la explicación de la catástrofe aparente cabía en una línea de un fichero de texto: una condición que había dejado de cumplirse porque la pieza a la que apuntaba estaba en un contenedor de reciclaje.

Que es, mirándolo con calma, la versión buena de Murphy y no la fatalista. Nadie se equivocó aquí. El anclaje a la MAC lo escribió cloud-init porque en su momento era lo correcto, y siguió siendo correcto durante meses. Simplemente nadie —yo incluido— se había parado a pensar qué pasaba con ese fichero el día que cambiara el hardware debajo. Si una pieza puede dejar de encajar, alguna vez dejará de encajar.

Lo he apuntado. Junto a otras cuantas cosas que he ido revisando por el camino y que llevaban tiempo sin que nadie las mirase, incluidos unos permisos en 644 que ya no lo están.

Y sigo fuera, por cierto. Que es exactamente el punto de partida de esta serie: los servidores que administro parecen tener una preferencia estadística notable por los fines de semana, los puentes y los días en que estoy lejos del ordenador.

Los datos sobre el origen de la Ley de Murphy proceden de la entrada «Murphy's law» de la Wikipedia en inglés, que recoge la investigación de la American Dialect Society sobre el asunto. Conviene leerla con la misma prudencia con la que está escrita: la propia entrada advierte de que la asociación con el incidente de Muroc «no es segura en absoluto» y de que no se ha encontrado rastro documental de la expresión anterior a 1951. Las dos versiones de la frase proceden, respectivamente, del testimonio de George E. Nichols y del de Robert Murphy, hijo de Edward.