Monitorizando nuestro SAI con nut (Reloaded-Parte 2)

En la entrada correspondiente a la Parte 1 contaba como monitorizar el SAI desde uno de nuestros servidores. Como estamos de renovación nos han llegado SAIs nuevos Salicru SPS 1500 One, así que voy a actualizar el documento anterior e incluir alguna cosa que quería corregir hace tiempo.

No me queda claro que sea o no un SAI online u offline (ver entrada anterior del blog para saber la diferencia) . Ya he tenido malas experiencias con SAIs offline y servidores HP Proliant (que es el nuevo servidor que nos han mandado), que se apagaban (bueno, se ponían en standby mode, que es casi apagado) antes de que al SAI le diese tiempo a activar la batería. Al primer corte de luz saldremos de dudas y podremos respirar tranquilos o bien darnos cabezazos contra la pared.

1) Configuración para el SAI Salicru SPS One 1500.

Lo primero es ver como se identifica. El lsusb me dice:

~# lsusb
Bus 004 Device 074: ID 0665:5161 Cypress Semiconductor USB to Serial

Buscando el identificador 0665:5161 por Internet el driver adecuado es blazer_usb, así que el fichero ups.conf sería:

~# cat /etc/nut/ups.conf
[salicru]
#Conexión USB falla al poco tiempo y da errores en syslog.
driver = blazer_usb
desc = "SAI Salicru"
port = auto
vendorid = 0665
productid = 5161
bus = "004"

El valor bus="004" tendrá que adaptarse al que tenga cada cual en su caso. Del resto de ficheros de configuración descritos en la anterior entrada del blog no he tocado nada. Bueno, pues solo queda reiniciar los servicios nut-server y ups-monitor:

# /etc/init.d/ups-monitor restart
# /etc/init.d/nut-server restart

Y decirle al SAI, "ola, ke ase?":

~# upsc salicru
battery.charge: 100
battery.voltage: 27.60
battery.voltage.high: 26.00
battery.voltage.low: 20.80
battery.voltage.nominal: 24.0
device.type: ups
driver.name: blazer_usb
driver.parameter.bus: 004
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 5161
driver.parameter.vendorid: 0665
driver.version: 2.6.4
driver.version.internal: 0.08
input.current.nominal: 6.0
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 233.6
input.voltage.fault: 233.6
input.voltage.nominal: 230
output.voltage: 233.6
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 22
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

Parece ser que todo está en orden: me da bien los parámetros y aguanta todo lo que tengo enchufado (4 servidores, 1 monitor, el switch troncal, el switch de cisco y el respaldo 4G de Telefónica). Me preocupa la línea:

ups.type: offline / line interactive. 

Como el servidor nuevo HP sea quisquilloso con los SAI offline eso nos va a dar problemas y el SAI va a ser un bonito adorno, pero seamos positivos como teletubbies y no pensemos en ello de momento.

Nota 23/11/2015: bueno, me congratula anunciar que tras una prueba involuntaria por un corte de corriente puedo afirmar que el servidor Proliant nuevo no se apaga ni se pone en standby al tener que alimentarse solo del SAI. Parece ser que el "line interactive" es suficiente para nuestro servidor.

2) Configuración del envío de correos.

En el post anterior el envío de correos de aviso lo hacia con el programa mailsend, que es una forma rápida y efectiva de enviar correos a través de un servidor SMTP externo. Para ello usaba una función bash con 2 parámetros, el título y el texto del mensaje:

~# cat /root/scripts/mail.sh
function mailSend() {
    mailsend -smtp smtp.gmail.com \
        -port 587 \
        -starttls -auth \
        -user micuenta@gmail.com \
        -pass mipassword \
        -f micuenta@gmail.com \
        -t micuenta@gmail.com \
        -sub "$1" -M "$2"
}

Esta función la incluía mediante "source mail.sh" dentro del script bash desde donde vamos a enviar los correos, en nuestro caso en el script /root/scripts/avisoups.sh descrito en la anterior entrada del blog.

El problema de usar mailsend es que es un comando que no espera: si en el momento de ejecutarlo no puede contactar con el servidor smpt.gmail.com la ejecución es abortada y el envío del mensaje no se realiza. Esto, dentro del contexto que nos ocupa, con el SAI generando eventos seguramente por un corte de corriente hace que tengamos muchas papeletas para que algún switch o router de la red no tenga corriente y no se pueda alcanzar smpt.gmail.com, por lo que la función mailSend no haría un carajo.

Por dicho motivo había que resolverlo de otra manera. Durante un tiempo implementé un sistema de colas de envío construido alrededor de mailsend y gestionado de forma artesanal. Tenía una pinta tan cutre que he decidido borrarlo de la faz de Matrix y no publicarlo aquí ni en ningún otro sitio.

