<br><br><div class="gmail_quote">2011/1/10 Arjen de Korte <span dir="ltr"><<a href="mailto:nut%2Bdevel@de-korte.org">nut+devel@de-korte.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Citeren EmilienKia@Eaton.com:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The main reason is to homogenize directive names between apps (mainly upsmon which uses CERTPATH and upsd which uses CERTNAME) to set the same property.<br>
</blockquote>
<br></div>
Why? The use of CERTFILE (OpenSSL only) and CERTPATH/CERTIDENT/CERTREQUEST (NSS only) is completely different. We have nothing to gain by reducing the number of directives here, since we will need different instructions on how to fill them anyway.<br>
<br>
Using different names will help us help people much more easily, since the directives they see in upsd.conf will already tell us if NUT was build to use the OpenSSL or NSS libraries.<br>
<br>
Throughout NUT we should maintain a clear distinction whether a filename is needed (like CERTFILE) or a directory (STATEPATH, DATAPATH and CERTPATH).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Note that the CERTFILE directive is working but is just flagged as deprecated.<br>
</blockquote>
<br></div>
Whatever.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As ssl support compilation is exclusive (only openssl or nss at the same time), I do not see any reason to keep two directives in parallel (one per compile profile) doing the same thing (pointing to the certificate database, in the form of a single file or a directory).<br>
</blockquote>
<br></div>
These should be surrounded by #ifdef/#endif directives and make upsd complain loudly about directives it doesn't understand. So if someone is accidentally using CERTFILE if NUT was build with NSS, it should inform them right away (not when the certificate store is being accessed). Similar the other way around.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
About configuration directive, only CERTFILE/CERTPATH change of content (a directory instead of a file) but the semantic is kept unchanged. All other SSL related directives are just for NSS mode. So generate different .conf.sample files is IMHO disproportionate related to the too few alterations. Perhaps add few lines of comment in these .conf.sample files?<br>
</blockquote>
<br></div>
You forget about the amount of problems we will see when people start switching over from OpenSSL to NSS. There is pretty much nothing to gain by consolidating these directives into one. What's wrong with<br>
<br>
# CERTFILE <certificate file> (OpenSSL only)<br>
# CERTFILE /usr/local/ups/etc/upsd.pem<br>
<br>
# CERTPATH <certificate directory> (NSS only)<br>
# CERTPATH /usr/local/ups/etc/cert/upsd<br>
<br>
# CERTIDENT <certificate name> <database password> (NSS only)<br>
# CERTIDENT "my nut server" "MyPasSw0rD"<br>
<br>
# CERTREQUEST <certificate request level> (NSS only)<br>
# CERTREQUEST [0|1|2]<br>
# - 0 to not request to clients to provide any certificate<br>
# - 1 to require to all clients a certificate<br>
# - 2 to require to all clients a valid certificate<br>
<br>
At best we would add some autoconf magic to only include the parts that are used (so that we don't clutter the configuration files with directives that are not used), but for the time being the above might be good enough.<br>
<br>
I'm one of the old dogs around here and even I already have problems setting this up (let alone the novice NUT users that try to make this work).</blockquote></div><br>valid points!<br><br>Emilien, can you please adapt the code as per the above.<br>
I'll check how we can condition the conf sample and <span id="result_box" class="short_text" lang="en"><span title="Cliquer ici pour voir d'autres traductions" class="hps">highlight the SSL support type in the doc.<br>
<br>cheers,<br clear="all"></span></span>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>