Nut upsdev - Dec 2013 - Nut (git) upsdrvctl fails without "-u root start <upsname>", upsd fails on state file GID

On 12/14/2013 09:04 PM, Charles Lepple wrote:
>> Is there someway nut can be modified to probe the 0664 permission usb
>> devices
>>> and then connect as root before dropping permissions back to the
"nut"
>>> gid?
> Given that the udev method should still work (and seems to, for handcrafted
> udev rules files), I would like to run that to ground first.
It is almost like we will need to develop a scheme that can probe for usb ups
devices and then create/install the custom rule on-the-fly.

Since there are not that many manufactures of usb ups devices, perhaps we can
get a collection of usb device information for each manufacturer, write a
routine to probe the usb ports, compare the results against the data and then
write/install a rule that will allow upsdrvctl to start gid 'nut'.

I'm wading into new water here, so I'll look at what information I have
available for my CyberPower ups and see if I can ID some parameters that are
useful. We can then see if APC, Belkin, etc.. devices have that information as
well. I know there are differences. My ups does not report an ATTRS{serial} on
the device itself when udevadmin is called. It does on the parent device, but
only the generic ATTRS{serial}=="0000:00:04.0" for bus 4. There is
useful
information though:

[14:37 phoinix:/srv/http/htdocs/nut] # udevadm info --attribute-walk --name
/dev/bus/usb/004/002

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

The group of ATTRS that look promising are:

  looking at device '/devices/pci0000:00/0000:00:04.0/usb4/4-3':
    ATTR{idVendor}=="0764"
    ATTR{bcdDevice}=="0001"
    ATTR{urbnum}=="161297"
    ATTR{manufacturer}=="CPS"
    ATTR{idProduct}=="0501"
    ATTR{bDeviceClass}=="00"
    ATTR{product}=="UPS CP1000AVRLCD"

  looking at parent device '/devices/pci0000:00/0000:00:04.0/usb4':
    ATTRS{idVendor}=="1d6b"
    ATTRS{bcdDevice}=="0312"
    ATTRS{serial}=="0000:00:04.0"
    ATTRS{urbnum}=="35"
    ATTRS{manufacturer}=="Linux 3.12.1-3-ARCH ohci_hcd"
    ATTRS{idProduct}=="0001"
    ATTRS{bDeviceClass}=="09"
    ATTRS{product}=="OHCI PCI host controller"

  I have very little udev knowledge, but it we can use this info to craft a udev
rule and then get similar information from the other vendors, then it should be
straight forward to add a routine to the upsdrvctl connection code that does
something like:

Attempt to connect
if no connect; then
  probe usb system with udevadm info -a -n for all /dev/bus/usb/*/*
  parse/compare to known iformation
  if data matches known; then
    write/install udev rule (or use found information to otherwise connect)
  fi
fi
Attempt to connect
if no connect; the throw error; fi

  This again, is all just brainstorming. If you have thoughts on it, let me
know. I will have limited time over the next few weeks, so it will be after the
holidays before I can commit a good block of time to this, but we have to start
somewhere...


-- 
David C. Rankin, J.D.,P.E.

On Dec 15, 2013, at 2:03 PM, David C. Rankin wrote:
> On 12/14/2013 09:04 PM, Charles Lepple wrote:
>>> Is there someway nut can be modified to probe the 0664 permission
usb
>>> devices
>>>> and then connect as root before dropping permissions back to
the "nut"
>>>> gid?
>> Given that the udev method should still work (and seems to, for
handcrafted
>> udev rules files), I would like to run that to ground first.
> 
> It is almost like we will need to develop a scheme that can probe for usb
ups
> devices and then create/install the custom rule on-the-fly.
> 
> Since there are not that many manufactures of usb ups devices, perhaps we
can
> get a collection of usb device information for each manufacturer, write a
> routine to probe the usb ports, compare the results against the data and
then
> write/install a rule that will allow upsdrvctl to start gid 'nut'.
Theoretically, that is the sort of information that we are already gathering
from the NUT drivers:

   https://github.com/networkupstools/nut/blob/master/tools/nut-usbinfo.pl

That script generates (among other things) the scripts/udev/nut-usbups.rules.in
file, which gets its @RUN_AS_GROUP@ token replaced by the group name at
configure time. On the Debian 7 (wheezy) box where I just verified that udev
works, it is installed to /lib/udev/rules.d/52-nut-usbups.rules

The necessary-and-sufficient set for the udev rules file (once the device is
identified as USB) should be ATTR{idVendor} and ATTR{idProduct}. Any additional
information could be used to distinguish between multiple UPSes (which can be
done at the NUT driver level in ups.conf), but would not be necessary for
setting the proper permissions with udev.
> Attempt to connect
> if no connect; then
>  probe usb system with udevadm info -a -n for all /dev/bus/usb/*/*
>  parse/compare to known iformation
>  if data matches known; then
>    write/install udev rule (or use found information to otherwise connect)
>  fi
> fi
> Attempt to connect
> if no connect; the throw error; fi

