NUT Package (2.8.1 and above)

pvk1

@dennypage Sorry if this is the wrong place. I migrated the configuration to a Netgate 4200. I have NUT package 2.8.2_1. It had permission errors. After including user=root in the ups.conf section (as suggested by you in the previous track) it started working. It also worked on the previous system.
Schermafbeelding 2024-03-30 091809.png

dennypage

@pvk1 Ownership of the /var/db/nut directory is incorrect. The following command will fix that:

chown -R nut:nut /var/db/nut

The errors for /usr/local/etc/nut are more of an issue. Those files should be accessed prior to switching to user "nut". What version of pfSense are you running? What does

pkg info | grep nut

report? Thx.

pvk1

@dennypage
I am running: 23.09.1-RELEASE (amd64)

pkg info:

nut-devel-2024.01.03 Network UPS Tools
pfSense-pkg-nut-2.8.2_1 Network UPS Tools

thx

dennypage

@pvk1 Can you post the output of the the following commands please?

ls -l /var/db/nut
ls -l /usr/local/etc/nut

Thanks

pvk1

@dennypage Hi, thx

ls -l /var/db/nut
total 0
ls: /var/db/nut: Permission denied

ls -l /usr/local/etc/nut
total 143
-rw-r--r-- 1 root wheel 15136 Mar 4 22:00 cmdvartab
-rw-r--r-- 1 root wheel 98236 Mar 4 22:00 driver.list
-rw-r--r-- 1 root wheel 1071 Mar 4 22:00 hosts.conf
-rw-r--r-- 1 root wheel 1071 Mar 4 22:00 hosts.conf.sample
-rw-r--r-- 1 root wheel 4774 Mar 4 22:00 nut.conf
-rw-r--r-- 1 root wheel 4774 Mar 4 22:00 nut.conf.sample
-rw-r----- 1 root wheel 124 Apr 1 18:43 ups.conf
-rw-r--r-- 1 root wheel 9845 Mar 4 22:00 ups.conf.sample
-rw-r----- 1 root wheel 28 Apr 1 18:43 upsd.conf
-rw-r--r-- 1 root wheel 9199 Mar 4 22:00 upsd.conf.sample
-rw-r----- 1 root wheel 167 Apr 1 18:43 upsd.users
-rw-r--r-- 1 root wheel 2349 Mar 4 22:00 upsd.users.sample
-rw-r----- 1 root wheel 530 Apr 1 18:43 upsmon.conf
-rw-r--r-- 1 root wheel 24735 Mar 4 22:00 upsmon.conf.sample
-rw-r--r-- 1 root wheel 4217 Mar 4 22:00 upssched.conf
-rw-r--r-- 1 root wheel 4217 Mar 4 22:00 upssched.conf.sample
-rw-r--r-- 1 root wheel 1871 Mar 4 22:00 upsset.conf
-rw-r--r-- 1 root wheel 1871 Mar 4 22:00 upsset.conf.sample
-rw-r--r-- 1 root wheel 6861 Mar 4 22:00 upsstats-single.html
-rw-r--r-- 1 root wheel 6861 Mar 4 22:00 upsstats-single.html.sample
-rw-r--r-- 1 root wheel 4096 Mar 4 22:00 upsstats.html
-rw-r--r-- 1 root wheel 4096 Mar 4 22:00 upsstats.html.sample

Gertjan

@pvk1 said in NUT Package (2.8.1 and above):

ls: /var/db/nut: Permission denied

Strange.
You are root, right ?

[24.03-BETA][root@pfSense.bhf.tld]/root: whoami
root

dennypage

@pvk1 said in NUT Package (2.8.1 and above):

ls -l /var/db/nut
total 0
ls: /var/db/nut: Permission denied

As @Gertjan noted, you need to run the commands as root.

pvk1

@dennypage
Thx. I had disabled the admin user, so I could not login as root. The user that I login with is member of the system admins.

I now enabled admin again.
s: /var/db/nut:
-rw-r--r-- 1 root nut 6 Apr 2 13:19 upsd.pid
-rw-r--r-- 1 root nut 6 Apr 2 13:19 upsmon.pid
srw-rw---- 1 root nut 0 Apr 2 13:19 usbhid-ups-ups
-rw-r--r-- 1 root nut 6 Apr 2 13:19 usbhid-ups-ups.pid

dennypage

@pvk1 Running as non-root will require that ownership of /var/db/nut, and all files therein, to be user "nut".

Note that all of the following needs to be done as root.

Suggested path:

Remove user=root from the configuration. NB: If you have anything else in the Advanced section, please post that before continuing...
Shut down the UPS service via command "/usr/local/etc/rc.d/nut.sh stop".
Do "ps -axuw | grep ups" and see if any of the nut commands, such as upsmon, are still running. If they are you can stop them with "killall upsmon".
Change ownership of /var/db/nut via command "chown -R nut /var/db/nut".

Following that, you should see permissions like so:

[23.09.1-RELEASE][root@fw]/root: ls -ld /var/db
drwxr-xr-x  22 root wheel 54 Apr  2 08:29 /var/db
[23.09.1-RELEASE][root@fw.cococafe.com]/root: ls -la /var/db/nut
total 10
drwxr-x---   2 nut  nut    3 Apr  2 10:17 .
drwxr-xr-x  22 root wheel 54 Apr  2 08:29 ..
-rw-r--r--   1 nut  uucp   6 Apr  1 14:40 upsmon.pid
[23.09.1-RELEASE][root@fw]/root:

You can also check permissions for /usr/local/etc/nut like so:

[23.09.1-RELEASE][root@fw]/root: ls -ld /usr/local/etc
drwxr-xr-x  35 root wheel 91 Apr  2 08:45 /usr/local/etc
[23.09.1-RELEASE][root@fw]/root: ls -ld /usr/local/etc/nut
drwxr-xr-x  2 root wheel 24 Feb 10 12:16 /usr/local/etc/nut
[23.09.1-RELEASE][root@fw]/root: ls -la /usr/local/etc/nut/*.conf
-rw-r--r--  1 root wheel 1071 Feb  7 11:02 /usr/local/etc/nut/hosts.conf
-rw-r--r--  1 root wheel 4774 Feb  7 11:02 /usr/local/etc/nut/nut.conf
-rw-r-----  1 root wheel   43 Apr  1 14:29 /usr/local/etc/nut/ups.conf
-rw-r-----  1 root wheel   28 Apr  1 14:29 /usr/local/etc/nut/upsd.conf
-rw-r-----  1 root wheel  530 Apr  1 14:29 /usr/local/etc/nut/upsmon.conf
-rw-r--r--  1 root wheel 4217 Feb  7 11:02 /usr/local/etc/nut/upssched.conf
-rw-r--r--  1 root wheel 1871 Feb  7 11:02 /usr/local/etc/nut/upsset.conf
[23.09.1-RELEASE][root@fw]/root:

Lastly, start the UPS service via command "/usr/local/etc/rc.d/nut.sh start".

dennypage

@pvk1 said in NUT Package (2.8.1 and above):

It just occurred to me... was this attempt to start nut via /usr/local/etc/rc.d/nut.sh done as a non root user?

If so, the output makes perfect sense.

jonlecroy

@dennypage I just upgraded to pfsense 24.03 with nut 2.8.2_2. Does this have the fix for this issue, or should I reapply the private? Thanks!

dennypage

@jonlecroy said in NUT Package (2.8.1 and above):

Does this have the fix for this issue, or should I reapply the private?

What issue are you referring to?

jonlecroy

@dennypage Ah sorry, this is a general thread isn't it. The UPS regular maintenance sending an 'administrative off' which triggers a pfsense immediate halt when it shouldn't.

dennypage

@jonlecroy said in NUT Package (2.8.1 and above):

The UPS regular maintenance sending an 'administrative off' which triggers a pfsense immediate halt when it shouldn't.

I believe this is addressed, yes.

incith

For what it's worth, I just did a pkg-static remove nut-devel and pfsense nut 2.8.2_1 blah blah. Cleaned it all out. Did a pkg-static update made sure repo is current. Installed the latest 2 packages from pfsense web gui, and tripplite USB is still broken.

pkg install -f nut-devel-2023.10.07_1.pkg

And it's fixed again.

dennypage

@incith The next release is expected switch over to the 2.8.2 production release of NUT.

rarlup

Not sure if you guys are aware but there is a bug with 2.8.2_4 and PPPoE as in when WAN goes down UPS states it's on battery (usbhid driver) and this causes unexpected shutdowns with internet offline, obviously.
Screenshot 2025-02-16 005154.jpg
pfSense+
24.11-RELEASE (amd64)
built on Sat Jan 11 18:11:00 EET 2025
FreeBSD 15.0-CURRENT

dennypage

@rarlup said in NUT Package (2.8.1 and above):

Not sure if you guys are aware but there is a bug with 2.8.2_4 and PPPoE as in when WAN goes down UPS states it's on battery (usbhid driver) and this causes unexpected shutdowns with internet offline, obviously.

Whenever an interface changes state, all packages are restarted. Expected, not particular to PPPoE.

Seems like you might be encountering an issue with the ups driver. What model of ups? And do you have anything in the Additional arguments to driver section? Or in any of the Advanced sections?

michmoor

@dennypage

Whenever an interface changes state, all packages are restarted. Expected, not particular to PPPoE.

Why does this happen? Why does it need to happen? Seems extremely disruptive for benign events

dennypage

@michmoor said in NUT Package (2.8.1 and above):

@dennypage

Whenever an interface changes state, all packages are restarted. Expected, not particular to PPPoE.

Why does this happen? Why does it need to happen? Seems extremely disruptive for benign events

It is required because pfSense does not have a view into what happens inside a package. Using NUT as an example, pfSense itself has no idea if NUT is using a remote connection, or what interface it may depend upon. Similar situations exist for all packages.

Package restart is the only current way to address this.