Administración básica del sai Salicru SPSOne 900VA con NUT

En este tutorial vamos a ver cómo podemos administrar, de forma muy básica, un sai Salicru SPS One 900VA con NUT (Network UPS Tools).

Para obtener mas información a cerca de este sai, podéis consultar mi última review hecha sobre el mismo en este enlace.

Si tenéis dudas o queréis hacer alguna crítica o posible corrección, no dudéis en poneros en contacto conmigo y os atenderé lo más rápido posible.

Espero que este tutorial sea de vuestro agrado y máximo interés.

Jordi


Introducción

Como ya vimos en mi review, el Salicru SPS One 900VA es un sai de “mediana estatura”, básico pero con un gran potencial que nos dará lo que necesitamos para nuestra pequeña empresa o despacho, tanto a nivel profesional como doméstico. Es un sai que nos dará soporte para un pc, una impresora y algún dispositivo mas, con una carga de 900VA y una autonomía de unos 15/30 minutos máximo a plena carga.

En este tutorial básico veremos cómo conectar el sai a un sistema Linux, en este caso una RaspberryPi 3B+, con Raspbian, y conseguir cominicarnos con él. De este modo podremos obtener datos de su estado y eventos, así como apagar de forma segura el sistema o los sistemas que protege.

A continuación os lo detallo todo.

Vamos a ello!

 

Qué necesitamos

Para llevar a cabo este tutorial necesitaremos disponer del siguiente material:

  • un sai Salicru SPS One 900VA
  • un cable USB tipo A – B (normalmente suministrado con el sai)
  • una RaspberryPi 3B+, o similar, correctamente actualizada y con un sistema operativo Raspbian o equivalente (un PC con Linux también nos sirve, presumiblemente)
  • conexión a Internet

Es imprescindible disponer de los suficientes conocimientos en entornos Linux para poder llevar a cabo las siguientes pautas del tutorial. En aquellos casos que no sea tan obvio, se dará explicaciones adicionales.

Instalación

Preparar el sistema

Mi Raspi tiene como nombre de host upscontroller, y lo iréis viendo a lo larga del tutorial.

Para empezar, deberemos actualizar los paquetes de nuestra raspberry. Posteriormente instalaremos NUT mediante el comando apt install, del siguiente modo:

Una vez finalice la instalación ya dispondremos en nuestro sistema de las herramientas que ofrece NUT para la gestión y el control de nuestro SAI.

Conexión del sai

Apagaremos el sistema, y es este el momento idóneo para conectar el sai con el cable USB.

Encontraréis el conector en la parte trasera del mismo, y con el cable, lo conectaremos a un puerto USB libre de nuestra raspberry.

El sai aporta dos conexiones shucko para tomas de 220V. Ahí deberemos conectar los sistemas que deseamos proteger. Podemos hacerlo de forma directa o bien mediante una regleta, si es que disponéis de mas de un sistema (raspi, router, nas, etc…).

Probando la instalación

Ahora ya podemos volver a arrancar, esta vez con el sai conectado mediante usb a nuestra raspberry pi.

Una vez iniciado, y desde la consola de comandos, haremos un pequeño test invocando el driver de monitor upsdrvctl:

Como podemos ver el sistema ha respondido correctamente. Esto nos indica que ya lo tenemos todo listo para empezar a configurar el servicio de monitorización del SAI.

Ficheros de configuración

La configuración de NUT se encuentra en el directorio /etc/nut:

El listado anterior muestra los ficheros implicados en la configuración de todo el sistema.

A continuación vamos a detallar cada una de las configuraciones necesarias.

Para editar los ficheros de configuración os recomiendo siempre usar la consola para controlar mas lo que hacemos. Yo utilizo nano por comodidad, pero sentiros libres de usar el editor que mejor se adecue a vuestras necesidades (vi, nedit, note, etc..).

Empecemos.

nut.conf

Este fichero contiene la configuración básica de NUT, en la que le indicaremos al driver si debe ser activado o no. Por defecto vemos que el único parámetro existente es MODE=none, lo que significa que el driver está desactivado.

