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

[Carroll, Jim P [Contractor]]

As I mentioned recently, NTray was written in Perl then converted to a Win32 binary using an apparently common utility (the name of which escapes me).

jc


> -----Original Message-----
> From: Randal, Phil [mailto:prandal at herefordshire.gov.uk]
> Sent: Tuesday, May 13, 2003 8:16 AM
> To: nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] NSClient + NRPE == NRPE+ (was: Rewriting
> nscli ent? (was NSClient 1.0.8.0 Installation Problem))
> 
> 
> Maybe I'm paranoid but I wouldn't be too happy about having a
> Perl interpreter sitting on our NT boxes waiting for malicious
> Perl scripts to happen along ;-)
> 
> I'd suggest that the C or C++ stuff for Windows should be 
> written to be compiled under MinGW
> (http://sourceforge.net/projects/mingw/) and Dev-CPP
> (http://sourceforge.net/projects/dev-cpp/).
> 
> Cheers,
> 
> Phil
> ---------------------------------------------
> Phil Randal
> Network Engineer
> Herefordshire Council
> Hereford, UK 
> 
> > -----Original Message-----
> > From: Roy Sigurd Karlsbakk [mailto:roy at karlsbakk.net]
> > Sent: 13 May 2003 13:16
> > To: Michael.Wirtgen at miwi-dv.com; sghosh at sghosh.org;
> > nagios-users at lists.sourceforge.net
> > Subject: Re: [Nagios-users] NSClient + NRPE == NRPE+ (was: Rewriting
> > nscli ent? (was NSClient 1.0.8.0 Installation Problem))
> > 
> > 
> > ok.
> > So why not:
> > 	- Rewrite nsclient in C or C++ (and perhaps renaming it?)
> > 	- Rewrite NRPE in perl to allow it to work in any environment
> > 
> > Whaddayathink?
> > 
> > On Tuesday 13 May 2003 12:46, Michael.Wirtgen at miwi-dv.com wrote:
> > > 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
> 


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