While this should work, the parse/compare step should be done by udev using the
existing rules file, and it seems like something is preventing that from
happening.

Apparently, udev is tolerant of being stopped and started manually (at least on
a server not running X), so I stopped it, and ran "udevd --debug
2>&1 |tee /tmp/udevd-`date -I`", then plugged in a supported UPS.
This seems to be the relevant part:

[1162874.300131] [17290] event_queue_insert: seq 1304 queued, 'add'
'usb'
[1162874.300298] [17290] worker_new: seq 1304 forked new worker [17394]
[1162874.300456] [17394] worker_new: seq 1304 running
...
[1162874.304114] [17290] event_queue_insert: seq 1305 queued, 'add'
'usb'
[1162874.304142] [17290] event_queue_insert: seq 1306 queued, 'add'
'hid'
[1162876.465264] [17290] event_queue_insert: seq 1307 queued, 'add'
'class'
[1162876.465436] [17290] worker_new: seq 1307 forked new worker [17397]
[1162876.465487] [17290] event_queue_insert: seq 1308 queued, 'add'
'usb'
[1162876.465508] [17290] event_queue_insert: seq 1309 queued, 'add'
'hidraw'
[1162876.465619] [17394] udev_rules_apply_to_event: GROUP 121
/lib/udev/rules.d/52-nut-usbups.rules:48
[1162876.465627] [17394] udev_rules_apply_to_event: MODE 0664
/lib/udev/rules.d/52-nut-usbups.rules:48
...
[1162876.466653] [17394] udev_rules_apply_to_event: MODE 0664
/lib/udev/rules.d/91-permissions.rules:36
[1162876.466668] [17394] udev_event_execute_rules: no node name set, will use
kernel supplied name 'bus/usb/002/004'
[1162876.472267] [17394] udev_node_add: creating device node
'/dev/bus/usb/002/004', devnum=189:131, mode=01664, uid=0, gid=121
[1162876.472282] [17394] udev_node_mknod: preserve file
'/dev/bus/usb/002/004', because it has correct dev_t
[1162876.472286] [17394] udev_node_mknod: set permissions /dev/bus/usb/002/004,
021664, uid=0, gid=121

If you want, we can take a look at the output of the aforementioned udevd
command from your system. Please compress the output, and if the list bounces
it, I'll extract the relevant portion from the bounce message.

I have a funny feeling we might either have a Debian-specific dependency on
91-permissions.rules, or some other package is masking the NUT udev rule.

-- 
Charles Lepple
clepple at gmail

On 12/16/2013 09:06 AM, Charles Lepple wrote:
> If you want, we can take a look at the output of the aforementioned udevd
> command from your system. Please compress the output, and if the list
bounces
> it, I'll extract the relevant portion from the bounce message.
> 
> I have a funny feeling we might either have a Debian-specific dependency on
> 91-permissions.rules, or some other package is masking the NUT udev rule.
> 
Charles,

  I'll be glad to get the information from my box, but we have to get upsd
running again. See thread: "kernel update to 3.12.5-1, now: upsd[617]:
getaddrinfo: Servname not supported for ai_socktype". upsd quit working
after my
kernel update today. I have no ideas what the ai_socktype error is, but I've
seen quite a bit of coding arguments about how to implement it on the web.
Perhaps the latest kernel makes the way nut does it not work anymore. That's
for
the other thread though...

  If the output from my udev test is large, I'll just post if for download
on my
site and include a link in the email. Thanks again for your help.

-- 
David C. Rankin, J.D.,P.E.