- Network UPS Tools permite monitorizar y gestionar múltiples SAI con gran flexibilidad en sistemas Linux y Unix.
- La combinación de upsmon, upssched y scripts personalizados posibilita apagados automáticos ordenados y notificaciones avanzadas.
- En entornos ESXi, los scripts basados en SNMP y vSphere CLI cubren la falta de soluciones oficiales de apagado remoto.
- Es clave revisar la compatibilidad del UPS y equilibrar configuración, seguridad y autonomía del hardware para evitar fallos.
Cuando montas un laboratorio, un pequeño servidor casero o cualquier infraestructura con cierta importancia, configurar correctamente el apagado automático del sistema apoyado en un SAI/UPS deja de ser un capricho para convertirse en una necesidad. Un corte de luz mal gestionado puede corromper máquinas virtuales, dañar discos o dejar servicios críticos en un estado impredecible.
El problema viene cuando descubres que tu flamante SAI no hace de serie lo que dabas por hecho: apagar de forma ordenada tus equipos y encenderlos de nuevo cuando vuelve la corriente, ya sea en entornos Linux clásicos, con Raspberry Pi o en servidores ESXi. Aquí entran en juego tanto el hardware (el propio UPS y sus opciones de gestión) como el software (Network UPS Tools, scripts personalizados, SNMP, etc.).
Qué significa realmente configurar un apagado automático con un UPS
Antes de meternos en archivos de configuración y scripts, conviene aclarar qué esperamos de un sistema bien montado: el UPS debe mantener el equipo el tiempo justo, lanzar un apagado limpio y, si procede, cortar él mismo la salida para evitar quedarse en un estado de “siempre encendido” cuando ya no tiene sentido.
En el mundo real esto se complica. Muchos modelos, como algunos APC Smart-UPS o equipos de la gama Riello iDialog, no incluyen de serie opción de apagado autónomo avanzado si no se compra una tarjeta de gestión de red (APC Network Management Card) o software propietario específico. En el caso de VMware, incluso se han dejado de soportar, por parte de algunos fabricantes, ciertas soluciones de “network shutdown” que antes eran estándar.
Esto provoca situaciones como la de un usuario con un APC Smart-UPS 1500 conectado a un laboratorio con dos hosts ESXi 7 y un VMCA7: descubre que necesita hardware extra para usar el apagado de red oficial, y que además ese método ya no es compatible con las últimas versiones de VMware. A pesar de haber invertido en el laboratorio, se encuentra con que la integración “bonita” y soportada ya no existe.
En otros escenarios más sencillos, por ejemplo un esquema básico Interruptor de corriente → SAI → Servidor Linux, también aparecen problemas prácticos: el usuario quiere que, si alguien baja el interruptor, el SAI mantenga el equipo unos segundos, se desconecte él solo y, cuando vuelva la luz, reactive la salida automáticamente, sin depender de ningún software externo. Muchos modelos económicos, sin embargo, no se comportan así y dejan la carga eternamente encendida si el sistema operativo no interviene.
La conclusión inmediata es que para conseguir un apagado automático fiable hay que combinar tres elementos: la capacidad nativa del UPS, un software de gestión robusto (como NUT) y, si hablamos de entornos de virtualización, scripts que coordinen el apagado ordenado de todas las máquinas implicadas.
Network UPS Tools (NUT): el pilar del apagado automático en Linux y Unix
En sistemas basados en Linux y Unix, uno de los estándares de facto para gestionar SAIs es Network UPS Tools, más conocido como NUT. Se trata de un conjunto de herramientas y demonios que permiten monitorizar, controlar y automatizar acciones frente a fallos de suministro eléctrico en una gran variedad de dispositivos.
A diferencia de muchos paquetes propietarios de los fabricantes, NUT es software libre (licencia GPL) y ofrece un soporte amplísimo de modelos y marcas gracias a su biblioteca de drivers. Esto hace posible centralizar la gestión de varios SAIs desde una misma máquina, habilitar notificaciones avanzadas y, sobre todo, coordinar apagados automáticos en distintos equipos de la red.
Su arquitectura se basa en un concepto maestro-esclavo: un sistema actúa como servidor NUT (maestro), directamente conectado al SAI (vía USB, serie o red), y otros sistemas se conectan como clientes NUT (esclavos) para leer el estado de la alimentación y reaccionar en consecuencia. De este modo, puedes tener tu SAI conectado a una Raspberry Pi o a un servidor Linux y, a su vez, propagar eventos a otros equipos que también deban apagarse de manera controlada.
Conviene tener en cuenta que, aunque NUT pone mucho orden en todo este panorama, su configuración inicial no es precisamente “plug and play”. La interfaz es esencialmente archivos de texto en /etc/nut, y necesitas entender bien el rol de cada demonio (upsd, upsmon, upssched, etc.) para montar una solución estable.
Instalar y preparar NUT en una Raspberry Pi con Raspbian
Un escenario muy habitual es usar una Raspberry Pi como “cerebro” que gobierne uno o varios SAIs. Gracias a su bajo consumo, la Raspberry Pi es ideal para monitorizar un UPS todo el tiempo sin gastar apenas energía, incluso cuando otros equipos están apagados.
En Raspbian (y en muchas distros Debian/Ubuntu), NUT está en los repositorios oficiales, así que la instalación básica se reduce a lanzar en la terminal:
sudo apt-get install nut
Tras la instalación, es importante confirmar que el sistema ha creado el usuario y el grupo nut, porque son los que usará el servicio para ejecutarse con privilegios limitados. Si por lo que sea no existen, habrá que crearlos manualmente para evitar problemas de permisos al arrancar los demonios.
A partir de aquí, toda la configuración se hace en el directorio /etc/nut/, donde encontrarás varios ficheros .conf que definen el modo de funcionamiento, los drivers, usuarios, clientes, política de apagado y programación de eventos. La idea general es que esta Raspberry Pi actúe como maestro, exponga el estado del SAI al resto de la red y sea capaz de enviar correos electrónicos o registrar avisos en el syslog cuando pase algo raro.
Archivos de configuración clave en NUT: nut.conf y ups.conf
El primer archivo a revisar es nut.conf, que indica en qué modo va a trabajar NUT. Si la Raspberry va a ser el maestro conectado directamente al SAI, lo habitual es establecer:
MODE=standalone
Con este modo, el sistema se encarga de gestionar el UPS de forma local y ofrece servicio de monitorización a otras máquinas si más adelante las configuramos como clientes.
El siguiente fichero crítico es ups.conf, donde se declara cada SAI que vamos a gestionar. Por ejemplo, para un SAI Salicru SPS SOHO+ 1400VA conectado por USB se puede usar una configuración similar a:
driver = blazer_usb
port = auto
desc = "SAI Salicru"
En este bloque, la sección entre corchetes define el nombre lógico del UPS (salicru) que utilizaremos en el resto de archivos. El parámetro driver especifica qué controlador de NUT se debe usar, port indica el puerto (auto suele funcionar bien por USB) y la descripción es solo informativa. Es muy recomendable verificar en la lista de compatibilidad oficial de NUT qué driver encaja con tu modelo concreto antes de lanzarse a configurar a ciegas.
Configuración del servidor NUT: upsd.conf y upsd.users
Una vez definido el UPS, toca indicar cómo se expone esta información a los clientes. El archivo upsd.conf controla parámetros como el tiempo máximo de actualización y las direcciones en las que escuchará el demonio de servidor:
MAXAGE 15
MAXCONN 1024
LISTEN 127.0.0.1 3493
LISTEN ::1 3493
Con esta configuración, upsd escucha solo en la máquina local, tanto en IPv4 como en IPv6, en el puerto por defecto 3493. Si quieres permitir que otros equipos de la red consulten el estado del SAI, tendrás que añadir líneas LISTEN con la IP correspondiente o la dirección 0.0.0.0, aunque eso implica tomar más precauciones de seguridad.
El fichero upsd.users define las cuentas que se usarán para autenticarse contra el servidor NUT. Un ejemplo sencillo de usuario maestro podría ser:
password = contraseña
actions = set
instcmds = ALL
upsmon master
Este bloque crea un usuario lógico que tiene permiso para ejecutar comandos sobre el UPS, se usa como “master” por parte de upsmon y está protegido por una contraseña en texto plano (por eso, mejor dar acceso solo a IPs de confianza y evitar exponer el servicio a Internet). Es importante emplear contraseñas robustas y, si se habilitan accesos remotos, reforzar con firewall y, si es posible, cifrado TLS en la comunicación.
Definir la política de apagado: upsmon.conf y el flujo de eventos
El componente encargado de tomar decisiones cuando cambia el estado del SAI es upsmon. Su configuración principal está en upsmon.conf, que indica qué UPS se monitorizan, quién manda sobre ellos y qué se hace en caso de pérdida de energía, batería baja u otros eventos.
Una línea típica para registrar un UPS maestro en upsmon.conf sería similar a:
MONITOR salicru@localhost 1 nonmaster contraseña master
Con esto, upsmon sabe que debe vigilar el UPS llamado salicru, servirá un solo suministro (el “1” indica el número de fuentes), utilizará el usuario nonmaster con su clave y actuará como máster en la gestión de apagado. A partir de ahí, el resto de parámetros definen tiempos de sondeo, órdenes de apagado y comportamiento ante distintos avisos.
Algunos campos clave que suelen aparecer son:
SHUTDOWNCMD "/sbin/shutdown -h +0"
POWERDOWNFLAG /etc/killpower
POLLFREQ 5
POLLFREQALERT 5
DEADTIME 15
FINALDELAY 5
La orden SHUTDOWNCMD marca el comando que se ejecutará cuando NUT decida que ha llegado la hora de parar el sistema (por ejemplo, en batería baja prolongada). El archivo POWERDOWNFLAG se utiliza para coordinar el apagado completo del UPS, y los parámetros de frecuencia y tiempos de espera afinan cuán rápido se reacciona ante los cambios de estado del SAI.
Además, upsmon permite asignar diferentes tipos de notificación a los eventos relevantes (ONBATT, LOWBATT, ONLINE, SHUTDOWN, FSD, etc.) usando NOTIFYFLAG y un comando de notificación centralizado, algo del estilo:
NOTIFYCMD /bin/upssched-cmd
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
Con esta combinación, cada vez que se dispara uno de esos eventos, se escribe en el syslog, se avisa a los usuarios conectados y se ejecuta un script (upssched-cmd) que ya veremos más adelante, y que es el que se encarga de mandar correos, iniciar apagados forzados o reintentar la conexión con el UPS.
Programar acciones avanzadas con upssched.conf y el script upssched-cmd
Para tener un control fino sobre qué pasa en cada situación, NUT incluye el componente upssched, configurable mediante el archivo upssched.conf. Aquí se define qué se hace ante determinados eventos y, muy importante, se pueden establecer temporizadores para retrasar el apagado, combinar estados y lanzar acciones específicas.
Un ejemplo típico de configuración de upssched.conf podría incluir líneas como:
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 FSD * EXECUTE forced-shutdown
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
La idea es que, por ejemplo, cuando el SAI entra en modo batería (ONBATT), se inicie un temporizador de apagado a 60.000 segundos o al valor que elijas, y se envíe una advertencia. Si la batería baja demasiado (LOWBATT), se pueden lanzar acciones de emergencia e iniciar otro temporizador más agresivo.
Todas estas acciones acaban llamando al script indicado en CMDSCRIPT, que en este caso es /bin/upssched-cmd. Este script, escrito habitualmente en shell, se encarga de traducir los distintos tipos de evento en mensajes para el administrador, envíos de correo y órdenes de apagado del sistema. Un fragmento representativo podría tener una estructura como:
#!/bin/sh
case "${NOTIFYTYPE}" in
ONLINE)
_notifymessage="UPS ${UPSNAME} - Equipo funcionando con la red eléctrica";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;;
ONBATT)
_notifymessage="UPS ${UPSNAME} - Corte de suministro, trabajando con batería";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;;
LOWBATT)
_notifymessage="UPS ${UPSNAME} - Batería baja";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;;
FSD)
_notifymessage="UPS ${UPSNAME} - Apagado forzado";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;;
COMMBAD)
_notifymessage="UPS ${UPSNAME} - Comunicación perdida";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;
upsdrvctl start salicru;;
NOCOMM)
_notifymessage="UPS ${UPSNAME} - UPS no disponible";
echo ${_notifymessage} | mail -s "SAI" destinatario@example.com;
upsdrvctl start salicru;;
esac
Después de este primer bloque, el script suele incluir otra estructura case que interpreta el primer argumento que recibe (shutdown-warning, shutdown, resume, forced-shutdown, notify, etc.) y construye un mensaje final, llegando incluso a invocar directamente al comando shutdown del sistema con distintos tiempos:
case "${1}" in
shutdown-warning)
_message="${_notifymessage}. Apagado inminente";;
shutdown)
_message="${_notifymessage}. Se inicia el apagado";
shutdown -p now ${_message};;
forced-shutdown)
_message="${_notifymessage}. Apagado forzado en 100 minutos";
shutdown -h 100;;
notify)
_message="${_notifymessage}";;
*)
_message="Unknown command: ${1}";;
esac
logger -t upssched-cmd "${_message}"
De este modo, se concentra en un único punto la lógica de notificación y apagado, quedando registradas en el syslog todas las acciones tomadas, lo que facilita luego el análisis de incidencias y la depuración de problemas.
Verificación, logs y resolución de fallos de driver en NUT
Cuando terminas de configurar todos estos archivos, lo prudente es reiniciar la máquina o, como mínimo, recargar los servicios de NUT y verificar que el driver del UPS arranca correctamente. Para ello suele usarse el comando:
upsdrvctl start salicru
Si todo va bien, el comando no debería devolver errores y el SAI aparecerá como operativo. En caso de que falle, lo primero es echar un vistazo a los logs del sistema, normalmente en /var/log/syslog o en el journal de systemd. Un comando muy práctico para acotar la salida es:
tail -f /var/log/syslog | grep ups
Los problemas más comunes suelen estar relacionados con permisos en el puerto USB, drivers incorrectos o el propio hardware apagado. A veces basta con cambiar el driver en ups.conf por otra variante compatible de la lista oficial o confirmar que el kernel de la distribución reconoce bien el dispositivo. Si se sigue sin éxito, puede ser necesario actualizar la versión de NUT o incluso el sistema operativo para acceder a soporte más reciente de hardware.
En entornos donde NUT actúa como maestro, también es posible utilizar clientes en otras plataformas, como WinNUT en equipos Windows, que se conectan al servidor NUT, leen el estado del SAI y ejecutan sus propios apagados automáticos en Windows. Esta combinación permite, por ejemplo, tener un solo SAI físico que proteja varios equipos distribuidos por la red, todos ellos coordinados para cerrarse correctamente cuando falte la luz.
Apagado automático en ESXi mediante scripts basados en UPS y SNMP
Cuando entramos en el terreno de VMware ESX/ESXi, la cosa se complica un poco más porque no siempre disponemos de software oficial de apagado remoto integrado con el hipervisor. En muchos casos, la alternativa realista pasa por usar scripts que consulten el estado del UPS vía SNMP y disparen un apagado ordenado del host cuando se cumplan ciertas condiciones.
Un enfoque típico consiste en elaborar un script que, de forma periódica o bajo demanda, consulte mediante snmpget parámetros clave del SAI, como el estado de la batería (por ejemplo, batteryNormal frente a batteryLow) y el tiempo restante estimado. Cuando el estado de la batería deja de ser “normal” o el tiempo disponible cae por debajo de un umbral configurado, el script lanza la secuencia de apagado automático del servidor ESXi para evitar daños o pérdida de datos.
Este tipo de herramientas se han probado con versiones como VMware ESX 4.x, ESXi 4.x y ESXi 6.x, y suelen apoyarse en varios prerrequisitos de software en el lado Linux donde se ejecuta el script: mailx para enviar correos, snmpget para interrogar al UPS y el paquete vSphere CLI, que proporciona utilidades como esxcli y vmware-cmd para gestionar remotamente hosts y máquinas virtuales.
El flujo de funcionamiento suele ser sencillo de entender pero delicado de afinar: primero se consultan las OID SNMP del SAI para saber si está en batería y cuánto tiempo queda; después se compara con los valores de umbral definidos en la configuración; si se superan esos límites, se notifica al administrador (por correo) y se inicia el apagado ordenado de las VMs y del propio host ESXi. Si la situación vuelve a la normalidad antes de llegar al punto de no retorno, se puede optar por no apagar y simplemente registrar el incidente.
Este tipo de integración no depende del software propietario del fabricante del UPS, lo cual resulta muy útil en entornos donde se han descontinuado soluciones de “network shutdown” oficiales para versiones recientes de VMware, como ha ocurrido con algunos modelos de APC. Sin embargo, exige mantener el script, controlar bien las credenciales de acceso al host ESXi y vigilar que las MIBs del UPS no cambien con actualizaciones de firmware.
El dilema del apagado “autónomo” del SAI sin software externo
Un punto que preocupa a muchos administradores, especialmente en entornos sencillos, es la dependencia del software. Imagina el escenario donde el usuario puede apagar fácilmente un interruptor general, el SAI queda inaccesible físicamente y el único control que tienes es el software en el equipo Linux. Si el cable USB se desconecta o el demonio NUT falla, el servidor puede quedarse encendido indefinidamente mientras el UPS aguante, justo lo contrario de lo que se pretende.
Algunos usuarios buscan expresamente un SAI que, al detectar la pérdida de corriente, mantenga la salida alimentada unos segundos y luego se apague él solo, incluso si no hay nada conectado. Y que, cuando la red eléctrica vuelve, reactive automáticamente la salida sin necesidad de ningún sistema operativo ni software de terceros.
Lo cierto es que, aunque parezca lo más lógico del mundo, no todos los modelos del mercado implementan este comportamiento. En el caso de ciertos Riello iDialog, por ejemplo, se ha observado que no se apagan cuando están conectados a corriente, de manera que si apagas el servidor manualmente y luego cortas la alimentación con el interruptor, el SAI puede entrar en ese estado de “siempre encendido” sin apagado automático autónomo.
La recomendación, si buscas este tipo de comportamiento puramente automático, es revisar muy bien las especificaciones del fabricante o incluso el manual de software asociado (por ejemplo, los manuales de software LAN de algunos fabricantes como Xmart UPS) para verificar si el equipo ofrece configuración programable de desconexión y reconexión de carga sin depender del sistema operativo. Muchos SAIs de gama profesional permiten establecer límites de tensión, retrasos de encendido, ventanas horarias y secuencias de arranque que cubren este tipo de casos.
Ventajas e inconvenientes de usar NUT para el apagado automático
Como cualquier solución flexible y potente, NUT tiene su cara y su cruz. En entornos Unix y Linux es una herramienta prácticamente de referencia, pero conviene valorar bien qué ofrece y qué exige antes de implantarla en producción.
Entre los puntos fuertes destaca la monitorización remota centralizada. Desde un único servidor NUT, o desde tu Raspberry dedicada, puedes consultar el estado de varios SAIs repartidos en la red, ya sea vía USB, serie o red. Esto permite controlar desde un CPD doméstico con dos equipos hasta una pequeña sala de servidores con diferentes SAIs.
También sobresale la gestión unificada de acciones automáticas: configurar notificaciones por correo, mensajes al sistema, scripts personalizados para apagar servidores, reiniciar servicios o incluso integrar con sistemas de monitorización como Nagios o Zabbix. Todo se puede coordinar en función del estado del SAI: cortes, sobrecargas, fallos de batería, comunicación perdida, etc.
Otro punto muy potente es la compatibilidad con multitud de modelos y fabricantes. En lugar de tener que instalar un software por cada marca de SAI, NUT actúa como capa de abstracción: eliges el driver adecuado, declaras el dispositivo y, a partir de ahí, el resto del flujo de monitorización y apagado es el mismo, lo que simplifica bastante las cosas si tienes un parque heterogéneo.
En el lado menos amable está la curva de aprendizaje de la configuración inicial. No hay una interfaz bonita y amigable, sino varios archivos de texto que hay que entender y relacionar. Para quienes no estén acostumbrados a editar .conf o a interpretar logs de sistema, poner todo en marcha puede resultar intimidante y llevar tiempo.
Además, NUT introduce cierta dependencia de la red y de la estabilidad del propio servidor maestro. Si el equipo que hace de maestro se cuelga, pierde la conexión con el UPS o sufre un problema de hardware, los esclavos podrían dejar de recibir notificaciones y el apagado no producirse. Por eso es importante que el maestro sea una máquina estable, con buena alimentación (idealmente protegida también por el SAI) y monitorizada.
No hay que olvidar tampoco los aspectos de seguridad. Al exponer interfaces de gestión de SAI por red, especialmente si se da acceso remoto, hay que proteger bien las credenciales en upsd.users, limitar las IPs en upsd.conf, habilitar firewall y, si el entorno lo requiere, compilar NUT con soporte SSL/TLS para cifrar las comunicaciones. Un SAI mal protegido podría convertirse en un vector de ataque inesperado.
Finalmente, al ser una herramienta de código abierto, el soporte formal puede ser más limitado que el de ciertas soluciones comerciales. Aunque cuenta con una comunidad activa y bastante documentación, los usuarios menos experimentados pueden echar en falta asistencia directa o herramientas gráficas más pulidas, sobre todo en despliegues corporativos.
Compatibilidad de NUT y alternativas en otros sistemas operativos
Aunque NUT está pensado principalmente para sistemas tipo Unix (Linux, BSD, etc.), existen ports y adaptaciones para otras plataformas. En macOS se puede instalar, por ejemplo, a través de Homebrew con paquetes como nut2, si bien el soporte de ciertos drivers USB es más limitado y puede requerir algo de experimentación.
En el mundo Windows hay algunas implementaciones y clientes compatibles, como WinNUT, que pueden conectarse a un maestro NUT en Linux para leer el estado del SAI y ejecutar apagados locales. Sin embargo, si buscas una solución totalmente integrada y soportada en Windows Server, muchas veces sale más a cuenta tirar de herramientas oficiales como APC PowerChute o los paquetes propietarios del fabricante del UPS.
En cualquier caso, antes de decantarte por NUT o por una herramienta propietaria, conviene consultar la lista de compatibilidad de hardware en la web oficial de NUT (Hardware Compatibility List), así como la documentación del fabricante del SAI. Esto te permitirá comprobar si tu modelo concreto está soportado, qué driver debes usar y si hay notas especiales de configuración.
Vista toda esta panorámica, configurar un apagado automático fiable con un UPS pasa por entender bien las capacidades de tu hardware, elegir la herramienta adecuada (NUT u otra) y dedicar algo de tiempo a probar escenarios de fallo controlados. Con una buena configuración de archivos como ups.conf, upsmon.conf y upssched.conf, scripts bien escritos y un poco de mimo en seguridad y monitorización, es perfectamente posible conseguir que tu laboratorio, tu servidor Linux o tu host ESXi se apaguen de forma ordenada cuando falla la luz y vuelvan a la vida sin sobresaltos cuando la corriente regresa.
