"Después del juego es antes del juego"
Sepp Herberger

Mostrando las entradas para la consulta monit ordenadas por relevancia. Ordenar por fecha Mostrar todas las entradas
Mostrando las entradas para la consulta monit ordenadas por relevancia. Ordenar por fecha Mostrar todas las entradas

domingo, 14 de abril de 2019

Monitorizando los puestos del aula con monit (I)


Mi compañero Esteban ha publicado en su blog varios artículos muy interesantes sobre monit. Resumidamente: monit es un servicio que se encarga de monitorizar el sistema y asegurarse de que otros servicios funcionan y/o informarnos ante determinados eventos.

Aparte de usarlo en los servidores del centro también viene bien tenerlo en funcionamiento en los ordenadores de los profesores dentro del aula, ya que se ocupan de varias tareas críticas dentro del contexto de sus funciones y es recomendable tener asegurada y controlada su disponibilidad.

1. Configuración de alertas mediante correo.

Para que monit nos notifique cosas la opción más sencilla es que nos envíe correos electrónicos a través de una cuenta de Gmail. En mi caso ya tengo en el centro un servidor de correo postfix que redirige sus correos a través de la cuenta de Gmail, tal como conté en al apartado 2 de la entrada sobre la Gestión de Avisos del SAI usando nut, por lo que lo mas correcto es que los distintos servicios monit que hay por los pc del centro envíen sus alertas al servidor postfix y este a su vez lo reenvíe a través Gmail.

Para que el servidor postfix admita correos de cualquier PC de nuestra red hay que editar su fichero /etc/postfix/main.cf y añadir:
..
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.19.196.0/24
..
smtpd_client_restrictions = permit_mynetworks, reject
Siendo 172.19.196.0 mi red local y no olvidando reiniciar el servicio postfix después.

A continuación, en cada /etc/monit/monitrc añadimos:
.....
set mailserver 172.19.196.X port 25

set alert mi.correo@gmail.com not on {instance}

set mail-format { from: mi.correos@gmail.com
subject: $HOST - $SERVICE $EVENT a $DATE
message: Monit $ACTION $SERVICE a $DATE en $HOST, Descripcion: $DESCRIPTION.
}
Siendo 172.19.196.X el servidor donde está ejecutándose el servicio postfix en mi red y mi.correo@gmail.com la cuenta de correo Gmail usada para notificar las alertas. El "not on {instance}" es un filtro para que no nos envien correos de alerta cada vez que el servicio monit se enciende o se apaga, ya que son bastante molestos.

2. Monitorizando servicios básicos.

En los puestos de los profesores tengo como mínimo 2 servicios críticos: dhcp (para dar IP a los portátiles, thinclients o worskstations de alumnos) y tftp (para la imagen de arranque de thinclients).
# cat /etc/monit/conf.d/monit.dhcp
check process dhcpd matching "dhcpd"
  start program "/etc/init.d/isc-dhcp-server start"
  stop  program "/etc/init.d/isc-dhcp-server stop"
Y:
# cat /etc/monit/conf.d/monit.tftp
check process tftp matching "/usr/sbin/in.tftpd"
  start program "/etc/init.d/tftpd-hpa restart"  # El restart funciona mejor, porque a veces si no se hace stop luego no arranca.
  stop  program "/etc/init.d/tftpd-hpa stop"
De igual manera podemos ir añadiendo ficheros para monitorizar cualquier servicio que juzguemos imprescindible.

3. Monitorizando los puntos wifi.

Otro recurso crítico en las aulas son los puntos wifi para permitir la conexión de portátiles y dispositivos móviles. Por regla general están en la IP 192.168.0.1 de la red interna del aula:
# cat /etc/monit/conf.d/monit.puntowifi
check host punto-wifi  with address 192.168.0.1
      if failed icmp type echo count 5 with timeout 30 seconds then alert
De esta manera si hay algún problema con el punto wifi (bloqueo o desconexión de cables) nos llegará una alerta por correo.

4. Monitorizando la conexión de las pizarras digitales.

Esta es más divertida: las pizarras digitales se conectan por USB y a veces por accidente o por diabluras de los alumnos se desconecta el cable que las une al PC.
# cat /etc/monit/conf.d/monit.pizarra
check program pizarra with path /usr/local/bin/check_pizarra
    if status != 0 then alert
Evidentemente, para este caso no hay orden específica de monit, lo que tenemos es un script que busca la pizarra entre los dispositivos USB y devuelve 1 si no la encuentra.
# cat /usr/local/bin/check_pizarra
#!/bin/bash
# Devuelve 1 para avisar de desconexión, 0 si esá conectada o bien ya se avisó.

pizarra=$(lsusb -d 0b8c: ; lsusb -d 13ff:) # 0b8c:0069  0b8c:0001  13ff:0008 - Pizarras SmartBoard 480/640 y Galneo
if test -z "$pizarra"
then
     if ! test -f /var/cache/no-pizarra
     then
         retorno=1
         touch /var/cache/no-pizarra
     else
         retorno=0 # Ya se avisó, no necesario volver a hacerlo
     fi
else
      retorno=0
      rm -f /var/cache/no-pizarra  # Reconectada, se borra el testigo de aviso.
