Nut upsuser - Jan 2011 - Getting a Plexus 500VA to work with NUT

Hi all,

First off thanks you for such a great tool - my searching so far
indicates that the developers and community behind nut are committed
and doing a great job!

Background: I've just purchased a Plexus 500VA UPS for ebuyer because
it was cheap. I didnt expect much but I've seen a few references to
people getting the same and similar models to work with NUT so was
encouraged to try! The NUT website compatability chart lists that the
blazer_usb driver is the correct one to use.

The monitoring server is actualy a linksys NSLU2 (ARM architecture)
but flashed to run vanilla debian etch. Initially, I installed nut
from the apt repositories (v 2.2.2 I believe) however this version did
not include the blazer_usb driver. I did not a t this stage attempt to
use another driver as the compat chart seemed to indicate blazer was
the way to go.

Instead I apt-get removed nut, and then downloaded and compile the
latest 2.6 source from tar ball (installing dependencies, and using
--with-user=nut --with-group=nut and --with-usb). I've check nut user
and group exist and nut user is a member of group nut.

I now have nut 2.6.0 installed however can't get the blazer_usb driver
to communicate with the UPS due to permissions issues. Debug output:

$ cat ups.conf
[rupert]
	driver = blazer_usb
        port = auto

$ ./blazer_usb -a rupert -DDDDD -u root
Network UPS Tools - Megatec/Q1 protocol USB driver 0.03 (2.6.0)
   0.000000	debug level is '5'
   0.019447	Checking device (0001/0000) (003/010)
   0.022465	- VendorID: 0001
   0.024659	- ProductID: 0000
   0.027246	- Manufacturer: unknown
   0.029307	- Product: unknown
   0.031805	- Serial Number: unknown
   0.034021	- Bus: 003
   0.036163	Trying to match device
   0.038393	Device matches
   0.040732	failed to claim USB device: could not claim interface 0:
Operation not permitted
   0.042969	failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
   0.045468	failed to claim USB device: could not claim interface 0:
Operation not permitted
   0.048084	failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
   0.050467	failed to claim USB device: could not claim interface 0:
Operation not permitted
   0.052842	failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
   0.055540	failed to claim USB device: could not claim interface 0:
Operation not permitted
   0.058121	failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
   0.060418	Can't claim USB device [0001:0000]: could not detach
kernel driver from interface 0: Operation not permitted

I've seen this come up and have checked all permisions/udev related
things. The relevant entry in udev rules is there (whole script copied
from the tar ball scripts/udev/52-nut-usbups.rules):

#  Krauler UP-M500VA  - blazer_usb
ATTR{idVendor}=="0001", ATTR{idProduct}=="0000",
MODE="664", GROUP="nut"

However it appears not to work. Incidentally, it DID work when I still
had the old 52_nut-usbups.rules file left over from the apt install. I
could ls -al the appropriate bus/device in /dev/bus/usb and see it was
owned by root:nut.

As part of troubleshooting I have removed the 52_nut-usbups.rules that
was left over from apt install and copied the 52-nut-usbups.rules file
from the 2.6.0 tar ball and now it appears not to work! i.e. ls -l
shows the correct bus/device dir owned by root:root. That seems to be
a secondary issue for now though because even with the older script
and ls -l returning correct perms, launching the driver still failed
with an identical debug output. Similarly, if I manual chown root:nut
the device dir now, I still get the same result form starting the
driver. If anyone has any ideas why the old version of udev rules
worked and the current doesn't that would be interesting but appears
not to be the root of my problem currently.

I've also created /var/run/nut and tried it with root:nut and nut:nut
ownership, even with 777 permissions. All give the same output as
above regardless of the -u setting.

Note that I get the above output when running the command from a
normal non-root user. (not nut user as that has no shell). If I run
the same as root I get a different error saying it couldn't connect to
UPS at all - I originally was going to post about that when I realised
that I probably should be running blazer-usb command as non-root. If
it SHOULD work to launch the driver directly as root then let me know
and I'll post the output as that might identify better the actual
issue here.

I've tried looking at all the options I've seen discussed related to
permissions and USB with NUT but I have searched for many hours now
with nothing getting this to work!

Would be very grateful for any tips that would nudge me in the right
direction. I hope I've provided all necessary info for now. If not,
please let me know.

Thanks again for your hard work on this and I hope someone can spot my
fatal mistake!

Cheers

Paul

On Jan 23, 2011, at 2:16 PM, Paul Banks wrote:
> $ ./blazer_usb -a rupert -DDDDD -u root
^ If this is in a non-root shell, this won't work.

NUT has no hooks to go from a non-root user ID to root, nor can it  
change from one non-root user to another non-root user. (To do so  
would require setuid binaries, or calling an existing setuid tool like  
sudo.)

The "-u root" option is to override the default behavior when started
as root, which is to change to the non-root user specified at  
configuration time (usually "nut", or the last-resort
"nobody").
> Note that I get the above output when running the command from a
> normal non-root user. (not nut user as that has no shell). If I run
> the same as root I get a different error saying it couldn't connect to
> UPS at all - I originally was going to post about that when I realised
> that I probably should be running blazer-usb command as non-root. If
> it SHOULD work to launch the driver directly as root then let me know
> and I'll post the output as that might identify better the actual
> issue here.
If you want to invoke a driver from a non-root account, then "-u"  
won't have an effect, and that non-root account should be the one  
specified at configuration time.