[Plugin] NUT v2 - Network UPS Tools

[Rysz]

12 minutes ago, secretstorage said:

I just installed it without a server reboot, and it seems that my case falls under the 'it's not going to work without a restart' category because I am getting some presumable permissions issue:
 

Can't open /etc/ups/ups.conf: Can't open /etc/ups/ups.conf: No such file or directory

This is while the conf file is clearly present and editable from their GUI, as well as it's modified in real time by GUI changes.

 

Would you consider it a restart based issue, or something more sinister?

 

BTW, thank you for a crystal clear explanation of the versioning and the plan moving forward! I would love it if many paid-for-services had such a level of 'support' let alone just a bunch of people helping each other out in their free time!

 

It's not a permission issue, it's remnants of the old 2.7.4. files (should be fixed with next update). What you can do in the meantime is uninstall the 2.8.0 plugin and install it again afterwards, this'll clear those directories without a restart and it should work then.

 

[secretstorage]

@Rysz Making progress, one step at a time:
 

Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Can't chdir to /var/state/ups: Permission denied
Driver failed to start (exit status=1)

Now stuck with an actual permissions issue – found this from millennia ago https://alioth-lists.debian.net/pipermail/nut-upsuser/2010-September/006223.html though may be complete irrelevant by now.

EDIT: Found this as well and it seems to indicate this directory is not created unless some services are enabled in NUT
https://bugzilla.redhat.com/show_bug.cgi?id=1187286

Edited July 26, 2023 by secretstorage

[Rysz]

15 minutes ago, secretstorage said:

@Rysz Making progress, one step at a time:
 

Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Can't chdir to /var/state/ups: Permission denied
Driver failed to start (exit status=1)

Now stuck with an actual permissions issue – found this from millennia ago https://alioth-lists.debian.net/pipermail/nut-upsuser/2010-September/006223.html though may be complete irrelevant by now.

 

I'm afraid this one will most likely require a reboot to work as permissions will "clean up" after reboot.

This is unfortunately one of the downsides on switching backends without rebooting in between.

Please let us know after the reboot if the permission issue has resolved and if it's working with NUT 2.8.0

 

[secretstorage]

Just now, Rysz said:

 

I'm afraid this one will most likely require a reboot to work as permissions will "clean up" after reboot.

This is unfortunately one of the downsides on switching backends without rebooting in between.

Please let us know after the reboot if the permission issue has resolved and if it's working with NUT 2.8.0

 

If reboot is what it wants, a reboot is what it is going to get!
I am very impatient, but this time will have to wait for the parity check to complete considering an unclean shutdown last night....

This said, I think I'll remove the plugin, restart and install it once more, which hopefully will resolve both any remaining hanging folder issues and permissions. Please let me know if you agree.

 

 

[Rysz]

1 hour ago, secretstorage said:

If reboot is what it wants, a reboot is what it is going to get!
I am very impatient, but this time will have to wait for the parity check to complete considering an unclean shutdown last night....

This said, I think I'll remove the plugin, restart and install it once more, which hopefully will resolve both any remaining hanging folder issues and permissions. Please let me know if you agree.

 

 

 

I've tested this and it's actually (in part) a permissions issue with this driver on NUT 2.8.0

I've added a fix into the most recent pull request, so it should be fixed with the next update.

 

Sorry for the inconvenience!

 

Edited July 26, 2023 by Rysz

[secretstorage]

Thank you!!
Fingers crossed it's released soon.
I have this UPS in place and if it's not going to work out, I can return it to the seller in 14 days.

 

Hopefully, the fix will resolve that issue and another is not right behind it.
Knowing my luck, it won't be that easy...

[Rysz]

3 minutes ago, secretstorage said:

Thank you!!
Fingers crossed it's released soon.
I have this UPS in place and if it's not going to work out, I can return it to the seller in 14 days.

 

Hopefully, the fix will resolve that issue and another is not right behind it.
Knowing my luck, it won't be that easy...

 

