Cuando el servidor es tuyo y corre servicios que la familia usa todos los días —clima, cámaras, automatizaciones—, parchear seguridad deja de ser un trámite abstracto. Un apt upgrade mal calzado puede terminar en un reinicio a las 3 AM que tira abajo la calefacción programada. Así que en algún momento tuve que resolver una tensión bien concreta: quiero que las actualizaciones de seguridad se apliquen solas, pero no quiero sorpresas.
El punto de partida: unattended-upgrades
Debian trae unattended-upgrades para esto. La configuración vive en /etc/apt/apt.conf.d/50unattended-upgrades, y lo primero es limitar el origen a solo actualizaciones de seguridad, no todo lo que haya en el repo:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Con Automatic-Reboot en false me aseguraba de que nada se reiniciara solo. El problema es que eso tiene un costo silencioso: si un parche de kernel o de glibc queda pendiente de reinicio, el sistema sigue corriendo con las librerías viejas cargadas en memoria hasta que yo me acuerde de reiniciar manualmente. Es decir, cambié "reinicio sorpresa" por "parche a medias indefinido", que tampoco es gran cosa en seguridad.
Donde entra la conversación con la IA
Terminé usando un asistente de IA como caja de resonancia para pensar los flags, no para que me escribiera el archivo. Le pasé la config y le describí el contexto: contenedores Docker, uno de ellos —Home Assistant— corriendo en --network host por el tema de mDNS que ya me había dado dolores de cabeza antes.
La pregunta que me hizo pensar fue simple: si en algún momento activo Automatic-Reboot para que el kernel sí se actualice solo, ¿qué le pasa exactamente a un contenedor en modo host cuando el host se reinicia? La respuesta técnica no es sorprendente —Docker lo levanta de nuevo si tiene restart: unless-stopped— pero el ángulo que no había considerado fue el de timing: un reinicio automático en una ventana mal elegida corta la conexión de red host justo cuando Home Assistant está a mitad de una automatización (por ejemplo, un aire acondicionado recién encendido esperando confirmación del dispositivo). El contenedor vuelve, pero el estado intermedio de esa automatización se pierde.
La solución no fue complicada, pero no la tenía tan clara hasta ese momento: activar reinicio automático solo para actualizaciones de kernel, y fijarlo a una hora de bajísimo uso real de la casa:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
Lo que de verdad aporta la IA acá
No fue "generar el yaml". Fue tener con quién pensar en voz alta las interacciones entre subsistemas que uno normalmente revisa por separado: la documentación de unattended-upgrades por un lado, la de Docker networking por otro. Nadie escribe un doc que diga "ojo con combinar reinicio automático de kernel y contenedores en network host que corren automatizaciones con estado". Esa intersección específica solo aparece cuando alguien —humano o IA— conoce ambas piezas a la vez y las cruza para tu caso concreto.
Es el mismo patrón que usé para pensar la capa de seguridad del túnel: cada pieza por separado es simple, la complejidad real vive en cómo interactúan entre sí. Ahí es donde un asistente de IA rinde más que buscando "mejor práctica de X" en el buscador: no te da una receta genérica, te ayuda a razonar sobre tu combinación específica de piezas.
El resultado, sin exagerar
El servidor sigue parchando seguridad solo, todas las noches, y el kernel se actualiza sin que yo tenga que acordarme, en una ventana donde nadie va a notar que el aire acondicionado tardó dos minutos más en confirmar su estado. No es una hazaña de ingeniería, es la clase de detalle aburrido que evita el incidente aburrido de las 3 AM. Y esa es, en el fondo, la parte de DevOps que menos se cuenta: no automatizar lo espectacular, sino cerrar bien los bordes de lo que ya automatizaste.