Tres veces «parecía configurado»: verificar leyendo el resultado, no asumiendo

En el homelab hay dieciocho errores documentados. La mayoría son distintos entre sí. Tres no: son el mismo error con tres caras, y a la tercera dejó de ser casualidad.

El patrón es este: ejecutas un comando para configurar algo, el comando no da error, das el cambio por hecho, y el sistema se queda aparentando estar configurado sin estarlo. No se rompe nada en el momento. Se rompe días después, o no se rompe nunca porque la protección que creías tener no llega a probarse.

Caso 1: ip_forward volvió a cero solo

Activé el reenvío de paquetes en el host para que Tailscale pudiera enrutar hacia las VLAN. Lo hice con sysctl -p en caliente y funcionó. Días después, tras varios reinicios por el rediseño de la red, el acceso remoto a la VLAN de laboratorio empezó a dar timeout. La ruta estaba anunciada y aprobada, el host llegaba a la máquina, las reglas del cortafuegos eran correctas.

sysctl net.ipv4.ip_forward
# 0  <- este es el problema

La línea nunca había quedado escrita en /etc/sysctl.conf. sysctl -p aplicó lo que había en el momento; un reinicio restauró el valor por defecto del kernel, en silencio, y no se notó hasta que hizo falta esa ruta en concreto.

Caso 2: la regla de udev que no se habría disparado jamás

El disco externo se dormía. hdparm -B 255 -S 0 lo arregla, pero se pierde al reconectar, así que hace falta una regla de udev que lo reaplique cada vez que el disco aparece. El primer intento filtraba por el fabricante:

ENV{ID_SERIAL}=="*Verbatim*"

Parece razonable. Pero ID_SERIAL reporta el disco interno real, un Toshiba, no la carcasa; la cadena «Verbatim» solo aparece en ID_USB_SERIAL:

ID_SERIAL=TOSHIBA_DT02ABA600_…
ID_USB_SERIAL=Verbatim_Desktop_HDD_3.0_…

Esa regla se habría quedado en el sistema para siempre, aparentando estar configurada, sin ejecutarse ni una vez. El disco habría seguido durmiéndose y yo habría buscado la causa en cualquier otro sitio.

Caso 3: el sed que editó un comentario

Para que el thin pool de LVM se autoextienda hay que cambiar un umbral en /etc/lvm/lvm.conf. Lancé un sed que buscaba thin_pool_autoextend_threshold = 100 y lo sustituía por 80. Se ejecutó sin error y no cambió nada útil: en ese fichero todas esas líneas están comentadas, porque son la documentación integrada, no configuración activa. El sed modificó una línea de ejemplo dentro de un comentario.

Solo revisando el fichero con grep se vio que todas las coincidencias empezaban por #. La solución fue localizar la sección activation real e insertar las líneas dentro, y comprobar después con lvs que el fichero seguía bien formado.

El patrón

Los tres comandos «funcionaron». Ninguno mintió: hicieron exactamente lo que se les pidió. Lo que falló fue la suposición de que lo pedido era lo que yo quería.

El hábito que los detecta todos

Después de configurar algo, verificar leyendo el resultado, no asumiendo que el comando hizo lo que parecía. sysctl net.ipv4.ip_forward después de sysctl -p. grep sobre el fichero después de sed. Leer las propiedades reales del dispositivo antes de escribir la regla.

Y cuando se trata de un automatismo, la prueba definitiva es otra: forzar el estado contrario y comprobar que se revierte. Con el disco:

hdparm -B 128 /dev/sda           # forzar a mano el estado contrario
udevadm trigger --action=change /dev/sda
sleep 2
hdparm -B /dev/sda               # si la regla funciona: off

Devolvió off. Eso demuestra que la regla se ejecuta de verdad, no que el valor simplemente siguiera como estaba. Es la diferencia entre observar una coincidencia y demostrar una causa, y es una prueba que cuesta diez segundos.

Lo apunto porque el patrón no es de Linux ni de homelabs. Es de cualquier sistema donde un cambio se aplica en un sitio y se lee en otro: variables de entorno, ficheros de configuración con valores por defecto comentados, migraciones que «se ejecutaron», permisos que «se dieron». Si no lo has leído después, no lo sabes.