similar to: Install problems (group permissions) with nut 2.7.2

On Feb 17, 2015, at 4:37 PM, Rob Groner <rgroner at RTD.com> wrote: > I had thought that giving the user and the group would mean that the /usr/local/ups/* directories and binaries created by "make install" would have "nut" as their group, but they don't....they have only root:root. Does the group permissions not get set in these directories upon install? I

Actually, nevermind....I found an easier way. This guide is simply going to be the "quick" way to prove the UPS works, and doing it securely will be an exercise left to the user. As long as I put that in bold letters at the top of the guide, then I don't have a problem just using "-u root" everywhere. Rob > -----Original Message----- > From: Rob Groner > Sent:

Hmmm...well, let's put it this way. I'm trying to do the "right" thing in regards to permissions and access for running NUT and everything involved with it. I note in the installation instructions it says that if you're impatient and want to try starting upsd, upsmon, and drivers right now, you can use "-u root", but that you should set the correct permissions

Thank you all for the help! I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. I looked at the file and saw how it was laid out...basically an ATTR for every known USB UPS. Well, since mine is not a known UPS, I had to

On Feb 18, 2015, at 10:40 AM, Rob Groner <rgroner at RTD.com> wrote: > Does this revolve around hotplug and udev? Yes. (Well, technically hotplug was superseded by udev) > In other words, is the idea that the created USB device will be in the "nut" group, Yes. > and thus I'd be able to tell upsdrvctrl to start if I am user "ups"? Or do ups/nut not

I am running tests on my system and UPS, making sure that it is reliably able to come up, detect power loss, shutdown safely, and then come back up when the power returns. It does that MOST of the time. However, a significant part of the time, the system comes up, and then doesn't respond to loss of power. Doing some checking, I find that the reason is because upsd never started. Capturing

On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote: > I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. My apologies, I got that backwards in my earlier email. udev applies the rules in numerical

On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote: > I looked at the file and saw how it was laid out...basically an ATTR for every known USB UPS. Well, since mine is not a known UPS, I had to add my own entry. If you want, once things are working, we can add an entry to that table (via drivers/usbhid-ups.c, which gets parsed into the udev script) > So I added a

On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com> wrote: > > I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/ba08f4c0/attachment.html>

I think I had a misconception about something.. My goal was that someone could use our UPS with the "default" UPS driver in NUT right out of the box, so they wouldn't have to alter any NUT code to get it working. NUT config files, yes, but not NUT code. I thought that if I put in the ups.conf file that I wanted to use the usbhid-ups driver, and then put our vendor and product ID,

On Mar 9, 2015, at 12:00 PM, Rob Groner <rgroner at RTD.com> wrote: > 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c and *.h files and making the makefile changes and then executing ./configure for the first time would be enough. Each tool serves a different purpose. autoreconf (and NUT's autogen.sh, by inclusion) generates the ./configure

Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. Thanks for the helps. Sincerely,

Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added &rtd_subdriver, to the subdriver_list in usbhid-ups.c

On Mar 2, 2015, at 12:49 PM, Rob Groner <rgroner at RTD.com> wrote: > Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid

On Fri, 4 Sep 2015, Rob Groner wrote: > Well, I tried the same script method with openSUSE 13.2, and it still did not execute. > > So I tried the system method, and it worked 1 time out of 3 attempts. I captured the last failure: > 2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB device [2a37:5110]: No such file or directory >

> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? --

I've followed the config setup docs and also the excellent guide from Roger Price. I'm using openSUSE 13.1 and built NUT 2.7.2 from the sources (latest stable). I'm hooked up to a dummy UPS that basically just cycles from fully charged down to about 20% discharged. I was pleased when I started seeing the messages on my screen indicating the UPS was online or on-battery. Given how

On Sep 10, 2015, at 8:49 AM, Rob Groner <rgroner at RTD.com> wrote: > > Charles, > > 3.16.6.-2-desktop I think that corresponds to this file: http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I don't see anything obvious there) What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when the driver isn't running,

Ok, so please correct me if I?m wrong?. The quickest way to get my UPS running with nut (as the current release exists) is to either: 1) Add my vendor and device ID to the openups_usb_device_table OR 2) Create my own driver file, and then add that driver to the usbhid-ups subdriver_list And then recompile/install. Obviously #1 will be easier at this point, but I understand that it

On Feb 20, 2015, at 3:15 PM, Rob Groner <rgroner at RTD.com> wrote: > Instead, it seems that the usbhid-ups driver will search through its own list of known devices with vid/pid, and won't "match" my device unless that device exists as an entry in its device table. Is that correct? More or less, yes. It turns out that UPS vendors all have somewhat different