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

On 12/14/2013 02:06 PM, David C. Rankin wrote:
> Charles,
> 
>   Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the
issue.
> The question now become how to automate this process so that the user
isn't
> required to manually hunt down the usb dev and change gid to the nut gid?
So
> far, either manually setting the gid or hand-rolling the udev files to do
the
> same thing seems like things that used to work automatically, but now
require
> user intervention. I don't know the answer, but I'll post this to
the Arch list
> and see if the devs there have any idea. Thanks again for your help.
Charles, All,

  Do you know if the problem with upsdrvctl being able to probe/connect to the
usb devices is the result of some default permission change in Linux in general.
It seems to me that since nut used to work right out-of-the-box, then all/most
distros must have had the default permissions on usb nodes set to 0666, where
currently they are 0664. (this is just brainstorming)

  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? I've
also posed this question and the problems encountered attempting to run nut out
of the box to the Arch list as well. A summary of that post and the problem here
is:

<quote>

  After working through errors starting the latest nut from git with systemd,
the problem was that /dev/bus/usb/004/002 is owned by root:root forcing
nut-driver.server to fail to start. Essentially upsdrvctl could not find/connect
with /dev/bus/usb/004/002 and could not find the ups usb connection. Modifying
the Execstart=/usr/bin/upsdrvctl start to:

/usr/bin/upsdrvctl -u root start <upsname>

  allowed upsdrvctl to connect, but then created the state files in
/var/state/ups with root:root permission which in turn caused nut-server.service
(upsd) to fail on startup. upsd could not read the device files created in the
state directory and could not create the upsd.pid as it was running gid
"nut".

  Changing gid ownership of /dev/bus/usb/004/002 to root:nut solves all problem
and allows upsdrvctl, upsd and upsmon to all start and connect fine. However,
there is no way for the packager to know what bus a device with install or or
whether it will be plugged back into the same port each time. I would like to
investigate how Arch could be changed/configured so that nut simply runs out of
the box as it used to before what ever changed changed. Is there a way the
packager can do this?

</quote>

  I think this is one of those issues that will take coordination between the
distros and nut to solve unless there is some magic nut can do to work with the
root:root 0664 device permissions by default. What do you think?

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

On Dec 14, 2013, at 4:23 PM, David C. Rankin wrote:
>  Do you know if the problem with upsdrvctl being able to probe/connect to
the
> usb devices is the result of some default permission change in Linux in
general.
> It seems to me that since nut used to work right out-of-the-box, then
all/most
> distros must have had the default permissions on usb nodes set to 0666,
where
> currently they are 0664. (this is just brainstorming)
Sounds logical, but I think the auto-generated hotplug and udev files properly
changed the group for a while after the permissions changeover to 0664.
>  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.

Although this is conceptually similar to opening a listening socket as root,
then forking and dropping privileges, I have a nagging feeling that it won't
be as easy for USB.

-- 
Charles Lepple
clepple at gmail

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.