[Nut-upsuser] Install problems (group permissions) with nut 2.7.2 [driver selection and starting]

[Charles Lepple]

On Feb 19, 2015, at 11:23 PM, Gene Heskett <gheskett at wdtv.com> wrote:

> Almost $800 dollars and worthless 
> on wheezy. I am asking a few ?? over that on their mailing list as it 
> worked perfectly on ubuntu-10.04.4 LTS.

If you still have a backup of /etc from the Ubuntu install, there might be some clues in /etc/cups about the duplex settings (or which drivers support duplex, more likely).

My printer is still chugging along from the grad school days where I didn't have nearly that much to spend on a printer, so I tend to do the manual duplex method: print odd-numbered pages, flip the stack over, make a sacrifice to the gods of static electricity, and print the even pages.

> I don't even know if I am using the correct driver, the ups-scanner seems 
> only to exist in my 2.7.2 src tree, but its not installed as its looking 
> for a much older libssl than I now have.

I can't say I really buy into the nut-scanner notion. For the amount of work that went into it, I feel that we could have written some better procedural documentation that would have worked with whatever tools were on hand. And I don't think it's capable of saying "try this driver, but if that doesn't work, here are the older ones that might also work".

So let's do it the manual way. Brand name? Any vendor-included software that is currently being used as a beverage coaster? USB or serial? If USB, what does lsusb say about it? (Might have to run lsusb as root, if the udev permissions are working as intended.)

>  And the error messages from an 
> attempted start are so generic they aren't a lot of help.  So and so 
> didn't start, but no reason why is given.

Don't laugh, but there are two levels of indirection between /etc/init.d/nut-server and the driver. There's the init script itself, and upsdrvctl. Both were optimized for starting several drivers.

We probably should be more explicit in the documentation about the possibility of starting the drivers manually at first (or using upsdrvctl "-D", with the appropriate number of "-D"s to print the driver name). Once the driver works on its own (and you can add "-D" to that command line to get more detail), you can kill the driver (important) and either try upsdrvctl or jump straight to the init.d script.

> After mv'ing that file, I still get:
> root at coyote:/etc/init.d# ./nut-server start
> [ ok ] Starting NUT - power devices information server and drivers:  
> (driver(s) failed). upsd.
> 
> Why can it not name the failed driver, so I would know to try another?

The debian maintainers switched to systemd from the init.d scripts, and that caused a release-critical bug in the Debian package of NUT for new installations. (Upgrades from pre-systemd days just worked, but if NUT was not configured yet, the post-install script would error out.) They were not willing to drop back to the init.d compatibility wrappers (which I think Ubuntu is still using) so I don't know if NUT is even going to make it into jessie, the release after wheezy.

So that doesn't really answer your question, but it should explain a bit of the mess behind the init scripts. (And at the same time, we have been trying to coordinate a release of NUT 2.7.3.)

If you have a github account, I would recommend creating an issue so that we don't forget about printing the driver name(s) at startup: https://github.com/networkupstools/nut/issues

(The combination of cold temperatures and a recent power outage seems to have taken out the one UPS in the house that I can't easily replace without voiding warranties: the DC supply for the broadband connection. While pairing a bluetooth keyboard to a smartphone works for the occasional email, the screen is a bit small to actually do anything useful on github, and I need to stop staring at the tiny screen for a while.)

- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150220/08f1626a/attachment.html>