Client NUT pour ESXi 5 et 6

Dans un précédent article je vous présentait un client NUT natif pour éteindre automatiquement un serveur VMWare ESXi 4 sur une alerte onduleur. La solution présentée n’était pas compatible avec ESXi 5 dont l’architecture logicielle a évoluée. Voici une solution pour intégrer un client NUT natif à vSphere Hypervisor  (ESXi 5.0, 5.1, 5.5, 6.0 et 6.5 testées). Le client NUT est désormais intégré et peut être contrôlé et paramétré depuis vSphere Client.

Mise à jour du 29/01/2017 : La version 2.0 du client NUT a été largement repensé pour mieux s’intégrer dans l’architecture VMware ESXi. Les modifications suivantes ont été apportées :

  • Le client s’appelle désormais NutClient dans la liste des services
  • Les règles de firewall portent le nom de NutServer
  • Le fichier VIB respecte le standard CommunitySupported pour les versions 6.x de ESXi. Pour les versions 5.x il faudra toujours forcer l’installation avec l’option –no-sig-check
  • Le VIB est indépendant, il n’est plus nécessaire d’utiliser les scripts d’installation pour déployer le VIB. Vous pouvez utiliser les outils de déploiement de VMWare. Les scripts servaient à créer les variables UserVars.Nut* c’est désormais intégré dans le VIB.
  • Le client prend en charge les connexions SSL en utilisant la librairie LibreSSL 2.5.0 mais la validité du certificat du serveur NUT n’est pas contrôlé.
  • L’état du service est désormais correctement remonté dans l’interface d’administration vCenter ou le client HTML après un reboot de l’hyperviseur
  • Si les variables de configuration n’apparaissent pas dans l’interface d’administration après l’installation, lancez la commande /etc/init.d/hostd restart sur l’hyperviseur. Attention à ne pas avoir de jobs en cours si vous faites ça (prise de snapshot, VMotion, …).

 

Principe

La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Je reprend le schéma des connexions qui ne change pas.

Câblage Onduleur

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 sous le contrôle d’un VMWare vCenter. Seul le client NUT est ajouté à l’hyperviseur, l’onduleur doit être surveillé par un serveur NUT.

Évolutions par rapport à ESXi 4

Les différences qui font que la solution pour ESXi 4 ne fonctionne pas sous ESXi 5 :

  • La méthode d’installation utilise un fichier VIB (vSphere Installation Bundle). Les binaires qu’il contient correspondent à un client nut 2.7.4 (upsmon et upsc)
  • Dans /etc/passwd, l’utilisateur nobody n’existe plus. Le client tourne désormais avec le compte daemon.
  • Le module VIB ne respecte pas les préconisations de sécurité imposées par VMWare. Vous perdez le support de VMWare en installant ce package. Je bricole pour mes besoins personnels en utilisant une licence gratuite de ESXi sans support, j’ai donc ignoré cette restriction.

Téléchargement du module

L’installation se fait en ligne de commande sur l’hyperviseur : un fichier TAR compressé doit être déposé sur l’hyperviseur.

Téléchargez ici le fichier NutClient-ESXi-2.0.0.tar.gz (348)

Installation

Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Cela est fait à partir du client vSphere ou de la console. A partir du client : dans l’inventaire choisissez votre hôte ESXi, onglet configuration, dans la liste Logiciel choisir profil de sécurité, dans services cliquez sur propriétés…, choisissez SSH puis options et enfin démarrer. Le service ssh sera actif jusqu’au prochain reboot de l’hyperviseur si vous ne le désactivez pas.

Copiez le fichier NutClient-ESXi-2.0.0.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.0.0.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.0.0.tar.gz          100%  671KB  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.0.0.tar.gz
/tmp # sh upsmon-install.sh
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Margar_bootbank_upsmon_2.7.4-2.0.0
   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 fichier qui ont été créés dans /tmp et désactiver le service SSH

Configuration

A l’aide de vSphere Client, rendez-vous dans l’onglet configuration de l’hôte ESXi. Sélectionnez les paramètres avancés et sélectionnez les UserVars. Vous avez 6 variables à configurer :

Configuration du client NUT sous ESXi 5

