NUT package (2.8.0 and below)

darkcorner

@dennypage
@DannyBoy2k
Thanks for your answers.

The UPS USB cable is connected to pfSense, but it covers multiple PCs/servers that need to shut down automatically.
So, pfSense is the Master of NUT and on these PCs/Servers I'm installing tools configured as NUT Slave.

TrueNAS is configured as "Slave" in its NUT service, but it doesn't seem to notice the presence of the Master.
On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.
(If it's not the right software, can you suggest me some other client?)

For all, the port is the standard one (3493).
In Windows10 I turned off its Windows Defender Firewall.
On pfSense there are two rules in LAN and DMZ for LAN-Net and DMZ-Net which allows any to any with any protocol.
In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".
On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

Gertjan

@darkcorner said in NUT package:

On a Win10 Pro PC I mounted WinNUT-Client and it gives me a login failure error for authentication.

This one ?
I'm using several of them, pfSense being the NUT-master. It works.

pfSense side :

and

Note : my ups is called 'ups'.

On the Win NUT client side, a PC :

where password = "secret2" as this is "pcrecep1".

I've no particular firewall rules on my LAN, 19.168.1.1 - just one pass-all, so the client connects just fine.

@darkcorner said in NUT package:

In pfSense, with Diagnostic - Test Ports the port seems open, but from console telnet 127.0.0.1:3493 or (localhost:3493) reports the error "Name does not resolve".

You instructed NUT (pfSense) to listen on what interfaces ?
127.0.0.1 is not reachable from LAN. So
I want NUT to listen on my LAN so I told it to do so :

@darkcorner said in NUT package:

On PC Win10 telnet LAN-NIC-Address:3493 reports error "Could not open connection to host. on port 23: Connection failed"

telnet could be a good test.
But telnet uses TCP. Not sure if NUT uses UDP or TCP.

A better test : ask the system directly. I know the port, 3493, so :

[22.05-RELEASE][admin@pfSense.local.net]/root: sockstat | grep '3493'
root     upsd       21699 4  tcp6   2001:470:xxxx:5c0:2::1:3493 *:*
root     upsd       21699 5  tcp4   192.168.1.1:3493      *:*
root     upsd       21699 6  tcp6   ::1:3493              *:*
root     upsd       21699 7  tcp4   127.0.0.1:3493        *:*
root     upsd       21699 11 tcp6   ::1:3493              ::1:64823
root     upsd       21699 12 tcp4   192.168.1.1:3493      192.168.1.33:36453
root     upsd       21699 13 tcp4   192.168.1.1:3493      192.168.1.6:58694
root     upsd       21699 14 tcp4   192.168.1.1:3493      192.168.1.7:60690
root     upsmon     20768 4  tcp6   ::1:64823             ::1:3493

This tells you everything you need to know.
Nut listens on my LAN IPv6, and 192.168.1.1 all port 3493. Protocol is tcp.
PC's (clients) 192.168.1.6 and 192.168.1.7 have an established connection.
Like 192.168.1.33, my syno NAS, using 'monuser' and 'secret' as login ID.
Btw : ok, it listens also on localhost or 127.0.0.1 or ::1 on port 3493, tpc.

@darkcorner said in NUT package:

As NUT users I am using both admin and local-monitor with the password present in /usr/local/etc/nut/upsd.users.

True, this information :

will be placed into that file.
Do NOT edit that file yourself, use the GUI.

My "/usr/local/etc/nut/upsd.users" file has more info in it.
At the top, I find :

[admin]
password=be7b490cda2016c2a1fe
actions=set
instcmds=all
[local-monitor]
password=e90150cecfe29445f4a3
upsmon master

These are created when you install the package.
Not sure why I should use these. These [admin] and [local-monitor] are probably RTFM items.

edit :
By now, you have your clients up and connected.

So, bonus time :

The NOTIFYFLAG lines ask nut to spam logs, messages on the console, which can be seen if you are logged in console or SSH.

This one : "NOTIFYCMD /usr/local/sbin/upssched" is special.

You have to make your copy of this file : /usr/local/etc/nut/upssched.conf - take upssched.conf.sample as an example.
My /usr/local/etc/nut/upssched.conf :

CMDSCRIPT /root/upssched-cmd.sh
PIPEFN /var/db/nut/upssched.pipe
LOCKFN /var/db/nut/upssched.lock

AT ONBATT * START-TIMER onbatt 15
AT ONLINE * CANCEL-TIMER onbatt online
AT LOWBATT * EXECUTE lowbatt
AT COMMBAD * START-TIMER commbad 30
AT COMMOK * CANCEL-TIMER commbad commok
AT NOCOMM * EXECUTE commbad
AT FSD * EXECUTE powerdown
AT SHUTDOWN * EXECUTE powerdown

and before you ask : here is my home made /root/upssched-cmd.sh :

#!/bin/sh

UPS="ups"
STATUS=$( upsc $UPS ups.status )
CHARGE=$( upsc $UPS battery.charge )
CHMSG="[$STATUS]:$CHARGE%"

# upssched-cmd  --slave --
/usr/bin/logger -i -t upssched-cmd Calling upssched-cmd $1

case $1 in
    online) 
    MSG="$UPS, $CHMSG - power supply has been restored."
    ;;
    onbatt)
    MSG="$UPS, $CHMSG - power failure - save your work!"
    ;;
    lowbatt) 
    MSG="$UPS, $CHMSG - shutdown now!"
    ;;
    upsgone)
    MSG="$UPS, $CHMSG - UPS has been gone for awhile"
    ;;
    powerdown)
    MSG="$UPS, $CHMSG - Going powerdown"
    ;;
    commbad)
    /usr/bin/logger -i -t upssched-cmd "Communcation with UPS is lost"
    ;;
    *) 
    /usr/bin/logger -i -t upssched-cmd "Unkown arg: \"$1\", $CHMSG"
    exit 1
    ;;
