← Volver al blog devops

El MOTD de SSH que terminó siendo un dashboard vivo de mi servidor

23 de agosto de 2026 · Rodolfo Ulloa
El MOTD de SSH que terminó siendo un dashboard vivo de mi servidor
devopsinfraestructurabashautomatizaciondesarrollo de software

El mensaje que nadie lee

Cada vez que uno hace ssh a un servidor Debian, aparece ese bloque de texto gris con la versión del sistema, cuántos paquetes tienen actualizaciones pendientes y, si tienes suerte, la carga promedio del último minuto. Es el MOTD (message of the day), y la inmensa mayoría de la gente lo ignora — yo incluido, durante meses. Es información genérica, la misma que te daría cualquier servidor Debian del planeta.

El problema es que ese momento, justo al conectarte, es exactamente cuando más contexto necesitas: ¿está arriba Home Assistant? ¿el túnel de Cloudflare sigue enrutando bien? ¿algún contenedor se cayó mientras dormías? En vez de seguir mostrando datos que no dicen nada sobre mi infraestructura real, decidí hacer que el MOTD respondiera esas preguntas.

Cómo funciona el MOTD en Debian

Debian no genera el mensaje con un solo archivo estático. Lo compone ejecutando, en orden numérico, todos los scripts ejecutables dentro de /etc/update-motd.d/ — cada uno imprime su propio bloque y el resultado se concatena. Eso significa que agregar una sección propia no es un hack: es exactamente el mecanismo para el que existe ese directorio. Basta con dejar un script ejecutable ahí, con un número de orden que decida en qué posición aparece.

De texto estático a estado real

Mi servidor no expone ningún puerto directamente: todo pasa por un único Cloudflare Tunnel que enruta cada subdominio de ulloa.cc a un contenedor Docker distinto. Esa configuración vive en un archivo de cloudflared con las reglas de ingress — qué hostname va a qué servicio interno. Así que el script del MOTD hace algo simple:

Algo así, simplificado:

#!/bin/bash
# /etc/update-motd.d/50-tunnel-status
echo "Estado de servicios (Cloudflare Tunnel):"
for host in $(grep -oP 'hostname:\s*\K\S+' /etc/cloudflared/config.yml); do
  service=$(echo "$host" | cut -d. -f1)
  if docker ps --format '{{.Names}}' | grep -q "^${service}$"; then
    echo "  ✅ $host"
  else
    echo "  ❌ $host (contenedor caído)"
  fi
done

Nada sofisticado — ni necesita serlo. La gracia no está en la complejidad del script sino en dónde aparece: en la pantalla que ya vas a ver de todas formas, sin tener que abrir Grafana, Netdata ni acordarte de qué dashboard mirar primero.

Observabilidad de bolsillo

Esto conecta con algo que aplica igual en un servidor casero que en un entorno corporativo: la mejor información de estado no es la más completa, es la que llega en el momento en que la necesitas sin que tengas que ir a buscarla. En Renta 4 pasa lo mismo con dashboards de guardia — el que sirve de verdad es el que un ingeniero de turno ve en los primeros cinco segundos, no el que tiene más métricas.

Un script en update-motd.d es la versión más pequeña posible de esa idea: cero infraestructura adicional, cero dependencias nuevas, solo aprovechar un mecanismo que Debian ya trae y que casi nadie toca.

Un uso concreto de IA en esto

Vale la pena mencionarlo porque es real, no una moraleja forzada: escribí la primera versión de este script con ayuda de un asistente de código basado en LLM, principalmente para no tener que recordar la sintaxis exacta de grep -oP con lookaheads. La parte de decidir qué mostrar, cómo cruzar la config del túnel con el estado de Docker y qué información es realmente útil en ese contexto — eso sigue siendo trabajo de entender tu propia infraestructura. La IA acelera la fricción mecánica de escribir bash; no reemplaza el criterio de qué merece estar en la pantalla que ves cada vez que entras a tu propio servidor.