RES: nsclient, is it still an acceptable method to monitor nt

[Dario B. Bestetti]

We are working (but slowly) to use the same protocol used/defined by Tony in NC_net, but so far, we decided to stick with an "upgrade" of the old NSClient without the use of .NET framework. The problem for us is that most of our customers doesn´t want to install the .NET framework and we don´t want to force them. 

We´ll have a new version of OpMon Agent in a few days, with some improvements, but our project is definitly different from NC_net.

[]s
_________________________________________________
Dario B. Bestetti        OpServices
                                  R. Luciana de Abreu, 471 - Sala 403
                                  Porto Alegre, RS - CEP 90570-060
Fone 55(51)30613588 Mobile  55(51)81518218 
Fax     55(51)30613588  Email    dario.bestetti at opservices.com.br 
 
               "In God we trust, the rest we monitor ..."
_________________________________________________


-----Mensagem original-----
De: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-bounces at lists.sourceforge.net] Em nome de Rui Miguel Silva Seabra
Enviada em: sexta-feira, 9 de novembro de 2007 08:42
Para: nagios-users at lists.sourceforge.net
Assunto: Re: [Nagios-users] nsclient, is it still an acceptable method to monitor nt


Sex, 2007-11-09 às 11:35 +0100, Andreas Ericsson escreveu:
> > NSClient (seems too old, not being developed)
> > NSClient++ (presumably enhanced in some way)
> > OpServices version of NSClient (still being developed)
> > NC_Net (still being developed)
> > 
> > In the end I simply went with NC_Net and it appears to work for us just
> > fine, and I often see the author on this list, which tells me that he's
> > still involved with Nagios in some way.
> > 
> > It would be nice if all the different people who independently developed
> > all the different versions 'unforked' their efforts though :-), it would
> > make the decision on which one to use much easier, by having a lack of
> > choice!!
> 
> They aren't really forks. OpServices have simply taken over maintainership
> of NSClient (more or less, as the original author seems to have vanished).
> NSClient++ is a re-implementation in C++, with support for NRPE style script
> based checks as well. NC_Net does things through dot net stuff and some m$
> voodoo, but incorporates the NSClient mode of address since that's what the
> official plugins support.
> 
> So it's really three different agents.

NSClient++ has a nasty bug on the option to check services. It can't
handle services that contain white space in their names.

Rui

All Hail Discordia!
Today is Pungenday, the 21st day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null