fi
exit $retorno
De esta manera se avisa de forma inmediata de cualquier desconexión, quedando registrado en el correo el momento en que sucedió por si necesitamos hacer indagaciones posteriores.

5. Monitorizando teclados y ratones.

Al igual que las pizarras digitales, los teclados y ratones en los puestos del profesor son causa de algún que otro problema. Ya traté este tema en otro artículo, pero ahora lo enfocaré para que la detección se haga desde monit:
# cat /etc/monit/conf.d/monit.kbmouse
check program teclado_raton with path /usr/local/bin/check_kb_mouse
    if status != 0 then alert
Siendo el script:
# cat /usr/local/bin/check_kb_mouse
#!/bin/bash

FICHERO=/var/cache/kbvigila

#En teclados Sweex USB, aparece mouse en devices, aun cuando no haya ratón 
#conectado. Con el filtro grep -v kbd eliminamos esas lineas, para que solo
#coja las corresponden a un ratón real.
raton=$(cat /proc/bus/input/devices  | grep -i mouse | grep -v kbd | grep Handlers| wc -l)

#En teclados RML, la cadena es "keykoard" en lugar de "keyboard"
teclado=$(cat /proc/bus/input/devices  | grep -i key[bk]oard | wc -l)

pizarra=$(lsusb -d 13ff:0008) # Pizarra Galneo
if test -n "$pizarra"
then
   #Las pizarras Galneo se identifican como ratón, asi que hay que decrementar el contador
   ((raton--))
fi

test $raton -eq 0  && hayraton="1" ||  hayraton="2"
test $teclado -eq 0 &&  hayteclado="1" || hayteclado="2"

#En hayXXX: Valor "1": no detectado. 
#           Valor "2": detectado. 

#Recupera el estado anterior de teclado y ratón.
if [ -f $FICHERO ]
then
   km_anterior=$(cat $FICHERO)
else
   km_anterior=""
fi
#Estado actual
km_actual="${hayteclado}${hayraton}"

#Si el estado teclado/raton ha cambiado respecto al estado anterior, devuelve 1
#para que haya una alerta
if  [ "$km_anterior" != "$km_actual" ]
then
   retorno=1
   #Guarda el estado actual para la siguiente comprobación.
   echo "${hayteclado}${hayraton}" > $FICHERO   
else
   retorno=0
fi
exit $retorno
Simplemente se comprueba el estado de conexión de teclado/ratón y se compara con el resultado de la comprobación anterior. Si ha variado algo se lanza un aviso.

6. Tarea puppet.

Todo esto lo distribuyo mediante una tarea puppet que aplicaría a las distintos pc de profesor que quiero monitorizar, siendo el init.pp de la tarea:
class  xubuntu18_monit {

        package { "monit": ensure =>installed }

        service { 'monit':
                ensure  => 'running',
                enable  => true,
                require => Package['monit'],
        }

        file { "monitrc":
                path => "/etc/monit/monitrc",
                owner => root, group => root, mode => 600,
                source => "puppet:///modules/xubuntu18_monit/monitrc",
                ensure => file,
                notify  => Service['monit'],  # Reinicia el servicio si el fichero cambia
                require => Package['monit'],
        }

        case $ies_isltsp {
                "si","yes","true" : {  #En los pc con thinclients hay serficio tftp
                        file { "monitrc-tftp":
                                path => "/etc/monit/conf.d/monitrc.tftp",
                                owner => root, group => root, mode => 600,
                                source => "puppet:///modules/xubuntu18_monit/monitrc.tftp",
                                ensure => file, notify  => Service['monit'], require => Package['monit'],
                        }
                }
                default: { 
                }
        }


        file { "monitrc-wifiap":
                path => "/etc/monit/conf.d/monitrc.wifiap",
                owner => root, group => root, mode => 600,
                source => "puppet:///modules/xubuntu18_monit/monitrc.wifiap",
                ensure => file, notify  => Service['monit'], require => Package['monit'],
        }

        file { "monitrc-pizarra":
                path => "/etc/monit/conf.d/monitrc.pizarra",
                owner => root, group => root, mode => 600,
                source => "puppet:///modules/xubuntu18_monit/monitrc.pizarra",
                ensure => file, notify  => Service['monit'], require => Package['monit'],
        }

        file { "pizarra":
                path => "/usr/local/bin/check_pizarra",
                owner => root, group => root, mode => 755,
                source => "puppet:///modules/xubuntu18_monit/check_pizarra",
        }

        file { "kb_mouse":
                path => "/usr/local/bin/check_kb_mouse",
                owner => root, group => root, mode => 755,
                source => "puppet:///modules/xubuntu18_monit/check_kb_mouse",
        }

}
7. Continuará...

Una vez montado el sistema lo seguiré ampliando con más scripts de monitorización de temperaturas de CPU, placa y GPU, espacio en disco, uso de CPU, estado de las fuentes de alimentación, etc. Lo iremos viendo en artículos sucesivos.