If you want to test it in the meantime (on your running system) - run these commands:

chown root:nut /var/state/ups
chmod 0770 /var/state/ups
/etc/rc.d/rc.nut stop
/etc/rc.d/rc.nut start

That should fix the problem on your running system and you can test if your UPS works with the driver.

But note that this permission fix won't persist a reboot, you'll have to wait for the actual update for that.

[secretstorage]

9 minutes ago, Rysz said:

 

If you want to test it in the meantime (on your running system) - run these commands:

chown root:nut /var/state/ups
chmod 0770 /var/state/ups
/etc/rc.d/rc.nut stop
/etc/rc.d/rc.nut start

That should fix the problem on your running system and you can test if your UPS works with the driver.

But note that this permission fix won't persist a reboot, you'll have to wait for the actual update for that.

No luck!

 

root@Server:~# chown root:nut /var/state/ups
root@Server:~# chmod 0770 /var/state/ups
root@Server:~# /etc/rc.d/rc.nut stop
Writing nut config
Updating permissions...
Stopping the UPS services... 
Network UPS Tools - UPS driver controller 2.8.0
Can't open /var/state/ups/nutdrv_qx-ups.pid: No such file or directory
Can't open /var/state/ups/nutdrv_qx-auto.pid either: No such file or directory
root@Server:~# /etc/rc.d/rc.nut start
Writing nut config
Updating permissions...
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
^[[ADevice not supported!
Device not supported!
Driver failed to start (exit status=1)
root@Server:~# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Device not supported!
Device not supported!
Driver failed to start (exit status=1)
root@Server:~# 

Tried also with the specific subdriver, but the outcome was the same:

Edited July 26, 2023 by secretstorage
New information

[Rysz]

8 minutes ago, secretstorage said:

No luck!

 

root@Server:~# chown root:nut /var/state/ups
root@Server:~# chmod 0770 /var/state/ups
root@Server:~# /etc/rc.d/rc.nut stop
Writing nut config
Updating permissions...
Stopping the UPS services... 
Network UPS Tools - UPS driver controller 2.8.0
Can't open /var/state/ups/nutdrv_qx-ups.pid: No such file or directory
Can't open /var/state/ups/nutdrv_qx-auto.pid either: No such file or directory
root@Server:~# /etc/rc.d/rc.nut start
Writing nut config
Updating permissions...
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
^[[ADevice not supported!
Device not supported!
Driver failed to start (exit status=1)
root@Server:~# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Device not supported!
Device not supported!
Driver failed to start (exit status=1)
root@Server:~# 

Tried also with the specific subdriver, but the outcome was the same:

 

The permission problem is resolved - that's good and important for many other users (thanks for this!)

 

Can please you try putting subdriver, vendorid and productid starting from line 7?

[ups]
driver = nutdrv_qx
port = auto



subdriver = armac
vendorid = "0925"
productid = "1234"

It's a known oddity that causes problems in some cases.

Then restart the services:

/etc/rc.d/rc.nut stop
/etc/rc.d/rc.nut start

And check back with us here what is happening?

Your UPS is a tricky one, at least the drivers are properly starting now.

[secretstorage]

Tried both with serial and without, and with the records in specific lines, as indicated – no dice!

[Rysz]

1 hour ago, secretstorage said:

Tried both with serial and without, and with the records in specific lines, as indicated – no dice!

The logs indicate something in your configuration is broken.

 

You should remove your broken configuration file:

rm -f /boot/config/plugins/nut/nut.cfg 

 

After you should remove and reinstall the 2.8.0 plugin.

 

After that's done disable the NUT service via the NUT settings.

 

After that's done edit the ups.conf as shown above via the NUT settings (mind the line 7 oddity as you did before).

 

Make sure to also set the driver to "Custom" and "nutdrv_qx" as well as the "Port" to "auto" in the NUT settings, not just inside the file.

 

After that's done enable the NUT service via the NUT settings and report back here please.

 

Don't restart the NUT service via the command line (rc.nut), it seems to mess up the configuration.

 

Edited July 26, 2023 by Rysz
Remove deprecated permission commands

[secretstorage]

34 minutes ago, Rysz said:

The logs indicate something in your configuration is broken.

 

You should remove your broken configuration file:

rm -f /boot/config/plugins/nut/nut.cfg 

 

After you should remove and reinstall the 2.8.0 plugin and then run these commands right after:

chown root:nut /var/state/ups
chmod 0770 /var/state/ups

 

After that's done disable the NUT service via the NUT settings.

 

After that's done edit the ups.conf as shown above via the NUT settings (mind the line 7 oddity as you did before).

 

Make sure to also set the driver to "Custom" and "nutdrv_qx" as well as the "Port" to "auto" in the NUT settings, not just inside the file.

 

After that's done enable the NUT service via the NUT settings and report back here please.

 

Don't restart the NUT service via the command line (rc.nut), it seems to mess up the configuration.

 

I've followed all the steps as indicated, minus disabling the NUT service via the NUT settings, since it was stopped when I reinstalled it and couldn't 'disable' it anymore.

The outcome is unfortunately exactly the same, even when I try it from CLI as well.

[Rysz]

1 minute ago, secretstorage said:

I've followed all the steps as indicated, minus disabling the NUT service via the NUT settings, since it was stopped when I reinstalled it and couldn't 'disable' it anymore.

The outcome is unfortunately exactly the same, even when I try it from CLI as well.

 

@SimonF just updated the plugin packages with our latest fixes. You can now update the package and don't need the fix-permissions commands from above anymore, so you can try again after the reboot is possible for you (just do the other steps).

 

If that still doesn't work, then I'm afraid then the Slackware NUT 2.8.0 package doesn't recognize your UPS (maybe it was from an older 2.8.0 build not including the specific drivers for that UPS).

 

You could wait for NUT 2.8.1. but I'm not sure that'll arrive within your return window for the UPS. Right now there's no indication in those logs that it's a problem with the plugin, rather that your device is not recognized by the driver itself.

[SimonF]

Released 2023.07.26, @ich777 is creating a new package for me to use, and I want to look to move to 2.8 as the default version but will need to check upgrade path works ok.

[secretstorage]

I've installed the latest version and so far (without a reboot) suffer from the same issue.

It's really strange that the ancient Power Manager software works just fine with this newer model (PF1 generation), while the driver and subdriver indicated to work for others with Armac UPSs fails.

Is there any way to troubleshoot, further down the rabbit hole, why the driver doesn't work?

It may be something trivial they changed in the unit, as compared to older variants, and thus it is not recognized.

[Rysz]

Thanks everyone for the hard work and @SimonF for bearing with our messy PRs. 😅

[SimonF]

On 6/29/2023 at 5:46 PM, Masterwishx said:

 

Wow it shows all the info ! include product and serial :

 

 

ich777 has compiled a new version of the package, it may be work installing to see if that fixes the USB errors.

 

Stop nut from the settings, copy the attached file to /boot/config/plugins/nut/

 

Then change dir, remove old package, check command is missing and then load new package.

 

You can now restart nut

 

root@computenode:~# cd /var/log/packages
root@computenode:/var/log/packages# removepkg nut-2.8.0-x86_64-1 
Removing package: nut-2.8.0-x86_64-1
+  lots of lines

Check commands are gone

root@computenode:/var/log/packages# upsc
bash: upsc: command not found
root@computenode:/var/log/packages# 

Install package

root@computenode:/var/log/packages# installpkg /boot/config/plugins/nut/nut-2.8.0-x86_64-1.txz 
Verifying package nut-2.8.0-x86_64-1.txz.
Installing package nut-2.8.0-x86_64-1.txz:
PACKAGE DESCRIPTION:
# nut (Network UPS Tools)
#
# The Network UPS Tools is a collection of programs which provide a
# common interface for monitoring and administering UPS hardware.
# It uses a layered apporoach to connect all the components. Drivers
# are provided for a wide assortment of equipment. The primary goal of
# the NUT project is to provide reliable monitoring of UPS hardware
# and ensure safe shutdowns of the systems which are connected.
#
# Homepage: http://www.networkupstools.org
#
Executing install script for nut-2.8.0-x86_64-1.txz.
Package nut-2.8.0-x86_64-1.txz installed.
root@computenode:/var/log/packages# 

 

 

@secretstorageYou may want to try the above also.

 

I plan to replace the current package with this version, so anyone else using 2.8.0 able test please do so.

 

 

@cassiusdrowWould you be able to test new package for me also?

nut-2.8.0-x86_64-1.txz

[Masterwishx]

57 minutes ago, SimonF said:

ich777 has compiled a new version of the package, it may be work installing to see if that fixes the USB errors

OK i will try

[Rysz]

I'll test the new package too, thanks a lot @ich777

 

Since we're moving in direction of 2.8.0 I've checked for potential permission issues.

A pull request was submitted so that all permissions are the same throughout the script.

This should eliminate any possible problems with services and drivers not having enough access.

[ich777]

8 minutes ago, Rysz said:

This should eliminate any possible problems with services and drivers not having enough access.

I‘ve now gone through the PR, please don‘t change the permissions to 770 they should be set to 755

 

Also I wouldn‘t recommend changing the permissions at all.

[Rysz]

25 minutes ago, ich777 said:

I‘ve now gone through the PR, please don‘t change the permissions to 770 they should be set to 755

 

Also I wouldn‘t recommend changing the permissions at all.

 

In the current version (disregarding my PR) we currently have a collection of:

• chmod +0755
• chmod 640
• chmod 0770
• chown root:nut
• chown -R 218:218 (= nut:nut)
• chmod -R -r /etc/nut (what even is this, -r is nowhere in man pages of chmod)

 

To me that seems like an inconsistent mess and asking for permission trouble in the future.

At the moment some folders get root:nut, others nut:nut, some files 0770, some files 640

 

I chose 0770 root:nut for everything because that was already the most used throughout the script. So that the root user and nut group (which includes the nut user) would have read/write/delete/execute access to all files. I'm open to another single permission number throughout the whole plugin, but why the mess we're currently doing with multiple permissions scattered all over the place?

 

What's the benefit of keeping those various different permissions throughout the plugin?

 

Edited July 26, 2023 by Rysz

[Masterwishx]

1 hour ago, SimonF said:

ich777 has compiled a new version of the package, it may be work installing to see if that fixes the USB errors.

 

I checked but still have unknown 2000 , i will try to check another usb cable when will buy it  

 

 

 

[ich777]

27 minutes ago, Rysz said:

In the current version (disregarding my PR) we currently have a collection of:

Because that's the correct permissions and how the developers of NUT have intended them to be, maybe not for chown -R 218:218 but for everything else these are the correct permissions and how the are compiled.

The files which are in /etc/nut should have 644 and have them by default, also why should a config file be executable?

 

27 minutes ago, Rysz said:

chmod -R -r /etc/nut (what even is this, -r is nowhere in man pages of chmod)

That means that all the files in this directory are changed to read only recursively.

 

27 minutes ago, Rysz said:

What's the benefit of keeping those various different permissions throughout the plugin?

Usually on a Linux filesystem you don't set all permissions to 770 to ensure that everything is working, at least I'm strongly against 770.

 

For Slackware I would recommend the permissions 755 and not 770, there is even an option when creating a Slackware package to set all permissions to 755 and even there it's not recommended doing that.

Quote

          -c, --chown y|n (resets all permissions to root:root 755 - not
               generally recommended)

 

Hope that makes sense to you.

[SimonF]

8 minutes ago, Masterwishx said:

 

I checked but still have unknown 2000 , i will try to check another usb cable when will buy it  

 

 

 

Unlikley to be the cable as udev reports correctly.

[Rysz]

@ich777: I'll trust you there, thanks for the compiling insight - closing PR.