Re: [Nut-upsdev] [nut-commits] svn commit r2804 - in branches/ssl-nss-port: clients server

[EmilienKia]

Hi Arjen, Hi all,

I agree with you to say that conf.c must do a minimal interpretation of SSL 
configuration, and should not set ssl related variables directly (I will change 
that soon), but I do understand the way you propose:

Do you mean that:
 - netssl.c provides a configuration function to call at the beginning of 
conf.c:parse_upsd_conf_args() and it parse all the ssl config ?
 - netssl.c provides some configuration functions, one per directive, and in 
the case of CERTREQUEST, parses and converts string argument into internal 
format (IMHO better way) ?
 - netssl.c provides some configuration function, one per directive, 
CERTREQUEST argument parsing is done in conf.c:parse_upsd_conf_args() and the 
dedicated nss configuration function is called with the corresponding value 
(IMHO best way because best decoupling between human readable configuration 
directive and functional storage) ?

BR,
Emilien

-Message d'origine-
De : nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.org 
[mailto:nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.org] De la 
part de Arjen de Korte
Envoyé : vendredi 7 janvier 2011 21:10
À : nut-upsdev@lists.alioth.debian.org
Objet : Re: [Nut-upsdev] [nut-commits] svn commit r2804 - in 
branches/ssl-nss-port: clients server

Citeren Emilien Kia :

> Modified: branches/ssl-nss-port/server/conf.c
> ==
> --- branches/ssl-nss-port/server/conf.c   Wed Jan  5 21:12:03 2011
> (r2803)
> +++ branches/ssl-nss-port/server/conf.c   Thu Jan  6 10:27:55 2011
> (r2804)
> @@ -178,6 +178,22 @@
>   return 1;
>   }
>
> + /* CERTREQUEST ("NO" | "REQUEST" | "REQUIRE") */
> + if (!strcmp(arg[0], "CERTREQUEST")) {
> + if (strcasecmp(arg[1], "REQUEST") == 0) {
> + certrequest = NETSSL_CERTREQ_REQUEST;
> + } else if (strcasecmp(arg[1], "REQUIRE") == 0) {
> + certrequest = NETSSL_CERTREQ_REQUIRE;
> + } else if (strcasecmp(arg[1], "NO") == 0) {
> + certrequest = NETSSL_CERTREQ_NO;
> + } else {
> + upslogx(LOG_WARNING, "CERTREQUEST in upsd.conf accept 
> only values "
> + "\"REQUEST\", \"REQUIRE\" or \"NO\", assuming 
> \"NO\"");
> + certrequest = NETSSL_CERTREQ_NO;
> + }
> + return 1;
> + }
> +

 From a maintenance point of view, the validation of the CERTREQUEST  
parameter should be handled in 'netssl.c', not here. We really don't  
want to mess with this here, to prevent having to change 'conf.c' too  
often when something changes in the NSS code.

Likewise, it would be useful if this would only be compiled in if the  
NSS library is actually used (same for CERTPATH and CERTIDENT). It  
would be better to complain about invalid parameters than to fail  
later on.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [nut-commits] svn commit r2809 -branches/ssl-nss-port/server

[EmilienKia]

Hi Arjen, Hi all,

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.
Note that the CERTFILE directive is working but is just flagged as deprecated.

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).

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?

Any other comment or point of view?

BR,
Emilien

-Message d'origine-
De : nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.org 
[mailto:nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.org] De la 
part de Arjen de Korte
Envoyé : vendredi 7 janvier 2011 20:59
À : nut-upsdev
Objet : Re: [Nut-upsdev] [nut-commits] svn commit r2809 
-branches/ssl-nss-port/server

Citeren Emilien Kia :

> Author: emilienkia-guest
> Date: Fri Jan  7 14:44:25 2011
> New Revision: 2809
> URL: http://trac.networkupstools.org/projects/nut/changeset/2809
>
> Log:
> Deprecate CERTFILE conf var to the benefit of CERTPATH : homogenize  
> conf directive names.
>
> Modified:
>branches/ssl-nss-port/server/conf.c

This patch breaks existing OpenSSL installations without valid reason,  
so I don't think this is a good idea.