Llevamos unas semanas frenéticas para los espaciotrastornados. Podría hablar de:
  • Increíbles fotos de agujeros negros.


  • El éxito completo de la Falcon Heavy de Space con los tres cohetes reutilizados aterrizando suavemente en sus plataformas.


    ¡Eres grande, Elon Musk!

  • Próxima C: otro candidato a planeta rocoso a 4 años luz de nosotros.

Pero no, la imagen es un eclipse de sol desde la superficie Marte, al pasar las lunas Fobos/Deimos delante del astro rey. ¿Quién tomó esta maravillosa imagen? Mi admirada Opportunity:


Impresionante.

martes, 25 de febrero de 2020

Monitorizando los portátiles del aula con monit (III)

Seguimos desde aquí.

Me interesaba saber en que momento en un aula concreta se habían conectado a la red los portátiles de los alumnos, con vistas a realizar unas comprobaciones y tareas en ellos con tmux-cssh.

La manera mas sencilla es usar monit para chequearlo y lanzar una alerta. Primero un script que encuentra todos los clientes conectados a la red del aula:
# cat /usr/local/bin/clientes-conectados.sh
#!/bin/bash
conectados=$(nmap -oG - -sP  192.168.0.200-253 | grep Up | awk '{print $2}')
total=$(echo $conectados | wc -w)
echo $conectados
exit $total
Ojo: para saber los clientes conectados escaneo el rango 192.168.0.200 a 253, que es el rango con el que se sirven IP a los portátiles en mis aulas. Cada cual debe adaptarlo a su caso.

El fichero de configuración de alerta de monit:
# cat /etc/monit/config.d/monitrc.clientes 
#Avisa cuando se conectan clientes a la wifi
check program clientes-conectados with path "/usr/local/bin/clientes-conectados.sh"
if status > 5  then alert
Por poner un límite inferior, he puesto que me avise cuando haya 5 o más portátiles conectados a la red wifi. En ese momento la alerta me llega con un correo tal como configuramos en entradas anteriores dedicadas a monit.

Out!

jueves, 25 de abril de 2019

Monitorizando los puestos del aula con monit (II)

Seguimos desde aquí. Vamos a ampliar añadiendo controles basándonos en esta entrada de mi compañero Esteban:
  • Temperatura de la CPU
  • Temperatura de la placa base
  • Temperatura del disco duro
  • Temperatura de la GPU (tarjeta gráfica)
  • Velocidad ventiladores
  • Estado de las fuentes de alimentación redundantes en el servidor del centro
Todo esto lo haremos usando los comandos sensors, nvidia-smi, hddtemp y hplog.

El comando sensors es el que mas información da, pero el problema es que es muy dependiente del hardware y con él no obtenemos una salida homogénea con los números bien colocaditos, sino distintos formatos de presentación a partir de los cuales extraemos los datos. A eso hay que añadir que no siempre tenemos accesibles todos los valores de temperaturas y/o ventiladores debido a que a veces los comandos sensors y hddtemp no son compatibles con el hardware subyacente.

Con esto así he adaptado los scripts para que sean los mas completos posibles, pero no es descartable irlos ampliando conforme vayamos recibiendo nuevos equipos o actualizaciones que hagan que sensorsse comunique mejor con el hardware.

El fichero de monitorización para todas la máquinas sería (esto se añadiría a la tarea puppet vista en el post anterior):
# cat /etc/monit/conf.d/monitrc.temperatura
check program mbtemperatura with path "/usr/local/bin/mbtemp.sh"
   if status > 60 for 3 cycles then alert
   group temperature

check program cputemperature  with path "/usr/local/bin/cputemp.sh"
   if status > 65 for 3 cycles then alert
   group temperature

check program hddtemperature with path "/usr/local/bin/hddtemp.sh"
   if status > 50 for 3 cycles then alert
   group temperature

check program vgatemperature with path "/usr/local/bin/vgatemp.sh"
   if status > 98 for 3 cycles then alert
   group temperature

check program fanspeed with path "/usr/local/bin/fanspeed.sh"
   if status = 1 for 3 cycles then alert
   group temperature
El script que comprueba la velocidad de los ventiladores (solo funciona en las placas Asus de los servidores LTSP que nos envió Telefónica) sería:
# cat /usr/local/bin/fanspeed.sh
#!/bin/bash
hardware=$(facter hardware)
FANSPEED=0 #
case $hardware in
   "telefonica")
         FANSPEED1=$(sensors |grep "^CPU FAN Speed" | awk '{print $4}')
         FANSPEED2=$(sensors |grep "^CHASSIS2 FAN Speed" | awk '{print $4}')
         test $FANSPEED1 -lt 600 -o $FANSPEED2 -lt 600 && FANSPEED=1       #Si alguno de los ventiladores gira por debajo de los 600RPM se avisa de ello
         ;;
esac
#echo $FANSPEED # for debug only
exit $FANSPEED
Para estos PC, que tienen una placa Asus P5Q DELUXE, la salida de sensors es muy completa:
# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +43.0°C  (high = +82.0°C, crit = +100.0°C)
Core 1:       +43.0°C  (high = +82.0°C, crit = +100.0°C)
Core 2:       +43.0°C  (high = +82.0°C, crit = +100.0°C)
Core 3:       +40.0°C  (high = +82.0°C, crit = +100.0°C)

