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

[Charles Lepple]

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