It would be better to use CERTFILE if OpenSSL is used and CERTPATH  
(and friends) if NSS is used. By doing so, it would be immediately  
clear if a user is using OpenSSL or NSS. This would probably be  
beneficial in case people ask how to set this up.

In order for this to work, we should generate different  
'upsd.conf.sample' files depending on the SSL library used. This would  
be worthwhile anyway, for versions compiled with OpenSSL and where  
some of these keywords are not used at all (and would only confuse  
people setting this up).

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [nut-commits] svn commit r2809-branches/ssl-nss-port/server

[EmilienKia]

 

2011/1/10 Arjen de Korte mailto:nut%2bde...@de-korte.org> >


Citeren emilien...@eaton.com:



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.


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.

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.

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. 



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?


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

# CERTFILE  (OpenSSL only)
# CERTFILE /usr/local/ups/etc/upsd.pem

# CERTPATH  (NSS only)
# CERTPATH /usr/local/ups/etc/cert/upsd

# CERTIDENT   (NSS
only)
# CERTIDENT "my nut server" "MyPasSw0rD"

# CERTREQUEST  (NSS only)
# CERTREQUEST [0|1|2]
#  - 0 to not request to clients to provide any
certificate
#  - 1 to require to all clients a certificate
#  - 2 to require to all clients a valid certificate

valid points!

Emilien, can you please adapt the code as per the above.
I'll check how we can condition the conf sample and
highlight the SSL support type in the doc.

 
 


--
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [nut-commits] svn commit r2809-branches/ssl-nss-port/server

[EmilienKia]

 






2011/1/10 Arjen de Korte mailto:nut%2bde...@de-korte.org> >


Citeren emilien...@eaton.com:



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.


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.

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.



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).


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.



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?


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

# CERTFILE  (OpenSSL only)
# CERTFILE /usr/local/ups/etc/upsd.pem

# CERTPATH  (NSS only)
# CERTPATH /usr/local/ups/etc/cert/upsd

# CERTIDENT   (NSS
only)
# CERTIDENT "my nut server" "MyPasSw0rD"

# CERTREQUEST  (NSS only)
# CERTREQUEST [0|1|2]
#  - 0 to not request to clients to provide any
certificate
#  - 1 to require to all clients a certificate
#  - 2 to require to all clients a valid certificate

valid points!

Emilien, can you please adapt the code as per the above.
I'll check how we can condition the conf sample and
highlight the SSL support type in the doc.



Done in r2817.
 
What about CERTPATH in upsmon.conf ?
 
BR
Emilien
 
 
PS : 
It seems f#k Outlook send this message without my response, really
sorry for the noise.

--
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Client certificates

[EmilienKia]

 

> -Message d'origine-
> De : 
> nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton@lists.alioth.d
> ebian.org] De la part de Arjen de Korte
> Envoyé : mardi 11 janvier 2011 22:15
> À : nut-upsdev
> Objet : [Nut-upsdev] Client certificates
> 
> While browsing the sources of the nss-ssl-port sources I 
> noticed that client certificates were added. What is the 
> reason behind this? As far as I can see, using a server 
> certificate and validating it in the upsmon client should 
> provide us with a secure channel. Authorizations for the 
> server will then be handled by the settings in upsd.users by 
> logging into the server with user and password (like we have 
> done for ages). What are client certificates going to add to 
> this? We'll still need the upsd.users to tie the certificates 
> to operations allowed on the upsd server (master or slave), 
> so what benefit will using client certificates have here? 
> What problem are we solving with client certificates?
> 
> Best regards, Arjen

I have added client certificate checking mainly to avoid man-in-the-middle 
attacks or identity usurpation.
Indeed If you just have server authentication (like 99% the web where just the 
sertver auth is required), you are just sure of the server's identity, but not 
the client's one. If you do not want that a vilain execute vicious commands (if 
it has the login/password), the server must be sure of the client's identity.

Moreover, note that the password is exchenaged uncrypted or unhashed (do not 
take in account the SSL tunnel) so nothing can prevent a manè-in-the-middle 
attack because the server can not detect it speaks to a vilain (or a client via 
a vilain) and not directly to the real client.

BR,
Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Client certificates

[EmilienKia]

 

