Changes between Version 2 and Version 3 of doc/about/0.4.x


Ignore:
Timestamp:
01/15/12 21:17:36 (17 months ago)
Author:
mickem
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • doc/about/0.4.x

    v2 v3  
    1414 * Syslog 
    1515 
    16 == Concepts == 
     16== Message Exchange Concepts (paradigms) == 
    1717 
    1818To 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: 
     
    3939It 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. 
    4040 
     41== Configuration Concepts == 
     42 
     43(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). 
     44We currently support five main different settings stores. 
     45 * old (legacy format used in 0.3.x versions) 
     46 * ini New version of the ini file wich supports all new options 
     47 * registry Windows registry (proper one this time) support. 
     48 * http (Currently very crude way to support loading remote configuration) 
     49 * 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) 
     50 
     51The "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. 
     52 
     53The 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: 
     54{{{ 
     55[/settings/NSCA/client/targets/default] 
     56host=192.168.0.1 
     57encryption=aes 
     58}}} 
     59 
     60Where 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. 
     61 
     62For more details about configuration see the configuration section [[wiki:doc/configuration/0.4.x]]. 
     63 
    4164'''TODO''' This page is a quick place holder for a more in depth version which I will write at some point :) 
    4265