-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 said in NUT Package (2.8.1 and above):
Now for better log reading, I've added a second entry, for my second client
...
I'm able to connect, however I can't see that this second client has connected from within the system logs in my pfSense. Does someone know why that is?No idea. Are you sure it is connecting with the username you expect? FWIW, you can distinguish client by IP address. Do you see a connection from the IP address you expect?
After a few restarts of the NUT service on my pfSense it's there in the log. However the second login doesn't have an explicit IP address.
upsd 81154 User client-xx1@192.168.1.xx logged into UPS [CyberPower_USV] upsd 81154 User client-xx2@::1 logged into UPS [CyberPower_USV] -
@endy66 said in NUT Package (2.8.1 and above):
After a few restarts of the NUT service on my pfSense it's there in the log. However the second login doesn't have an explicit IP address.
upsd 81154 User client-xx1@192.168.1.xx logged into UPS [CyberPower_USV]
upsd 81154 User client-xx2@::1 logged into UPS [CyberPower_USV]"::1" is an IP address. It's the IPv6 version of localhost, equivalent to 127.0.0.1 in IPv4.
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 said in NUT Package (2.8.1 and above):
After a few restarts of the NUT service on my pfSense it's there in the log. However the second login doesn't have an explicit IP address.
upsd 81154 User client-xx1@192.168.1.xx logged into UPS [CyberPower_USV]
upsd 81154 User client-xx2@::1 logged into UPS [CyberPower_USV]"::1" is an IP address. It's the IPv6 version of localhost, equivalent to 127.0.0.1 in IPv4.
Hm this is weird because this user is connecting from a different host, so shouldn't it be anything other than a "localhost" address?
-
@endy66 said in NUT Package (2.8.1 and above):
Hm this is weird because this user is connecting from a different host, so shouldn't it be anything other than a "localhost" address?
Referring to post #2 in this thread, how are you allowing remote connections? Are you using option 1 (NAT/Port forward)? Or are you using option 2 (LISTEN)?
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 said in NUT Package (2.8.1 and above):
Hm this is weird because this user is connecting from a different host, so shouldn't it be anything other than a "localhost" address?
Referring to post #2 in this thread, how are you allowing remote connections? Are you using option 1 (NAT/Port forward)? Or are you using option 2 (LISTEN)?
I'm using option 2 (LISTEN).
-
@endy66 Please post the contents of these files:
/usr/local/etc/nut/upsmon.conf /usr/local/etc/nut/upsd.conf /usr/local/etc/nut/upsd.users -
@dennypage said in NUT Package (2.8.1 and above):
@endy66 Please post the contents of these files:
/usr/local/etc/nut/upsmon.conf /usr/local/etc/nut/upsd.conf /usr/local/etc/nut/upsd.usersHere's the content of these 3 files. Passwords are masked. Monitor password of the upsmon.conf matches the one from the [admin] section of the upsd.users.
upsmon.conf
MONITOR CyberPower_USV 1 local-monitor *************** master SHUTDOWNCMD "/sbin/shutdown -p +0" POWERDOWNFLAG /etc/killpowerupsd.conf
LISTEN 127.0.0.1 LISTEN ::1 LISTEN 192.168.1.1upsd.users
[admin] password=*************** actions=set instcmds=all [local-monitor] password=*************** upsmon master [client-xx1] password = *************** upsmon slave [client-xx2] password = *************** upsmon slave -
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 And the output of
netstat -a -n | grep 3493please.
netstat -a -n | grep 3493 tcp4 0 0 192.168.1.1.3493 192.168.1.8.33624 ESTABLISHED tcp6 0 0 ::1.3493 ::1.2785 ESTABLISHED tcp6 0 0 ::1.2785 ::1.3493 ESTABLISHED tcp4 0 0 192.168.1.1.3493 *.* LISTEN tcp6 0 0 ::1.3493 *.* LISTEN tcp4 0 0 127.0.0.1.3493 *.* LISTEN -
@endy66 In the output I see one local connection and one remote connection.
The local connection will be upsmon, and is the one that is on
::1.2785->::1.3493. This will be userlocal-monitor. You can easily confirm this withsockstat -c | grep 3493The local upsmon connection should generate a log entry like this,
Feb 1 08:01:20 fw upsd[45590]: User local-monitor@::1 logged into UPS [CyberPower_USV]however you did not show such a log entry. Given that you clearly have a local upsmon connection, there absolutely should be a corresponding log entry.
The remote connection is on
192.168.1.8.33624->192.168.1.1.3493. This presumably is one of your client-xx users.In sort, your config files are good. Your netstat output is good, with one remote connection [there is no second remote connection]. The only thing is that I cannot reconcile your configuration files and netstat output with the log entries that you posted.
Is it possible that you made configuration changes between when the logs were taken and when the config files / netstat output were taken?
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 In the output I see one local connection and one remote connection.
The local connection will be upsmon, and is the one that is on
::1.2785->::1.3493. This will be userlocal-monitor. You can easily confirm this withsockstat -c | grep 3493The local upsmon connection should generate a log entry like this,
Feb 1 08:01:20 fw upsd[45590]: User local-monitor@::1 logged into UPS [CyberPower_USV]however you did not show such a log entry. Given that you clearly have a local upsmon connection, there absolutely should be a corresponding log entry.
The remote connection is on
192.168.1.8.33624->192.168.1.1.3493. This presumably is one of your client-xx users.In sort, your config files are good. Your netstat output is good, with one remote connection [there is no second remote connection]. The only thing is that I cannot reconcile your configuration files and netstat output with the log entries that you posted.
Is it possible that you made configuration changes between when the logs were taken and when the config files / netstat output were taken?
I've re-checked everything and you're right indeed, I might have missed something. The log only shows the local and one remote connection
User local-monitor@::1 logged into UPS [CyberPower_USV] User client-xx1@192.168.1.8 logged into UPS [CyberPower_USV]So the second user is missing, but I'm clearly able to receive all the values on it. This client is a Home Assistant instance with the NUT client package and I see all the things. And I also used the second login I specified in upsd.users.
-
@endy66 said in NUT Package (2.8.1 and above):
So the second user is missing, but I'm clearly able to receive all the values on it. This client is a Home Assistant instance with the NUT client package and I see all the things.
This one?
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 said in NUT Package (2.8.1 and above):
So the second user is missing, but I'm clearly able to receive all the values on it. This client is a Home Assistant instance with the NUT client package and I see all the things.
This one?
Yes exactly.
-
@endy66 That's what I thought.
The short version is that you are wasting your time trying to set up a username/password for a remote HA client because the HA integration doesn't use it. You don't need to enter a username/password when you set up the integration.
Since you asked, here's the longer version...
You won't see a login from the integration because it isn't a NUT client, and doesn't actually send a LOGON command to upsd. The NUT HA integration doesn't even send the username and password for remote connections. And even if it did send the username/password, upsd would not attempt to validate it until a command (such as LOGON or an instant command) is sent by the client.
NUT allows read-only access to ups information without a login which is how the HA integration is written. It connects every 60 seconds (default), polls current status, and disconnects. An actual NUT monitoring client is different. It connects, sends username and password, then issues a LOGIN command to attach to the UPS. It remains connected and polls the UPS on a frequent interval (usually less than 15 seconds).
For upsd, the difference is significant. A logged in client is something that upsd is responsible for, and it will monitor the client connection and wait for the client to disconnect before initiating its own shutdown. A non logged in client is expected to be something like a web page. Information display only.
I believe that the only time the username/password for HA NUT is used is if you are running the dedicated HA OS and want to be able to issue instant commands to the UPS. Entertainingly, even though it has not sent a LOGIN command, the HA integrations always sends a LOGOUT command before disconnecting from upsd. Very polite.
-
@dennypage said in NUT Package (2.8.1 and above):
@endy66 That's what I thought.
The short version is that you are wasting your time trying to set up a username/password for a remote HA client because the HA integration doesn't use it. You don't need to enter a username/password when you set up the integration.
Since you asked, here's the longer version...
You won't see a login from the integration because it isn't a NUT client, and doesn't actually send a LOGON command to upsd. The NUT HA integration doesn't even send the username and password for remote connections. And even if it did send the username/password, upsd would not attempt to validate it until a command (such as LOGON or an instant command) is sent by the client.
NUT allows read-only access to ups information without a login which is how the HA integration is written. It connects every 60 seconds (default), polls current status, and disconnects. An actual NUT monitoring client is different. It connects, sends username and password, then issues a LOGIN command to attach to the UPS. It remains connected and polls the UPS on a frequent interval (usually less than 15 seconds).
For upsd, the difference is significant. A logged in client is something that upsd is responsible for, and it will monitor the client connection and wait for the client to disconnect before initiating its own shutdown. A non logged in client is expected to be something like a web page. Information display only.
I believe that the only time the username/password for HA NUT is used is if you are running the dedicated HA OS and want to be able to issue instant commands to the UPS. Entertainingly, even though it has not sent a LOGIN command, the HA integrations always sends a LOGOUT command before disconnecting from upsd. Very polite.
Thank you so much for this detailed explanation! I didn't knew that there's such a difference or even that the HA integration isn't a "real" NUT client and it also works that different. Then I'll remove the second user from my pfSense.
However the integration on HA still helps for notifying if there's a power outtage, even if it's not instant. The server where HA (a VM) runs on, has proper NUT integration (the first client), so it still can shut down properly. I just wondered what's going on as I haven't seen any "login" logs in the pfSense box. Now I know. Thanks again so much for your awesome support, appreciate it a lot! -
@endy66 said in NUT Package (2.8.1 and above):
Thank you so much for this detailed explanation!
You're welcome.
However the integration on HA still helps for notifying if there's a power outtage, even if it's not instant.
Just FYI, HA may miss the power outage completely if it is shorter than the polling interval.
-
@dennypage said in NUT Package (2.8.1 and above):
Just FYI, HA may miss the power outage completely if it is shorter than the polling interval.
That's true yes. I set up a delay of some seconds because I only need a notification if it's a real / longer power outage, otherwise my UPS will just kick in and since it has the capacity to provide power for almost an hour, it's okay to get the norification a bit delayed.
-
@endy66 Cool. Just wanted to make sure you were aware.
-
This post is deleted! -
I dunno what happened. I just updated to 2.8.2_1 and now my tripplite USB connection isn't working.
[nutdev1]
driver = "tripplite_usb"
port = "auto"
vendorid = "09AE"
productid = "0001"
product = "TRIPP LITE SMART500RT1U"
vendor = "Tripp Lite"
bus = "000"
device = "002"
busport = "005"
###NOTMATCHED-YET###bcdDevice = "000A"
