Hi, I spent quite some time pulling my hair out and trying to figure out why NUT wasn't working properly with SSL enabled. I tried several approaches until I found something interesting. I'm using NUT 2.7.1 in Ubuntu Server 14.04 Trusty Tahr After properly configuring a self signed certificate with "certutil" from libnss3-tools, there was no way to get proper SSL connection eventhough upsd didn't complain in logs. Shell# upsc TEST Init SSL without certificate database Connecting in SSL to 'localhost' (no certificate name specified) Error while connecting to localhost, disconnect Error: Unknown error I then tried, for the sake of understanding, to compile the package in a test environment with OpenSSL support instead of LibNSS and it worked right away without trouble, provided I supplied the PEM "crt + key" combo file. Back to the regular distro packages, I really tried hard to understand what was wrong until I managed to get it working! Putting - UPSD_OPTIONS="-D" - in /etc/nut/nut.conf and "service nut-server restart" (which does not detach from the shell of course) made the whole system work! "upsmon" was happy as well as "upsc TEST" too! Shell# upsc TEST Init SSL without certificate database Connecting in SSL to 'localhost' (no certificate name specified) Do not intend to authenticate server localhost SSL handshake done successfully with server localhost Connected to localhost in SSL Certificate verification is disabled [...] I first thought this was "start-stop-daemon" fault so I tried in standalone mode. Shell# /lib/nut/dummy-ups -a TEST Shell# upsd Shell# ps axu [...] nut 19116 0.0 0.0 37688 772 ? Ss 18:35 0:00 /lib/nut/dummy-ups -a APC nut 19119 0.0 0.0 77296 6548 ? Ss 18:36 0:00 upsd Here, trying "upsc TEST" fails again! So, there's definitely something wrong here when "upsd" detaches itself from the calling shell which makes SSL choke, at least with LibNSS! I've browsed the GIT commit history from release 2.7.1 to current state and I didn't see any commit that would make me think the problem was already addressed. Could someone look into it please? :-) -- Unix _IS_ user friendly, it's just selective about who its friends are. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150301/d602ef71/attachment.html>
On Sun, Mar 1, 2015 at 7:11 PM, Melkor Lord <melkor.lord at gmail.com> wrote:> Shell# ps axu > [...] > nut 19116 0.0 0.0 37688 772 ? Ss 18:35 0:00 > /lib/nut/dummy-ups -a APC > nut 19119 0.0 0.0 77296 6548 ? Ss 18:36 0:00 upsd >Argh... sorry for the typo here, this should read "TEST" instead of "APC" which comes from my real environment but produces exactly the same behaviour of course. -- Unix _IS_ user friendly, it's just selective about who its friends are. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150301/e8780cb2/attachment.html>
On Sun, Mar 1, 2015 at 1:11 PM, Melkor Lord <melkor.lord at gmail.com> wrote:> Hi, > > I spent quite some time pulling my hair out and trying to figure out why NUT > wasn't working properly with SSL enabled. I tried several approaches until I > found something interesting. > > I'm using NUT 2.7.1 in Ubuntu Server 14.04 Trusty TahrThank you for taking the time to write up this bug report. Just for reference, what are the full versions of the packages? (including the .deb revisions) for instance: $ dpkg-query -W nut-server libnss3 libnspr4 libnspr4:i386 2:4.10.7-0ubuntu0.14.04.1 libnss3:i386 2:3.17.4-0ubuntu0.14.04.1 nut-server 2.7.1-1ubuntu1> After properly configuring a self signed certificate with "certutil" from > libnss3-tools, there was no way to get proper SSL connection eventhough upsd > didn't complain in logs.I was able to reproduce this on a version of Linux Mint corresponding to Ubuntu 14.04. I got the same results with both the default 2.7.1-1ubuntu1 package, as well as a build from the Git master branch. To be honest, I haven't exercised the NSS code much. I usually build for OpenSSL on my development machines (since I am not distributing the binaries), and even then, I don't use the SSL code if I am just testing a new driver. But given the large amount of testing that went into the NSS branch, I am somewhat surprised at this. The test plan doesn't specify exactly how to start upsd: http://www.networkupstools.org/tmp/NUT-NSS_Mini_DVT_exec10Oct2012-FBohe.pdf although it doesn't specify using debug mode, either. Also, the Ubuntu test script does not pass "-D" to upsd: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-nut.py I will try to test this on some other OSes. - Charles Lepple
On Mon, Mar 2, 2015 at 12:37 AM, Charles Lepple <clepple at gmail.com> wrote:> On Sun, Mar 1, 2015 at 1:11 PM, Melkor Lord <melkor.lord at gmail.com> wrote: >> > I'm using NUT 2.7.1 in Ubuntu Server 14.04 Trusty Tahr > > Thank you for taking the time to write up this bug report. >Well, thank you for replying so quickly :-)> Just for reference, what are the full versions of the packages? > (including the .deb revisions) > > for instance: > $ dpkg-query -W nut-server libnss3 libnspr4 > libnspr4:i386 2:4.10.7-0ubuntu0.14.04.1 > libnss3:i386 2:3.17.4-0ubuntu0.14.04.1 > nut-server 2.7.1-1ubuntu1 >We run exactly on the very same versions.> > After properly configuring a self signed certificate with "certutil" > from > > libnss3-tools, there was no way to get proper SSL connection eventhough > upsd > > didn't complain in logs. > > I was able to reproduce this on a version of Linux Mint corresponding > to Ubuntu 14.04. I got the same results with both the default > 2.7.1-1ubuntu1 package, as well as a build from the Git master branch. >Good! So it's not something specific to my environment. It really would have surprised me though because there's nothing fancy on my server other than very standard stuff and packages.> To be honest, I haven't exercised the NSS code much. I usually build > for OpenSSL on my development machines (since I am not distributing > the binaries), and even then, I don't use the SSL code if I am just > testing a new driver. >As I never played with NSS before, being more comfortable in the OpenSSL world, I quickly tried the "recompile package with OpenSSL instead" approach to see how it worked. In debootstrap environment, apt-get source nut, apt-get build-dep nut, apt-get install libssl-dev, modify debian/rules to replace "--with-libnss" by "--with-openssl". Once the packages were ready, I installed them over the distro ones on my server (dpkg -i for libupsclient3 nut-server and nut-client). I edited upsd.conf just adding CERTFILE /path/to/nut.pem (crt+key combo) and that was it. Worked right away without trouble ! In fact, I found the working state (debug mode) with NSS by pure luck! I was tired of typing "service ups-server start" (and stop) several times per minute to watch the logs and see what happened. So I used "upsd -D". When I fired the "upsc TEST" and saw it working I almost screamed of despair :-) After some more tests, I figured out the pattern. Fun way to spend my sunday afternoon :)> > But given the large amount of testing that went into the NSS branch, I > am somewhat surprised at this. The test plan doesn't specify exactly > how to start upsd: > > > http://www.networkupstools.org/tmp/NUT-NSS_Mini_DVT_exec10Oct2012-FBohe.pdf > > although it doesn't specify using debug mode, either. > > Also, the Ubuntu test script does not pass "-D" to upsd: > > > http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-nut.py > > I will try to test this on some other OSes. >I hope it won't be a PITA to find the root cause of the problem because SSL is a very nice and useful feature to have. What puzzles me is the difference in behaviour between debug mode and non-debug mode. What could possibly happen after upsd detaches itself from the calling shell that make upsd fail to handle SSL stuff while working flawlessly without detaching? I thought start-stop-daemon was involved because it closes stdin/stdout file descriptors after exec()'ing the daemon. I tried "--no-close" option to no avail. After that, I validated the init script working fine with UPSD_OPTIONS="-D" in /etc/nut/nut.conf. To my understanding, the problem lies only within "upsd". When working (or not), "upsc" and "upsmon" are affected the same way with the same result which makes sense. Now you have the whole story with the gory details. If you need more tests and validation, do not hesitate, that's the least I can do to help solve the problem. Thank you again for your time! -- Unix _IS_ user friendly, it's just selective about who its friends are. -- Unix _IS_ user friendly, it's just selective about who its friends are. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150302/af0529e8/attachment-0001.html>
On Sun, Mar 1, 2015 at 8:10 PM, Melkor Lord <melkor.lord at gmail.com> wrote:> What puzzles me is the difference > in behaviour between debug mode and non-debug mode. What could possibly > happen after upsd detaches itself from the calling shell that make upsd fail > to handle SSL stuff while working flawlessly without detaching?I'm thinking it's something here: https://github.com/networkupstools/nut/blob/master/common/common.c#L114> I thought start-stop-daemon was involved because it closes stdin/stdout file > descriptors after exec()'ing the daemon. I tried "--no-close" option to no > avail. After that, I validated the init script working fine with > UPSD_OPTIONS="-D" in /etc/nut/nut.conf.Not strictly the same as closing the file descriptors, but I tried the following: /sbin/upsd -D >/dev/null 2>&1 < /dev/null And it still worked. So I need to recompile with debugging symbols - the Ubuntu packages did not have them. -- - Charles Lepple