Bug 187105

Summary: usb ups persmissions not correct (included a possible fix in udev).
Product: [Fedora] Fedora Reporter: Kapoios Kanenas <firewalkergr>
Component: nutAssignee: Than Ngo <than>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: kay.sievers
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-24 16:50:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
udev rule file to change permissions for USB UPS devices
none
mge ups rules
none
udevinfo -a -p /class/usb_device/usbdev1.3
none
lshal output (only the ups) none

Description Kapoios Kanenas 2006-03-28 15:42:56 UTC
Created attachment 126911 [details]
udev rule file to change permissions for USB UPS devices

Comment 1 Kapoios Kanenas 2006-03-28 15:42:56 UTC
Description of problem:

nut user is not able to write USB UPS device.


lsusb 
...
Bus 001 Device 005: ID 0463:ffff MGE UPS Systems UPS
...

LANG=C ls -l /dev/bus/usb/001/005
crw-r--r-- 1 root nut 189, 4 Mar 28 17:46 /dev/bus/usb/001/005



As result nut fails: 
anarchos64[tasos]:/etc/udev/rules.d$ sudo service ups start
Starting upsdrvctl: Network UPS Tools - UPS driver controller 2.0.2
Network UPS Tools: New USB/HID UPS driver 0.23 (2.0.2)

No USB/HID UPS found
Driver failed to start (exit status=1)
                                                           [FAILED]

nut works ok if you change the permissions to 664 and the group to nut for the
device 

Find attached a udev rule file to fix the permissions.


Version-Release number of selected component (if applicable):
rpmquery nut
nut-2.0.2-6.2

Comment 2 Kay Sievers 2006-04-09 13:50:16 UTC
Matching on a single 0xffff value to identify a UPS sounds pretty wrong. USB
UPS'es are usually HID devices and can identified as such, is that different for
you UPS? You may run:
   udevinfo -a -p /class/usb_device/usbdevX.Y
for the device to look for a better match.

Comment 3 Kapoios Kanenas 2006-04-09 14:14:04 UTC
Created attachment 127522 [details]
mge ups rules

Comment 4 Kapoios Kanenas 2006-04-09 14:15:39 UTC
My mistake I forgot to add the vendor id.

Find the rules with vendor ID attached.

Comment 5 Kay Sievers 2006-04-09 14:34:47 UTC
I'm pretty sure we better identify the UPS's by its generic class and not by
vendor/product. Can you please attach the udevinfo -a output.

Comment 6 Kapoios Kanenas 2006-04-09 15:11:59 UTC
Created attachment 127523 [details]
udevinfo -a -p /class/usb_device/usbdev1.3

It's the 1.3 

Besides the product the manufacturer and the vendor/product ids, I don't see
anything else , class & subclass are zero.
Is there another variable that identifies this as a UPS device ?

Comment 7 Kay Sievers 2006-04-09 16:14:11 UTC
Oh, that thing again. :) It's a kind of mess with the usb devices, interfaces
and the userspace access nodes. They are at different levels in sysfs. We will
hopefully be able to solve that proper with a future version of the usb
userspace access, which is currently under development, and that exports an
individual device node for every interface.

The information about your UPS is likely at the interface level, which
unfortunately is not reachable from within the event for the usb device node:
  grep . /sys/devices/pci0000:00/0000:00:02.0/usb1/1-3/*-*/*

Can you please attach the output (or just the section for the UPS) of:
  lshal
to see if HAL can recognize your device correctly.

Comment 8 Kapoios Kanenas 2006-04-09 17:16:53 UTC
Created attachment 127525 [details]
lshal output (only the ups)

here it is, it has only the sections with mge ups vendor id.

Comment 9 Kay Sievers 2006-04-10 09:10:49 UTC
Thanks for all the infos. Seems there is currently no easy way to solve that.
Listing vendor/product should be fine then. Thanks again.

Comment 10 Than Ngo 2006-04-24 16:50:29 UTC

*** This bug has been marked as a duplicate of 189674 ***