<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Mar 2, 2015 at 12:37 AM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Mar 1, 2015 at 1:11 PM, Melkor Lord <<a href="mailto:melkor.lord@gmail.com" target="_blank">melkor.lord@gmail.com</a>> wrote:<br></span></blockquote><div> </div></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span><span>> I'm using NUT 2.7.1 in Ubuntu Server 14.04 Trusty Tahr<br>
<br>
</span>Thank you for taking the time to write up this bug report.<br></blockquote><div><br></div></span><div>Well, thank you for replying so quickly :-)<br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just for reference, what are the full versions of the packages?<br>
(including the .deb revisions)<br>
<br>
for instance:<br>
$ dpkg-query -W nut-server libnss3 libnspr4<br>
libnspr4:i386 2:4.10.7-0ubuntu0.14.04.1<br>
libnss3:i386 2:3.17.4-0ubuntu0.14.04.1<br>
nut-server 2.7.1-1ubuntu1<br></blockquote><div><br></div></span><div>We run exactly on the very same versions.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>
> After properly configuring a self signed certificate with "certutil" from<br>
> libnss3-tools, there was no way to get proper SSL connection eventhough upsd<br>
> didn't complain in logs.<br>
<br>
</span>I was able to reproduce this on a version of Linux Mint corresponding<br>
to Ubuntu 14.04. I got the same results with both the default<br>
2.7.1-1ubuntu1 package, as well as a build from the Git master branch.<br></blockquote><div><br></div></span><div>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.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be honest, I haven't exercised the NSS code much. I usually build<br>
for OpenSSL on my development machines (since I am not distributing<br>
the binaries), and even then, I don't use the SSL code if I am just<br>
testing a new driver.<br></blockquote><div><br></div></span><div>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.<br><br></div><div>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 !<br><br></div><div>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 :-)<br><br></div><div>After some more tests, I figured out the pattern. Fun way to spend my sunday afternoon :)<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But given the large amount of testing that went into the NSS branch, I<br>
am somewhat surprised at this. The test plan doesn't specify exactly<br>
how to start upsd:<br>
<br>
<a href="http://www.networkupstools.org/tmp/NUT-NSS_Mini_DVT_exec10Oct2012-FBohe.pdf" target="_blank">http://www.networkupstools.org/tmp/NUT-NSS_Mini_DVT_exec10Oct2012-FBohe.pdf</a><br>
<br>
although it doesn't specify using debug mode, either.<br>
<br>
Also, the Ubuntu test script does not pass "-D" to upsd:<br>
<br>
<a href="http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-nut.py" target="_blank">http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-nut.py</a><br>
<br>
I will try to test this on some other OSes.<br></blockquote><div><br></div></span><div>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?<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><div>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! <br clear="all"></div></div><span class=""><br>-- <br><div>Unix _IS_ user friendly, it's just selective about who its friends are.</div>
</span></div></div>
</div><br><br clear="all"><br>-- <br><div class="gmail_signature">Unix _IS_ user friendly, it's just selective about who its friends are.</div>
</div>