[Nut-upsuser] Fwd: SSL only working in DEBUG mode

[Melkor Lord]

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>