NSClient++ (Early ßeta release)

[Michael Medin]

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: WWW.ALTCOM.SE <BLOCKED::http://www.altcom.se/> 

 

ALTCOM AB  SEGELBÅTSVÄGEN 2, 11264 STOCKHOLM
TELEFON: 08-7 300 300  FAX: 08-7 300 305
EMAIL: INFO at ALTCOM.SE <BLOCKED::mailto:INFO at ALTCOM.SE>   INTERNET: WWW.ALTCOM.SE <BLOCKED::http://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/20050215/e63acee3/attachment.html>