> -Message d'origine-
> De : 
> nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton@lists.alioth.d
> ebian.org] De la part de Arjen de Korte
> Envoyé : mercredi 12 janvier 2011 09:59
> À : nut-upsdev@lists.alioth.debian.org
> Objet : Re: [Nut-upsdev] Client certificates
> 
> Citeren emilien...@eaton.com:
> 
> > I have added client certificate checking mainly to avoid 
> > man-in-the-middle attacks or identity usurpation.
> 
> A man-in-the-middle attack is impossible if you verify the 
> server certificate (CERTVERIFY 1). If someone manages to 
> stage a man-in-the-middle attack by providing a certificate 
> that is trusted by your clients CA store, you have bigger 
> worries than this.
> 
> > Indeed If you just have server authentication (like 99% the 
> web where 
> > just the sertver auth is required), you are just sure of 
> the server's 
> > identity, but not the client's one.
> 
> That's why we have users defined in 'upsd.users'. Generally 
> speaking, we want to grant/limit access to a role/person 
> (user/password) rather than a machine (client).
> 
> > If you do not want that a vilain execute vicious commands 
> (if it has 
> > the login/password), the server must be sure of the 
> client's identity.
> 
> I see no difference here. You're using the same file 
> (upsmon.conf) to store the existing user/password mechanism 
> and the information to use a client certificate. If someone 
> unauthorized is able to read this file, you're toast either 
> way, so the client certificate is not adding to the security here.
> 
> In general, you should have at least three different users defined in
> upsd.users:
> 
>  upsslave - only able to read status information from the server
>  upsmaster - same as the above, but can also initiate a FSD
>  admin - can issue instant commands and change settings
> 
> The admin account should *never* be used in 'upsmon.conf' and 
> only be used by operators for changing settings or initiating 
> instant commands. Practically they should use a secure shell 
> to connect to the upsd server and issue the commands there. 
> So most of the time, you'll want to limit access to this 
> account to the localhost interface only (maybe additionally 
> the webserver too, if you use that for remote administration).
> 

If you think that login/password is enought to authenticate clients, I can 
remove SSL client authentication parts. It is not a problem.

> > Moreover, note that the password is exchenaged uncrypted or 
> unhashed 
> > (do not take in account the SSL tunnel) so nothing can prevent a 
> > manè-in-the-middle attack because the server can not detect 
> it speaks 
> > to a vilain (or a client via a vilain) and not directly to the real 
> > client.
> 
> If you can't trust your network (which in the vast majority 
> of the cases is not the case, because it will be internal), 
> use SSL encryption. It is then the responsibility of the 
> client to not sent username/password if it can't verify the 
> server certificate (which is the case in upsmon already).
> 
> Generally speaking a client will be aware that it is talking 
> to the server over an untrusted network (for instance, an 
> operator monitoring a UPS in a remote location). In that 
> case, 'CERTVERIFY 1' will make sure the user/password 
> information remains secure.
> 
> Also note that the amount of mischief a upsmon client can do, 
> is limited to initiating a FSD if it is in master mode only. 
> Changing settings and initiating instant commands is limited 
> to the upsrw and upscmd tools respectively, which don't use 
> encryption at all. This means that these can only be run 
> securely on the remote system itself (for instance in a ssh).
> 
> I'm still not convinced that client certificates are 
> needed/useful for upsmon.


I have implemented SSL/NSS in the upscli part, not directly in upsmon.
Actually, just upsmon uses it but, ideally, all clients should use SSL to 
dialog with upsd.

BR
Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

[Nut-upsdev] SSL certificate verification with OpenSSL in NUT trunk

[EmilienKia]

Hi all,

After client's certificate verifications discussion in the mailing-list,
I have done some tests with nut trunk and - if my config is not too bad
- I think ther is a bug with server certificate verification.

With a clean trunk checkout, compile and installation; and with the
following config :

upsmon.conf:
CERTPATH /usr/local/ups/etc/cert/
CERTVERIFY 1
FORCESSL 1

Upsd.conf:
CERTFILE /usr/local/ups/etc/upsd1.pem

And /usr/local/ups/etc/cert/ is empty (no file).

When I start upsd and upsmon, there is a valid SSL connection between
them.

So, do I misunderstand CERTVERIFY directive ? Or is there a bug ?
Can you reproduce such behaviour ?

BR,
Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] SSL certificate verification with OpenSSL in NUTtrunk

[EmilienKia]

Hi all,

