Rob Groner
2015-Feb-19 13:43 UTC
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Thank you all for the help! I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. I looked at the file and saw how it was laid out...basically an ATTR for every known USB UPS. Well, since mine is not a known UPS, I had to add my own entry. So I added a similar entry to all the others, but putting in my USB vendor and product IDs and setting GROUP="nut" (like all the other entries do). ATTR{idVendor}=="04d8", ATTR{idProduct}=="005c", MODE="664", GROUP="nut" But so far as I can tell, when I plug in the USB cable from the UPS...it is still not setting it to nut group permissions. I am looking at the file in /dev/usb/hid/hiddev0 (which goes away when I unplug the UPS). Either way, upsdrvctrl still won't start unless I add "-u root". So I think my udev rule is simply not taking somehow. Sincerely, Rob Groner> -----Original Message----- > From: Charles Lepple [mailto:clepple at gmail.com] > Sent: Wednesday, February 18, 2015 8:11 PM > To: Rob Groner > Cc: nut-upsuser List > Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut > 2.7.2 > > On Feb 18, 2015, at 10:40 AM, Rob Groner <rgroner at RTD.com> wrote: > > > Does this revolve around hotplug and udev? > > Yes. (Well, technically hotplug was superseded by udev) > > > In other words, is the idea that the created USB device will be in the "nut" > group, > > Yes. > > > and thus I'd be able to tell upsdrvctrl to start if I am user "ups"? Or do > ups/nut not really play into any of this? > > The usual startup procedure is to run upsdrvctl as root (such as in a login > script). It will automatically drop the driver to ups/nut. > > However, as you mentioned, that requires udev. I don't have an opensuse > system, and the broadband connection is down, so I'm not exactly sure what > you need to do there. On recent Debian and Ubuntu with 2.7.2 and earlier, > there was an issue where the udev rules file needed to be renamed from 62- > nut* to 52-nut* in order to not be overridden by another set of rules. It lives > somewhere like /lib/udev/rules.d
Charles Lepple
2015-Feb-20 03:08 UTC
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote:> I looked at the file and saw how it was laid out...basically an ATTR for every known USB UPS. Well, since mine is not a known UPS, I had to add my own entry.If you want, once things are working, we can add an entry to that table (via drivers/usbhid-ups.c, which gets parsed into the udev script)> So I added a similar entry to all the others, but putting in my USB vendor and product IDs and setting GROUP="nut" (like all the other entries do). > > ATTR{idVendor}=="04d8", ATTR{idProduct}=="005c", MODE="664", GROUP="nut" >You might need to tell udev to reload, although newer versions seem to re-read the rules files automatically. Also, I think there is a debug mode for udev that will show what is being parsed when.> But so far as I can tell, when I plug in the USB cable from the UPS...it is still not setting it to nut group permissions. I am looking at the file in /dev/usb/hid/hiddev0 (which goes away when I unplug the UPS). Either way, upsdrvctrl still won't start unless I add "-u root"./dev/bus/usb/*/* is the place to look (the hiddev* nodes are not used by libusb). Once the permissions there look correct, can you post the output of running the driver directly with -D?
Charles Lepple
2015-Feb-20 03:11 UTC
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote:> I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d.My apologies, I got that backwards in my earlier email. udev applies the rules in numerical sequence, so 62 overrides 52. The file should be renamed to 62-nut... to take effect.
Rob Groner
2015-Feb-20 14:31 UTC
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
Charles, Success! But also curious. I renamed the 52-* file to 62-*, rebooted, confirmed that the USB device created when I plugged in the UPS had a group of "nut" (it does), and then started the upsdrvctrl as user "ups", without "-u root". Yay, that's all a first! However, I then went back and renamed the 62-* file back to 52-*, just to check, rebooted, etc....and it still works. So I think I was doing something else wrong in the process, and it wasn't necessarily the fact it was named 52-*. For now, however, it works just great! Now to once again confirm it shuts my system down when it should... And I'll be happy to add our UPS info to the correct nut files when it is all done and working, which looks to be around late April. Thanks! Sincerely, Rob Groner> -----Original Message----- > From: Charles Lepple [mailto:clepple at gmail.com] > Sent: Thursday, February 19, 2015 10:12 PM > To: Rob Groner > Cc: nut-upsuser List > Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut > 2.7.2 > > On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote: > > > I followed the log messages and found where it had created the udev > rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there > is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. > > My apologies, I got that backwards in my earlier email. udev applies the rules > in numerical sequence, so 62 overrides 52. The file should be renamed to 62- > nut... to take effect.
Rob Groner
2015-Feb-20 20:15 UTC
[Nut-upsuser] Install problems (group permissions) with nut 2.7.2
I think I had a misconception about something.. My goal was that someone could use our UPS with the "default" UPS driver in NUT right out of the box, so they wouldn't have to alter any NUT code to get it working. NUT config files, yes, but not NUT code. I thought that if I put in the ups.conf file that I wanted to use the usbhid-ups driver, and then put our vendor and product ID, it would find whatever USB device matched those vid and pid, and then use the usbhid-ups driver with it. Instead, it seems that the usbhid-ups driver will search through its own list of known devices with vid/pid, and won't "match" my device unless that device exists as an entry in its device table. Is that correct? In other words, instead of the ups.conf file saying "Use usbhid-ups with USB device of vid/pid", it is saying "Use usbhid-ups with USB device of vid/pid *if* they are in the list of devices for usbhid-ups"? Sincerely, Rob Groner> -----Original Message----- > From: Charles Lepple [mailto:clepple at gmail.com] > Sent: Thursday, February 19, 2015 10:09 PM > To: Rob Groner > Cc: nut-upsuser List > Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut > 2.7.2 > > On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote: > > > I looked at the file and saw how it was laid out...basically an ATTR for every > known USB UPS. Well, since mine is not a known UPS, I had to add my own > entry. > > If you want, once things are working, we can add an entry to that table (via > drivers/usbhid-ups.c, which gets parsed into the udev script) > > > So I added a similar entry to all the others, but putting in my USB vendor > and product IDs and setting GROUP="nut" (like all the other entries do). > > > > ATTR{idVendor}=="04d8", ATTR{idProduct}=="005c", MODE="664", > GROUP="nut" > > > You might need to tell udev to reload, although newer versions seem to re- > read the rules files automatically. > > Also, I think there is a debug mode for udev that will show what is being > parsed when. > > > But so far as I can tell, when I plug in the USB cable from the UPS...it is still > not setting it to nut group permissions. I am looking at the file in > /dev/usb/hid/hiddev0 (which goes away when I unplug the UPS). Either > way, upsdrvctrl still won't start unless I add "-u root". > > /dev/bus/usb/*/* is the place to look (the hiddev* nodes are not used by > libusb). Once the permissions there look correct, can you post the output of > running the driver directly with -D?