Étiquette : nut

Onduleur – Surveillance sur le réseau

Dans un article précédent, nous nous étions quitté avec une connexion directe par USB entre l’une des machines connectée à l’onduleur et l’onduleur lui-même. Aujourd’hui, retour sur la configuration du service de surveillance de l’état de l’onduleur, cette fois pour que la machine connectée partage l’information sur le réseau. Le but étant que les autres machines connectées à l’onduleur soit elles aussi capable de connaître son état, de déclencher un arrêt en cas de batterie faible et ainsi, de pouvoir s’éteindre avant de subir une perte de courant totale.

Je repars ici de ma configuration déjà en place. Comme la première fois, plusieurs fichiers sont à modifier, mais en nombre plus réduit. Je commence par éditer le fichier /etc/nut/upsd.users, sur la machine déjà configurée en mode client et connectée à l’onduleur, pour y ajouter un utilisateur « esclave » qui servira à mon autre ordinateur pour l’authentification des demandes d’état.

[slave]
  password = PASSWORD
  upsmon slave

Je modifie ensuite /etc/nut/upsd.conf pour que le serveur nut soit accessible sur le réseau et non plus seulement en localhost; en considérant que l’IP de ma machine est statique.

LISTEN 192.168.24.42 3493

J’enchaîne ensuite avec /etc/nut/nut.conf, où je précise que nut devra désormais fonctionner en mode serveur.

MODE=netserver

Enfin, pour terminer la configuration de la machine principale, je redémarre ups-monitor et nut-server.

Passons maintenant à la machine cliente, où, après avoir installé nut, je définie la manière dont nut va récupérer les informations d’état de l’onduleur, en modifiant /etc/nut/upsmon.conf. J’utilise ici l’utilisateur « slave » configuré précédemment.

MONITOR eaton@192.168.24.42 1 slave PASSWORD slave

Ensuite, édition du fichier /etc/nut/nut.conf afin de préciser le mode de fonctionnement de nut, à savoir ici, client du réseau.

MODE=netclient

Pour finir sur cette machine cliente, redémarrage de ups-monitor et nut-client.

Dernier point de configuration important, mais non lié à nut, au démarrage, j’ai constaté que nut n’était pas capable d’écouter sur l’IP définie dans la configuration, cela étant due, au fait que la récupération de l’IP était encore en cours d’acquisition (statique côté DHCP), au moment du démarrage de nut. Pour palier au problème, j’ai configuré mon RPI pour attendre la connexion au réseau avant de continuer plus avant dans la procédure de boot. Sur un RPI, la configuration s’effectue comme suit :

  • sudo raspi-config
  • 3 Boot Options
  • B2 Wait for Network at Boot
  • « Yes ».
  • Sauvegarder et quitter.

Une fois ces configurations réalisées sur mes deux machines, je suis en mesure de consulter l’état de l’onduleur sur chacune des machines. Un test d’arrêt forcé, m’a permis de vérifier que l’extinction de la machine cliente a bien lieu avant l’extinction de la machine ayant le rôle de serveur, et de m’assurer que l’ensemble redémarre sans assistance au retour du courant.

Onduleur – Nut en client direct

Il y a de cela quelques semaines, j’ai fait l’acquisition d’une pièce manquante de mon réseau interne, à savoir: un onduleur. Je n’avais pas, jusqu’à présent, considéré cet élément comme indispensable, mais la perspective d’un déplacement professionnel de plus d’une dizaine de jours m’a poussé à l’achat. J’espère ainsi protéger mes services auto-hébergés d’une éventuelle coupure de courant.

Une coupure de courant reste un événement relativement exceptionnel, du moins dans mon environnement géographique, puisqu’après plusieurs années d’auto-hébergement, je n’ai jamais eu d’arrêt de service provoqué par un défaut d’alimentation. Après avoir considéré ces facteurs, un onduleur a donc trouvé sa place dans mon logement, à proximité du routeur, du switch, etc… N’ayant pas noté d’interruption de service durant mon déplacement, je peux en déduire que l’onduleur a rempli son rôle…, ou que le réseau électrique est resté stable, comme à son habitude.

Bref, après m’être contenté du raccordement électrique des périphériques à l’onduleur, je me suis intéressé à la configuration d’un service de surveillance de l’état de l’onduleur. Le but étant de détecter un état de batterie faible subséquent à une coupure de courant, et d’être ainsi en mesure de procéder proprement et automatiquement à l’extinction des composants critiques du réseau, serveurs et routeur en particulier.

