similar to: Nut (git) upsdrvctl fails without "-u root start <upsname>", upsd fails on state file GID

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.

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? > Why doesn't > "upsdrvctl start" allow nut to find the UPS when it can find it without a > problem with

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 >

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

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

Charles, All, I just updated the kernel on my Arch box (the one we have been working on nut with on this list). Now upsd fails to start. (upsdrvctl is fine). I've posted working then -- Reboot -- the failing log information below. The 'Reboot' was for the kernel upgrade: Dec 14 14:02:00 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Dec 14

On Dec 15, 2013, at 2:03 PM, David C. Rankin wrote: > 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

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

On 12/16/2013 09:06 AM, Charles Lepple wrote: > If you want, we can take a look at the output of the aforementioned udevd > command from your system. Please compress the output, and if the list bounces > it, I'll extract the relevant portion from the bounce message. > > I have a funny feeling we might either have a Debian-specific dependency on > 91-permissions.rules, or

On 12/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

I was getting: "Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted" so I manually installed the udev rules the source (I installed the Gentoo ebuild). I am now getting: # upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using

Arjen, I just installed openSuSE 11.1. I though it would be simple to setup the same CyberPower CP1000AVRLCD on the same machine that we worked through the 20+ voltage issue with, but usbhis-ups driver is failing for some reason. I have gotten the output I remember you needing from the last issue for you. What do you think the problem might be? Here is the information: First the logs from the

On Dec 16, 2013, at 10:11 PM, David C. Rankin wrote: > On 12/16/2013 08:01 PM, Charles Lepple wrote: >> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: >> >>>> Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >>>> ai_socktype >> [...] >>>> The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't

On 12/16/2013 08:01 PM, Charles Lepple wrote: > On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > >> > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >> > ai_socktype > [...] >> > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what >> > could have changed. How do I attempt to further

Using the HOWTO in http://keystoneit.wordpress.com/2006/09/25/network-ups-tools-nut-on-ubuntu/ I installed nut on an Ubuntu Edgy LAMP Server with an Eaton Powerware 5110 attached to it via usb. But nut fails to start properly (see the error message "Starting Network UPS Tools: (upsdrvctl failed) upsd upsmon" below). It then complains about communication with the UPS being lost ("UPS

On Dec 17, 2013, at 1:08 PM, David C. Rankin wrote: > On 12/17/2013 10:43 AM, David C. Rankin wrote: >> Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" >> as "3493" (could have just used "nut" from /etc/services): > > Sheepishly looking for a place to hide.... > > Yes there was a ':' there all

Arjen, All, I need help unwrapping my head from around the problem of getting nut running on the same machine it runs fine with on another drive!! Sound easy -- not here :) I have network-ups-tools 2.4.1-2 on two servers. On one server I had a raid drive fail (which I'm still booting from and running nut on just fine). I bought a second pair of drives to establish a new array in the

On 12/17/2013 10:43 AM, David C. Rankin wrote: > Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" > as "3493" (could have just used "nut" from /etc/services): Sheepishly looking for a place to hide.... Yes there was a ':' there all right. Seems I was hit by a vi error: [12:04 phoinix:/etc/ups] # grep 3493 *.conf

Hi. I have this this on a Odroid-u2 backing it up. Have the USB from the CyberPower SX650G plug in the Odroid-u2 and when I do a lsusb it looks like this: Bus 001 Device 008: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The User's Manual list SE450G and SX650G. So I guess they would take the same driver. CyberPower web page has a driver but it's for i386 not ARM like

On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for > ai_socktype [...] > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what > could have changed. How do I attempt to further debug/fix this? getaddrinfo(3) is a libc function - is it possible that libc was updated as well? I am