Can anyone point me to information for getting the Tripplite SMART3000RM2U
to work with NUT? Our newer Tripplite units seem to work with the
usbhid-ups driver, but these older ones seem to need something different.
So far I have had little success getting tripplite_usb to work.
[root at banyan ~]# tripplite_usb -a tripplite
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.6.1)
Warning: This is an experimental driver.
Some features may not function correctly.
Can't claim USB device [09ae:0001]: could not detach kernel driver from
interface 0: Operation not permitted
May  9 14:09:11 banyan upsd[5464]: Can't connect to UPS [tripplite]
(tripplite_usb-tripplite): No such file or directory
May  9 14:09:11 banyan upsmon[5469]: Login on UPS [tripplite at localhost]
failed - got [ERR ACCESS-DENIED]
May  9 14:09:15 banyan upsmon[5469]: Poll UPS [tripplite at localhost] failed
- Driver not connectedMay  9 14:09:25 banyan last message repeated 2 times
May  9 14:09:30 banyan upsmon[5469]: Poll UPS [tripplite at localhost] failed
- Driver not connected
I think the start of my trouble is I need to change the file added to
/etc/udev/rules.d
# This file is generated and installed by the Network UPS Tools package.
ACTION!="add", GOTO="nut-usbups_rules_end"
SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules_real"
SUBSYSTEM=="usb", GOTO="nut-usbups_rules_real"
SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end"
LABEL="nut-usbups_rules_real"
# TrippLite
#  e.g. ?  - usbhid-ups
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="3014",
MODE="660", GROUP="nut"
LABEL="nut-usbups_rules_end"
-- 
Mark Moorcroft
ERC Corp.
650-604-4784
mailto:mark.moorcroft at nasa.gov
2012/5/9 Moorcroft, Mark (ARC-TSM)[ERC, Inc.] <mark.moorcroft at nasa.gov>:> (...) > > I think the start of my trouble is I need to change the file added to > /etc/udev/rules.d > > > # This file is generated and installed by the Network UPS Tools package. > > ACTION!="add", GOTO="nut-usbups_rules_end" > SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules_real" > SUBSYSTEM=="usb", GOTO="nut-usbups_rules_real" > SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end" > > LABEL="nut-usbups_rules_real" > > # TrippLite > # ?e.g. ? ?- usbhid-ups > SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="3014", MODE="660", GROUP="nut" > > > LABEL="nut-usbups_rules_end"well, you should indeed have a line like in this file: SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut" but it has been there since 2008, so if you use a recent package, it should already be there! note that udev rules location have changed over the past year. so the file may be located at /lib/udev/rules.d/52-nut-usbups.rules if the line is present somewhere, remember that udev needs to be restarted if NUT has just been installed. use for example "udevadm --reload-rules" if all the above does not work, send in more details on your setup (OS, NUT version, install from packages or source, ...) cheers, Arnaud
On May 9, 2012, at 7:40 PM, Moorcroft, Mark (ARC-TSM)[ERC, Inc.] wrote:> > Hmm, ok, that worked, now how do I track down the permission problem? The > file permissions on my two boxes are the same in /etc/ups for starters. >It will be on the /dev/bus/usb device nodes (or whatever the path is on CentOS). You mentioned two different VID:PID pairs - on the box running tripplite_usb, does it have the entry for 09ae:0001 in the udev files? Also, udev typically doesn't apply new permissions until you kick it (I forget how) or until you plug in the USB device again. The 09ae:0001 entry in the udev files should have come with your version of NUT, unless that file was installed to the wrong directory.> On 5/9/12 4:25 PM, "Charles Lepple" <clepple at gmail.com> wrote: > >> On May 9, 2012, at 7:16 PM, Moorcroft, Mark (ARC-TSM)[ERC, Inc.] wrote: >> >>> Seems to skip right over 003/002? >> >> Odd... Can you try with "-u root" as well, just to rule out permissions >> issues? >> >> (if it still doesn't work, I suspect libusb, and you could try "export >> USB_DEBUG=3" before running.) >> >> -- >> Charles Lepple >> clepple at gmail >> >> >> >-- Charles Lepple clepple at gmail
I found the problem was a collision with the gid we use for another group and the gid that Splunk grabbed when it installed. Thanks for the help. -- Mark Moorcroft ERC Corp. 650-604-4784 mailto:mark.moorcroft at nasa.gov