radeon-pci-0100
Adapter: PCI adapter
temp1:        +56.0°C  

atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage:       +1.13 V  (min =  +0.80 V, max =  +1.60 V)
 +3.3 Voltage:       +3.28 V  (min =  +2.97 V, max =  +3.63 V)
 +5 Voltage:         +5.14 V  (min =  +4.50 V, max =  +5.50 V)
 +12 Voltage:       +12.21 V  (min = +10.20 V, max = +13.80 V)
CPU FAN Speed:      2556 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS1 FAN Speed:    0 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS2 FAN Speed: 3515 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS3 FAN Speed:    0 RPM  (min =  600 RPM, max = 7200 RPM)
POWER FAN Speed:       0 RPM  (min =  600 RPM, max = 7200 RPM)
CPU Temperature:     +27.0°C  (high = +60.0°C, crit = +95.0°C)
MB Temperature:      +45.0°C  (high = +45.0°C, crit = +95.0°C)
Por desgracia, en el resto de máquinas que tengo la información es mucho mas limitada.

El script que comprueba la temperatura de la VGA utiliza varios filtros y comandos para extraer a los datos. Su código es:
# cat /usr/local/bin/vgatemp.sh
#!/bin/bash

#ati radeon y nouveau se comprueban con "sensors"
#nvidia se comprueba con nvidia-smi
#intel no se puede monitorizar, no he encontrado herramienta
 
VGATEMP=0
if sensors | grep -q radeon-pci
then
  VGATEMP=$(sensors | sed -n '/radeon-pci/,/^$/p' | grep "^temp" | tr -d '+°C' | awk '{printf("%d\n",$2 + 0.5)}' | sort -nr | head -1)
else
   if sensors | grep -q nouveau-pci
   then
     VGATEMP=$(sensors | sed -n '/nouveau-pci/,/^$/p' | grep "^temp" | tr -d '+°C' | awk '{printf("%d\n",$2 + 0.5)}' | sort -nr | head -1)
   else
      if test -f /usr/bin/nvidia-smi
      then
        VGATEMP=$(nvidia-smi -q | grep "GPU Current Temp" | awk '{printf("%d\n",$5)}')
      fi
   fi

fi

#echo $VGATEMP # for debug only
exit $VGATEMP
El script que comprueba la temperatura de la placa base, según el hardware que usemos, sería:
# cat /usr/local/bin/mbtemp.sh
#!/bin/bash
hardware=$(facter hardware)
MBTEMP=0
case $hardware in
   "telefonica") MBTEMP=$(sensors |grep "^MB Temperature:"| awk '{printf $3}'  | tr -d '+°C'  | awk '{printf("%d\n",$1 + 0.5)}')
           ;;
   "siatic") MBTEMP=$(sensors | sed -n '/acpitz-virtual-0/,/^$/p' | grep "^temp" | tr -d '+°C' | awk '{printf("%d\n",$2 + 0.5)}' | sort -nr | head -1)
           ;;
   "infolab" ) MBTEMP=$(sensors | sed -n '/pch_skylake-virtual-0/,/^$/p' | grep "^temp" | tr -d '+°C' | awk '{printf("%d\n",$2 + 0.5)}' | sort -nr | head -1)
           ;;

   * ) MBTEMP=$(sensors | sed -n '/acpitz-virtual-0/,/^$/p' | grep "^temp" | tr -d '+°C' | awk '{printf("%d\n",$2 + 0.5)}' | sort -nr | head -1)

        ;;
esac
#echo $MBTEMP # for debug only
exit $MBTEMP
El script que obtiene la temperatura de todos los discos duros y devuelve la mayor entre ellas es:
# cat /usr/local/bin/hddtemp.sh
#!/bin/bash

HDDTEMP=0
DISCOS=$(lsblk  -l | grep disk | cut -f1 -d" ")
for i in $DISCOS
do
  TEMP=$(hddtemp  /dev/$i 2> /dev/null | tr -d "°C " | cut -d":" -f3)
  test -z "$TEMP" && TEMP="0"
  test "$TEMP" -gt "$HDDTEMP" && HDDTEMP="$TEMP"
done

#echo $HDDTEMP # for debug only
exit $HDDTEMP
El script que comprueba la temperatura de la CPU o sus cores y devuelve la mayor:
# cat /usr/local/bin/cputemp.sh
#!/bin/bash
hardware=$(facter hardware)
CPUTEMP=0
case $hardware in
   "telefonica") CPUTEMP=$(sensors |grep "^CPU Temperature"| awk '{printf $3}'  | tr -d '+°C'  | awk '{printf("%d\n",$1 + 0.5)}')
           ;;
   "siatic" | "infolab" ) CPUTEMP=$(sensors |grep "^Package id"| awk '{printf $4}'  | tr -d '+°C' | awk '{printf("%d\n",$1 + 0.5)}')
           ;;
   * )  CPUTEMP=$(sensors |grep "^Core "| tr -d '+°C' |  awk '{printf("%d\n",$3 + 0.5)}'  | sort -nr | head -1) #El mayor de los cores
        ;;