En nuestro caso iniciaremos el servicio en “modo único”, que nos permitirá controlar un solo SAI en modo local. Existe otro caso, en red, para un sistema servidor de SAIs pero es un caso que en estos momentos no nos ocupa.

Para iniciar el driver en modo único, debemos indicar el siguiente modo:

Guardamos y salimos.

ups.conf

Este fichero define cada uno de los SAIs que vamos a controlar de forma local. En nuestro caso solo será uno, por medio de un puerto USB.

En la siguiente configuración indicamos que disponemos un dispositivo definido por salicru, para el que definimos el driver y el puerto usados para comunicarnos con el mismo. Además, podremos indicar una breve descripción:

Con estos valores tenemos:

  • driver: blazer_usb
    • es el driver que acepta comunicaciones con sistemas Salicru (aunque no está indicado oficialmente, por experiencia sabemos que es el driver que mejor se adapta a estos SAIs)
  • port = auto
    • indicamos que haga un escaneo inteligente de todos los puertos abiertos en el sistema por el USB, de este modo no tenemos que preocuparnos por qué puerto específico usa el SAI (en las instrucciones del aparato aparece detallado)
  • desc = “Salicru SPS One 900VA”
    • una breve descripción, muy útil si tuviéramos más de un dispositivo

upsd.conf

Este fichero define la configuración del servicio de monitorización del sistema SAI. En él detallaremos los parámetros necesarios para el acceso al SAI.

Nosotros usaremos los siguientes valores:

Para nuestro caso sólo es necesario indicar en qué nodo (host) corre el servicio, que en nuestro caso es localhost o 127.0.0.1, en el puerto 3493 (valores por defecto del sistema).

upsd.users

En este fichero configuraremos los usuarios que deseamos definir como administradores del sistema o explotadores de datos del SAI.

En nuestro caso definiremos todos los usuarios por defecto que indica el fichero de ejemplo:

Básicamente:

  • admin
    • usuario administrador, con password 12345, al que se le permite gestionar completamente el sistema
  • testuser
    • identificado con el password de test, 12345, se le permite hacer test de baterías y calibración
  • upsmon
    • usario de monitorización, se le asignael password 12345, y se le permite monitorizar el sistema master

Notad que los passwords son simplemente de test, en un caso real deberíamos usar unos passwords más seguros, dado que el usuario administrador puede realizar cualquier tipo de intervención en el sistema. Para nuestro tutorial esto es suficiente.

upsmon.conf

Este fichero de configuración, que es el mas extenso, es además el mas interesante, dado que es el que nos ofrece la posibilidad de configurar cómo debe comportarse el servidor y el driver, qué parámetros nos interesa obtener y algunas acciones que podremos realizar para atender a los diferentes eventos que el servicio genera.

Valores por defecto

Por defecto, dejaremos tal cuál los parámetros siguientes que ya vienen en el fichero base de ejemplo:

Este parámetro indica que, al menos, tendremos una instancia del driver corriendo.

Este es el parámetro que ejecutará el servidor cuando detecte que el sistema está funcionando con baterías y haya pasado el tiempo configurado (lo veremos más abajo). Es sumamente importante que verifiquéis con vuestro SO cuál es el comando idóneo para ello, dado que es el punto y final antes del apagado controlado de todo el sistema…

Tiempo, en segundos, cada cuánto el servidor hará polling al sistema SAI para obtener los datos de su estado normal.

Tiempo, en segundos, cada cuánto el servidor hará polling al sistema SAI para obtener los datos de su estado de alarma por funcionamiento con baterías.

Tiempo, en segundos, que esperará el sistema maestro por cada uno de los esclavos para saber si siguen activos.

Tiempo, en segundos, que esperará el servidor para dar por “muerto” un dispositivo. Básicamente, indica cuántos segundos esperará el sistema para dar la alarma de que el servidor no da señales de funcionamiento.

