Dans le but de pouvoir stopper proprement un hyperviseur VMware et ses machines virtuelles en cas d’alerte onduleur, voici une solution pour intégrer un client NUT (Network UPS Tools) natif à vSphere Hypervisor (ESXi 5.0, 5.1, 5.5, 6.0, 6.5, 6.7, 7.0, 8.0 testés). Le client NUT est installé dans l’hyperviseur et peut être contrôlé et paramétré depuis l’interface de configuration de ESXi ou depuis le vCenter s’il est géré.
Mise en garde 01/11/2023 : Sous ESXi 8.0 et à partir de la version 2.5.0 du client Nut, dans l’interface client HTML, vous ne verrez pas les descriptions associées aux UserVars du client NUT à jour tant que le host ESXi n’aura pas rebooté.
Mise à jour du 19/10/2022 : ESXi 8.0 est sorti ce 11/10/2022, seules les versions du module avec un numéro de version supérieur à 2.3.2 pourront s’installer sur cette nouvelle version de ESXi (abandon du support des binaires 32-bits et checksum SHA256 requis dans la signature du module).
Principe
La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Le schéma classique minimal des connexions entre les éléments d’un réseau électrique protégé par un onduleur est le suivant :
Câblage Onduleur
Cette solution n’est pas officiellement supportée par VMware et elle ne s’applique qu’à des hyperviseurs standalone. Elle ne peut pas convenir pour des fermes d’hyperviseurs en cluster de haute disponibilité sous le contrôle d’un vCenter. Seul le client NUT est ajouté à l’hyperviseur, l’onduleur doit être surveillé par un serveur NUT indépendant.
Caractéristiques et fonctionnalités
- La méthode d’installation utilise un fichier VIB (vSphere Installation Bundle). Il n’y a rien d’autre ce qui permet une installation rapide et sûre et une désinstallation propre en utilisant les standards de VMware.
- La compatibilité du module a été assurée pour qu’il fonctionne sur toutes les versions de ESXi entre 5.0 et 8.0. Cependant pour les versions 5.x l’installation automatique par déploiement de ViB n’est pas possible, il faut l’installer manuellement en suivant les instructions ci-dessous et passer outre les avertissements de sécurité. A partir de la version 6.0 de ESXi il n’y a plus ce soucis.
- C’est un client NUT 2.8.1 qui est inclus dans le paquetage. Il peut se connecter aux serveurs avec une version plus ancienne (disons 2.6.4 mais je n’ai pas testé les serveurs plus anciens).
- Actuellement seule la version pour processeur x86 est disponible. Il n’y a pas de version pour ESXi ARM (je n’ai ni le besoin ni la plateforme de test/développement pour ça).
- Le client (secondary dans la terminologie NUT) peut se connecter au serveur (primary) en privilégiant une connexion SSL/TLS si elle est disponible. Il ne sera pas fait de vérification de validité de certificat serveur et il n’y a pas de certificat client configurable.
- Le client peut envoyer un mail très succinct à une adresse configurable lors de la réception d’un évènement onduleur (perte du secteur, batterie faible, engagement de l’arrêt, retour du secteur). L’outil mail est très simple et il récupère les informations pour l’envoi des messages du DNS (enregistrements MX). Vous pouvez aussi utiliser un relais SMTP personnel.
- Le client peut se connecter à plusieurs serveurs NUT s’il y a plusieurs onduleurs (cas des serveurs avec une redondance d’alimentation). Il utilisera le même compte et le même mot de passe pour se connecter aux différents serveurs NUT. A vous de déclarer ce compte sur tous les serveurs NUT.
- Normalement il est possible de préciser le port TCP de connexion au serveur NUT sous la forme onduleur@serveur:port mais ESXi impose des règles de firewall pour le trafic sortant et seul le port 3493 est autorisé. C’est le port par défaut des serveurs NUT.
- Il est possible de demander l’arrêt du système ESXi après un laps de temps sur batterie configurable. Le client reste à l’écoute de l’évènement batterie faible et le système entamera sa procédure d’arrêt soit après le temps imparti soit sur évènement de batterie faible, au premier des deux qui surviendra quand le système est sur batterie. L’attente est interrompue si le courant secteur est rétabli entre temps, mais si la procédure d’arrêt a déjà été initiée, elle ira jusqu’à l’extinction du host ESXi.
- Le redémarrage du serveur après une coupure de courant est aussi une phase importante mais c’est à vous de le prévoir avec d’autres outils. Personnellement (mais ce n’est qu’une suggestion) j’aime bien l’idée d’un chef d’orchestre qui redémarre automatiquement. Il surveille le retour des services tels que le réseau, le serveur NUT etc… et il envoie des trames WOL pour réveiller les machines dans l’ordre désiré. Configurez votre serveur NUT pour qu’il ordonne à l’onduleur de couper effectivement le courant pendant un petit laps de temps même si le courant est revenu pendant la procédure d’arrêt. La plupart des onduleurs ont cette fonction avec les libellés « Interval to wait after shutdown with delay command » et « Interval to wait before (re)starting the load ». Certains onduleurs ont aussi une valeur « Minimum battery level for restart after power off » qui est interessante pour attendre que l’onduleur ait suffisamment rechargé ses batteries avant de faire redémarrer le système. Le risque est de se retourner dans une situation où un second arrêt propre serait impossible si une nouvelle coupure de secteur se produit juste après le redémarrage (ce qui est plutôt fréquent).
- Le client tourne avec le compte root. C’est habituellement déconseillé par la documentation du projet NUT mais l’hyperviseur a un nombre très limité de comptes locaux. Ce nombre de compte s’est beaucoup réduit au fil des versions. Des comptes restants, root est le seul encore utilisable.
Téléchargement du module
Pour toutes les versions de ESXi, l’installation peut se faire en ligne de commande sur l’hyperviseur : un fichier TAR compressé doit être déposé sur l’hyperviseur.
Téléchargez ici le fichier
Télécharger “NutClient-ESXi (binaires)” NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz – 821,90 Ko
A partir de ESXi 6.0 vous pouvez utiliser le bundle offline pour une installation en ligne de commande en appelant la commande « esxcli software vib install -d » . Ou par le manager de mises à jour du vCenter si vous en avez un.
Téléchargez ici le bundle offline.
Télécharger “NutClient-ESXi (offline bundle)” NutClient-ESXi-2.8.2-2.6.2-offline_bundle.zip – 823,83 Ko
Vous pouvez créer votre propre package personnalisé à partir des sources. Elles sont distribuées sous licence GPLv3 (GNU Public License version 3). Utilisez un environnement de développement linux 64 bits tel que CentOS 7 avec les outils de compilation et développement C habituels. Un fichier INSTALL décrit la procédure. Les sources sont disponibles également dans un dépot git publique : NutClient-ESXi
Téléchargez ici les sources
Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.8.2-2.6.2-src.tar.gz – 121,64 Ko
Installation
Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Cela est fait à partir de l’interface d’administration ESXi ou de la console DCUI. A partir de l’interface d’administration : dans la rubrique gérer de votre hôte, onglet services, dans la liste sélectionnez TSM-SSH et démarrez le service. Le service ssh sera actif jusqu’au prochain reboot de l’hyperviseur ou pendant un temps limité selon la version de votre ESXi.
Copiez le fichier NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz dans le répertoire /tmp du host ESXi. Ici je vous donne l’exemple depuis une machine linux (remplacez 10.0.0.8 par l’adresse IP du host ESXi ou son nom FQDN). Depuis Windows vous pouvez utiliser l’outil gratuit WinSCP.
[root@linux ~]# scp NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz root@10.0.0.8:/tmp The authenticity of host '10.0.0.8 (10.0.0.8)' can't be established. RSA key fingerprint is 89:49:ce:6d:... ...:40:76:7a:4a:fe. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.8' (RSA) to the list of known hosts. Password: (saisir le mot de passe administrateur ESXi) NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz 100% 869KB 1.9MB/s 00:00
Passez votre hyperviseur au niveau d’acceptance Communauté si ce n’est pas déjà fait !
Connectez-vous root en ssh à l’hôte ESXi et tapez la suite de commandes suivantes pour installer le VIB (l’opération peu être longue si votre système est installé sur une clé USB lente) :
~ # cd /tmp /tmp # tar -xzf NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz /tmp # sh upsmon-install.sh Installation Result Message: Operation finished successfully. Reboot Required: false VIBs Installed: Margar_bootbank_upsmon_2.8.2-2.6.2 VIBs Removed: VIBs Skipped:
Vous n’avez pas besoin de rebooter pour commencer à utiliser le client NUT sur votre système. Vous devez toutefois le configurer avant son premier lancement.
Vous pouvez supprimer les fichiers qui ont été créés dans /tmp et désactiver le service SSH
Configuration
A l’aide de l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez les paramètres avancés de l’onglet Système et filtrez la liste sur UserVars.Nut, vous avez 8 variables à configurer :
Configuration du client NUT sous ESXi7
- UserVars.NutUpsName : Nom de l’onduleur sur le serveur NUT (sous la forme nom_onduleur@nom_ou_ip_serveur). Plusieurs onduleurs peuvent être saisis séparés par un espace. Il n’y aura pas d’arrêt système tant que le dernier onduleur encore debout n’aura pas donné l’ordre d’arrêt.
- UserVars.NutUser : Nom du compte de connexion au serveur NUT
- UserVars.NutPassword : Mot de passe du compte de connexion au serveur NUT
- UserVars.NutFinalDelay : Secondes qu’il faudra attendre après la réception de l’événement batterie faible pour procéder à l’arrêt du système
- UserVars.NutOnBatteryDelay : Délai en secondes après le début du passage sur batterie de l’onduleur pour stopper le système. Si la valeur est 0 alors le client NUT attendra l’évènement batterie faible pour stopper le système. La valeur par défaut est 0, c’est le fonctionnement normal pour garder le système en fonctionnement le plus longtemps possible. Si l’onduleur repasse sur secteur avant la fin du délai, le système ne sera pas stoppé.
- UserVars.NutSendMail : A mettre à 1 pour que le client NUT envoie un e-mail à chaque évènement important de l’onduleur. La valeur 2 permet d’avoir dans le mail l’état des l’onduleurs lors de l’évènement.
- UsersVars.NutSmtpRelay : Nom ou IP d’un relai SMTP pour y faire transiter le mail. Laisser vide ou saisissez none pour ne pas utiliser de relai (none par défaut).
- UserVars.NutMailTo : Adresse e-mail à laquelle envoyer les évènements de l’onduleur
- UserVars.NutMinSupplies : Pour les systèmes multi onduleurs. Le nombre d’onduleurs qui doivent être en capacité d’alimenter le système avant d’entamer un arrêt. Ce nombre doit être inférieur ou égal au nombre d’onduleurs définis dans UserVars.NutUpsName. Si vous ne respectez pas cette contrainte, le client ne démarrera pas. Avec un seul onduleur, laissez la valeur à 1.
Notez qu’à chaque modification de ces paramètres il sera nécessaire de faire un arrêt/relance du service pour leur prise en compte.
Lancement du service
A l’aide de l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez l’onglet Services, trouvez et sélectionnez le service NutClient dans la liste:
Client NUT dans les services ESXi7
Dans les actions du service, choisissez la stratégie démarrage (Démarrer et arrêter avec l’hôte me semble un bon choix). Vous pouvez également le démarrer immédiatement ou l’arrêter.
Configuration du lancement de NUT Client
Astuces
Utilisez la rubrique démarrage automatique de l’onglet Système de l’hôte ESXi pour décider de l’ordre de démarrage et d’arrêt (ou suspension) des machines virtuelles. Cet ordre sera respecté par la procédure d’arrêt sur alerte onduleur. Un bug de ESXi fait que les valeurs par défaut ne sont pas respectées. Vous devez configurer ces paramètre pour chaque VM au moins une fois (quitte à la dé-configurer ce qui la fera réellement suivre les règles par défaut).
Important : L’arrêt propre des OS dans les machines virtuelles n’est possible que si les vmware tools sont installées. Sinon l’arrêt sera brutal, préférez alors une suspension dans la configuration d’arrêt de la VM.
Là encore je rappelle que cette solution n’est pas adaptées aux fermes cluster avec haute disponibilité. Si HA est activé sur la machine hôte le mécanisme d’arrêt propre des VM n’est plus respecté et l’arrêt sera brutal pour toutes les VM.
UEFI secure boot
Si votre hôte ESXi est configuré pour booter en mode UEFI secure boot, l’installation du ViB restera compatible avec cette configuration. En revanche vous ne pouvez pas descendre le niveau d’acceptation à CommunitySupported quand secure boot est activé. Vous devrez :
- rebooter pour aller dans les paramètres UEFI de votre carte mère
- désactiver le secure boot dans les paramètres UEFI de votre carte-mère
- booter (sans secure boot)
- descendre le niveau d’acceptation à CommunitySupported
- Rebooter une seconde fois pour retourner dans les paramètres UEFI
- réactiver le secure boot
- booter (avec secure boot).
Vous aurez secure boot actif et le niveau d’acceptation minimal à CommunitySupported.
Désinstallation
Pour désinstaller le client NUT, utilisez le script upsmon-remove qui se trouve dans le fichier que vous avez téléchargé :
/tmp # sh upsmon-remove
Test
Pour estimer le temps nécessaire au serveur pour s’éteindre sur alerte onduleur tapez la commande « /opt/nut/sbin/upsmon -c fsd » sur le host ESXi (par ssh ou sur la console). La procédure d’arrêt est immédiatement lancée (ne faites pas ça si vous n’aviez pas prévu d’arrêter votre machine).
We have vsphere 6.0 U2.
After installing via ssh on the esxi server I do not get the extra 6 USERVAR options.
any suggestions ?
Use the heavy client or reboot hypervisor
Ottimo lavoro. Bravissimo!!!
travail tres bon (excusez mon francais)
Bonjour René,
Merci, tout d’abord, pour ces articles fort intéressants.
J’ai 2 petites questions:
A quoi sert l’estimation du temps nécessaire pour l’arrêt de l’ESX (commande upsmon -c fsd) ?
J’imagine que c’est pour affiner le réglage, mais sur quels paramètres ?
UserVars.NutFinalDelay sur le client ou HOSTSYNC sur le serveur NUT ?).
Merci d’avance pour votre réponse.
Il est bon de connaitre le temps nécessaire pour un arrêt propre du système. C’est principalement pour régler le seuil de déclenchement de l’évènement batterie faible sur le serveur NUT (qui va envoyer un ordre d’arrêts aux clients). Certains onduleurs peuvent être configurés pour déclencher cet évènement sur un pourcentage de charge de batterie ou sur une autonomie en minutes et parfois les deux. Imaginons que le système a besoin de 7 minutes pour un arrêt propre mais que l’onduleur soit réglé pour alerter quand il ne reste que 5 minutes d’autonomie. Le courant sera coupé par l’onduleur avant la fin de l’arrêt du système. C’est à éviter.
Pour résumer, le temps d’arrêt permet d’affiner le réglage du seuil batterie faible sur le serveur NUT.
Sur le client NutFinalDelay est un délai en secondes avant de déclencher l’arrêt du système sur réception de l’ordre d’arrêt du serveur NUT. Il allonge le temps d’arrêt de l’hyperviseur.
Sur le serveur HostSync est le temps maxi qu’attendra le serveur pour que les clients se déconnectent avant de poursuivre sa propre procédure d’arrêt.
Merci pour cette rapide réponse ^^
Si le serveur NUT déclenche son arrêt avant que ces clients (ESX au autre) ne se soient arrêtés, il y a un risque (si je ne fais pas erreur) que l’onduleur passe en poweroff avant l’arrêt ‘propre’ des clients ?
Donc j’en conclu que le « HostSync » doit correspondre au temps d’arrêt max du client le plus lent ?
Oui pour HostSync, si un client met plus de temps alors on considère que c’est une anomalie et l’arrêt du serveur a quand même lieu.
J’ai une dernière question …
Elle concerne le déclenchement d’arrêt des VM sur l’ESX.
Est-ce qu’il se fait à l’issue du NutFinalDelay ou avant dès réception par le client NUT réceptionne la demande d’arrêt.
Merci
En principe c’est a l’issue du NutFinalDelay. Ce paramètre m’a été demandé par des utilisateurs qui hébergent le serveur NUT dans une machine virtuelle de l’hyperviseur même. Ca permet au serveur NUT de lui laisser un peu de temps avant d’être coupé.
Ping : Installing NUT on ESXi 4.1 – Darkglade
Hi!
Im a long time user of the nut client for ESXi with v6.0.
Thank you, It works perfectly (with hostsync/finaldelay adjusted properly).
Does it support ESXi v6.5? Im considering upgrading…
Regards,
LCH
I’m considering testing. Still haven’t find time for that… I will update the post as soon as I have the answer
Great! Thanks again!
I have tested sucessfully Nut client on a fresh ESXi 6.5 install, it works exactly the same as before (tested with or without SSL, on IPv4 and IPv6). The only quirck is the UserVars not showing up in the new HTML5 interface right after the install. I had to reboot ESXi to see them (maybe just restarting the hostd service is enough, not tested).
If you perform an upgrade of your existing hypervisor I would advise you to uninstall nut client before upgrade. Then reinstall nut client after the upgrade to prevent errors during the upgrade process due to ViB not compliant with VMWare security scheme.
Type
services.sh restartin the ESXi shell if you wan to see UserVars in HTML5 interface without ESXi reboot. You will need to reconnect to ESXi HTML5 interfaceHi René,
First of all, thank you very much for your work — the NUT client works very well.
Anyway, I was wondering if you know that you can complete all the tasks handled by yours scripts directly as part of the VIB install/uninstall? I mean, stuff like adding the user variables can be handled automatically by including an specific type of script in /etc/init.d. I have repackaged your VIB to do just that, so it can be added to customised ESXi installers.
If you are interested, feel free to contact me via email and I will send you a copy of the script. You can then evaluate that and add to your package if deemed appropriate.
Once again, thank you for your work.
Jose
Hi Jose,
Yes you can send me your customised vib or script. I have not searched the way to have a included script automatically run at VIB install, this would be more elegant than the way I do with the install/uininstall scripts but I want the User Variables to be available and configurable before starting the nut client service. I’m sending you and email to confirm.
Hi,
many thanks for the solution.
I have a big problem, the service does not autostart. I used the VMware Host Web Client on free ESXi 6.5 and set the service (via the services tab, written to the security policy) to autostart, but no autostart is performed after reboot(s). Any ideas? I also tried with the Client software, all state they change the policy but settings is gone each reboot. I did the same with NTP and that worked.
Regards,
Christian
Can’t edit, so just a short post to keep updated on comments, sorry for that.
Hi
Usually if service is set to « stop and start with host » it should be ok. Then if parameters (uservars) are wrong service may fail to start
Hi,
that’s exactly what I set but setting get lost with reboot. Values are correct as manual start works and script verify also.
Regards,
Christian
It works fine on my 6.5 test hypervisor. This is what I do :
– enable ssh to connect to hypervisor.
– login to hypervisot and download in tmp tgz file. Untar file
– run upsmon-install.sh
– restart hostd service (to avoid reboot) : /etc/init.d/hostd restart
– log in vmware UI https://youresxi_IP/ui/ as root
– In host advanced setting set Uservar.Nut* parameters to match your configuration
– In host services select Network UPS Tools Client
– In action/strategy set « start and stop with host »
– start service
– check your UPS server log to see if your esxi has sucessfully connected to it
– restart host from UI. In server log you should see the client disconnect and then reconnect when rebooted
Hi,
that’s exactly what I did. But with each reboot, the action/strategy set is lost and reset to manual start.
How to check the server log? My server is a Synology and I don’t see a server log there. I have a syslog but I can’t find any event like this there. However, upsc on ESXi worked well and gave same response about the UPS as the Synology does itself.
Regards,
Christian
Hi,
I just recognized, the service seems to run, although security policy as well as the services tab itself states it’s not running, neither via Web Host GUI nor via old Client GUI nor via PowerCLI. Maybe it’s because of the long name « Network UPS Tools Client »? I had big trouble to try out to set the security policy via PowerCLI as it got not recognized, I needed to pipe a find on the services and then pipe to the set service policy command. Maybe it would work better, if the client states itself as upsmon (similar to the daemon name)?
Regards,
Christian
Ok, I see. I’ve made a second test and you are right. Service looks disabled on HTML client (esxui) even if it’s running. This is a 6.5 only behaviour as it works under 5.5 and HTML client. I tried to update to latest esxui bundle but it makes no change.
Long name is only a friendly name. Internal service name is upsmon. I will try with a short name just to see if it makes any difference.
Edit: Tested also on ESXi 6.0, service is shown running. So it’s a 6.5 version only bug
Tested with short service name… nope. Service is still shown not running. I put some traces in service script and I see that status is not called from the web interface. So it cannot know if service is running or not.
Hi,
strange. However as long as it’s running, everything is fine. 😉 I now started to install ghettovcb but get a dependency error and violation of security policy warning. I just was able to install with -f. Is this because of community signed? I changed the security level to community.
Regards,
Christian
Upsmon vib violates some security constraints as it installs binary executables in the system directories. This is not allowed for CommunitySupported VIBs
Ah, okay. Does this now always pop up if I install other VIBs as security alert? As I’m wondering, what ghettovcb has to do with upsmon when I try to install it?
Yes, you will have this error message for each VIB install/upgrade/remove operation as long as upsmon VIB is installed. You can add –no-sig-check or -f to esxcli command to avoid acceptance level verification.
I tried –no-sig-check but that failed with ghettovcb (as I already set acceptance level to Community), however, I believe, what you wrote, that the not allowed binaries in system directories cause the error message, which can only be ignored by forcing with -f
Christian,
All subsequent VIB installations (even if they are from VMware) will be affected and will require the force flag (-f).
However, the limitation of not writing to system folders is only applicable to ESXi 5.x, and has been dropped for 6.x. What it means is that CommunitySupported VIBs can now write to system folders and are not subject to the security constraints — as long as the acceptance level is changed accordingly.
If you are running ESXi 6.5, you can simply remove the VIB and reinstall without the force flag. You will need to edit René’s install script (upsmon-install.sh) and remove the -f flag from the install command.
Jose
Unfortunately my tests confirm that some restriction is still present and I have the error message « VIB Margar_bootbank_upsmon_2.7.4-1.4.0vmw.500 violates extensibility rule checks » if I don’t set -f of –no-sig-check under 6.0 or 6.5
It’s the same for me. I tried to reinstall but it’s the same behavior. However, to get further with ghettovcb I also was not able to install with –no-sig-check as before, I’m required to use -f instead.
Hi René/Christian
I have to apologise. You are absolutely correct as the VIB will not install without the force flag… I might have performed my test install with the -f flag without noticing. I do have a couple of VIBs for USB Ethernet drivers I ported from Linux, which required the force flag on ESXi 5x, but not on 6.x — that is the reason I mistakenly assumed sings had been relaxed.
Anyway, I have been playing around and got two different ways to get the VIB installed without the force flag:
1. Set the VIB acceptance level to VMware Accepted — this will allow the VIB to install with the —no-sig-flag, which is better than -f as it doesn’t interfere with the installation of other VIBs
or what I did
2. Recompile the client to use /opt as prefix, including for the configuration files — with the binaries and configuration under /opt you can also get rid of the file under /etc/vmware/secpolicy (also not allowed). With the acceptance level set to CommunitySupported the VIB will install without -f or —no-sig-check.
Off course, I also had to edit the scripts to reflect the new location for the binaries and configuration file. Something else I did was to compile the client binaries statically, so that libraries don’t need to be included. The contents of the payload become:
etc/
etc/vmware/
etc/vmware/service/
etc/vmware/service/upsmon.xml
etc/vmware/firewall/
etc/vmware/firewall/upsmon.xml
etc/init.d/
etc/init.d/install-upsmon
etc/init.d/upsmon
opt/
opt/upsmon/
opt/upsmon/sbin/
opt/upsmon/sbin/upsmon
opt/upsmon/etc/
opt/upsmon/etc/upsmon.conf.template
opt/upsmon/etc/notify.sh
opt/upsmon/etc/notify.conf.template
opt/upsmon/bin/
opt/upsmon/bin/upsc
opt/upsmon/bin/smtpblast
If you would like to test the VIB let me know and I will send it to you via email. I can also send any other details, such a compilation flags, etc.
Note: I removed the step to reload hostd from the install-upsmon. Reloading hostd manually after installation is required for the user vars to appear in the GUI, though.
Jose, sounds interesting. Can you send me the VIB?
Hi Christian,
I believe René will be preparing a new release of the client, but send me an email (gomesjj at devtty.co.uk), and I will send you the VIB.
Jose
Yes I’m working on a new version of the Nut client but I’m still facing some issues. I’m trying to make the ViB « community compliant » but it’s not as easy as I thought. I wish to keep the NUT source code unmodified. Testing takes a lot of time.
Hi René,
You don’t need to modify the source code — just change the runtime options at compilation time. I will send you an email with the options I used to compile with /opt as prefix.
Jose
Client 2.0.0 released. Post updated
Hello,
Thank you for this great packaging.
I am wanting to do custom handling for ONBATT-plus-1_minute in order to shut down early some VMs instead of waiting for LOWBATT. (MS Windows has no good, scriptable Nut client, or else I would use that). Please may I request to bundle upssched and to support a user-specified NutUpsSchedDotConf variable to activate upssched as the NOTIFYCMD (and associated conf)?
I would put the source upssched.conf and supporting scripts on a local datastore. (Still I would call /etc/ups/notify.sh as needed).
Binary file upssched is not in the VIB but the reason is simple : you have no simple way to give a configuration file to it. Just imagine that the system is running on a volatile filesystem. Each time you reboot, the filesystem is recreated from scratch and all your changes are lost. The only way is to have a fixed configuration or to create it from UserVars when service starts (as I did in this service). You may say that I could store it on a datastore but I don’t want to encourage this.
What about /etc/rc.local.d/local.sh? That is persistent across reboots, and a couple of here-documents could be used to write /opt/nut/etc/upssched.conf and a supporting NOTIFYCMD script.
Feel free to modify the package as you want. This is opensource software under GLP licence and NUT client is just compiled unmodified. I will not make this changes myself. This package was fist written for my own configuration and I am sharing it for whom it will be useful but I know that it can’t match 100% of people’s need. For those who don’t have an UPS that can send an event on low battery the package may be useless and I understand that upssched is the solution. I did this on my spare time (as most opensource projects)
Hi,
which kind of UPS do you use? How to determine, if the battery give this signal? I have a APC Back UPS 650 Schuko.
Regards,
Christian
I’m using quiet old UPSes : APC SmartUPS 3000 (su3000inet) using RS232 connection, EATON Ellipse 1000 (USB) and MGE Protection Center 675 (USB). Usually to know if an UPS can send the lowbatt event, look for the battery.runtime.low or battery.charge.low attribut with upsc command. Somme UPS will use a remaining timing estimation other will use a battery charge threshold. You can configure this on many UPS using the upscmd command. You should take a look to NUT project and documentation. This is on the NUT server side.
Great, many thanks for your work, recommendations and tipps. I have both values on my Back UPS 650. So I will see, what will happen then on power interruption.
Bonjour René
Je viens de mettre en application votre nouveau client NUT
Bravo pour votre travail.
J’ai une question concernant les variables UserVars.Nut notamment celles-ci :
UserVars.NutUpsName : Nom de l’onduleur sur le serveur NUT (sous la forme nom_onduleur@nom_ou_ip_serveur).
UserVars.NutUser : Nom du compte de connexion au serveur NUT
UserVars.NutPassword : Mot de passe du compte de connexion au serveur NUT
J’utilise un serveur NAS Synology comme serveur NUT mais je ne sais pas où trouver les valeurs de ces variables. Comment puis-je les définir.
Merci pour votre aide
Cordialement
Je n’ai pas de NAS Synology et je n’ai aucune idée des réponses exactes mais la première réponse google dit qu’il faut écrire ups@adresse_ip_du_nas pour NutUpsName, monuser pour NutUser et secret pour NutPassword. Bien entendu le NAS devra être configuré avec une adresse ip fixe pour que le client puisse toujours le retrouver.
Sinon il y a http://lab.piszki.pl/synology-network-ups-nut-and-esxi-5-5/ qui en parle.
Merci René
Je viens de tomber sur le même lien et effectivement j’ai pu vérifier que ce sont bien ces variables.
Encore merci pour votre travail
Cordialement