NUT / TrippLite / Permission problems?

[tekgeek]

 I have a TrippLite su1000rtxl2ua UPS setup with NUT.

General Settings
  Service Mode = standalone
  Name = TrippLiteTest
  Listen Address 127.0.0.1
UPS Type
  Driver: USBHID-Driver
    port=auto vendorid=09ae productis=40004 (values found on the console)



I don't ever get an output on the diagnostics page, so i check the logs and see.

Notice   usbhid-ups   writepid: fopen /var/db/nut/usbhid-ups-TrippliteTest.pid: Permission denied


So I stop the services and jup on the console and google. I manage to start the services as root no problem. So I stop them and try to start them as the "nut" user. Everything starts, I hop on the UI and boom UPS stats! So I reboot. 95% sure its going to break, and i was right. So I try modifying the service to do this for me by changing the nut-prestar to start it with root, kill it, and start it the second time as nut.

nut_prestart() {
        #
        # As of PR/268960 UID/GID uucp is no longer used by nut.
        # Instead UID/GID nut is used. Make sure preexisting nut files
        # and directories are owned by nut instead of uucp.
        #
        if [ "${nut_file_fixup}" == "YES" ]; then
                find ${nut_prefix}/etc/nut -user uucp -exec chown nut {} \;
                find ${nut_prefix}/etc/nut -group uucp -exec chgrp nut {} \;
                find /var/db/nut -user uucp -exec chown nut {} \;
                find /var/db/nut -group uucp -exec chgrp nut {} \;
        fi

        # Start the driver as root first
        /usr/local/libexec/nut/usbhid-ups -a TrippliteTest -u root
        # Give it a moment to initialize
        sleep 2
        # Kill the root instance
        pkill -f "/usr/local/libexec/nut/usbhid-ups -a TrippliteTest -u root"

        # Now start the driver normally
        ${nut_prefix}/sbin/upsdrvctl start
}

This works but of course gets nuked with reboots, updates, and sometimes seemingly at random. I assume there is a proper way of editing services and this isn't it. So instead of learning the right way i save a copy in my home folder and create a script to copy the file and restart the service.

#!/bin/sh

# Define the source and destination paths
SOURCE="/home/tekgeek/nut"
DESTINATION="/usr/local/etc/rc.d/nut"

# Move the file from the source to the destination
cp -p "$SOURCE" "$DESTINATION"

# Restart the NUT service to apply changes
service nut restart


I also put the script here /usr/local/opnsense/scripts/fixNUT/fixNUT.sh, and an action for the script to gain UI access to setup a cron job.

[run]
command:/usr/local/opnsense/scripts/fixNUT/fixNUT.sh
parameters:
type:script
message:Fixing NUT
description: Fix NUT


This still breaks so I need to occasionally run the script in my home folder manually?

This seems like a permissions bug in one of the startup scrips, but I don't know where or how to fix it. I would really like to not have this kludgy, fragile config. ChatGPT was used to modify the service and create the scripts.

[doktornotor]

Dunno, but this was fixed about 1 1/2 years ago. Perhaps you should remove and reinstall the package.

https://github.com/opnsense/plugins/commit/16cbe99ebf0e776afa5deee349f9e0ff73fbe8aa

Code Select Expand


# ls -l /var/db/nut
total 2
-rw-r--r--  1 nut nut 6 Aug 30 02:05 upsd.pid
-rw-r--r--  1 nut nut 6 Aug 30 02:05 upsmon.pid
srw-rw----  1 nut nut 0 Aug 30 02:05 usbhid-ups-CyberPowerOR600
-rw-r--r--  1 nut nut 6 Aug 30 02:05 usbhid-ups-CyberPowerOR600.pid



[tekgeek]

Thanks for the reply. This was a somewhat fresh install, but I did try removing and reinstalling a couple of times to no effect.

For a sanity check, I uninstalled and removed users nut, messagebus, and avahi as the output of the uninstall process said. Rebooted, installed, rebooted, setup, rebooted. This fixed it. I think something was broken with the users/groups, I always ignored the output or the uninstall process and left the users/groups each reinstall. 3 extra commands in the console fixed it.
sudo rmuser nut
sudo rmuser avahi
sudo rmuser messagebus

I think it might be useful to send a popup message when extra actions are needed to finish an uninstall. Or give the uninstaller permission to remove the users after a confirmation popup. I can't be in the minority, most people at best skim the last couple of lines. "DONE" at the end maybe should be more specific. Like "Sucess" when no extra actions are needed and "DONE, some extra actions may be needed, read the entire output."

[doktornotor]

The post-(un)install messages from pkgs in output are very much irrelevant for OPNsense. Honestly, cannot see how would that affect the resursive chown either.

[tekgeek]

IDK what or how it really broke. It seems like a one-off or edge case. I couldn't find any others with the problem, but my google fu has been a bit off since AI got involved. Its fixed so I'm happy.

Do you happen to know what NUT is looking for to initiate a shutdown. Is it just looking for the low power warning? I want to configure a 2nd nut instance (using the SNMP driver, on a 2nd system) for the rest of the stuff covered by the UPS. With more control over that instance I can define the shutdown parameters to be something like 50% or remaining battery (low battery warning should trip at 25% for my UPS). Im trying to keep my WIFI up as long a possible while shutting down the rest of the network.

[tekgeek]

Woke up this morning to NUT broken again. This is getting really annoying.  I give up, I'll just schedule a restart of the service with my script every 6 hours and cross my fingers that a power outage doesn't happen at a time NUT is broken.

[doktornotor]

Well, I would suggest undoing your "fixes" and doing a fresh OPNsense re-install.

[tekgeek]

All my "fix'" does is start NUT as root, kill, start NUT as nut. A full reinstall isn't really an option. I might just get a Rpi to do all the NUT stuff. If OPNsense's NUT continues to fail with the SNMP-driver or in client mode I'll just schedule remote backups and let it die with a power loss. Im done banging my head against the wall with this for a while. I'm going to leave it for a couple of days. Maybe try to scrounge up the parts for a test machine.   

[tekgeek]

Come to think of it I have an HP DL360 G7 collecting dust, but that thing sounds like a jet. IDK if i can sit next to it long enough to test, and racking it would be a pain for a quick test.