Este parámetro indica al servidor qué fichero se debe crear en en el proceso de apagado por funcionamiento con baterías. Es un fichero de flag, y se suele utilizar para avisar a otros sistemas que no disponen de un modo de comunicación serie o que imposibilita su sincronización. Es decir, cualquier otro servicio puede mirar la existencia de este fichero para ser avisado del inicio del proceso de apagado del SAI.

Alerta de reemplazo de baterías. Por defecto 43200 segundos, o 12h, indica cada cuánto tiempo el servicio de monitorización debe avisar sobre el reemplazo necesario de las baterías.

Indicador o aviso de no comunicación con el sistema. Por defecto, un aviso cada 300 segundos, o 5 minutos.

Tiempo previo al envío de la notificación de apagado, una vez se ha iniciado el proceso. Es el tiempo final de espera, 5, expresado en segundos.

upssched.conf

Este fichero de configuración contiene todos los detalles relacionados con el sistema de temporización del driver del sai.

Dado que para este tutorial básico no nos es necesario modificarlo, no entraremos en detalles sobre el mismo. Basta con dejarlo tal cuál viene por defecto.

 

Primera puesta en marcha

Ya hemos visto de forma rápida el contenido de cada uno de los ficheros de configuración de NUT.

A continuación haré una propuesta de parametrización básica y veremos cómo aplica cada uno de los parámetros que usaremos, para personalizar, quizá completamente, nuestras necesidades.

Probando el servidor de monitorización

Lo primero que vamos a probar es la declaración del MONITOR del sistema.

Para ello debemos añadir el siguiente contenido al final del fichero upsmon.conf:

Con esta configuración estamos indicando al driver que debe iniciar el servicio MONITOR en el sai salicru, ubicado / conectado en 127.0.0.1 (localhost), y al puerto 3493 (por defecto). Posteriormente indicamos el usuario (upsmon), su contraseña y el modo de conexión (master, ya que solo controlaremos un sai en la red de sais). No parece complicado, en este punto, poder disponer de otros sais en la red y poder comandarlos de forma paralela…

Guardamos y reiniciamos la Raspi, para que el sistema reconozca la nueva parametrización, e inicie de forma automática el servidor de monitorización.

Para verificar que todo ha ido correctamente, haremos nuestra primera prueba tras el reinicio…

Ejecutaremos el siguiente comando, y veremos los resultados básicos que ofrece el servicio NUT, con este mínimo de configuración detallado anteriormente:

La ejecución finaliza con el siguiente resultado:

Perfecto!

No voy a entrar en detalle en cada una de las líneas de información que arroja el comando de sondeo que hemos lanzado, ya que es bastante autocontenido (en cualquier caso puedes preguntarme). Podemos ver datos como nivel de carga de las baterías y su voltaje, así como otros muchos datos relacionados con el sistema y el driver.

Así pues, ya tenemos nuestro el servidor de monitorización funcionando correctamente. Pero por ahora sólo sirve de test o para obtener datos del estado del sistema SAI.

Podemos conseguir bastante más, si dedicamos unos cuantos minutos a configurar un poco más este importante fichero.

A continuación lo vemos.

Parametrización customizada

Ahora es el momento de hacer que el driver sea “inteligente”, y no sólo ofrezca información de estado, sino que sea capaz de realizar actividades automatizadas según el estado del SAI.

Insertamos el siguiente contenido al final del fichero de configuración:

A continuación, os detallo qué estamos consiguiendo con estas sentencias o flags de configuración:

  • MONITOR
    • es la sentencia que instancia el monitor del sai, ya comentado anteriormente
  • NOTIFYCMD
    • indicamos qué fichero batch ejecutaremos en cada evento
  • NOTIFYMSG
    • con estos flags estamos creando los mensajes que el sistema creará cuando se lancen cada uno de los eventos a los que hacen referencia
    • estos mensajes aceptan parametrizaciones del tipo %s (string) o %d (number), por ejemplo
    • ejemplo: NOTIFYMSG LOWBATT “UPS %s battery is low”
      • indica que el evento LOWBATT (batería baja) generará un mensaje con el contenido “UPS <nombreDelSai> battery is low”, dónde <nombreDelSai> lo sustituirá por el nombre que actualmente hemos asignado al sai que lanza el evento (si tenemos mas de uno) mediante el parámetro %s
    • para más datos, podéis consultar la sección NOTIFY MESSAGES de la página del manual de NUT (UPSMON)
  • NOTIFYFLAG
    • con estos flags estamos indicando al sistema qué tipo de evento debe generar para cada caso:
      • SYSLOG: deja rastro en el log del sistema
      • WALL: manda el mensaje del evento a todos los usuarios logueados en el sistema (mensaje de consola)
      • EXEC: ejecuta el batch registrado en NOTIFYCMD, pasándole como parámetro el dato del evento
    • por ejemplo, NOTIFYFLAG LOWBATT, enviará un mensaje de evento de baterías bajas a los sistemas definidos (en nuestro caso, los tres sistema de aviso)
    • para más datos, podéis consultar la sección NOTIFY FLAGS de la página del manual de NUT (UPSMON)

Para cada uno de los flags anteriores se utilizan NOTIFY EVENTS, que son los identificadores de los eventos que el sai es capaz de lanzar:

  • ONLINE: el sai ha vuelto a estar conectado a la red eléctrica
  • ONBATT: el sai ha entrado en modo baterías
  • LOWBATT: el nivel de las baterías del sai es bajo (configurable a nivel de driver)
  • FSD: se ha enviado el comando Force Shutdown Mode al sai (apagado forzado)
  • COMMOK: comunicación con el sai establecida
  • COMMBAD: comunicación con el sai perdida
  • SHUTDOWN: el sistema local ha entrado en el proceso de apagado
  • REPLBATT: es necesario reemplazar las baterías del sai
  • NOCOMM: no se puede comunicar con el sai

Como veis, NUT ofrece un amplio abanico de eventos de sistema que pueden ser fácilmente explotados mediente los flags anteriores y sus configuraciones. Disponéis de más información en la página del manual de NUT (UPSMON), sección NOTIFY EVENTS.

 

Fichero batch de gestión de avisos

Una de las partes mas interesantes de la monitorización del sistema sai es recibir de forma automática los eventos que el sistema lanza. Para ellos debemos declarar un fichero batch que se encargue de hacer lo que sea necesario. Puede ser tan sencillo o tan complejo como necesitemos.

El fichero batch que os propongo, ups_notify.sh, lo hemos generado a mano, y es tan sencillo como esto:

Simplemente, lo que hace es obtener de la entrada estandard (mediante $) como parámetro el evento que el sistema monitor ha lanzado, y enviarlo por correo electrónico. Notad que las variables de configuración son de test, aquí deberíais indicar vuestro correo electrónico. Además, tened en cuenta que el comando sendmail debe existir en el sistema y deberéis tener permisos de ejecución del mismo.

Lo veremos en otro tutorial, mas adelante, pero pensad que en este punto podríais usar un cliente de ifttt, twitter, telegram o cualquier otro servicio online, para poder enviar los datos a los destinatarios interesados…

 

Conclusión

Con esto finalizamos el tutorial “básico” para la administración de un sai Salicru SPSOne 900VA.

En futuros tutoriales explicaré qué aplicaciones podemos usar para la explotación de los datos, así como la automatización de su obtención y posterior tratamiento. Podemos tener desde gráficas y avisos hasta sistemas en la nube que nos ejecuten rutinas en caso de caída del sai.

Algunas de las tecnologías de las que hablaremos serán, por ejemplo, OpenMediaVault, que es un sistema operativo completo para gestionar un sistema NAS, y que acepta una configuración muy básica de NUT, y por otro lado, NodeRED, para la automatización de rutinas y flujos de trabajo. Éste último lo encuentro muy especialmente interesante, ya que con muy poco trabajo podremos obtener una automatización completa de la información de nuestro sai.

Espero que haya sido de vuestro agrado y utilidad.

No dudéis en dejar vuestros comentarios, dudas y críticas. Todo será bienvenido.

Gracias por leerme!

Jordi

Share Button