En este artículo vamos a ver cómo permitir que Hermes pueda solicitar el apagado de un servidor Ubuntu, pero sin darle permiso directo para ejecutar comandos peligrosos como `shutdown`, `reboot`, `poweroff` o `halt`.
La idea nace de un escenario muy habitual en un homelab:
└── Ubuntu Server
└── Hermes
Hermes se ejecuta dentro de una máquina virtual Ubuntu Server, alojada en Proxmox. Por tanto, en principio, podríamos pensar que bastaría con pedirle a Hermes algo como:
Apaga Ubuntu dentro de 1 minuto
Sin embargo, aquí aparece un detalle importante: Hermes bloquea determinados comandos peligrosos de forma incondicional. Es decir, aunque el usuario tenga permisos de `sudo`, el propio agente puede impedir la ejecución directa de órdenes como:
sudo shutdown -h +1
Y esto, lejos de ser un problema, es una medida de seguridad bastante razonable.
El objetivo
Queremos conseguir algo sencillo como es pedirle a Hermes que apague Ubuntu Server en 1 minuto, por ejemplo.
Pero con una condición importante: Hermes no debe ejecutar directamente shutdown.
En su lugar, vamos a montar un pequeño mecanismo intermedio:
↓
Ubuntu detecta esa solicitud
↓
Un script controlado por root ejecuta el apagado
De esta forma, Hermes no tiene acceso directo al comando de apagado, pero sí puede dejar una petición controlada que el propio sistema validará.
Por qué no ejecutar shutdown directamente desde Hermes
La primera idea podría ser permitir a Hermes ejecutar:
sudo shutdown -h +1
Pero al probarlo, Hermes bloquea la orden con un mensaje similar a este:
No se ejecutó el apagado.
Esto significa que el bloqueo no viene de Ubuntu ni de `sudoers`, sino de la propia política de seguridad del agente.
Por tanto, la solución no consiste en darle más permisos a Hermes, sino en diseñar un flujo más seguro.
Solución propuesta
La solución consiste en que Hermes no apague directamente el servidor. En su lugar, solo creará un fichero de solicitud.
Por ejemplo:
/home/[USUARIO]/Hermes/control/solicitud_apagado.txt
Con este contenido:
apagar_ubuntu_1min
Después, un script del sistema revisará ese fichero. Si existe y contiene exactamente ese texto, programará el apagado de Ubuntu en 1 minuto.
Crear la carpeta de control
Primero creamos una carpeta donde Hermes pueda dejar sus solicitudes:
- mkdir -p /home/[USUARIO]/Hermes/control
Esta carpeta será el punto de comunicación entre Hermes y el sistema.
Crear el script de apagado
Ahora creamos un script que será ejecutado por el propio sistema, no directamente por Hermes.
- sudo nano /usr/local/sbin/hermes-control-apagado.sh
Contenido del script:
SOLICITUD="/home/[USUARIO]/Hermes/control/solicitud_apagado.txt"
if [ ! -f "$SOLICITUD" ]; then
exit 0
fi
CONTENIDO="$(cat "$SOLICITUD" | tr -d '\r\n')"
if [ "$CONTENIDO" = "apagar_ubuntu_1min" ]; then
rm -f "$SOLICITUD"
/usr/sbin/shutdown -h +1
fi
Guardamos el fichero y le damos permisos seguros:
- sudo chmod 700 /usr/local/sbin/hermes-control-apagado.sh
- sudo chown root:root /usr/local/sbin/hermes-control-apagado.sh
Con esto conseguimos que el script solo pueda ser modificado y ejecutado por `root`.
Prueba manual del script
Antes de automatizar nada, conviene probar que el script funciona.
Creamos manualmente el fichero de solicitud:
- echo "apagar_ubuntu_1min" > /home/[USUARIO]/Hermes/control/solicitud_apagado.txt
Y ejecutamos el script:
- sudo /usr/local/sbin/hermes-control-apagado.sh
Si todo está correcto, Ubuntu mostrará un mensaje parecido a este:
Shutdown scheduled for Mon 2026-06-01 13:57:30 UTC, use 'shutdown -c' to cancel.
Para cancelar el apagado:
- sudo shutdown -c
El sistema confirmará la cancelación:
System shutdown has been cancelled
Con esto ya tenemos validado el mecanismo principal.
Automatizar la revisión con systemd
Ahora vamos a crear un servicio y un timer de `systemd` para que Ubuntu revise automáticamente si Hermes ha solicitado el apagado.
Creamos el servicio:
- sudo nano /etc/systemd/system/hermes-control-apagado.service
Contenido:
Ahora creamos el timer:
- sudo nano /etc/systemd/system/hermes-control-apagado.timer
Contenido:
Activamos el timer:
- sudo systemctl daemon-reload
- sudo systemctl enable --now hermes-control-apagado.timer
Comprobamos que está activo:
- systemctl status hermes-control-apagado.timer
Y podemos ver cuándo será la próxima ejecución con:
- systemctl list-timers | grep hermes-control
Prompt para probarlo desde Hermes
Una vez configurado el sistema, podemos pedirle a Hermes que cree la solicitud de apagado.
El prompt utilizado fue:
No ejecutes shutdown, reboot, poweroff ni halt.
Crea únicamente este fichero:
/home/madiazg/Hermes/control/solicitud_apagado.txt
con este contenido exacto:
apagar_ubuntu_1min
No modifiques ningún otro fichero.
No ejecutes ninguna otra orden de apagado.
No intentes apagar Proxmox.
- si el fichero se ha creado correctamente
- la ruta del fichero
- el contenido escrito
Hermes respondió:
- Ruta del fichero: /home/madiazg/Hermes/control/solicitud_apagado.txt
- Contenido escrito: apagar_ubuntu_1min
A partir de ese momento, el timer de `systemd` detectó la solicitud y el sistema programó el apagado.
Cómo cancelar el apagado
Si queremos cancelar el apagado antes de que se produzca, basta con ejecutar:
sudo shutdown -c
Esto cancela el apagado programado.
Qué hemos conseguido
Con este sistema, Hermes puede solicitar el apagado de Ubuntu Server sin saltarse sus propias restricciones de seguridad.
El flujo final queda así:
↓
Hermes
↓
Crea solicitud_apagado.txt
↓
systemd ejecuta el script de control
↓
Ubuntu programa el apagado
La gran ventaja es que Hermes no ejecuta directamente comandos peligrosos. Solo crea un fichero con una orden muy concreta, y es el propio sistema quien decide si esa solicitud es válida.
Conclusión
Este pequeño truco permite integrar Hermes con tareas delicadas del servidor sin romper el modelo de seguridad del agente.
En lugar de forzar a Hermes a ejecutar comandos bloqueados, usamos un mecanismo intermedio mucho más controlado:
- Hermes solicita.
- Ubuntu valida.
- Root ejecuta.
Es una solución sencilla, limpia y bastante segura para un homelab, especialmente cuando queremos que Hermes participe en tareas de administración sin darle control absoluto sobre el sistema.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.