esac
#echo $CPUTEMP # for debug only
exit $CPUTEMP
En el caso del servidor del centro tenemos un HP Proliant que gracias al paquete hp-health nos permite acceder a más valores interesantes, como el estado de las dos fuentes de alimentación redundantes que tiene.
# cat /etc/monit/conf.d/monitrc.temperatura
check program mbtemperatura with path "/usr/local/bin/mbtemp.sh"
   if status > 60 then alert
   group temperature

check program cputemperature  with path "/usr/local/bin/cputemp.sh"
   if status > 60 then alert
   group temperature

check program hddtemperature with path "/usr/local/bin/hddtemp.sh"
   if status > 50 then alert
   group temperature

check program fanspeed with path "/usr/local/bin/fanspeed.sh"
   if status = 1 then alert
   group temperature

check program powersupply with path "/usr/local/bin/powersupply.sh"
   if status = 1 then alert
   group temperature
El script de chequeo de ambas fuentes de alimentación sería:
# cat /usr/local/bin/powersupply.sh
#!/bin/bash
fans=$(hplog -p | grep Normal | wc -l)
if [ $fans -ne 2 ] #Verificamos que ambas fuentes estén en estado "normal"
then
   salida=1
else
   salida=0
fi
#echo $salida # for debug only
exit $salida
El script de chequeo de los ventiladores (para el HP Proliant se usa hplog en lugar de sensors) sería:
# cat /usr/local/bin/fanspeed.sh
#!/bin/bash
fans=$(hplog -f | grep Normal | wc -l)
if [ $fans -ne 2 ] #Verificamos que ambos ventiladores estén en estado "normal"
then
   salida=1
else
   salida=0
fi
#echo $salida # for debug only
exit $salida
Nota: los valores de temperatura en monitrc.temperatura los he ido afinando con diversas pruebas a lo largo de 10 días, ya que no es raro que haya máximos puntuales sobre todo cuando se reproducen vídeos. Cada uno debe ir probando y cambiando valores hasta dar con el equilibrio óptimo que no te fría a mensajes y a la vez te alerte cuando algo empiece a ir mal.

Bueno, pues hasta aquí hemos llegado. Si nos salen nuevas cosas que comprobar haremos una tercera parte.

martes, 19 de noviembre de 2019

Avisos multicanal desde monit.

Aunque ya he usado monit para avisar de determinados eventos, hay veces que necesito una notificación inmediata. En concreto quería monitorizar punto wifi que sospechosamente perdía la conexión más de lo habitual.

Para ello decidí no limitarme a mandar un "alert" cuando se pierde el ping, sino que lanzo un script que hará más ruido:
check host punto-wifi with address 192.168.0.1
       if failed icmp type echo count 3 with timeout 5 seconds then exec "/usr/local/bin/aviso-wifi"
1. Avisos multicanal.

El script aviso-wifi usa distintos tipos de aviso por diferentes cauces:
# cat /usr/local/bin/aviso-wifi 
#!/bin/bash

MENSAJE="Otra vez desconectado $(date)!"

#Log del sistema
echo $MENSAJE >> /var/log/wifilog.log

#Correo
mailsend -to destinatario@gmail.com \
      -from emisor@gmail.com \
      -ssl -smtp smtp.gmail.com -port 465 \
      -sub "Aviso" \
      -M "$MENSAJE" \
      +cc +bc -q -auth -user "emisor@gmail.com" -pass "mipassword"

#Mensaje push al móvil android
PUSHKEY="APcdkK"
curl --data "key=$PUSHKEY&title=Aviso&msg=$MENSAJE" https://api.simplepush.io/send

#Mensaje SMS al móvil android
MOVIL="+34855123456"

curl -X POST https://textbelt.com/text \
       --data-urlencode phone="$MOVIL" \
       --data-urlencode message="$MENSAJE" \
       -d key=textbelt

exit 0
Los distintos métodos usados son:
  • Guarda un registro en /var/log/wifilog.log.
  • Envía un correo mediante gmail usando mailsend, que tendríamos que instalar previamente.
  • Envía un mensaje push a nuestro móvil mediante la aplicación simplepush.io, que saltará de forma inmediata. Es tan sencillo como instalar esta aplicación en el móvil y poner en el script la PUSHKEY que nos aparece al abrirla, que identifica nuestro móvil de forma única como destinatario.
    Como pequeño inconveniente tenemos que los mensajes son gratuitos los 7 primeros días, luego hay que comprar la aplicación (cuesta unos merkels) para poder recibir mensajes. Se pueden establecer alarmas sonoras distintas en función de diversos tipos de mensajes push.
  • Por último, por volver a los 90, mandamos un SMS a nuestro móvil (+34855123456, es un número ficticio, pon el tuyo empezando por +34). Este servicio de textbelt permte mandar un único SMS al día gratis, pero si nos resulta útil podemos comprar paquetes SMS prepago.

Tanto simplepush.io como textbelt son dos de los muchos servicios push y SMS que hay. Yo he puesto estos porque los encontré pronto y me resultaron fáciles de usar mediante sencillas peticiones web con el comando curl.

Por supuesto, se podría ampliar el script con otros medios de aviso, por ejemplo mensajes telegram o cualquier otro sistema que se pueda hacer mediante scripts.

2. Avisos sonoros.

