NSClient + NRPE == NRPE+ (was: Rewriting nscli ent? (was NSClient 1.0.8.0 Installation Problem))

Michael.Wirtgen at miwi-dv.com Michael.Wirtgen at miwi-dv.com
Tue May 13 12:46:24 CEST 2003


hi all,

just some thoughts and ideas for comments...

- Perl for services
Even if the idea of using perl with a wrapper for this is tempting, wearing
my windows hat, I'd always prefer something really "talking" to the SCM
instead of using a wrapper. I've done that several times in the past, using
svcany an the like, results were mixed. I think it can be done, but if
someone is taking the effort for a rewrite, why not use C and accommodate
the existing sources to compile on non UX platforms.

- "Porting" NRPE to windows
While putting together nrpe_nt (my attempt at "porting" nrpe), I found that
there is not TOO much stuff to be changed. Before attempting a complete
rewrite I'd suggest to review the existing sources, and split up nrpe.c into
two files, a generic one, and a platform dependent one. The platform
dependent file would (for windows) roughly contain: main(),
wait_for_connections() and handle_connection(), plus some additional code to
make stuff like services work. 
(Talk to the SCM etc.). stuff like utils.c and common.h compiled on win with
~4-5 one line patches.

- Integrating nrpe with nsclient functionality
Personally, I think nsclient and nrpe serve different purposes on windows
(or could do so in a "clean" design):
nsclient is platform specific to windows, and not easily modified to allow
for custom plugins. 
nrpe allows only for plugins, doesn't care for specific checks at all, just
executes them.

The way I would like to use both, would be:
nsclient as a local agent, running continuous checks for stuff, that has to
be checked local and/or requires activity, that can't be done in a plugin
(eg. register callback to some windows functions like spooler/filesystem
events etc). These could be reported back passive checks. 

nrpe as a "gateway" to windows checks, to either local or remote windows
hosts.
This allows distributed active checks, without the need for an agent like
nsclient on every monitored host. (A lot of my customers are really
reluctant to install any additional agent "only for monitoring").   

It would be possible to integrate nrpe functions with nsclient, but you
would either:

- Start with from the delphi nsclient sources
Roys arguments about which languages to be used applies here, as in fact not
too much people use delphi these days.
Also, it would make nsclient an even more complex beast to maintain.

- Start a complete rewrite in perl
If you'd add all nsclient functionality, the code would be platform specific
to windows again, wasting the initial reason to do a rewrite.

Pheew, that has become a little lengthy...
So in summary I'd suggest:
a) don't mix functionality between nsclient and nrpe, as they serve
different purposes
b) If someone is willing to start a rewrite, don't go with perl easily
because "it's platform independent". It may bite back later...

thanks for your attention
cheers
MiWi


-----Original Message-----
From: Roy Sigurd Karlsbakk [mailto:roy at karlsbakk.net]
Sent: Dienstag, 13. Mai 2003 10:48
To: Subhendu Ghosh; nagios-users at lists.sourceforge.net
Subject: [Nagios-users] NSClient + NRPE == NRPE+ (was: Rewriting
nsclient? (was NSClient 1.0.8.0 Installation Problem))


On Friday 09 May 2003 18:50, Subhendu Ghosh wrote:
> ActiveState has a perl to binary/service converter.

hi all.

As Ghosh says above, we can use perl to write services. Is it only me, or 
would this allow us to standardize on perl for a new NRPE+ with NRPE + 
NSClient functionality? I guess we can read Windoze counters from perl 
without problems?

roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.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


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.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





More information about the Users mailing list