Fans of NSCP
Next Change →
side by side
lines around each change
Show the changes in full context
White space changes
01/15/12 21:17:36 (
Message Exchange Concepts (paradigms)
To create a generic client it was important to find a few paradigms which are generic and extensible enough to facilitate various uses. In NSClient++ we currently support three main paradigms:
It is important to understand that these are '''not protocols''' they are paradigms. For instance internally there is no payload limit but if you check from Nagios using check_nrpe you are still stuck with the 1024 char limitation. So currently the "wonders of no limits" are not really useful to you (but this will change). But the main idea is to show the community that it is possible and hopefully as time goes on new protocols will emerge. It is also important to understand that a lot of these things can still be used with great benefits even now as you can use all this internally inside scripts and what not. So dont think that it is unimportant just because NRPE still has a payload limit.
== Configuration Concepts ==
(Again) Since the goal was to make something which is flexible enough for everyone the settings subsystem allows you to do whatever you want (almost).
We currently support five main different settings stores.
* old (legacy format used in 0.3.x versions)
* ini New version of the ini file wich supports all new options
* registry Windows registry (proper one this time) support.
* http (Currently very crude way to support loading remote configuration)
* dummy In-memory store which cannot be saved. (mainly used for scripts and such which will create a temporary run which does not require saving)
The "cool" thing about the whole concept is that on store can include another this means that if I want to keep my legacy "old" store I can simply create a include section which includes a ini file and thus have another file where I can place all new configuration settings. Or if I want to have the bulk of the config in the registry but allow an administrator the ability to override some keys locally we can (from the registry) include a file and vice verse.
The actual settings are key value pairs store in a hierarchical tree (much like the registry in that regards logical grouping). But of course we can still store this in a file thus the end result is:
Where you can notice the '''/settings/NSCA/client/targets/default''' which is the hierarchical path '''host''' is the key and '''192.168.0.1''' is the value.
For more details about configuration see the configuration section [[wiki:doc/configuration/0.4.x]].
'''TODO''' This page is a quick place holder for a more in depth version which I will write at some point :)