2015-03-26 9:03 GMT+01:00 Arnaud Quette <arnaud.quette at gmail.com>:> Hey mister M' > > A first huge thanks for taking care of this, and so late in the night. I > know that it's not easy... > > (sent from my S3... please excuse my brevity) > Le 25 mars 2015 18:49, "Emilien Kia" <kiae.dev at gmail.com> a ?crit : > > > > > > > > > 2015-03-21 17:06 GMT+01:00 Melkor Lord <melkor.lord at gmail.com>: > >> > >> > >> On Fri, Mar 20, 2015 at 4:40 PM, Emilien Kia <kiae.dev at gmail.com> > wrote: > >> > >>> Some precisions: > >>> > >>> we are not alone, some projects had similar problem: > http://bugs.bitlbee.org/bitlbee/ticket/785 > >>> And the problem is really coming from NSS initialization. Discussion > about the issue here : > http://osdir.com/ml/mozilla.crypto/2002-08/msg00016.html > >> > >> > >> Wow! Congratulations on finding the source of the problem, I bet this > wasn't easy! > > > > > > You have done the hardest job. Once you isolate the problem occurs only > when running as a deamon and not in debug mode, searching for a problem is > easier. > > Moreover we have done so many tests on this feature that it is really > surprising we didn't detect this problem before. > > But when we look more precisely at DVT linked by Charles, we can see we > did test only in direct mode, not in deamonized mode. > > > >> > >> > >> I'm glad to see that NUT isn't faulty :-) > >> > >>> > >>> There is a workaround to use NSS with fork but it is more setting a > flag to share some resources (primarily sockets) but must (re)initialize > NSS library on all children. > >>> > >>> AFAIK why we initialize NSS library before becoming user and forking > is to be able to access and read certificates and keys which is readable > only by root and should not be readable in userland. This behavior is this > because it was the behavior used when using OpenSSL. Modifying this > behavior implies to modify key/certificate storage and acces right policy. > >> > >> > >> Well, NUT uses a dedicated unpriviledged user to run ("nut" in my case) > so why not initialize the SSL stuff after forking? > >> > >> Before forking, just check that the SSL cert/key files belong to the > same user as the user which started "upsd" and throw an error message to > the logs if it's not the case to warn the user. Then it's your decision > whether to "disable SSL usage" and continue or refuse "upsd" execution if > conditions are not met. > >> > > > > I will look to do something like that. > > > >> > >> > >> If it's convenient, make this part NSS dependent with the usual #ifdef > spaghetti :-) to avoid influence on the OpenSSL code. > > > > > > What I will do is to move ssl initializing after usering and forking, > than add key file right checking where ssl was initialized before (before > forking). > > As keys should be owned by nut user, this would not be a problem. > > And moving this code, independently of SSL implementation (OpenSSL or > NSS) should work. And will not add more code implementation dependent. > > > > Charles, Arnaud ? Ok with that ? > > Works for me at first, but I'll see once yiu push the PR and we have some > tests validating the behavior in daemon mode, including some reload with > added certs (will that work?!) > > Thanks again *a lot* and cheers > Arno >After looking a bit deeply, we have another little problem. When we intend to start upsd with the init script (at least under debian-based distrib - tested on Linux Mint 17.1) when we have the NSS problem, the init script exit with the "[OK]" state even if the "real" deamon process does not run correctly. Perhaps we could add some tests to validate if the deamonization is OK. But it is a little bit out of my competencies (I am not a bash and linux-init-process expert). Emilien -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150326/1d8fab02/attachment-0001.html>
On Mar 26, 2015, at 4:16 AM, Emilien Kia <kiae.dev at gmail.com> wrote:> After looking a bit deeply, we have another little problem. When we intend to start upsd with the init script (at least under debian-based distrib - tested on Linux Mint 17.1) when we have the NSS problem, the init script exit with the "[OK]" state even if the "real" deamon process does not run correctly. > > Perhaps we could add some tests to validate if the deamonization is OK. But it is a little bit out of my competencies (I am not a bash and linux-init-process expert).Are you still using http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-nut.py to test? That script already checks for PIDs of the daemons. It should not be hard to extend it to 'kill -0' each PID to check if it is still running. I admit that I have not tried this test script, though. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150326/82ba6570/attachment.html>
On Thu, Mar 26, 2015 at 9:16 AM, Emilien Kia <kiae.dev at gmail.com> wrote:> > > After looking a bit deeply, we have another little problem. When we intend > to start upsd with the init script (at least under debian-based distrib - > tested on Linux Mint 17.1) when we have the NSS problem, the init script > exit with the "[OK]" state even if the "real" deamon process does not run > correctly. > > Perhaps we could add some tests to validate if the deamonization is OK. > But it is a little bit out of my competencies (I am not a bash and > linux-init-process expert). >I'm running Ubuntu Server 14.04 in all the servers I maintain and also use NUT. The process is started with the following command in /etc/init.d/nut-server: start-stop-daemon -S -p $upsd_pid -x $upsd \ -- $UPSD_OPTIONS >/dev/null 2>&1 && log_progress_msg "upsd" || log_progress_msg "(upsd failed)" and obviously, a backslash is missing on the second line! (line 83 on the real script) So even if it fails, the next command (log_process_msg) will always start as if the previous command returned 0 (OK). This script always write "upsd" after starting instead of the right text, depending on the correct execution of $upsd! In normal conditions, this construction shouldn't work. Try "ping localhost &&" for example and any shell would wait for more data before executing the line. But these lines are in a function which is called inside a switch/case construct and by some nesting effect and redirection to /dev/null, it works with the missing backslash and nothing is printed out! -- 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/20150329/ac679249/attachment.html>
On Sun, Mar 29, 2015 at 1:50 PM, Melkor Lord <melkor.lord at gmail.com> wrote:> On Thu, Mar 26, 2015 at 9:16 AM, Emilien Kia <kiae.dev at gmail.com> wrote: >> >> >> >> After looking a bit deeply, we have another little problem. When we intend >> to start upsd with the init script (at least under debian-based distrib - >> tested on Linux Mint 17.1) when we have the NSS problem, the init script >> exit with the "[OK]" state even if the "real" deamon process does not run >> correctly. >> >> Perhaps we could add some tests to validate if the deamonization is OK. >> But it is a little bit out of my competencies (I am not a bash and >> linux-init-process expert).The Ubuntu/Mint script is explicitly catching any non-zero exit codes (with the '|| log_progress_msg "(upsd failed)"' portion). I wonder if this was intentional to keep going after upgrades, the way that the Debian+systemd scripts do?> I'm running Ubuntu Server 14.04 in all the servers I maintain and also use > NUT. The process is started with the following command in > /etc/init.d/nut-server: > > start-stop-daemon -S -p $upsd_pid -x $upsd \ > -- $UPSD_OPTIONS >/dev/null 2>&1 && > log_progress_msg "upsd" || log_progress_msg "(upsd failed)" > > and obviously, a backslash is missing on the second line! (line 83 on the > real script) So even if it fails, the next command (log_process_msg) will > always start as if the previous command returned 0 (OK). This script always > write "upsd" after starting instead of the right text, depending on the > correct execution of $upsd!Close, but not quite. If I tweak $upsd to point to the wrong filename (after the -x check at the beginning), it will call the second log_progress_msg() on my system (Mint 17). See below for the reason.> In normal conditions, this construction shouldn't work. Try "ping localhost > &&" for example and any shell would wait for more data before executing the > line. > > But these lines are in a function which is called inside a switch/case > construct and by some nesting effect and redirection to /dev/null, it works > with the missing backslash and nothing is printed out!The backslash is needed on the start-stop-daemon line because it is syntactically complete as-is. The line ending in "&&" is not complete, so the shell continues to read to the next line. The fact that it prints nothing is due to Ubuntu redefining log_progress_msg() in /lib/lsb/init-functions.d/50-ubuntu-logging (which masks the definition in /lib/lsb/init-functions).