Cómo configurar software de apagado automático con UPS y NUT

Contar con un SAI o UPS y no tener bien configurado el software de apagado automático es como llevar cinturón de seguridad desabrochado: parece que te protege, pero en el momento crítico no hará su trabajo. Si has llegado hasta aquí, seguramente buscas una forma fiable de que tus servidores, tu laboratorio de virtualización o tus equipos domésticos se apaguen de manera ordenada cuando se vaya la luz.

En este artículo vamos a ver cómo configurar un sistema de apagado automático con un UPS usando herramientas de software, con especial foco en Network UPS Tools (NUT) sobre Linux/Raspbian, pero también comentando alternativas y casos reales como los típicos APC Smart-UPS que ya no tienen soporte oficial de ciertas soluciones para VMware. La idea es que, al terminar de leer, tengas claro qué opciones tienes, cómo montarlo paso a paso y cuáles son los puntos clave para que no te pille un corte eléctrico con el pie cambiado.

Por qué necesitas un apagado automático con tu UPS

Muchos usuarios compran un SAI pensando solo en tener unos minutos de autonomía, pero se olvidan de que el verdadero valor está en automatizar el apagado seguro cuando la batería comienza a agotarse. Sin ese paso, tus máquinas virtuales o servidores pueden apagarse de golpe, con el consiguiente riesgo de corrupción de datos.

En entornos de laboratorio con hosts ESXi, clústeres o equipos con varias VMs, lo ideal es que el UPS envíe la señal de que está en batería y el software coordine un apagado ordenado: primero máquinas virtuales críticas, luego servicios secundarios y, por último, los propios hosts. Cuando el fabricante deja de soportar su propio software (como pasó con algunas soluciones de apagado de red para VMware), toca buscar alternativas.

Qué es Network UPS Tools (NUT) y por qué se usa tanto

NUT es un conjunto de herramientas de código abierto pensado para gestionar Sistemas de Alimentación Ininterrumpida (SAI/UPS) en sistemas tipo Unix y Linux. Incluye drivers, demonios y utilidades de monitorización que permiten leer el estado del SAI, reaccionar ante eventos y orquestar apagados automáticos.

Uno de sus grandes puntos fuertes es que ofrece un modelo maestro/esclavo: un equipo actúa como servidor NUT conectado físicamente al UPS (normalmente por USB o serie) y uno o varios clientes se conectan a él por red para leer el estado y tomar decisiones de apagado. Así puedes tener, por ejemplo, una Raspberry Pi gestionando el SAI y varios servidores Windows conectados como esclavos.

Además, NUT es muy apreciado por su amplia compatibilidad de hardware. Soporta muchos fabricantes y modelos distintos: APC, Salicru, Eaton, CyberPower y un largo etcétera. Aun así, siempre es recomendable consultar la Hardware Compatibility List de su web oficial antes de lanzarse, para confirmar que tu modelo concreto está soportado.

Otro aspecto interesante es que, al ser software libre bajo licencia GPL, se mantiene activo y bien cuidado. Recibe mejoras, correcciones y drivers nuevos con frecuencia, algo especialmente útil frente a soluciones propietarias que los fabricantes pueden abandonar de la noche a la mañana.

Ventajas e inconvenientes de usar NUT como software de apagado automático

Antes de entrar en comandos y archivos de configuración, conviene tener clara la lista de pros y contras de NUT para valorar si encaja en tu escenario o si te merece la pena mirar alternativas comerciales.

Ventajas principales de NUT

Una de las grandes bazas de NUT es la monitorización remota centralizada y la posibilidad de complementarla con políticas de energía avanzadas. Desde un único servidor puedes ver el estado de uno o varios SAI: nivel de carga, porcentaje de batería, tiempo estimado restante, eventos recientes, etcétera. Esto simplifica mucho la supervisión en redes con varios equipos.