I have tested with many configurations and whatever certificate
configuration (with, without, self-signed or not) used, server
certificate is always approved.

Reverting commit r2819 seems fixing the problem.

Index: /trunk/clients/upsclient.c
===
--- /trunk/clients/upsclient.c (revision 2724)
+++ /trunk/clients/upsclient.c (revision 2819)
@@ -387,5 +387,5 @@
}
 
-   SSL_set_verify(ups->ssl, ssl_mode, NULL);
+   SSL_CTX_set_verify(ups->ssl_ctx, ssl_mode, NULL);
 
return 1;

IMHO, as the secured socket is already instanciated, context
modification is not propagated to the socket so the secured socket does
not switch to "verify" mode.

Do I revert commit ?

BR,
Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

[Nut-upsdev] End of NSS port

[EmilienKia]

Hi all,

I am pleased to announce that NSS port of NUT is finished.
Port is fully functionnal (same functionnalities as openssl, and a
not-activated-by-default client certificate validation function) and
successfully tested by myself (external tests are pending, Frederic Bohe
is planned for)  with a test matrix which will be uploaded to the web
site soon (by Arnaud), tested functionnality by functionnality in each
installation context (no ssl, openssl and nss) and in interoperability
context (no ssl/openssl, no ssl/nss, openssl/nss).

Due to my "not-well" english, probably that a pass must be done on
documentation and error messages by better english-speaking.

I was happy to work on a such subject on a FOSS like nut.

So long, folks.

Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] 2.8.0 roadmap [jNUT]

[EmilienKia]

 

2011/6/12 Charles Lepple 


On Jun 12, 2011, at 12:48 PM, Arnaud Quette wrote:



2011/6/12 Charles Lepple 


On Jun 11, 2011, at 3:53 PM, Arnaud
Quette wrote:



 * jNUT Java binding
   the exact content of this task is
still to be defined, but this should include native client access and
NSS support,
   the following will be considered with
a lower priority:
 - device discovery (JNI using
libnut-scanner),
 - configuration (using Augeas)
 - mDNS discovery
   I'm currently checking resources
staffing with Eaton



I'm not a huge fan of Java to begin
with,


so do I.
but having played with Android a year and a half
ago, and having some requests more recently made me think we are still
lacking a Java binding...
 

but if I had to interface a Java tool
with NUT, I wouldn't want the hassle of native bindings (i.e. JNI)
unless it was absolutely necessary. Most of the NUT protocol should be
easily implementable in pure Java (including SSL).



indeed, native client access (ie implement the
ascii NUT protocol in Java) is easy enough to be implemented directly
(as we have in Python, Nagios plugin, ...)



Ah, I think we're saying the same thing. IIRC "native"
in terms of Java is the underlying processor/OS, and I think you are
describing a "pure Java" implementation.


indeed, so let's go for native ;-)

cheers,
Arno

 

Hi all,
 
In general:
As the current client API is a little too low level to be interesting to
be wrapped to Java (and others), is there more interesting to develop a
higher level API in C (like in Python) and to wrap it many languages
(java but not only: python, perl and many others can be targeted) with a
tool like SWIG ( http://swig.org/   ).
Two linked benefits can be gained from such approach :
1- A common API can be distributed over all languages and rely on an
unique implementation, which make them more visible and clear than many
rewrites in each languages.
2- When you augment the API (like adding a method), all languages
benefit of it with least effort (just running again the generation
tool).
 
In java specific wrapper:
In term of distribution : platforms which provide package management can
easily resolve dependancies between wrapped client pack and "native"
one; on other plateforms (like windows) project can build and provide a
"big" stand-alone jar with "native" client build for all plateforms
(Windows x86/x64, Linux on many plateforms and so on...) or dedicated
"light" jars for many plateforms (windows/linux, x86/x64/arm ...). This
can probably be provided automatically with smart commands on buildbot.
 
In my developer point of view:
I think it is more interesting for a developper to implement a
high-level API than a simple communication protocol rewrite.
I think also it is more valuable at long term for the nut project.
 
My two cents.
BR,
 
Emilien
 
 

--
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[Nut-upsdev] upsclient high level API and Java wrapping

[EmilienKia]

Hi all,
 
on proposal by Arnaud Quette and sponsored by Eaton, I will work on a port on 
Java of client, discovery and config API.
 
As I have already suggested (mail of 2011-06-14 of this ml), instead of 
developping another port of nut protocol, I suggest to develop a higher level 
API in C/C++ uppon existing upsclient, inspirated by existing C-based tools and 
python and perl rewrites.
The second goal is to release a convergent high-level API which can be easily 
wrapped (via SWIG ?) in Java and other languages, and perhaps make an uniform 
API for all wrappers (including perl and python).
 
I will precise my ideas in a future mail, but if anyone want to talk about its 
point of view or needs.
 
Best regards,

Emilien KIA
Software Engineer

Team Open Source
Engineering Software & Connectivity
Eaton's Electrical Group PQCO/DPQD
Immeuble Viseo - Bâtiment A
110, rue Blaise Pascal
38330 Montbonnot St Martin
FRANCE
tel: +33(0)4 7600 6620
emilien...@eaton.com
www.eaton.com  

 

 

 

--
<>___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] upsclient high level API and Java wrapping

