[Nut-upsdev] Nut (git) upsdrvctl fails without "-u root start <upsname>", upsd fails on state file GID
David C. Rankin
drankinatty at suddenlinkmail.com
Sun Dec 15 19:03:53 UTC 2013
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.
More information about the Nut-upsdev
mailing list