Un escalón mas es hacer sonar un aviso por los altavoces del PC del aula donde se detecta el evento, para que si es especialmente grave el usuario tome medidas. El script sería:
# cat /usr/local/bin/aviso-audio 
#!/bin/bash

#Subimos el volumen al máximo en el alsamixer
amixer set Master unmute
amixer set Master 100%

#Si hay un usuario logado, conectamos con su pulseaudio para subir el volumen al máximo
user=$(who | grep "(:0)" | head -1 | cut -f1 -d" "); 
if  [ -n "$user" ]
then
  su $user -c "DISPLAY=:0 pactl set-sink-volume 0 150%"
  su $user -c "DISPLAY=:0 pactl set-sink-mute 0 0"
fi

#Si esta instalado placasiatic es una siatic y podemos encender por comando la barra de sonido.
test -f /usr/sbin/placasiatic && placasiatic sonido up

if  [ -n "$user" ]
then
  while true
  do
     ffplay /root/scripts/locucion.mp3 -nodisp -nostats -hide_banner 
     su $user -c "DISPLAY=:0 zenity --info  --width 400 --height 100  --title='Desconexion de sistema' --text='Avise al administrador informatico de forma urgente.'"
  done
else
   ffplay /root/scripts/locucion.mp3 -nodisp -nostats -hide_banner -loop 0
fi


exit 0
Comentamos:
  • Con amixer quitamos el mute (silencio) y subimos al 100% del volumen del canal de audio Master.
  • Si hay un usuario con sesión iniciada, conectamos con su instancia pulseaudio para subir al máximo el volumen allí mediante pactl y hacer unmute.
  • Si estamos en una Siatic encendemos la barra de sonido mediante el relé. Esto garantiza que si el usuario ha apagado la barra la encendemos de nuevo usando la utilidad placasiatic. Por supuesto, si los altavoces del PC son convencionales y están apagados físicamente en su interruptor, no saldrá nada de sonido. Es algo que puede pasar y para lo cual no tenemos solución.
  • Por último, se reproduce una locución en bucle infinito codificado en mp3 mediante ffplay. Si hay usuario con sesión iniciada se muestra además un mensaje de texto en su escritorio mediante zenity.
  • La locución se puede generar fácilmente con texttomp3.
Para ejecutar este script desde el del apartado anterior es suficiente con añadir:
nohup /usr/local/bin/aviso-audio >/dev/null 2>&1 &


Cuando lo extraordinario empieza a ser habitual es señal de que se está haciendo bien: SpaceX ha lanzado una nueva carga de satélites Starlink.


Se lanzan 60 microsatélites Starlink (que mientras se van desplegando en las próximas semanas se podrán ver como un tren por el cielo nocturno una vez más), la etapa inicial del Falcon reutilizado por cuarta vez aterriza en la plataforma barcaza Of Course I Still Love You y la cofia se reutiliza por primera vez y se recupera mediante un barco.

Y todavía hay gente que afirma que todo lo relacionado con Elon Musk es humo.

miércoles, 5 de marzo de 2025

Monitorización del SAI con nut en Debian 12.

Ya hemos tratado varias veces en el pasado de este blog el tema de la monitorización del SAI del servidor desde Debian. Vamos a hacer ahora una recopilación de todo lo aplicado otras veces montado sobre Debian 12, que es el sistema que usamos a día de hoy. Vamos allá.

SAI que tenemos: un Salicru SPS One, que conectado por USB se detecta así:
# lsusb
...
Bus 002 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial
...
Paquetes a instalar:
# apt-get install nut-client nut-server nut-cgi
Antes de empezar la configuración se aconseja tener un servidor de correo activo para poder enviar los mensajes de cambio de estado del SAI. En el Apartado 2 de esta entrada del blog cuento como montar el sistema que mejor me ha funcionado: postfix reenviando los correos a través de una cuenta de gmail.com

Vamos ahora a ver los distintos ficheros de configuración. El primero es ups.conf, que tiene los datos para conecar al SAI. Una buena manera de saber que ponemos aquí es usar la salida del comando "nut-scanner".
# cat /etc/nut/ups.conf
maxretry = 3
[salicru]
driver = "nutdrv_qx"
port = "auto"
vendorid = "0665"
productid = "5161"
product = "HID UPS"
serial = ""
vendor = "HID UPS"
Los otros ficheros quedarían:
# cat /etc/nut/upsd.conf 
LISTEN 127.0.0.1
LISTEN 172.1.1.2 # PONER LA IP de la maquina donde se ejecuta la monitorización
LISTEN 0.0.0.0 3493
# cat /etc/nut/upsd.users
[admin]
password = mipasswordfavorita
actions = set
actions = fsd
instcmds = ALL
upsmon primary
# cat /etc/nut/hosts.conf 
MONITOR salicru@localhost "SAI Salicru Servidor"
# cat /etc/nut/nut.conf
MODE=standalone
# cat /etc/nut/upsmon.conf 
RUN_AS_USER nut
MONITOR salicru@localhost 1 admin mipasswordfavorita primary
MINSUPPLIES 1
SHUTDOWNCMD "/usr/local/bin/apagar_servidores.sh"
NOTIFYCMD "/sbin/upssched"
NOTIFYMSG ONLINE "UPS: Normal state"
NOTIFYMSG ONBATT "UPS: On battery"
NOTIFYMSG LOWBATT "UPS: Battery low"
NOTIFYMSG FSD "UPS: Starting shutdown"
NOTIFYMSG COMMOK "UPS: Communication restored"
NOTIFYMSG COMMBAD "UPS: Communication lose"
NOTIFYMSG SHUTDOWN "UPS: Shutting down"
NOTIFYMSG NOCOMM "UPS: No communication"
NOTIFYMSG REPLBATT "UPS: Replace battery"
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 NOCOMM SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5
# cat /etc/nut/upsset.conf 
# Network UPS Tools - upsset.conf sample file
#
# This file is provided to ensure that you do not expose your upsd server
# to the world upon installing the CGI programs.  Specifically, it keeps
# the upsset.cgi program from running until you have assured it that you
# have secured your web server's CGI directory.
#
# By default, your web server will probably let anyone access upsset.cgi
# once it is installed.  This means that anyone could attempt to crack
# upsd logins since they would appear to be coming from your web server,
# rather than the outside world, slipping through any ACL/ACCESS definitions.
#
# For this reason, you *MUST* first secure your CGI programs before
# enabling upsset in this configuration file.  If you can't do this in
# your web server, then you should *not* run this program.
#
# For Apache, the .htaccess file can be used in the directory with the
# programs.  You'll need something like this:
#
#   <Files upsset.cgi>
#       deny from all
#       allow from your.network.addresses
#   </Files>
#
# You will probably have to set "AllowOverride Limit" for this directory in
# your server-level configuration file as well.
#
# If this doesn't make sense, then stop reading and leave this program alone.
#
# Assuming you have all this done (and it works), then you may uncomment
# the line below and start using upsset.cgi through your web browser.
#
###
I_HAVE_SECURED_MY_CGI_DIRECTORY
###
# cat /etc/nut/upssched.conf
CMDSCRIPT  /usr/local/bin/avisoups.sh
PIPEFN /tmp/upssched.pipe
LOCKFN /tmp/upssched.lock
AT ONBATT * START-TIMER  ups-on-battery-shutdown  600
AT ONLINE * CANCEL-TIMER  ups-on-battery-shutdown
AT ONBATT * START-TIMER ups-on-battery 5
AT ONLINE * CANCEL-TIMER ups-on-battery
AT ONLINE * EXECUTE ups-back-on-line
AT REPLBATT * EXECUTE ups-change_battery
AT LOWBATT * EXECUTE ups-low-battery
AT COMMOK * EXECUTE ups-comunication-ok
AT COMMBAD * EXECUTE ups-comunication-bad
AT NOCOMM * EXECUTE ups-nocomm
AT FSD * EXECUTE ups-fsd
AT SHUTDOWN * EXECUTE ups-shutdown
Para probar que funciona podemos reiniciar los servicios e intentar conectar manualmente con SAI a ver si nos da los datos de carga, voltaje y demás:
# service nut-server restart
# service nut-monitor restart
# upsc salicru
Init SSL without certificate database
battery.charge: 100
battery.voltage: 27.10
battery.voltage.high: 26.00
battery.voltage.low: 20.80
battery.voltage.nominal: 24.0
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: HID UPS
driver.parameter.productid: 5161
driver.parameter.serial: 
driver.parameter.synchronous: auto
driver.parameter.vendor: HID UPS
driver.parameter.vendorid: 0665
driver.version: 2.8.0
driver.version.data: Mustek 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.current.nominal: 6.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 232.7
input.voltage.fault: 232.7
input.voltage.nominal: 230
output.voltage: 234.8
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 10
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665
Con lo anterior se ha instalado un interface web al que podemos acceder en la URL: "http://ip-maquina/cgi-bin/nut/upsstats.cgi?host=salicru@localhost". De los diferentes ficheros .cgi que permiten gestionar vía web el SAI me gusta dejar, por temas de seguridad, el fichero "upsset.cgi" sin permisos:
 ls -l /usr/lib/cgi-bin/nut/
total 140
-rwxr-xr-x 1 root root 45416 ene 25  2023 upsimage.cgi
-rwx------ 1 root root 43336 ene 25  2023 upsset.cgi
-rwxr-xr-x 1 root root 47456 ene 25  2023 upsstats.cgi
Ahora muestro los scripts que uso para manejar los eventos y comunicarlos al servidor:
# cat /usr/local/bin/apagar_servidores.sh
#!/bin/bash
# Ejecutado desde  upsmon.conf cuando se la la orden de apagado de servidores.

function mailSend() {

   echo "$2" | mail -s "$1" -a "From: Avisos.ies <tu.correo@gmail.com>"  tu.correo@educarex.es

}

FECHA=$(date)
estado=$(upsc salicru ups.status 2> /dev/null)
en_bateria=$(echo $estado | tr ' ' '\n' | grep "OB")

if [ -z $en_bateria ]  #Si en up.status no parece OB, no estamos en bateria. Es un SHUTDOWNCMD innecesario
then
   MESSAGE_MAIL="Evento SHUTDOWNCMD pero estado $estado. No apagamos el servidor"
   mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Evento SHUTDOWNCMD"
   echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log  # /var/log/sai.log permisos 644 y nut:nut
else
   MESSAGE_MAIL="Apagado servidor por evento SHUTDOWNCMD"
   mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Evento SHUTDOWNCMD"
   echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log  # /var/log/sai.log permisos 644 y nut:nut
   ssh root@tercero "/sbin/shutdown -h +0"
   sleep 10
   /sbin/shutdown -h +0
fi

exit 0
# cat /usr/local/bin/avisoups.sh
#!/bin/bash

function mailSend() {

   echo "$2" | mail -s "$1" -a "From: Avisos.ies <tu.correo@gmail.com>"  tu.correo@educarex.es

}

MESSAGE_MAIL=""
EVENT_TYPE=$1
APAGADO=0
FECHA=$(date)

case "$EVENT_TYPE" in
    "ups-on-battery-shutdown")
        MESSAGE_MAIL="UPS on battery: shutdown now"
        APAGADO=1
        ;;
    "ups-on-battery")
        MESSAGE_MAIL="UPS on battery: warning"
        ;;
    "ups-comunication-bad")
        MESSAGE_MAIL="Communications with UPS lost"
        ;;
    "ups-change_battery")
        MESSAGE_MAIL="UPS battery needs to be replaced"
        ;;
    "ups-back-on-line")
        MESSAGE_MAIL="UPS on line power"
        ;;
    "ups-low-battery")
        MESSAGE_MAIL="UPS battery is low"
        ;;
    "ups-comunication-ok")
        MESSAGE_MAIL="Communications with UPS established"
        ;;
    "ups-nocomm")
        MESSAGE_MAIL="No communication with UPS"
        ;;
    "ups-fsd")
        MESSAGE_MAIL="UPS FSD: forced shutdown received"
        APAGADO=1
        ;;
    "ups-shutdown")
        MESSAGE_MAIL="UPS shutdown: shutdown received"
        APAGADO=1
        ;;
esac

mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Event $EVENT_TYPE de SAI Virgen de Guadalupe:"
echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log

if [ $APAGADO = "1" ]
then
    sleep 30
    /usr/local/bin/apagar_servidores.sh
fi
Por último, si tenemos monit podemos controlar que los servicios están levantados:
# cat /etc/monit/conf.d/monitrc.nut
check process nut-monitor with pidfile /var/run/nut/upsmon.pid
   group nut
   start program = "/bin/systemctl start nut-monitor.service"
   stop  program = "/bin/systemctl stop nut-monitor.service"
   if not exist then restart
   if 5 restarts within 5 cycles then timeout

check process nut-server matching "/lib/nut/upsd"
   group nut  
   start program = "/bin/systemctl start nut-server.service"
   stop  program = "/bin/systemctl stop nut-server.service"
   if not exist then restart
   if 5 restarts within 5 cycles then timeout
Y con esto lo tenemos ya, el porqué de todas las cosas que se configuran en estos ficheros está explicado en los anteriores artículos dedicados a nut en este blog. Espero que este sea la entrada definitiva.

viernes, 14 de febrero de 2025

Paquete hp-health para servidores HP con Debian modernos.

A los que tenemos servidores HP el paquete hp-health viene muy bien para monitorizar (por ejemplo con monit) distintos parámetros físicos, como la temperatura, los ventiladores o el estado de las fuentes de alimentación redudantes que trae.

El paquete mas actualizado que ofrece HP para Debian en https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/ es hp-health_10.80-1874.10_amd64.deb, de 2019.

Si lo intentamos instalar sobre Debian 11 o superior con "dpkg -i health_10.80-1874.10_amd64.deb" nos da problemas de dependencias por librerías obsoletas. Muchas veces, cuando pasa esto la explicación es que las versiones o nombres de las librerias vinculadas están puestas a piñon y si pudieramos editar el .deb y cambiar esas dependencias por versiones mas modernas el paquete se instalaría sin problema. Vamos a ello:
# wget https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/hp-health_10.80-1874.10_amd64.deb
# dpkg-deb -R hp-health_10.80-1874.10_amd64.deb hp-health  
# nano hp-health/DEBIAN/control
En este fichero se guardan las dependencias. Tenemos que editar la linea "Version: XXX" para poner una versión mayor, por ejemplo "Version: 10.81" y la linea "Depends: XX" para poner las versiones actuales de las librerías que nos han dado error al intentar instalar el paquete. En mi caso, para instalarlo sobre Debian 12 lo debemos dejar así:
Depends: libc6 (>= 2.14), binutils, dmidecode, pciutils, libc6-i386 | lib32gcc-s1
Simplemente, en este caso cambiamos "libc6-i686 | lib32gcc1" por "libc6-i386 | lib32gcc-s1", su equivalente en Debian 12. Una vez editado el fichero de control reempaquetamos todo en un nuevo .deb:
# dpkg -b hp-health hp-health_10.81_amd64.deb 
# dpkg -i hp-health_10.81_amd64.deb 
Y con esto se instala sin problemas en nuestro Debian. Ya tenemos el paquete disponible para otra temporada.