Voici donc, à la suite, la configuration déployée sur la machine chargée de la surveillance de l’onduleur. Les deux éléments sont connectés via le cable USB fournit avec l’onduleur. Une dernière chose, mon onduleur est de marque Eaton. Entrons maintenant dans le vif du sujet.

Après avoir connecté l’onduleur, un petit tour du côté du contenu de dmesg, me permet de vérifier que celui-ci est détecté. Je procède également à l’installation de nut via aptitude install nut.

[238029.826593] hid-generic 0003:0463:FFFF.0001: hiddev96,hidraw0: USB HID v1.10 Device [EATON Ellipse PRO] on usb-3f980000.usb-1.5/input0

Avant d’aller plus loin et pour pouvoir commencer à configurer nut, il est nécessaire de déterminer le driver à utiliser pour l’onduleur. Pour trouver cette information, il est conseillé de s’aider de la page « Hardware compatibility list« . Pour ma part, je n’ai pas trouvé mon modèle dans la liste (Eaton Ellipse Pro), mais les modèles présents les plus récents et les plus proches de la gamme « Ellipse Pro », indiquent de choisir usbhid-ups.

Munis de cette information, je peux donc passer à l’édition du fichier /etc/nut/ups.conf, afin de déclarer l’onduleur dans nut.

[nom_onduleur]
        driver = usbhid-ups
        port = auto
        desc = "EATON UPS"

A ce stade, il est déjà possible d’effectuer un premier test de fonctionnement.

$ sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39

Après avoir vérifié avec la commande ci-dessus que notre déclaration de l’onduleur est correct, c’est-à-dire, que nut communique bien avec l’onduleur, je passe à l’édition du fichier /etc/nut/upsd.conf, afin de n’autoriser que les connexions provenant de la machine locale.

LISTEN 127.0.0.1

Il convient ensuite de définir un utilisateur qui sera ensuite autorisé à accéder à l’état de l’onduleur. Cette fois, les modifications sont apportées au fichier /etc/nut/upsd.users.

[nom_utilisateur]
     password = PASSWORD_HERE
     upsmon master

Pour la suite, je modifie /etc/nut/upsmon.conf, pour configurer la surveillance de l’onduleur. A noter qu’il est possible de configurer la commande d’extinction, en modifiant la propriété SHUTDOWNCMD. J’ai de mon côté configuré la propriété NOTIFYCMD, en précisant le chemin vers un script relativement simple ayant pour rôle de m’envoyer un mail pour les événements ONLINE, ONBATT et LOWBATT, comme l’indique la présence de l’instruction EXEC pour chacune des trois lignes NOTIFYFLAG.

MONITOR nom_onduleur@localhost 1 nom_utilisateur PASSWORD_HERE master

NOTIFYCMD /path/to/script/notif-ups.sh
NOTIFYFLAG ONLINE       EXEC+SYSLOG+WALL
NOTIFYFLAG ONBATT       EXEC+SYSLOG+WALL
NOTIFYFLAG LOWBATT      EXEC+SYSLOG+WALL

Enfin, le dernier fichier à modifier est /etc/nut/nut.conf, pour déterminer le mode de fonctionnement de nut. L’utilisation se limitant à une seule machine pour le moment, j’utilise donc le mode client seul.

MODE=standalone

Maintenant que l’ensemble est configuré, il est possible de récupérer les informations de l’onduleur par appel à la commande upsc nom_onduleur@localhost. Ayant réussi à obtenir les informations d’état de l’onduleur, il reste à effectuer un dernier test, en simulant une situation nécessitant l’arrêt de la machine connectée à l’onduleur.

sudo upsmon -c fsd

La demande d’exécution de l’arrêt forcé est particulièrement intéressante, puisqu’elle m’a permit de vérifier la bonne extinction de la machine surveillant l’onduleur. J’ai été un peu surpris, car l’onduleur, simule également une coupure complète et un retour du courant sur toutes les prises. Quelques appareils ont donc subi un arrêt un peu rude, mais cela m’a permis de vérifier que tout le système est capable de revenir à un fonctionnement normal automatiquement.

Il faudra néanmoins que je prévois un test de coupure complète en débranchant l’onduleur, afin de tester le comportement de l’ensemble dans cette situation. Par ailleurs, il me reste à modifier cette configuration de surveillance de l’onduleur, afin de passer à un modèle client-serveur et d’être en mesure de partager les informations d’état avec les autres composants branchés à l’onduleur et que ces derniers soient en mesure de déclencher leur arrêt avant une coupure totale du courant.

Source :