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

On 12/14/2013 07:20 AM, Charles Lepple wrote:
> On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote:
> 
>> lsusb shows:
>> 
>> Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR
UPS
> 
> 
> I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the
device node is
> not owned by the NUT gid?
> 
crw-rw-r-- 1 root root 189, 385 Dec 14 12:31 /dev/bus/usb/004/002

It does now.
>> Why doesn't "upsdrvctl start" allow nut to find the UPS
when it can find it
>> without a problem with the options "-u root start
<upsname>"?
> 
> The NUT USB drivers use libusb, which need read/write access to the /dev
node
> for the UPS. The "-u root" hack tells the driver not to drop
privileges from
> root to the 'nut' system user.
> 
That's what I thought was going on, I just didn't know where to fix the
usb dev
node.
>> Second why doesn't nut create the .pid files and the usbhid file
with
>> root:nut ownership?
> 
> Mostly because the "-u root" option is meant to be a temporary
fix while
> tracking down permissions issues. Hopefully we can figure out the
underlying
> permissions issue, and we can table that question.
> 
<snip>

I found another really good article that describes writing the udev files to fix
these issues. The url is:

http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/

I will test with the new ubs dev permission and report back. Thank you for your
help Charles.

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

On 12/14/2013 12:37 PM, David C. Rankin wrote:
> I will test with the new ubs dev permission and report back. Thank you for
your
> help Charles.
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.

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

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.