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

Displaying 20 results from an estimated 30000 matches similar to: "Install problems (group permissions) with nut 2.7.2"

2015 Feb 18
0
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
2015 Feb 18
0
Install problems (group permissions) with nut 2.7.2
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:
2015 Feb 18
3
Install problems (group permissions) with nut 2.7.2
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
2015 Feb 19
4
Install problems (group permissions) with nut 2.7.2
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
2015 Feb 19
0
Install problems (group permissions) with nut 2.7.2
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
2015 Jul 07
4
upsd not starting sometimes (Porteus 3.1, nut 2.7.2)
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
2015 Feb 20
0
Install problems (group permissions) with nut 2.7.2
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
2015 Feb 20
0
Install problems (group permissions) with nut 2.7.2
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
2015 Sep 09
6
UPS/NUT with openSUSE 13.1
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>
2015 Feb 20
2
Install problems (group permissions) with nut 2.7.2
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,
2015 Mar 10
4
Install problems (group permissions) with nut 2.7.2
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
2015 Mar 02
3
Install problems (group permissions) with nut 2.7.2
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,
2015 Mar 09
2
Install problems (group permissions) with nut 2.7.2
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
2015 Mar 03
0
Install problems (group permissions) with nut 2.7.2
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
2015 Sep 05
2
UPS/NUT with openSUSE 13.1
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 >
2015 Sep 09
3
UPS/NUT with openSUSE 13.1
> 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? --
2014 Sep 11
2
How do I disable messages from upsmon?
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
2015 Sep 10
3
UPS/NUT with openSUSE 13.1
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,
2015 Feb 25
3
Install problems (group permissions) with nut 2.7.2
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
2015 Feb 21
0
Install problems (group permissions) with nut 2.7.2
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