Configuration du client NUT sous ESXi 5

  • 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.NutSendMail : A mettre à 1 pour que le client NUT envoie un e-mail à chaque évènement important de l’onduleur
  • UserVars.NutMailTo   : Adresse e-mail à laquelle envoyer les évènements de l’onduleur

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 vSphere Client, rendez-vous dans l’onglet configuration de l’hôte ESXi. Sélectionnez les profils de sécurité et les propriétés des services :

Services-ESXi5

Client NUT dans les services ESXi 5

Dans les options du service Network UPS Tools Client, choisissez le mode de 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.

NutClientService-ESXi5

Configuration du lancement de NUT Client

Astuces

Utilisez l’onglet de configuration du host ESXi dans vSphere Client 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.

L’arrêt propre des OS dans les machines virtuelles n’est possible que si les vmware tools sont installées.

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

Pour estimer le temps nécessaire au serveur pour s’éteindre sur alerte onduleur tapez la commande « upsmon -c fsd » sur le host ESXi (par ssh ou sur la console). La procédure d’arrêt est immédiatement lancée.

 

VN:F [1.9.22_1171]
Evaluation: 4.5/5 (20 votes exprimés)
Client NUT pour ESXi 5 et 6, 4.5 out of 5 based on 20 ratings

Suivre les commetaires avec le flux RSS 2.0. Vous pouvez laisser un comentaire, or trackback depuis votre site.

331 Commentaires »

 
  • avatar Mark dit :

    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 ?

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
  • avatar Mauro Cascio dit :

    Ottimo lavoro. Bravissimo!!!

    travail tres bon (excusez mon francais)

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
  • avatar Blue dit :

    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.

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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.

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
      • avatar Blue dit :

        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 ?

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
        • avatar René dit :

          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.

          VN:F [1.9.22_1171]
          Evaluation: 0 (sur 0 votes)
          • avatar Blue dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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é.

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
  • […] rummaging around online turned up a NUT Client for ESXi 5 (french) which doesn’t work for ESXi 4, fortunately the same guy has also done a NUT Client for ESXi 4 […]

  • 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

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      I’m considering testing. Still haven’t find time for that… I will update the post as soon as I have the answer

      VN:F [1.9.22_1171]
      Evaluation: +1 (sur 1 vote)
      • Great! Thanks again!

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
        • avatar René dit :

          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.

          VN:F [1.9.22_1171]
          Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            Type services.sh restart in the ESXi shell if you wan to see UserVars in HTML5 interface without ESXi reboot. You will need to reconnect to ESXi HTML5 interface

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
  • avatar Jose Gomes dit :

    Hi 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

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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.

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
  • avatar Christian dit :

    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

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar Christian dit :

      Can’t edit, so just a short post to keep updated on comments, sorry for that.

      VA:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
      • avatar Christian dit :

        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

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
        • avatar René dit :

          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

          VN:F [1.9.22_1171]
          Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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.

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            Upsmon vib violates some security constraints as it installs binary executables in the system directories. This is not allowed for CommunitySupported VIBs

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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?

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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.

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
  • avatar Jose Gomes dit :

    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

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
      • avatar Christian dit :

        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.

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
      • avatar Jose Gomes dit :

        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.

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
        • avatar Christian dit :

          Jose, sounds interesting. Can you send me the VIB?

          VA:F [1.9.22_1171]
          Evaluation: 0 (sur 0 votes)
          • avatar Jose Gomes dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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.

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Jose Gomes dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      Client 2.0.0 released. Post updated

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
  • avatar Fred dit :

    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).

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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.

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
      • avatar Fred dit :

        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.

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
        • avatar René dit :

          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)

          VN:F [1.9.22_1171]
          Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar René dit :

            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.

            VN:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
          • avatar Christian dit :

            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.

            VA:F [1.9.22_1171]
            Evaluation: 0 (sur 0 votes)
  • avatar taxi dit :

    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

    VA:F [1.9.22_1171]
    Evaluation: 0 (sur 0 votes)
    • avatar René dit :

      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.

      VN:F [1.9.22_1171]
      Evaluation: 0 (sur 0 votes)
      • avatar taxi dit :

        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

        VA:F [1.9.22_1171]
        Evaluation: 0 (sur 0 votes)
 

Laisser un commentaire

XHTML: Vous pouvez utiliser ces balises : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>