[EmilienKia]

This mail is a reply to mails from Charles Lepple and Petr Kubánek dated from 
july 7 with the same topic.

> From: Charles Lepple
> 
> "One thing with SWIG (and other binding systems) is that it is not  
> easy to handle errors gracefully. I can't count how many times I got  
> segmentation violation errors calling well-tested C code from Python  
> via SWIG.
> 
> I tried using ctypes, which doesn't require any recompilation of the  
> target library, but it has similar problems.

I am surprised. I follow wxWidgets open source project for a while, their 
python wrapping is done with SWIG and they do not have so many problems with 
that.
Note I have not used SWIG for python (nor python itself) personnally, so 
perhaps I missed something.

> The big advantage to SWIG is supposed to be that you can generate  
> bindings to many languages once you set things up, but in reality,  
> each language has its nuances for passing things by 
> reference, and so  
> each set of bindings has slightly different semantics.

I never say that SWIG will generate all bindings magically without any specific 
code.
The experience I had with SWIG was with Java and Lua on separated projects. In 
theses cases, once some specific code was set (mostly typemapping), adding 
methods and objects was not so problematic.

> From: Petr Kubánek
>
> I believe pure Java implementation is doable and will bring more
> benefits then hard-to-build generic Swig implementation.
>
> From: Charles Lepple
>
> Since our network protocol is so simple, we may want to stick 
> to that  
> for access from other languages. (SWIG and ctypes make sense for  
> libraries like libusb and libhid where you cannot otherwise 
> access the  
> device from the target language.)"

> I think this still applies. The bulk of the NUT logic is in the  
> drivers, with a little less in the server and clients. We're not  
> talking about wrapping the drivers or server, and very little 
> logic is  
> actually in the upsclient library. And the code in the upsclient  
> library (or a C++ library which wraps the upsclient functionality in  
> object-oriented-ness) can probably be recreated in another language  
> with less effort than it would take to write the SWIG bindings.

I know the upsclient protocol is sipmle and the java wrapping is easily doable, 
including SSL features. But the target of jNUT is greater than just upsclient 
and include nut-scanner (dev in progress) and nut-conf (augeas). Actually 
nut-scanner and nut-conf are libraries or simple executables over these 
libraries. Calling scanner functions can be done with a wrapper (like SWIG) or 
with an interprocess method (socket, pipes, dbus, slave process cli ...) 
talking to a scanner process.

> Picking on the Java bindings for a minute, the build procedure for a  
> JAR file with native code (e.g. x86, not Java bytecode) is more  
> complex than building a JAR with Pure Java code, and the resulting  
> library is non-portable.

It is true, but the complexity is not so high.

About not portable distribution, there are three problems:
1- on a package based platform (like Linuxes), nothing prevent to have 
plateform specific .jar with dedicated dynamic library, one per distribution 
per architecture.
2- on other platforms (like Windows), we have 2 solutions:
  a- distribute dedicated .jar with one plateform-specific dynamic library 
(probably too many)
  b- distribute .jar with many dynamic libraries (one for 32 bits, one for 64b 
...) and let java choose the good one at run time
3- distribute a .jar with *all* dynamic libraries and let java choosing which 
one is the correct one.
Solutions 2b and 3 can probably be done with a well configured integration and 
build solution or with cross-compilation.

