rss
Switch to GIT (from subversion)
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
To upgrade or not that is the question?
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.
- 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.
- 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.
- 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:
- Don't upgrade configuration unless you want/need new features and/or want to spend some time tweaking your configuration.
- If you migrate your configuration make sure you validate it (and please report anything which doesn't work out of the box)!
- If you generate default configuration make sure you remove what you don't need (defaults are good).
- Make sure you run this in you lab before you push it onto all your servers.
Michael Medin
Last chance!
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
Another attempt at a "final 0.4.0 RC"
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