También destaca por su capacidad de gestionar múltiples UPS desde la misma instalación. Puedes empezar con un único SAI doméstico y escalar a configuraciones más complejas con varios dispositivos en distintos racks o salas, manteniendo la misma lógica de notificaciones y apagados automáticos.

Otro punto a su favor es la automatización de acciones. NUT permite definir qué debe pasar en cada evento: al irse la luz, al entrar en batería baja, cuando se pierde comunicación con el SAI, etc. Lo habitual es lanzar apagados ordenados de servidores, pero también puedes ejecutar scripts personalizados, apagar ciertos servicios o mandar avisos antes de que se corte todo.

En lo referente a notificaciones, NUT ofrece una base muy flexible. Con el script adecuado puedes enviar emails, SMS o notificaciones push a apps de terceros. De serie se suele usar correo electrónico, pero con integraciones con Twilio, Pushover, Slack, Telegram o sistemas de monitorización como Nagios o Zabbix, las opciones se multiplican.

Por último, hay que destacar que es una solución ligera en consumo de recursos. Incluso en hardware modesto o antiguo, como una Raspberry Pi de generaciones previas, el impacto en rendimiento es mínimo, lo que la hace ideal para dejarla funcionando 24/7 sin preocuparte por el consumo.

Inconvenientes y puntos delicados de NUT

La principal desventaja es que su configuración inicial no es trivial. No hay un asistente gráfico sencillo; todo se hace mediante archivos .conf en /etc/nut/. Requiere cierto nivel técnico y leer bien la documentación, sobre todo si mezclas varios modelos de SAI o entornos con muchos clientes.

También existe una cierta dependencia de la red cuando usas el modelo maestro/esclavo. Si la red falla o hay problemas de conectividad justo durante un corte eléctrico, los equipos esclavos podrían dejar de recibir información del UPS y no ejecutar el apagado como se espera, salvo que tengan mecanismos de respaldo locales.

En el plano de seguridad, al exponer el daemon de NUT por red, hay que ir con cuidado. Si no configuras bien usuarios, contraseñas y restricciones de acceso, el sistema podría ser vulnerable a accesos no autorizados, con el riesgo obvio de que alguien apague equipos críticos de forma remota.

Por último, aunque la comunidad es muy activa, no deja de ser una herramienta de código abierto con soporte comunitario. No vas a tener un teléfono de soporte comercial 24/7 como en ciertas soluciones propietarias, lo que puede ser un hándicap si la van a administrar personas con poca experiencia.

Escenario típico: UPS APC, VMware y alternativas cuando falta el software oficial

Un caso muy habitual hoy en día es el de quien compra un APC Smart-UPS para proteger un laboratorio de virtualización con varios hosts ESXi y descubre que el fabricante exige una tarjeta de gestión adicional para usar su solución de apagado en red. Y, para rematar, resulta que el software de apagado para VMware está descontinuado o ya no soporta las versiones más recientes del hypervisor.

En ese contexto, tiene sentido buscar una solución independiente del fabricante que te permita configurar el apagado de forma flexible. Aquí es donde entra NUT como intermediario: conectas el APC por USB a una máquina Linux (por ejemplo, una Raspberry Pi o un pequeño servidor) y usas ese sistema como «cerebro» que detecta eventos y desencadena apagados en el resto de máquinas.

Para los hosts ESXi hay varias estrategias: desde usar scripts remotos que envían comandos de apagado a las VMs y al host, hasta apoyarte en una máquina virtual de gestión que, cuando recibe la alerta de NUT, apaga ordenadamente todo el entorno. No es tan plug and play como el software original del fabricante, pero te permite recuperar el control incluso con productos que ya no tienen soporte oficial.

La idea general es la misma en todos los casos: un equipo de control monitoriza el UPS, detecta estados de batería y, en caso de riesgo, orquesta el apagado suave de todos los sistemas implicados, ya sean físicos o virtuales.

Usar una Raspberry Pi con NUT como servidor maestro del UPS