Vaya tontería reinventar la rueda si podemos usar postfix para enviar correos a través de gmail. Siguiendo las instrucciones de dicho enlace ya tenemos un sistema que manda correos usando postfix, basado en hacer un relay de los mensajes a la cuenta SMTP de gmail, que envía el correo. Como postfix si que tiene un sistema de encolado serio y profesional, si intentamos enviar un correo ante un corte de corriente y si no hay respuesta de smtp.gmail.com el mensaje queda encolado para intentarlo mas tarde.

Los ficheros main.cf, sasl_passwd, mailname y sender_canonical quedan finalmente:

~# cat /etc/postfix/main.cf 
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = gmail.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.example.com, miserver.vguadalupe, localhost.vguadalupe, localhost
relayhost =  [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
sender_canonical_maps = hash:/etc/postfix/sender_canonical

~# cat /etc/postfix/sasl_passwd
[smtp.gmail.com]:587    micuenta@gmail.com:mipassword

El comando postmap a continuación crea /etc/postfix/sasl_passwd.db a partir de /etc/postfix/sasl_passwd, de manera que no se guarda la contraseña en texto plano sino en cifrado.

~# postmap hash:/etc/postfix/sasl_passwd

~# cat /etc/mailname 
gmail.com

~# cat /etc/postfix/sender_canonical
root micuenta@gmail.com
~# postmap /etc/postfix/sender_canonical

Para que los mensajes lleguen apareciendo como remitente micuenta@gmail.com en lugar de el aséptico "root" hay que retocar un poco los parámetros del comando "mail", que es el que usaremos para enviar los mensajes en lugar de "mailsend" ya que "mail" los envía a través del gestor de correos de salida por defecto, en nuestro caso postfix:

~# cat /root/scripts/mail.sh
function mailSend() {
echo "$2" | mail -s "$1" -a "From: avisos.ies "  cuenta.destino@gmail.com
}

3) Uso de knutclient para controlar el SAI desde nuestro PC de trabajo

Esta es una sugerencia de mi compañero Paco, del IES Garcia Téllez. Tengo pendiente probarla y describir aquí que tal va en una futura entrada. Se basa en que el nut es un sistema cliente-servidor, así que nada impide instalar un cliente nut gráfico en mi PC que contactará con el servidor remoto y me mostrará en la barra de tareas el estado del SAI. Una vía interesante para explorar.

Bueno, pues hasta pronto si la invasión de Microsoft y Adobe que esperamos en los centros educativos de Extremadura nos deja vivos. Siempre nos quedará Masada.

Addenda 29-marzo-2016: Bueno, pues después de unos meses monitorizando el SAI hemos tenido un problema bastante puñetero. Tarde o temprano el SAI dejaba de comunicarse con el PC y llenaba el syslog con mensajes:

Nov 12 14:27:21 servidor kernel: [  798.728084] usb 1-2: USB disconnect, device number 72
Nov 12 14:27:23 servidor kernel: [  800.628034] usb 1-2: new low-speed USB device number 73 using uhci_hcd
Nov 12 14:27:23 servidor kernel: [  800.806068] usb 1-2: New USB device found, idVendor=0665, idProduct=5161
Nov 12 14:27:23 servidor kernel: [  800.807639] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 12 14:27:23 servidor kernel: [  800.809114] usb 1-2: Product: USB to Serial
Nov 12 14:27:23 servidor kernel: [  800.810592] usb 1-2: Manufacturer: INNO TECH
Nov 12 14:27:23 servidor kernel: [  800.842240] hid-generic 0003:0665:5161.0048: hiddev0,hidraw0: USB HID v1.00 Device [INNO TECH
USB to Serial] on usb-0000:00:1d.0-2/input0
Nov 12 14:27:33 servidor kernel: [  810.136084] usb 1-2: USB disconnect, device number 73
Nov 12 14:27:34 servidor kernel: [  811.680031] usb 1-2: new low-speed USB device number 74 using uhci_hcd

Y así horas y horas. A veces se solucionaba reiniciando el servidor (que gracia), o desconectando el SAI, o reiniciando el servicio nut. La mayoría de las veces no había otra opción que desconectarlo del USB antes de que el syslog explotase.

Los de soporte técnico de HP han puesto cierto interés en arreglarlo, pero sin grandes resultados. Propusieron usar el parámetro POLLFREQ con valor 2 en upsmon.conf, pero no sirvió de nada. También intentaron convencerme de que abandonase nut y usase ViewPower/WinPower, un monstruo propietario hecho en Java (agárrate, Manuel) para monitorizar el SAI. Ni de coña.

Al final nuestro compañero Carlos Martín me configuró esto:

# cat /etc/nut/ups.conf:
......
......
# Set maxretry to 3 by default, this should mitigate race with slow devices:
maxretry = 3

[salicru]
driver = blazer_usb
port = auto

Y con ese mágico maxretry llevo varios meses en mis dos SAIs sin más problema de comunicación. Carlos: eres un crack.