esac
/usr/bin/logger -i -t upssched-cmd $MSG
/usr/local/pkg/nut/nut_email.php $MSG
exit 0

Make this file executable :

chmod +x /root/upssched-cmd.sh

and be careful for the file encoding. (Unix LF UTF-8, not some Windows format)

It's this file that takes care of the mail sending when power events happen.

Do not use this option :

as it hard codes a mail transmission, and blast away other possible settings.
=> Never ask a stupid GUI to do something that you can do yourself better ;)
The thing is : there can only be ONE CMDSCRIPT in /usr/local/etc/nut/upssched.conf.

Check the GUI 'mail me' option and that places the CMDSCRIPT. I wanted to have some more control of the process.
As you ca see, I use the NUT mail php script to mail : "/usr/local/pkg/nut/nut_email.php $MSG".

I'm using the settings and files as shown. I'm not saying they are perfect. I just want the systems to go down as soon as a power loss event arrives.

Btw : and yes, NUT is quiet big, and you can make it as complex as you want.
Testing is important, and you have to test a lot. No testing means : you have an UPS and you still have a no controlled power loss which might translate in data loss.

dennypage

@darkcorner said in NUT package:

The UPS USB cable is connected to pfSense, but it covers multiple PCs/servers that need to shut down automatically.
So, pfSense is the Master of NUT and on these PCs/Servers I'm installing tools configured as NUT Slave.

Please see post #2 in this thread for information on allowing remote access to the NUT server.

darkcorner

@Gertjan
Thank you, your suggestions have been very valuable.
I haven't tested them all yet because I had to deal with another problem at the office, but it will be the first thing I do tomorrow (Monday).
But now WinNUT-Client has immediately detected the status of the UPS.

In the meantime, I want to ask you a few other things, hoping not abusing your courtesy.

I also read in other comments that the name is "ups"; is it perhaps binding? I named mine as the model of UPS (Back-UPS_BX2200MI)
I haven't seen how to run a script from WinNUT-Client yet. Do you have a suggestion about it?
In your opinion, an ESXi host server (Free) and a Proxmox server is better to shut down by a command executed from WinNUT-Client, or directly from the script on pfSense?

dennypage

@darkcorner said in NUT package:

I also read in other comments that the name is "ups"; is it perhaps binding? I named mine as the model of UPS (Back-UPS_BX2200MI)

People often use the name "ups" because some NUT installations, particularly those on NAS, are hardcoded to use that name.

darkcorner

But I didn't understand how to get pfSense and the servers to turn on after they shut down.
There is a delay. If the power returns before the shutdown has started, everything will stay on. And that's OK.
But two cases can arise, especially in the evening when nobody is there.

The power is back, but the shutdown has already started or maybe pfsense and the servers are already off.
Power has returned, but the battery is now dead and the UPS is off.

Sure, one person can turn everything back on, but what if you want the machines to turn themselves back on?

4o4rh

@darkcorner
2. is not an issue. this can be solved through the bios setting.
i.e. acpi settings to power on upon restoration of power.

it is 1. that is a problem. i.e. the system shutdown because the timer has determined to shutdown, but the battery hasn't expired before the restoration of power. now there is no way to wake the system up, unless you can use a WakeOn LAN function. But so far, i haven't worked out how to make the switch cause a wake-on situation for the pfsense box

dennypage

@darkcorner

Regarding 1: Once a low battery situation is declared, NUT begins the shutdown process. Once this starts, it does not stop. The process includes instructing the UPS to cut power, and this will happen regardless of whether or not the mains have been restored. So what happens is that the UPS cuts the power, and after a brief interval restores power. The attached systems should be configured to boot automatically when power is applied.

Regarding 2: UPSs are generally designed/configured to not restore power until there is a certain percentage of battery charge available. The reason for this is to ensure that systems can safely shutdown again in the event of a subsequent power failure. Often this percentage defaults to 25% or more, but may be configurable. Look to your UPS documentation or consult with the UPS vendor for more information.

4o4rh

@dennypage
I believe in 1: we are saying the same thing. The option to boot automatically when power is applied, is a bios setting (i believe under the ACPI settings from memory).

In 2: actually i was thinking of a slightly different scenario, but same principle.
i.e. where the remote device being shutdown, has a dumb battery.
In this situation, it is possible the remote device is shutdown before the battery dies, so when power is replied, there is no way to power up, as the device never lost power.
This is a similar situation to the one described i.e. where power to the UPS is restored, but because the battery died, the UPS doesn't automatically turn on. Although in this scenario, wake-on lan wouldn't work anyway because the UPS hasn't powered on.

dennypage

@gwaitsi said in NUT package:

i.e. where the remote device being shutdown, has a dumb battery.
In this situation, it is possible the remote device is shutdown before the battery dies, so when power is replied, there is no way to power up, as the device never lost power.

FWIW, I've never heard of a "dumb battery" UPS that does not re-energize the load when mains return and the battery has reached a sufficient level. I definately would not recommend such a device for use with NUT.

4o4rh

@dennypage i mean a dumb power pack, not a ups. I use a dumb power pack on my J1900 with a remote connection to the NAS which has the UPS

dennypage

@gwaitsi said in NUT package:

i mean a dumb power pack, not a ups. I use a dumb power pack on my J1900 with a remote connection to the NAS which has the UPS

I'm assuming that "J1900" is a computer system...

If the computer system is powered by the UPS, and the UPS is controlled by the NAS, you should have a NUT client (slave) on that system that talks to the NUT server (master) to coordinate the shutdown. Do you? How does the dumb power pack fit into this?

JonathanLee

Hello fellow Netgate community members can you please help?

I have never had any issues with NUT until I upgraded to 23.01 I keep having the driver disconnect now until I re-apply the settings. The pFsense software is working great, it runs so much better with the internet traffic and proxy speeds, however I found a bug. I have removed rebooted pkg cleaned and reinstalled the and error returned. Keep in mind prior to update this was not a issue. If I reapply the settings the driver recovers and dashboard displays correctly. Again this only lasts for a short time and it is disconnected again.

Screenshot 2023-02-16 at 8.04.50 PM.png
(Errors: Driver not connected)

Screenshot 2023-02-16 at 8.04.17 PM.png
(Current pfSense Version)

Screenshot 2023-02-16 at 8.04.01 PM.png
(2.8.0_2)

Does anyone know what would cause this change, prior to this I never had any errors on the older version of pFsense 21.

JonathanLee

Screenshot 2023-02-16 at 8.10.58 PM.png
(connection refused?)

Screenshot 2023-02-16 at 8.11.31 PM.png
(Unavailable)

JonathanLee

Changing it off of port = auto and setting it to what the sockets was showing seemed to resolve this. I always wanted to see the GUI monitor like the website has, has anyone set that up where you can just go to for example https://192.168.1.1:3493 and access a login prompt and monitor the ups?

Screenshot 2023-02-16 at 9.21.45 PM.png

4o4rh

@jonathanlee did you check the contents of ups.conf after reboot? if the contents are being lost, you might be able to use the Filer plugin to work around it

dennypage

@jonathanlee In the Advanced settings -> Additional configuration lines for ups.conf, you have entries that are not allowed there. That section is for global directives only. What you have there are UPS Fields (driver configuration).

All entries in that section should be removed. If you wish, the "desc" line can be moved into the Extra Arguments to driver section, but all the others should be removed. Those entries are in conflict with the driver configuration.

4o4rh

@dennypage the stuff he has in the "additional configuration lines for ups.conf" should be in the "extra arguements to driver" section no?

dennypage

@gwaitsi said in NUT package:

@dennypage the stuff he has in the "additional configuration lines for ups.conf" should be in the "extra arguements to driver" section no?

No. See the post immediately above. The lines should be not be present in either section.

tman222

Hi @dennypage - I ran into the same issue as @JonathanLee after upgrading to 23.01. I have a CyperPower UPS hooked up via USB using the usbhid NUT driver that worked fine up to now (i.e. in 22.05). After the upgrade, the NUT driver can't seem to keep a connection to the UPS. If I reload the NUT service / restart NUT, it will work anywhere from 5-20 minutes before disconnecting again. I have tried reinstalling the package and also manually setting the port line in "Extra Arguments to driver" section to the actual USB port/device the UPS is attached to, but no dice. The only left to try is a different USB port on the system to see if that fixes it. Is there anything else can you think of that is worth checking into to try to resolve this? Thanks in advance.