> For Perl and Python, the situation seems even more silly to me - the  
> current Perl and Python bindings don't require any compilation  
> (besides the optional bytecode step for Python).

I understand the point to not have anything to compile.

> I agree that there is value to a consistent API across the various  
> language bindings, but I don't know that SWIG is the way to go about  
> doing it.

It is not *the*, it is one.

> libhid had a pretty basic C API, but due to some arguments being  
> passed by reference, the resulting SWIG configuration was pretty ugly:
> 
> http://boxster.ghz.cc/projects/libhid/browser/trunk/swig/hid.i
> 
> All in all, maybe it's not a compelling argument against 
> SWIG, but be  
> prepared to make major changes to the new C/C++ API to accommodate  
> various languages and their quirks.

I am sure if we use SWIG, we will have some modifications for each target 
languages.

> Also be forewarned that I can be a 
> merciless style critic of C++ (note that we don't have any in NUT at  
> the moment)...

No problem ;)

Best regards

Emilien KIA
Software Engineer
Open Source Team
Eaton's Electrical Group PQCO/DPQD

--

Re: [Nut-upsdev] [PATCH 1/3] Fix file descriptor leak

[EmilienKia]

Hi Thomas

> -Message d'origine-
> De : 
> nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton.com@lists.alioth.d
> ebian.org] De la part de Thomas Jarosch
> Envoyé : dimanche 28 août 2011 01:02
> À : nut-upsdev@lists.alioth.debian.org
> Objet : [Nut-upsdev] [PATCH 1/3] Fix file descriptor leak
> 
> Credit goes to "cppcheck"
> 
> Signed-off-by: Thomas Jarosch 
> ---
>  common/common.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/common/common.c b/common/common.c index 
> f443cb7..e8004d7 100644
> --- a/common/common.c
> +++ b/common/common.c
> @@ -244,6 +244,7 @@ int sendsignalfn(const char *pidfn, int sig)
>  
>   if (fgets(buf, sizeof(buf), pidf) == NULL) {
>   upslogx(LOG_NOTICE, "Failed to read pid from 
> %s", pidfn);
> + fclose(pidf);
>   return -1;
>   }   
>  
> @@ -251,6 +252,7 @@ int sendsignalfn(const char *pidfn, int sig)
>  
>   if (pid < 2) {
>   upslogx(LOG_NOTICE, "Ignoring invalid pid 
> number %d", pid);
> + fclose(pidf);
>   return -1;
>   }
>  
> @@ -259,6 +261,7 @@ int sendsignalfn(const char *pidfn, int sig)
>  
>   if (ret < 0) {
>   perror("kill");
> + fclose(pidf);
>   return -1;
>   }
>  
> @@ -267,9 +270,11 @@ int sendsignalfn(const char *pidfn, int sig)
>  
>   if (ret < 0) {
>   perror("kill");
> + fclose(pidf);
>   return -1;
>   }
>  
> + fclose(pidf);
>   return 0;
>  }
>  
> --
> 1.7.4.4
> 
> 

Thanks for your patch.
I have just applied it to the trunk (r3171).

QA checks are always welcome.

Best regards

Emilien KIA
Opensource Team
Engineering Software & Connectivity
Eaton's Electrical Group PQCO/DPQD
emilien...@eaton.com
www.eaton.com 

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [PATCH 2/3] Fix use of uninitialized variable

[EmilienKia]

Hi Thomas

> -Message d'origine-
> De : 
> nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton.com@lists.alioth.d
> ebian.org] De la part de Thomas Jarosch
> Envoyé : dimanche 28 août 2011 01:03
> À : nut-upsdev@lists.alioth.debian.org
> Objet : [Nut-upsdev] [PATCH 2/3] Fix use of uninitialized variable
> 
> Credit goes to "cppcheck".
> 
> Signed-off-by: Thomas Jarosch 
> ---
>  drivers/mge-utalk.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mge-utalk.c b/drivers/mge-utalk.c index 
> c6114c7..616e2ad 100644
> --- a/drivers/mge-utalk.c
> +++ b/drivers/mge-utalk.c
> @@ -465,7 +465,8 @@ void upsdrv_shutdown(void)  {
>   char buf[BUFFLEN];
>   /*  static time_t lastcmd = 0; */
> - 
> + memset(buf, 0, sizeof(buf));
> +
>   if (sdtype == SD_RETURN) {
>   /* enable automatic restart */
>   mge_command(buf, sizeof(buf), "Sx 5");
> --
> 1.7.4.4
> 
> 


Thanks for your patch.
I have just applied it to the trunk (r3172).


Best regards

Emilien KIA
Opensource Team
Engineering Software & Connectivity
Eaton's Electrical Group PQCO/DPQD
emilien...@eaton.com
www.eaton.com 

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] [PATCH 3/3] Fix pointer check on wrong variable

[EmilienKia]

Hi Thomas

> -Message d'origine-
> De : 
> nut-upsdev-bounces+emilienkia=eaton@lists.alioth.debian.or
> g 
> [mailto:nut-upsdev-bounces+emilienkia=eaton.com@lists.alioth.d
> ebian.org] De la part de Thomas Jarosch
> Envoyé : dimanche 28 août 2011 01:04
> À : nut-upsdev@lists.alioth.debian.org
> Objet : [Nut-upsdev] [PATCH 3/3] Fix pointer check on wrong variable
> 
> Credit goess to "cppcheck"
> 
> Signed-off-by: Thomas Jarosch 
> ---
>  drivers/usb-common.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb-common.c b/drivers/usb-common.c 
> index e51f3cf..e459872 100644
> --- a/drivers/usb-common.c
> +++ b/drivers/usb-common.c
> @@ -116,7 +116,7 @@ int USBNewExactMatcher(USBDeviceMatcher_t 
> **matcher, USBDevice_t *hd)
>   USBDevice_t *data;
>  
>   m = malloc(sizeof(*m));
> - if (!matcher) {
> + if (!m) {
>   return -1;
>   }
>  
> --
> 1.7.4.4
> 

Thanks for your patch.
I have just applied it to the trunk (r3173).


Best regards

Emilien KIA
Opensource Team
Engineering Software & Connectivity
Eaton's Electrical Group PQCO/DPQD
emilien...@eaton.com
www.eaton.com 

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Scheduling 2.6.2 release (was: on Ubuntu Developer Summit (Oneiric), NUT and 2.8.0)

[EmilienKia]

Hi,

> 
> One minor thing: the @author tags in the javadoc comments 
> should probably have the angle brackets around the email 
> address escaped as "<" and ">", or the email address 
> should be dropped. At least the version of javadoc on my 
> system is treating the email address like an HTML tag.
> 

Thanks for the comment, I will do something for.

BR

Emilien KIA
Software Engineer
Engineering Software & Connectivity
Open-Source Team
Eaton's Electrical Group PQCO/DPQD
emilien...@eaton.com
www.eaton.com 

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] Scheduling 2.6.2 release (was: on Ubuntu Developer Summit (Oneiric), NUT and 2.8.0)

[EmilienKia]

> One minor thing: the @author tags in the javadoc comments 
> should probably have the angle brackets around the email 
> address escaped as "<" and ">", or the email address 
> should be dropped. At least the version of javadoc on my 
> system is treating the email address like an HTML tag.
> 

Done in r3222.

BR

Emilien

--

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[Nut-upsdev] Introduce jNutWebApi

[EmilienKia]

Hi All,

 

Perhaps you have seen, a few weeks ago, a release of jNut-0.2 which
introduces nut-scanner capability to jNut java library, see
http://networkupstools.org/download.html#_java_packages.

With this package have been released jNutWebApi, a java web archive
which uses jNut to present some UPSD and nut-scanner data on the form of
a web service.

 

This package is a maven-based project which uses Apache's WINK to
provide a HTTP/JSON web service interface to interact mainly with upsd.

To do this, just compile sources and deploy war file in your favorite
container (like Apache's Tomcat) and access it with your favorite
browser like detailed in the README
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNutWebAPI/READM
E?revision=3306.

You can use it to manually look at nut data or to make a program
interoperates via WS.

 

Use it without moderation and do not hesitate to comment or suggest
features in order to orient future developments.

 

Best regards,

 

Emilien KIA

 

Software Engineer

Engineering Software & Connectivity

Open-Source Team

Eaton's Electrical Group PQCO/DPQD

emilien...@eaton.com  

www.eaton.com   

 


--
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev