RE: [Nagios-users] NSClient++ (Early ßeta release)

[Randal, Phil]

We already have nrpe_nt (http://www.miwi-dv.com/nrpent/
<http://www.miwi-dv.com/nrpent/> ) with its own ability to run
"plugins".  It also talks SSL if you want any hints on how to do it.
 
I'd love to see a single program with the combined functionality of
nsclient, nrpe_nt, and your own enhancements.
 
Cheers,
 
Phil
----
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK 
 


  _____  

From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of Michael
Medin
Sent: 15 February 2005 11:38
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] NSClient++ (Early ßeta release)



Hi,

 

I just spent some time adding a project on source forge
(http://sourceforge.net/projects/nscplus) for a program I wrote about a
year ago. The program is a simple NSClient clone written in C++ for W32
(obviously). It has most of the feature of NSClient (at least I think
so). Some of the features are untested and to put it plainly I haven't
used the program nor NSClient for over a year and don't even recall
exactly the status of things. But I promised I would release it as open
source a few months back. Unfortunately the process took a bit more time
than I thought but here it is.

The main difference between NSClient and NSClient++ is;

1, It is modularized and has plug-in support

2, It is written in C++ and should (haven't really looked into it
though) be fairly lightweight. It is also a straight W32 API application
meaning it does not have any third party dependencies (apart from
STLPort which is statically linked, and can be removed as MS STL works
just as fine) like MFC etc.

3, It also features (though this is as of yet unsupported, as I haven't
written any *nix client yet) a Windows EventLog Checker.

4, I think it should be compatible with most NT-base (as it uses
threads, mutexes and such w9x might be off?) versions of Windows.
(NSClient might have been this but I had a lot of problems with PDH
library dependences).

 

The modularization is in the form of DLLs that are loaded on start-up
and have a pretty simple and straight forward API. Thus it should make
it quite simple to write a module that does pretty much anything if
there is any interest. (Also as modules are external they can be
provided as third party extensions as well as toggled off to provide a
minimalist resource footprint)

 

Future plans are (if there is an interest): 

Modules for: 

* SSL (need to read up on the subject first).

* Event log (already there but not finished).

* Scripting support (would be I think simple to allow scripts to be
written in some language and executed (much like Nagios).

* Passive checking (is this really useful, haven't ever used it myself)

 

But the big question is: is there any need for this? 

A year ago I wrote it because NSClient broke our exchange server. And a
few weeks ago I refactored parts of it to support modules and wrote a
module for the event log (because I wanted to check the windows event
log). But I think that SNMP is much simpler and works better in mixed
environments. So personally I don't really see much demand for a
"NSClient:ish" plug-in but I don't really know. Secondly there is NC_net
(which I personally am not to keen on as I dislike the whole .NET
concept, but that's a passing issue). So is there an interest? Should I
continue to write this (apart from the event log monitoring module that
I need). I would like to get feedback on this so I know what to do about
it, but regardless of that issue the program will become "production
stable" and get an event log as that is what I need.

 

As for when to expect anything from this project?

As of now (well my SF skills broke everything) the project should (in
extreme theory) be a drop in replacement for NSClient barring two (IIRC)
features (I think it was file age and something more along those lines).
But proc, service, mem, disk, uptime, version, etc is there.

I will spend the next weekend and some spare time working on this (don't
want to do to much of this during work hours as we have a tight schedule
now, with a deploy of a few new servers) so perhaps Monday for a
"production version" (expect bugs but should be stable). This includes
the Event log plug-in (with a client). 

Something to test and feel it out will be available tonight (GMT+1).

>From this point on it all depends on the interest and/or feedback from
testers and ideas.

 

BTW; I just noticed that the zip file on SF was broken (don't really
know why) so you have to wait a few hours (we are talking something
along the lines of 18:00-19:00 GMT when I get home) before you can try
it. I also noticed that the CVS only had directories in it so Ill have
to check about that too, my 1337 SourceForge skillz are not what they
should be I suppose but this is pretty much the first time in years I
post to SF :)

 

Regards,

 

Michael Medin

 

Direkt: 08-410 052 42

Mobil:  0733-35 55 42

E-mail: michael.medin at altcom.se

Internet:  <BLOCKED::http://www.altcom.se/> WWW.ALTCOM.SE

 

ALTCOM AB  SEGELBÅTSVÄGEN 2, 11264 STOCKHOLM
TELEFON: 08-7 300 300  FAX: 08-7 300 305
EMAIL:  <BLOCKED::mailto:INFO at ALTCOM.SE> INFO at ALTCOM.SE  INTERNET:
<BLOCKED::http://www.altcom.se/> WWW.ALTCOM.SE

 

This message contains information that may be privileged or confidential
and is the property of the Altcom AB. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are
not authorized to read, print, retain, copy, disseminate, distribute, or
use this message or any part thereof. If you receive this message in
error, please notify me immediately and delete all copies of this
message.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20050216/b13675c4/attachment.html>