I sort of sneaked out 0.4.0 last week in hopes of getting a bit of a slow start and have since fixed a few issues so I figured now is the time to get the rest of you on board.

So finally after a years of vapor ware we finally have what I consider to be the biggest release of NSClient++ ever! SO whats in it for me you ask?

Versions

Well the first noticeable change is that there is now build number in the version as well as versions. So you will not be downloading 0.4.0 you will be downloading 0.4.0.172. Meaning this is the 172:th build with more to come. The builds to follow will be bug fixes. I am already working on a 0.4.1 (which will in the near future add support for NRDP, check_mk and NSCP) this version will be a "compatible version" which is aimed at "bigger bugfixes" and additions. After this we will have 0.4.2 which will be the "next" version.

Whats new

The main new feature of 0.4.0 is the "core" which has been replaced with a new modern one built on top of various standard libraries. In addition to this we also have a new command line syntax and a new improved setting subsystem. There is also a lot of new features and enchantments in various modules and check commands. I would say this is the the biggest update of NSClient++ ever.

Protocols

Many new protocols supported:

• NRPE
• NSCA
• NSClient "check_nt"
• SysLog??
• SMTP
• Graphite
• NSCP (early concept version, both as distributed (think gearman) and non distributed (think NSCA/NRPE))

I am planning: http (rest), check_mk, NRDP, SNMP, WMI, "native remote windows checks"

Scripting

There is a brand new plugin/script API which has been extended to allow extensions in:

• Python
• Lua
• .Net
• plugins (C/C++/*)

Settings

Brand new flexible settings sub systems which supports many new formats as well as generation and inclusion between formats.

• ini-files
• registry
• http (ini files)
• old
• dummy (in memory store)

Currently planned:

• XML
• remote configuration
• improved http (server side support)

Random picks from change log

Some other highlights from the change log:

• Real time event log checking
• Brand new (easy to use?) command line interface
• Linux suppport
• New installer
• Reworked CheckWMi with nice command line syntax as well as remote check support
• Almost 10.000 unit tests (ish)
• Many many more things...

I finally decided (as I need to start working on multiple versions) to switch to git as it has a slightly better workflow for that.

This means in addition to browsing the source here locally you can now also enjoy the source over at:  GitHub and  SourceForge.

I don't really plan to host a public repository on nsclient.org as GitHub? and SourceForge? will have the same code.

Michael Medin

Well, NSClient++ 0.4.0 will be released in a few days so I guess the big question everyone has right now is to upgrade or not.

And it is a big question which I have been pondering for quite some time. I usually pride myself in the quality of NSClient++ and it is not that "it is bug free" but it has had few critical bugs over the years (since 0.3.0) but with 0.4.0 it is to large degrees a rewrite which means it has thousands of new lines of code as well as thousands of changed lines of code. This of course all adds up thousands of new bugs. To try to combat this I have introduced unit tests as well as been running betas and release candidates for quite some time. Yet I cant help but feel a bit scared about releasing this: will this be big heap of bugs or not?

My recommendation for upgrading to 0.4.0 is colored by this and caution is what I advocate. I think you can classify people into three groups.

1. I need/want/covet new cool stuff. In this case you have no option but to upgrade. But remember do so with care and read the "upgrade for advanced user" section below.

2. I don't need new features but I don't mind experimenting a bit. Definitely a candidate for upgrading but read the "upgrade for existing user" section below.

3. I have 5000 production critical servers and my boss gets really really mad. You should start (in your lab) to upgrade and report any issues so you can feel secure and upgrade all your machines once 0.4.1 is here! You should read both sections below.

Upgrade for existing users.

The current recommendation is to upgrade the client but not the configuration. The main reason for this is that the old configuration "should work" in 90% of all cases. And since configuration migration can have some issues migrating now means you are certain to be affected by any bugs where as if you migrate later on you can most likely avoid any issues.

Upgrade for advanced users.

This is not so difficult as it may sound you simply run the following command to migrate your old configuration to the new configuration. But it is important that you validate your configuration to make sure everything works as it should.

nscp settings --migrate-to ini

Also note that there are a number of new features you can use in the configuration so be sure to try out the "generate full config" command below.

nscp settings --generate settings --add-defaults

There is also a number of new modules and if you want to see what they provide in the form of configuration you can run the following command:

nscp settings --generate settings --add-defaults --load-all

The last two commands will create a lot of noise so it is recommended (until the arrival of the --remove-defaults) to not base your new configuration from them but use them as inspiration.

Conclusion

Hopefully that's answers all questions if not feel free to ask. Thus the general guidelines are:

1. Don't upgrade configuration unless you want/need new features and/or want to spend some time tweaking your configuration.
2. If you migrate your configuration make sure you validate it (and please report anything which doesn't work out of the box)!
3. If you generate default configuration make sure you remove what you don't need (defaults are good).
4. Make sure you run this in you lab before you push it onto all your servers.

Michael Medin

Well, if nothing popups this week 0.4.0 will be release this weekend! So now's the time to test or it will ship with bugs :)

Michael Medin

Build 153

Almost starting to feel a bit pathetic but hopefully this means it will be a smoother release. So again please, please, please test!

Anyways, The main fix is the does-not-start-on-boot which was due to a problem with the boost library I used to to thread/process communication (it apparently required DNS to load which caused timeouts as well as failing the service). Other fixes and enhancements include NSCA settings parsing/upgrading as well as reworked the generation command making it possible to generate a settings file with less "crap" and more things you actually need. I will BTW also in the next few days write a blog post about using the settings subsystem from a 0.3.x perspective...

UPDATE This means the FileLogging? module is no longer used/required so please remove that from your config file (log-to-file is now included in the main program).

Full changelog here:

2012-04-01 MickeM
 * Fixed issue with default port for NSCA/NRPE/* clients

2012-03-31 MickeM
 * Rewritten log implementation from ground up without using crappy boost library which requires DNS :(

2012-03-27 MickeM
 * Removed some annoying "error" messages
 * Tweaked FGileLogger a bit to be more "modern"
 * Changed so file-name expansion is more efficient
 * Changed so modules are defaulted to 0 in config.
 * Log levels are case sensetive
 * Fixed so log level is not read from ini file
 * improved plugin processing from ini files

2012-03-26 MickeM
 * Fixed perfoamcen data parsing issue
 * Fixed external scripts perfoamcen data issue
 * Fixed boolen flag handling in settings (default generated as false regardless of actual state)
 * Fixed so "advanced properties" are not generated with --update-defalts
 * Added some "advanced properties" here and there
 * Fixed path handling for object

2012-03-25 MickeM
 * Added last few features to the GraphitePlugin (which is now usable)
 * Tweaked nscp settings command line syntax a bit to be more flexible and usable...

Michael Medin

Well, a few bugs got caught and fixed and I managed to add a bunch of test cases for event log checking as well. Nothing major but please please est and let me know. If no new bugs pop up this will become 0.4.0 in a bit...

Full change log

2012-03-20 MickeM
 * Fixed alias/service name for real-time event log filters
 * Added smtp/syslog and graphite clients to installer
 * Fixed so eventlog wont crahs on invalid messages

2012-03-19 MickeM
 * Fixed issue in installer and "Make file writable" by everyone now uses Users SID.
 * Fixed issue in installer and "Default plugins" now correctly sets them to 1.
 
2012-03-18 MickeM
 * Removed dependency on tcpip from the service and the installer
 * Added new command to EventLog CheckEventlogCached which checks result caught by the real-time process.
   CheckEventLogCACHE warn=gt:1 crit=gt:5
   Requires a configured real-time checker to work.
 * Added a series of keywords to EventLog check to facilitate better checking
 * Added a set of aliases to make EventLog behave more like Wdinwos Eventlog viewer.
 * Added a lot of unit test cases to the Eventlog checker.
 * Fixed issue with default schedule beeing added as an item and not a template

Hello,

Another RC out now. Main focus for this one has been fixing bugs and making sure various things works. The good thing is I have now closed almost half the tickets (many of then was already fixed). And hence forth I plan to work more actively at closing defect which means defects will work better for bugs/feature requests then forum posts.

There are mainly minor tweaks and updates in this version so nothing really to write about. But hopefully most things will now work.

Please try it out and let me know if you have any issues as I hope to release 0.4.0 pretty soon! And if I have forgotten/missed an issue you have reported before please remind me I tend to miss some defects when time drags out and I get sidetracked!

Michael Medin

Full changelog:

2012-03-11 MickeM
 * Fixed a lot of issues with the installer
 * Added so the installer can generate a config file for you
 * Fixed so installer uses the correct path for password and allowed hosts

2012-03-08 MickeM
 * Major improvments to the WMI command line syntax.
   You can now: list namespaces, list classes, list instances as well as run queries.
   Means you can use NSCLient++ as a almost full featured WMI command line client.
   For details use: nscp wmi --help
 * Added sample python WMI script to list all classes in all namespaces
 * Fixed so if python scripts does not expose init and shutdown they will not be called
 * Added new option --simple to CheckWMI wmi commands to return a simple list without formatting.
	
2012-03-06 MickeM
 * Added "back" WMI Query command line exec like so:
    nscp wmi --exec wmi-query
	CheckWMI Command line syntax:
	Allowed options:
	  -h [ --help ]                        Show help screen
	  -w [ --wmi-query ] arg               Query to execute
	  -l [ --limit ] arg                   Limit number of rows
	  -n [ --namespace ] arg (=root\cimv2) Namespace
	nscp wmi --exec wmi-query --query="Select * from Win32_Process" --limit 2

2012-03-05 MickeM
 * Fixed so time/date comparissons are actually done in UTC (fixed for real this time!)
 * Added a series of testcases for CheckFiles (test_w32_file)

2012-03-04 MickeM
 * Added new dot-net API (Which does not require any strange wrappers)
 * Added brand new sample C# plugin
 * Fixed issue with python unit script loading usig the wrong default options

2012-02-21 MickeM
 * Added new module CauseCrash which has a single command CrashClient to allow the service to be crashed remotly
   *WARNING* Dont use this command, it is for debugging and testing purpouses only
 * Fixed issue with BreakPad which was disabled
 * Fixed some unix issues (sorry but hudson's stopped emailing me again:( )
 * Fixed service --install (now sets correct options)
 * Fixed service --install (now sets description correctly)
 * Fixed log level defined in protobuf (now same as rest of the system)
 * Fixed some issues with the check_nscp command

2012-02-20 MickeM
 * Fixed NRPE buffer issue
 * Added test case for 65K NRPE buffer length as well as 1Mb 
 * Added support for not regexp as operator to filters (Eventlog) (#463)
 * Added support for computer as filter keyword and format keyword in EventLog (#442)
   "filter=computer = 'foo'" syntax=%computer%
 * Improved messages rendering of eventlog messages a bit 

2012-02-19 MickeM
 * Added new unit context on command line for running simple unit test cases:
   nscp unit --language python --script test_nsca
 * Added dependency on Tcpip
 * Dropped OS bit-match requirement so now you can install any version on x64 plattform.
 * Added so you can specify multiple counters for CheckCounter and poll them all in one go (#387)
 * Added test cases (a bit flaky) for counters.
 * Added ${host} and ${domain} to hostname settings option which might be used to construct your own hostname. (#428)
   Not 100% sure about domain as on my box the "hostname" is only a name ie. has no domain...

2012-02-18 MickeM
 * Fixed so too long log messages are trunacated instead of discarded
 * Added option to truncate logfile if to large (#358)
   [/settings/file logger]
   max size = 1000
 * Added keyword to reload (settings) to reload settings store (ie. flushing the cache) (#249).
 * Added ability to load all files in a given directory (#366)

2012-02-17 MickeM
 * Tweaked a bit in regards to ExternalScripts so it works better and handles errors better (#367)
 * Fixed default report mode in 0.4.0 (#290)
 * Made NSCA Client handle timestamps like send_nsca (ie. ignoring local time)

2012-02-16 MickeM
 * Replaced command reader with object handler
 * Added support for running commands as other users (#131)
 * Improved pseed oflarge buffers for external commands (ie. when you return very large outputs) (#481)
 * Added limit to test interface message length (when messages are to long only first 4k are displayed)

2012-02-15 MickeM
 * Fixed missing icon on nscp.exe
 * Fixed missing version info on nscp.exe (#294)

Just a quick heads up to let people know I am actually doing something. I got a bit of inspiration from someone asking about interfacing from dotnet and thought: Well, why the heck not...

? NSClient++ 0,4,0,140 2012-02-22 x64 booting...
...
d Loading plugin: DotnetPlugin
d Using factory: NSCP.Plugin.PluginFactory for test.dll
d About to load dotnet plugin: D:/source/nscp/build/x64//modules/dotnet\test.dll
d Plugin loaded: test.dll
e Hello World from C#
...
? Enter command to inject or exit to terminate...

check_dotnet
d Injecting: check_dotnet...
e Got command: check_dotnet/check_dotnet
d Result check_dotnet: WARNING
? WARNING:Hello from C#

This is the first working version of the new dot.net API and plugin support. This works via a proxy plugin (DotnetPlugins?) which loads all configured dotnet plugins. Plugins can be written in pretty much any language and I am implementing mine in C#. It currently requires native protocol buffer support which is avalible for atleast C# and presumably others as well.

The API is a bit sketchy but follows closely how the internal API looks as well as the modern plugins for Lua and

Python.

The idea is that you have a factor class which creates instances of plugins like so:

namespace NSCP.Plugin {
    public class PluginFactory : NSCP.IPluginFactory
    {
        public NSCP.IPlugin create(NSCP.ICore core, String alias)
        {
            return new test.MyPlugin(core);
        }
    }
}

Then the plugin itself has access to all internal functions such as settings and query and registry such so registering the commands looks like this:

        public bool load(int mode)
        {
            core.getLogger().error("Hello World from C#");
            core.getRegistry().registerCommand("check_dotnet", "This is a sample command written in C#");
            return true;
        }

Then we can of course act on our command by providing a query handler like so:

        public NSCP.IQueryHandler getQueryHandler()
        {
            return new MyQueryHandler(core);
        }

The last and rather messy step (mainly due top the extreme verbosity of the  C-Sharp port of protobuffer) is to provide the command handler. I hope at some point someone will be able to provide a plugin layer (written in native dot-net) to make is slightly less verbose much like I have for Python, C++ and Lua.

        public NSCP.Result onQuery(string command, byte[] request)
        {
            NSCP.Result result = new NSCP.Result();

            // Process the incoming message
            Plugin.QueryRequestMessage request_message = Plugin.QueryRequestMessage.CreateBuilder().MergeFrom(request).Build();
            string intcommand = request_message.GetPayload(0).Command;
            core.getLogger().error("Got command: " + intcommand + "/" + command);

            // Create response message
            Plugin.Common.Types.Header.Builder header = Plugin.Common.Types.Header.CreateBuilder();
            header.SetVersion(Plugin.Common.Types.Version.VERSION_1);

            Plugin.QueryResponseMessage.Builder response_message = Plugin.QueryResponseMessage.CreateBuilder();
            Plugin.QueryResponseMessage.Types.Response.Builder response = Plugin.QueryResponseMessage.Types.Response.CreateBuilder();
            response.SetCommand(command);
            response.SetResult(Plugin.Common.Types.ResultCode.OK);
            response.SetMessage("Hello from C#");
            response_message.AddPayload(response.Build());
            response_message.SetHeader(header.Build());

            result.data = response_message.Build().ToByteArray();
            result.result = 1;
            return result;
        }

This will all be checked in (if you prefer to check the entire C# plugin) during the weekend and a new RC next week will feature this. As this has taken some time I will most likely have to skip a few of the bugs I was planing to fix :) So hopefully the next RC will be the last one. Also note that the C# plugin API is sketchy so please use it but beware that things are bound to change as I discover issues and problems...

Michael Medin

Michael Medin

Just a quick shout to let everyone know I have updated the road map and classified all tickets (ish) as well as assigned them to 0.4.0, 0.4.1 and future.

The idea with the next few versions are:

milestone:0.4.0

RC2 out now, release in the next month or so.

milestone:0.4.1

A month or so after 0.4.0 with fixes and updates

milestone:0.4.2

Next major release which improves scripting and simplifies monitoring as well as updates the Windows Subsystem making NSClient++ much better to monitor modern windows.

milestone:0.4.3

Maintenance release for 0.4.2 (again a month or so behind with fixes and updates).

milestone:future

Everything I haven't planned yet...

Michael Medin

Yaay!

Finally cleaned up and classified all tickets. This means you can now get an idea about when something will be fixed. Issues I think are mainly bugfixes and/or small changes have been set to 0.4.0 but I cannot guarantee that they will all be included. I will fr RC3 out in a week or soo) have a defined scope and after that everything not fixed will be retargeted to 0.4.1. Please note that if your "issue" is NOT included in 0.4.0 milestone PLEASE let me know now if you feel it would be important as now it´s the time to make changes to it.

Michael Medin

RC2 out finally (Built 134)!. This is again long over due mainly as the target re factoring took 2 more weeks than anticipated. Well it is not really out it is building currently and I am an optimist assuming it will build ok meaning in a bit you can find 134 under nightly and tomorrow morning you can find it under RCs.

The main highlights are fixes with loading "objects" (targets and schedules) which now works much more smoothly and you now also get documentation in your settings file as well. The other main high light is a new improved Lua API meaning you can now utilize the same (almost) features as the Python scripts can do from Lua. The only thing lacking currently is protocol buffer support. But protobuf support for Lua will not make it into 0.4.0 as I am unsure how to do that since there is no native Lua library for protobuf.

Other notable fixes are:

• The broken installer is now fixed
• Ability to target scheduled tasks easily
• A lot more unit tests
• Bug fixes here and there

2012-02-13 MickeM
 * Fixed installer issue (could not start service)

2012-02-12 MickeM
 * Added support for specifying targets on schedules:
   [/settings/scheduler/schedules/foo]
   target = foo-host
   Will re-target the NSCA (or whatever you use) towards a given target.
 * Fixed is schedule manager uses new standard object reader
 * Fixed some issues with reading schedule

2012-02-05 MickeM
 * Added test cases for targets to NRPE
 * Added test cases for targets to NSCA
 * Added test cases for lenghts to NSCA
 * Changed to python API sleep uses milliseconds (not seconds as before)
   Makes NSCA unittests go much faster (as I can wait much less)
 * Fixed a lot of bugs related to target handling.
 * implemented target refactoring on all Client modules.

2012-02-05 MickeM
 * Refactored the targets concept internally to be simpler to use (less code)
 * Fixed issue with reloading plugins
 * Fixed target handling in NRPE Client, will add NSCA client tomorrow...

2012-02-02 MickeM
 * Implemented full API for LuaScript
	Now "everything" (ish) works including channels, exec and query (via moderna API)
	Still no protocol buffer support but not sure how to play that yet so will not be avalible in 0.4.0.

2012-02-01 MickeM
 * Implemented full settings API for LuaScript (next RC will have to wait till next weekend)

2012-01-31 MickeM1
 * Fixed issue with parsing "invalid external commands".
   If parsing falies it will notify you but use the legacy split string method instead.
 * LuaScript module is now modern (ie. works with 0.4.0)
   Should be 99% compatbile (function needs to be defined before registration) but all old scripts should work now (I think)
 * LuaScript module has been modernized
   The new API is very similar to Python
   Concepts are working but not all commands have beenh implementes (and no testcases either)
   The old API will still work
 * Fixed issue with 

2012-01-27 MickeM
 * Changed CheckCounter format option to take a coma separated list of keyword from the below list:
	 nocap100: Counter values above 100 (for example, counter values measuring the processor load on multiprocessor computers) will not be reset to 100. The default behavior is that counter values are capped at a value of 100.
	 1000: Multiply the actual value by 1000.
	 noscale: Do not apply the default scaling factor.
	 So format=nocap100,noscale would combine the two aspects above.

2012-01-26 MickeM
 * Fixed issue with parsing multiple performance data items (internally)
 * Added option to CheckCounter format=nocap100 to not cap counters at 100% (for multi cpu machines)

2012-01-22 MickeM
 * Fixed help when specifying invalid options on command line
 * Eradicated a potential memoryleakin the NSCA encryption library

Since I forgot xmas and new years eve (was ill) I figured I'd post the Chinese new year instead! :)

build 126, 127 will be out later tonight whith some fixes to NSCA unit-tests.

After years of vapor ware and many broken promises I can finally proudly pressent the first release candidate of NSCLient++ 0.4.0!

So what can you expect you ask? Quite a lot in fact but currently the rather sad answer will be unfortunetly "not much". Now this is a good thing and the reason is that the idea is that anyone runnign on a previous version of NSCLient++ should be able to just upgrade and not notice the difference (except for the odd bug fix here and there).

But for all the rest of you who do not want to "just upgrade" there is a massive amount of new features. The two biggest changes will undoubtedly be the linux support as well as is a shift from beeing a "NRPE client" to more of a monitoring gateway which supports more protocols (with even more in the pipe). Another other major change is ofcourse the embedded python interpreter and the very extensive python API making it possible to create plugins in python which can have state across your monitoring.

So now it is just for everyone to go out test it and let me know what is not working so we can release a bug free version in the near future. I have not set a date as I am relaying on the community (yes, that is you!) for doing much of the test work and that may or may not take a lot of time (depending on how much YOU! test).

Stability and quality wise I hope it is farily stable and everything works as-is but one never knows when there is such a massive update. Especially as it is apretty free-form application which has a lot of the edge cases. But another major improvment is that there are now unit-tests which test various parts of the application at the time of writing there is around 1000 unit tests which more to come.

Many new protocols

We now support a number of new protocols (as well as old).

Currently supported:

• NRPE
• NSCA
• "check_nt"
• SysLog?
• SMTP
• NSCP (early concept version, both as distributed (think gearman) and non distributed (think NSCA/NRPE))

In the works:

• http (rest)
• Graphite
• check_mk
• NRDP
• SNMP
• WMI
• "native remote windows checks"

Brand new API

Major new API changes which allows a lot more flexibility as well as extensible from modules and scripts.

Currently supported:

• Python
• plugins
• Lua (old API currently)

In the works:

• Lua
• .Net

Brand new settings sub systems

Brand new flexible settings sub systems which supports many new formats as well as generation and including cross formats.

Currently supported:

• ini-files
• registry
• http (ini files)
• old
• dummy (in memory store)

In the works:

• XML
• improved http

Other fixes and enhancments

We have of course a myrriad of bug fixes enhancments and and such here are a few highlights.

highlights:

• Brand new (easy to use?) command line interface
• Linux suppport (as mentioned previously)
• CheckProcState: Enchancements
• CheckEventLog: Real time checking
• CheckWMI: Remote check support (rather crude currently)
• lots of other things but focus is mainly on internals so checks are mainly the same

So! Test away, and hit me with your bugs, defects, problems, and issues... Michael Medin

Hello google bot!

Just a quick heads up that the first draft of the migration guide as well as the concepts guide is now live!

• doc/about/0.4.x
• doc/migrate
• doc/migrate/0.4.0

Now I am off to make some last minute changes before releasing RC1!

Michael Medin

I have started to write documentation for the 0.4.x version. Currently we have the following documents:

• doc/configuration/0.4.x
• doc/usage/0.4.x
• doc/usage/0.4.x/client
• doc/usage/0.4.x/settings
• doc/usage/0.4.x/service
• doc/usage/0.4.x/test

Next up is a migration guide as well as a concept document. RC1 is still scheduled for this weekend so please help out next week to do some testing!

Note that all documents are "first draft" so it is a bit all over the place currently :P

Michael Medin

Well, I sort of promised to release rc1 of 0.4.0 on which has now become last year. This was in fact almost about to happen but unfortunately I grew ill shortly after xmas (nothing serious really). But this has keep me away from the computer for about 2 weeks now meaning I am slightly behind. And what is worse I missed the golden "holiday opportunity" to do some serious documentation.

Now it is not too bad I finished the NRPE unit test last night and hopefully I will get some spare time during night this week to document the initial usage of 0.4.0 so with luck next week we will in fact see the first RC of 0.4.0!

Michael Medin

Hello,

The main new things is a much improved client syntax as well as fully functional client modules and much improved handling of "Clients".

Get it from the download section (113) or here:

•  http://files.nsclient.org/nightly/NSCP-0.4.0.113-x64.msi
•  http://files.nsclient.org/nightly/NSCP-0.4.0.113-Win32.msi
• On linux just checkout trunk and build (see build page)

I will post a guide to getting started with 0.4.0 later tonight.

Michael Medin

Full change log:

2011-12-06 MickeM
 * Fixed so command line client wont try to run commands in modules which does not support it.
 * Changed to when no settings is found a default one is created
 * Removed old "location" key from switch context and changed so it use the new number scheme
 
2011-12-06 MickeM
 * Added python unittests to make sure threading is working properly
 * Simpliefied and cleaned up the command line syntax a bit
 * Now --exec is the default option for client mode (but it will notify you it thought so)
 * Added "command-less" execution to PythonScript so you can do --exec --script ... (without having --exec run)
 * Fixed an issue related to python threading
 * Fixed Scheduler header propgation
 * Fixed so all Client module use "complex" API meaning headers are propagated correctly
 * Fixed scheduler alias issue

2011-11-27 MickeM
 * Fixed some NSCA issues (reading from new conf)
 * Fixed some linux build issues (related to refactoring)

2011-11-27 MickeM
 * Major refactoring in the command line interface
 * Added support for alias to many common module (command line)
   so: nscp eventlog (is the same as nscp client --module CheckEventLog)
 * Fixed issue with CheckEventLog message rendering and eventid
 * Refactored all Client modules to all support command line, commands and submissions.
 * Added uniform handling of "everything" to all Client plugins
 * Fixed SyslogClient to work "as advertised" (ie. all hardcoded stuff is removed)
 * Fixed utf8 issue with text strings (now have a working concept which needs to be implementd "all over the place")
 * Many issues and fixes related to clients.
 * Fixed so CheckEvent log (insert) works much better (added new options)

This is really about Python threadsafeness I guess (but the numbers sounds cool).

I have had various issues with python through out the development of the module (mainly related to pythons rather strange threading model). After discovering some issues the night before the conferance pressentation I set it upon myself to write some unit-tests for the python script module to make sure the threads are actually safe and works correctly.

And in doing so I got some interesting numbers.

OK: Summary Collected 109989 checks in 10 seconds: 10930/s

At the OSMC conference the other day they presented some numbers comparing Shinken with Nagios and Icinga and the gist of it was that Shinken was around 4 times as fast as Nagios with Shinken running 120k checks in 5 minutes which roughly translates to 400 checks/second.

Now in my python unit test what I do is I run an internal python based check (forwarding the result via internal channels again to Python) but in doing so to be able to force simultaneousness I run 50 threads pumping around 15k checks per second. This means I get (after running around 100000 checks) an average measured from python 10930 checks per second. This at an average 30% CPU load on my machine...

And yes, this is not fair at all, first off I have no idea what kind of hardware they used to run their checks and neither do I do any proper service checks (in fact running 10k+ service checks per second could actually even exhaust my local port stash since each remote check would probably take a few seconds).

Regardless I think it shows that NSClient++ is able to schedule a lot of checks and more importantly for me Python is now thread safe (I hope :) )...

Michael Medin

Hello,

We now have the first beta version of 0.4.0 released. The main goal of this version is to verify that everything works "smoothly" for existing users. So essentally try to upgrade an existing 0.3.x version and let me know if everything is working out alright.

Everything should be the same after upgrading to 0.4.0 and you should not notice any differences. But this is an early release so please be carefull as it probably will have many issues and defects yet.

But it would realley help me and speed things along if a lot of people could help test this version with various existing configurations.

Also please do a backup of your existing configuration before installing this version (in case the installer is broken).

Download:

•  NSCP-0.4.0.111-x64.msi
•  NSCP-0.4.0.111-Win32.msi

Also I will tonight try to start answering all questions last few weeks, I have been busy elesewhere last few weeks...

Since elfichero asked for a changelog I pasted it in. Notice These are changes since 0.4.x was split apart. But during a lot of the internal work I did not keep track of changes are things were moving back and forth so the "internal changes" will not be reflected here in detail.

I will write up a blog post about "whats new" in 0.4.x but in essence the "core" is new whereas the plugins (check_xxx) are the same (ish). There is also also a lot of new plugins (which were not part of 0.3.9).

2011-11-14 MickeM
 * Fixed issue with installer not saving nsc.ini when upgrading from 0.3.9

2011-11-09 MickeM
 * Added initial SyslogClient module to allow syuslog forwarding (of passive checks ish)
   Still requires template support and configuration options (mainly PoC right now).
 * Added initial SMTPClient to allow sending messages via SMTP.
   Still requires template support and configuration options (mainly PoC right now).
 * Fixed unicode log issue (still not sure message format is correct)
 * Renamed Message to log in internal wrapper API
 * Fixed issue in settings old (regarding readin new keys, not 100% supported yet)

2011-11-06 MickeM
 * Had some "vacation" so no updates for a while
 * A lot of fixes to the NSCA parts (now 100% compatible with old settings file)
 * Added option to read sections (to plugin API)
 * Fixed issues in settings wrapper so child paths are also mapped (not just keys)
 * Many fixes related to NRPE/NSCA/*
 * "RC quality" expect RC within the week (only need to fix default config file somehow)
 * Upgraded all unit test to use the simplified API
 * Fixed a some unicode issues in PythonScript module
 * Improved threading a bit
 * Fixed CheckSystem (service check)
 * Fixed duplicate keys (when replacing) in old settings client
 
2011-10-21 MickeM
 * Some more threading issues in Python (works perfectly(?) now)
 * Refactored the tests a bit making test suites runable from a central hub
 * Fixed soo everything builds and works on Linux

2011-10-19 MickeM
 * Fixed some threadding issues in PythonScript
 * Still working on refactoring the unittest helpers a bit

2011-10-16 MickeM
 * Fixed issue with loading zero-byte UTF-8 config files
 * Fixed some issues with settings subsystem (debug log as well as createing instances for --generate)
 * Added ability to set event log to real-time
 * Added support for multiple eventlogs in real-time

2011-10-09 MickeM
 * Real-time CheckEventLog working (still only for one, and I think application log)
 * Added python tests to validfate that Real-time eventlog is working.
 * Fixed som defects here and there (now builds on Linux again)
 * Fixed so it builds in "debug mode"
 * Fixed issue in grammar which caused infiniate loop in som cases
 * Fixed so error rendering in eventlog works with "infininate number of argumnets"
 * Added support for targeting execs (in API)
 * Fixed some invalid return messages
 * Streamlined submissions wrappers to be more inline with "other wrappers"
 * Fixed a myrriad of minor python script bugs
 * Added sleep command (which sometimes causes issues so use with care)

2011-10-06 MickeM
 * Initial command for createing eventlog records
 * Initial real-time eventlog checker
 * Fixed obscure c-tor issue with filters
 
2011-09-27 MickeM
 * Fixed many many issues all over the place as I tried to make things working for my pressention at nwc.
 
2011-09-24 MickeM
 * Started on NSCA unit-tests in python
 * Refactored channel API a bit to better suite NSCA (and how it actually works)
 * Changed how headers are created (nothice this might have broken NSCP stuff, havent checked)
 * Created helper lib for Python Unittests

2011-09-21 MickeM
 * Renamed NSCAAgent to NSCAClient (to be consistant)
 * Created a NSCAServer module (again for consistancy)
   This will be the defenition of the new "channels" so keep a lookout in the next few weeks

2011-09-18 MickeM
 * Implemented first version of DistributedClient and DistributedSServer which work so now we have a proper message based transport.
   Still a lot of rough edges such as cookie and authentication support is hard coded.
   We also need a proper two way distributed server as well as implement "all" payload types.

2011-09-11 MickeM
 * Massive overhaul here and there
 * Added new helper for handling "targets" (so they are the same)
 * Extracted "command line handling" so all clients will work the same
 * Extracted command processor to a common class to make all clients work the same
 * Added initial zeromq stuff (nothing usable)
 * Added an implementation layer for NSCP protocol parsing (so zeromq stuff can reuse it)
 
2011-09-05 MickeM
 * Cleaned up some dependencies (on config.h)
 * Fixed invalid data in config.h.in

2011-09-03 MickeM (0.4.0.93)
 * Created a protcol buffer free version of the python test script
 * Upgraded to new version of simpleinin class
 * Added new component for python protocol buffer library to installer
 * Added installer for unittests to test.py run like so:
   nscp --client --module PythonScript --command execute-and-load-python --script test.py
 * Fixed so settings are created if not existing
 * Fixed so plugins are not loaded in client mode
 * Fixed so core is booting correctly in client mode
 * Added new option --settings --switch <context> to allow switching context without migrating data
 * Fixed unicode error on linux (settings file)

2011-09-02 MickeM
 * Fixed several issues in PythonScript
 * PythonScript supports loading multiple instances as well as scripts
 * Added some basic channel test to test.py script (the idea is that this will become "unit tests" eventually)

2011-09-01 MickeM
 * Implemented registration of channels (so no longer faked)
 * Added settings key to change the NSCAAgent channel name
 * Addded proper channel handling to PythonScript module
 * Improved error handling in channels API
 * Rewrote wrapper API to use templates and classes instead of macros (ish)
 * Improved the internal plugin wrapping API to support multiple plugin load
 * Fixed so PythonScript module supports multiple plugin load (with new argument for plugin_id)
 * Added API for registrying routers and handling routing (almost there now)

2011-09-01 MickeM
 * Fixed issue with messages due to new API

2011-08-31 MickeM
 * Added support for loading same plugin twice (in different sessions)
 * Added preliminary support for routing passive checks

2011-08-30 MickeM
 * Fixed uncaught exception in test client
 * Added protocol buffers to source (needs to be added to installer as well)
 * Added example python protocol buffer handler
 * Added lib folder to python scripting (and automagicall load)

2011-08-29 MickeM
 * Fixed some *nix build issues...

2011-08-25 MickeM
 * Fixed some issues in the NSCPClient
 * Fixed debug log issue in core
 * Added support for "pushing" passive checks via NSCP

2011-08-24 MickeM
 * Sever refactoring of the new API (there is now two pb files ipc for NSCP protocol and plugin for plugin communication)
 * Cleaned up API helper functions
 * Fixed client argument for "client mode" to allow arbitrary arguments
 * Cleaned up the argument processor code now requires "mode" to be first argument

2011-08-23 MickeM
 * Fixed issue in the NSCP server

2011-08-22 MickeM
 * Added initial NSCP protocol implenmentation (very vrude and not really usefull yet)
 * Fixed so it builds on linux
 * Fixed so automagic plugin renaming add lib<LIB name> on *nix.
 * Fixed so it works on linux (fixed issues with timeout)

2011-08-16 MickeM (0.4.0.85)
 * Added support for remote WMI checking using target/username/password options like so:
    CheckWMI target=192.168.0.123 user=\\foobar password=foobar namespace=root\\cimv2 MaxCrit=3 MinWarn=1 "Query:load=Select * from win32_Processor"
 * Added support for looking up targets to CheckWMI
   CheckWMI target=my_test_xp MaxCrit=3 MinWarn=1 "Query:load=Select * from win32_Processor"
   Where <target> is defined under /settings/targets as well as /settings/targets/my_test_xp

2011-08-15 MickeM
 * Readded allowed hosts function
 * Moved default socket options to /settings/default/socket
 * Added more default socket options
 * Added support for target in default plugin helpers
 * Added remote WMI commands
 * Added target section under /settings/targets

2011-08-14 MickeM
 * NRPEClient now works on linux
 * Added "portable" settings map file to installer (so it will work with old installed versions)
 * Rename Function to Registry in PythonScript API as well as some other function renames
 * Started to clean up the helpers around the API
 * Added support for execute to PythonScripts to execute commands
 * BUG: just realised that static plugin instances prevent multiple instances :)
   Will fix but not now as it is not important (for me)...
 * Added initial support for channels to PythonScript
   Core still lacks support for subscribing to arbitrary channels

2011-08-13 MickeM
 * Added support for command line execution to PythonScript module
 * Readded support for specifying module on command line with --client mode
 * Fixed some issues with the NRPEClient module
 
2011-08-12 MickeM
  * Finnished (rough) adding back command line exec (with modern API)
  * Fixed so installer uses correct name for dll:s (now Server not Listsener)
  
2011-08-11 MickeM
  * Started to add back command line exec (with modern API)
  
2011-08-10 MickeM
 * Fixed linus issues and defect
 * Fixed some issues in the test python script regarding how prefix is handled
 * Fixed PythonScript module to actually use the correct function map :)
 * Fixed so it builds and runs on linux (but parser had issues so disabled som grammar rules whichneeds to be enabled again)
 * Added a lot of freatures and cleand up the PythonScript module
 * Started to merge som features from PythonScript back to Lua script
 
2011-08-07 MickeM
 * Fixed a lot of issues with PythonScript module adding suport for alias and "raw command processing"
 * Fixed issue with loading plugins and aliases as well as duplicate plugin detection
 
2011-08-01 MickeM
 * Added new module: PythonScript

2011-07-25 MickeM
 * merged in all 0.3.9 changes
 * refactored where filter to be "non template" to drastically reduce compile time (as well as potentially size if I ever go dll instead of static link)
 * streamlined checkeventlog toi be same as "the other" where filters as well as dropped support of "old" syntax.

2010-02-05
 * Multiple fixes all over the place
 * Availible modules: CheckExternalScripts, CheckHelpers, FileLogger, NRPEClient, NRPEServer, Scheduler
 ! Performance data is still missing (will be for a while yet)
 
2010-01-31 MickeM
 + Added google protocol buffers
 ! Changed internal handle command logic (now uses protocol buffers)
 - Removed (temporarily) performance data (due to protocol buffer changes)

2010-01-19 MickeM
 + Rename NRPEListener to NRPEServer
 + Added NRPEServer to CMake build

Michael Medin

Hello,

If you have an old account please attempt to recover your password and let me know if it works, and/or if it does not. As I, might not have said, the changes were due to replacing a file based password store with a database based one so importing passwords was not "possible" as I only store hashes and they have (or so I think) different hashing algorithms.

Michael Medin