Un montaje muy popular es usar una Raspberry Pi con Raspbian como servidor maestro de NUT. Este enfoque tiene varias ventajas claras: la Pi consume muy poca energía, puede estar encendida permanentemente, es barata y, además, te permite personalizar notificaciones, integraciones y scripts sin depender del sistema principal que protege el UPS.

La arquitectura es sencilla: conectas el SAI a la Raspberry por USB o puerto serie, instalas NUT desde los repositorios oficiales y configuras los distintos archivos .conf para definir el driver, el modo de funcionamiento (standalone, master, slave), los usuarios y las acciones de apagado. Después, puedes añadir equipos esclavos que consulten el estado del UPS a través de red.

Antes de nada conviene revisar la compatibilidad del modelo de UPS con NUT. En el caso de un SAI Salicru SPS SOHO+ 1400VA, por ejemplo, se emplea el driver blazer_usb con puerto auto, pero cada modelo puede requerir un driver distinto, así que es buena idea comprobar la documentación oficial o la lista de hardware soportado.

Instalación de NUT en Raspbian

La instalación es muy directa porque el paquete está disponible en los repositorios estándar. Basta con ejecutar el siguiente comando como superusuario para instalar el software base junto con sus dependencias:

sudo apt-get install nut

Tras la instalación, es importante confirmar que se ha creado correctamente el usuario y grupo “nut”, ya que serán los que utilicen los demonios de NUT para interactuar con el hardware y gestionar los servicios. Si por alguna razón no se crean, habría que añadirlos manualmente.

Archivos de configuración básicos en /etc/nut/

La configuración de NUT se realiza principalmente en /etc/nut/, donde se encuentran varios archivos .conf. A continuación se resumen los más importantes y el papel que juegan en una configuración típica con la Raspberry como maestro:

En primer lugar está nut.conf, donde se define el modo general de operación. En una configuración sencilla de un único equipo que controla el SAI y se encarga de su propio apagado, se suele usar:

MODE=standalone

Después encontramos ups.conf, el archivo donde se declara el UPS y el driver que se va a usar. Para el caso del Salicru citado, la configuración de ejemplo sería:


driver = blazer_usb
port = auto
desc = "SAI Salicru"

El archivo upsd.conf controla el comportamiento del daemon que escucha las peticiones de los clientes NUT. Incluye parámetros como el tiempo máximo de antigüedad de los datos o el número máximo de conexiones. Un ejemplo típico sería:

MAXAGE 15
MAXCONN 1024
LISTEN 127.0.0.1 3493
LISTEN ::1 3493

Para definir cómo se monitoriza el SAI y qué hacer en caso de eventos, se usa upsmon.conf. Aquí se indica qué UPS se vigila, el usuario con el que se autentica, el comando de apagado del sistema y muchos parámetros de temporización y notificación. Un fragmento representativo podría ser:

MONITOR salicru@localhost 1 nonmaster contraseña master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
NOTIFYCMD /bin/upssched-cmd
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC
NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC
NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC
NOTIFYFLAG NOPARENT SYSLOG+WALL+EXEC
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

En upsd.users se definen los usuarios autorizados a interactuar con el daemon NUT, sus contraseñas y qué acciones pueden realizar. Un ejemplo sencillo sería:


password = contraseña
actions = set
instcmds = ALL
upsmon master

Por último, upssched.conf se encarga de relacionar eventos de NUT con acciones concretas que ejecuta el script de programación. Aquí se definen timers, comandos y la tubería que se usa para comunicar los eventos. Un trozo típico podría ser:

CMDSCRIPT /bin/upssched-cmd
PIPEFN /var/run/nut/upssched/upssched.pipe
LOCKFN /var/run/nut/upssched/upssched.lock
AT COMMOK * EXECUTE notify
AT COMMBAD * EXECUTE notify
AT REPLBATT * EXECUTE notify
AT NOCOMM * EXECUTE notify
AT FSD * EXECUTE forced-shutdown
AT NOPARENT * EXECUTE notify
AT SHUTDOWN * EXECUTE notify
AT ONLINE * CANCEL-TIMER shutdown
AT ONLINE * EXECUTE resume
AT ONBATT * START-TIMER shutdown 60000
AT ONBATT * EXECUTE shutdown-warning
AT LOWBATT * START-TIMER shutdown
AT LOWBATT * EXECUTE shutdown-warning

El papel del script upssched-cmd en el apagado automático

Todo lo anterior cobra sentido cuando entramos en el archivo /bin/upssched-cmd, que es el script encargado de ejecutar las acciones concretas asociadas a cada evento: enviar correos, relanzar drivers, iniciar apagados o simplemente escribir registros en el sistema de logs.

El script suele estar escrito en shell y utiliza la variable de entorno NOTIFYTYPE para saber qué evento de NUT se ha producido. En función de ese valor, construye un mensaje y lo envía por email, además de registrar el evento en syslog. Ejemplos de eventos que se contemplan son:

• ONLINE: el equipo vuelve a funcionar con suministro eléctrico normal.
• ONBATT: se ha cortado la luz y el UPS está usando batería.
• LOWBATT: el nivel de batería es bajo y se acercan apagados inminentes.
• FSD (Forced Shutdown): se fuerza el apagado del equipo.
• COMMOK / COMMBAD: se restablece o se pierde la comunicación con el UPS.
• REPLBATT: indica que la batería debe ser sustituida.
• NOCOMM / NOPARENT: el UPS no está disponible o no se puede delegar el apagado.

Un detalle práctico es que, en algunos casos como COMMBAD o NOCOMM, el script puede intentar reiniciar el driver del UPS con un comando tipo:

upsdrvctl start salicru

Además de tratar los eventos, el script suele aceptar parámetros adicionales que definen acciones específicas, como “shutdown-warning”, “shutdown”, “resume” o “forced-shutdown”. En función del parámetro, construye mensajes diferentes y puede llegar a ejecutar comandos como:

shutdown -p now o shutdown -h 100

Al final del script, es habitual que se escriba el mensaje generado en el syslog del sistema mediante una línea del estilo:

logger -t upssched-cmd "${_message}"

De este modo, todos los eventos quedan registrados y se pueden revisar a posteriori para depurar fallos o comprobar el comportamiento durante cortes eléctricos reales.

Comprobaciones, logs y resolución de problemas con NUT

Una vez configurados los archivos y el script, conviene hacer algunas pruebas de funcionamiento antes de dar por bueno el sistema. Un paso sencillo es reiniciar el sistema operativo para asegurarte de que todos los servicios de NUT arrancan bien al inicio.

Un comando muy útil para verificar que el driver del UPS arranca sin problemas es:

upsdrvctl start salicru

Si este comando falla, lo primero que hay que hacer es mirar los logs del sistema filtrando por NUT o por mensajes relacionados con el UPS. Una forma rápida de hacerlo es:

tail -f /var/log/syslog | grep ups

Ahí suelen aparecer errores típicos de puerto USB ocupado, permisos insuficientes, modelo no soportado, problemas con el driver elegido, etc. Si se detecta un fallo de driver, se puede probar a reinstalar NUT o a usar un driver alternativo soportado para ese modelo, revisando la documentación de compatibilidad. También es importante comprobar que el UPS está encendido y correctamente conectado.

En el caso de Raspbian, conviene revisar que el kernel reconoce el dispositivo cuando se conecta por USB. Comandos como lsusb o dmesg pueden dar pistas si el sistema ni siquiera detecta el hardware.

Clientes esclavos, integraciones y otros sistemas operativos

Una vez que tu servidor maestro NUT está estable, puedes añadir clientes esclavos en otros equipos de la red. En Linux, basta con instalar el cliente de NUT y apuntar la configuración a la IP del servidor maestro, autenticar con el usuario definido en upsd.users y configurar upsmon para que ejecute su propio apagado cuando reciba señales de batería baja o eventos FSD.

En sistemas Windows puedes recurrir a herramientas como WinNUT, que actúan como cliente para conectar con el servidor NUT y leer el estado del SAI. Desde ahí se puede configurar el apagado automático del equipo Windows cuando el servidor maestro indique que la batería se está agotando.

NUT también cuenta con ports e instalaciones en macOS, normalmente a través de gestores de paquetes como Homebrew (por ejemplo, con un comando tipo “brew install nut”). Sin embargo, en macOS el soporte de drivers USB puede ser más limitado, por lo que no siempre es tan directo como en Linux.

En cuanto a Windows, aunque hay maneras de hacer funcionar NUT, en muchas ocasiones es más práctico recurrir a soluciones específicas del fabricante como APC PowerChute para entornos puramente Windows, siempre que el producto siga con soporte activo.

Notificaciones avanzadas e integración con sistemas de monitorización

Una de las partes más potentes (y menos explotadas) de NUT es la personalización de notificaciones. El script upssched-cmd no tiene por qué limitarse a enviar emails; también puede integrarse con APIs externas para mandar SMS mediante servicios como Twilio, o notificaciones push con Pushover o Pushbullet.

Además, NUT se integra bastante bien con plataformas de monitorización como Nagios, Icinga, Zabbix o Prometheus a través de plugins o scripts personalizados. Gracias a esto, los avisos de batería baja, cortes de luz o fallos de comunicación pueden llegar a tus canales habituales: Slack, Telegram, paneles gráficos, etc.

La clave está en aprovechar las llamadas desde upssched-cmd para lanzar los scripts adecuados o hacer peticiones HTTP a los endpoints de tus servicios de alerta. De este modo, cualquier evento crítico del SAI será visible en el mismo ecosistema donde ya controlas el estado del resto de tu infraestructura.

Buenas prácticas de seguridad al exponer NUT en red

Como cualquier servicio accesible por red, el daemon de NUT debe configurarse pensando en la seguridad desde el primer momento. No olvidemos que, en última instancia, puede ejecutar apagados de máquinas críticas, así que más vale ir con cuidado.

La primera capa de protección es usar usuarios y contraseñas robustas en el archivo upsd.users, evitando claves triviales o compartidas con otros servicios. También es recomendable restringir los permisos de cada usuario a lo necesario: no todos necesitan ejecutar comandos de administración.

En upsd.conf es buena idea limitar las direcciones que pueden conectar al daemon usando directivas como LISTEN apuntando solo a IPs concretas, o dejando el servicio accesible únicamente desde la red de gestión. Combinado con reglas de firewall, se puede reducir mucho la superficie de ataque.

En entornos donde la seguridad sea crítica, puede plantearse compilar NUT con soporte para SSL/TLS y cifrar las conexiones entre maestro y esclavos, especialmente si pasan por redes no confiables. Y como siempre, revisar regularmente los logs para detectar intentos de acceso no autorizados o comportamientos extraños.

Finalmente, conviene mantener el sistema operativo y NUT actualizados, aplicando parches de seguridad y nuevas versiones del software cuando se publiquen, para reducir el riesgo de vulnerabilidades conocidas.

Contar con un UPS es solo la mitad del trabajo; la otra mitad consiste en montar un software de apagado automático bien afinado que combine herramientas como NUT, una Raspberry Pi ligera, clientes esclavos en los distintos equipos y una buena estrategia de notificaciones y seguridad. Siguiendo una configuración cuidadosa de los archivos en /etc/nut/, afinando el script upssched-cmd y monitorizando los logs, es posible tener un sistema sólido que responda rápido ante cortes de energía, proteja tus datos y te dé margen de maniobra incluso cuando el fabricante ha dejado de ofrecer soporte oficial para tu entorno.