Feature request: remote config for deployment

[Stephane Rosa]

Hi,

I'm working with ely_j2002 on our Nagios infrastructure.

There are two things missing right now that we would find
very helpful. The issue with deploying NC_Net on multiple
hosts is the configuration. The fact that passive checks
are different on each hosts means that we cannot have a
single unique package to be deployed.

My idea is the following :
1) We deploy the MSI on each server
2) We Unzip a standard, unique startup.cfg and passive.cfg
   feature request: NC_Net finds the hostname by itself, so
   it immediately gets ready to run
3) feature request: A passive check in the default passive.cfg
   above connects to the Nagios server and checks for an updated
   version of startup.cfg and passive.cfg (based on timestamp or
   serial number). If there is something new, it retrieves the
   file(s), save them and reload them.
4) feature request: If we could have different polling times for
   each passive check, we could set the CheckForNewConfig every
   1 day or so, while still having normal checks more frequent

This has many advantages :

- Only one set of files, almost never changing, are deployed on
  all servers and any new server.
- All configurations are managed centrally on the Nagios server,
  no need to remote connect on each server to update/change things
- We can set a passive check that checks for a new config every
  day, so we can easily manage changes.

That's it :) I know it's pretty heavy but I think it would
add great functionality. I would be glad to dig myself in
your code (pretty clean by the way) but do not (yet) have
the time...

Thanks
Clipper

[tony]

Thanks for the complement clipper,

As for your feature requests,
the new default Passive check Host name will be the computer name from WMI (I think it is in the system object)
The two feature requests you have (1. remote updates of Config files, 2.Passive checks on different time intervals) are not going to be added at this time.  the primary reason, is due to lack of financial support to add these requests.  It is not that I am trying to be greedy. I have been maintaining NC_Net as a personal project and a resume builder.

for your first request of updating the config files, the Startup config, really should not need to be updated on a regular basis.  Its roll is to setup the defaults of the network as well as set the limits of NC_Nets security allowances.  As an alternate to adding these features to NC_NEt your request can currently be achived via Unix Scripts through active checks. for example, for refreshing the passive checks on a daily bassis, run the command to list the Passive checks, then through check_nc_net delete all the passive checks, then reload all the passive check via check_nc_net. The startup config cannot be modified in the same way, The startup config is only used at startup time of NC_NEt, but via the CONFIG command you can modify the running configuration of nc_net that may be your true goal rather than making sure the startup.cfg file is updated.

As for the second request, it is something that I would like to include, and I have thought about in the past.  It would require an overhaul of the way NC_NEt does checks, And for versitility NC_NEt should be completely redesighed to be able to preform this.  the redesign should be a more OOD design, this would allow for easier updating and expandability and reuse. 

As for the three advantages that you listed,
Each of these will be availible via adding Unix side scripts, once the next update is released.  the two primary updates that facilitatate this are: Host able to self-configur Computer name (this is only helpful on Nagios configurations that match the Windows system computer name.)  the other update I have added into release 4.x is the ECHO command.  If you add a Passive check using the ECHO command you would be able to use this with a Unix Script to validate the version of the Passive.cfg and Startup.cfg

Also please note: there were no advantages listed for the Feature request of Passive checks being run on different time intervals, but I think the best advantage of that is reducing resource usage by only having critical things checked frequently while other less critical resources can be checked once a day/week.  for example Disk usage does not drastically change over 5 min but CPU does. 

On a second note: I am in the planning eventually on making some NC_NEt tools (most likely in Java for the crossplatform advantage) these would be availible for purchase.  These tools would include a Graphic configuration tool that modifies any/all config or command files, an enhanced windowed Test Console, and a Enhanced Graphical WMI viewer tool. I am also planning on releasing more comprehensive Documentation for purchase. The biggest issue associated to these endevors is how to price the value of these tools/documents since I would want users to purchase them because they would be helpfull, but if I price too high no one would want to purchase them, and if I price too low then I would not be able to get back any of my development costs. 

Once again thank you for the input,
Hope this responce helps,

Tony