similar to: UPSSched UPSNAME env variable

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 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 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 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 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 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

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 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.

All, I have built and installed nut from git on Archlinux. It uses the usbhid driver. Beginning a couple of years ago, nut begin failing to run on Archlinux without 'tweaking' or 'fudging' the install. There are two primary problems: (1) upsdrvctl cannot be launched normally i.e. (/usr/sbin/upsdrvctl start) without failing to connect: Dec 14 02:24:39 phoinix systemd[1]:

Hello list, In my quest to get Mongrel working as service for win32, found some problems with win32/service that make it impossible to solve. Attached is the simplest service script I could do with ruby, which depends on win32/service. I found that doing anything complex in service_stop (killing threads, doing file handling, even sleeping for 0.25 seconds). crash the service with backtraces (of

Hi everybody, i'm getting mad regarding a very serious (since it's happening on a production server) issue with a samba domain joined installation. This machine has worked perfectly for an year and the last configuration tune up and version upgrade (3.0.23c) went along fine in the first days of January. It's been two weeks approximately now since we started to have a bad issue, a

Hi everybody, in my opensuse 10.2 with a samba 3.0.23d, installed and updated via yast, i constantly get this error: [2007/05/15 10:34:39, 0] lib/util_sock.c:write_data(564) write_data: write failure. Error = Connection reset by peer [2007/05/15 10:34:39, 0] libsmb/clientgen.c:write_socket(138) write_socket: Error writing 104 bytes to socket 17: ERRNO = Connection reset by peer [2007/05/15