best solution for configuration changes

[Matthias Flacke]

I'd like to suggest a completely different approach - again with the plugin 
check_multi (http://my-plugin.de/check_multi) which I yesterday introduced in 
another context. ;-)

Take the following scenario: you have a parent check_multi service for each 
region (user/admin/organisational) you want to serve and it is configured 
within nagios by you - this is the fix frame.

Now the flexible part - the plugin configuration. Multiple child plugins are 
configured in a plain ASCII file like the following:

# group1.cmd
command [ proc1 ] = check_procs -C abc ...
command [ disk1 ] = check_disk -w ...
command [ load  ] = check_load ...
...

This command file is easy to understand, to change and to test (on the command 
line). There has nothing to be changed in Nagios, no need to run any further 
'nagios -v' check. So you can delegate this job to your users.

If the users do anything wrong with it, they only earn an error message (which 
is shown in Nagios parent plugin output) and at worst a CRITICAL state for 
their parent service. But Nagios remains sane and integer.
These check_multi configs can be maintained by SVN, and security is based on 
standard Unix access control.

The only disadvantage: all child checks only have one parent. This means only 
one notification, escalation logics a.s.o. If you want to split this, take a 
second service.
And another point: it's more or less Nagios3 stuff because it extensively uses 
multiline output.

Greetz,
Matthias

Brian Loe wrote:
> I was thinking of some convoluted solution for users to configure 
> "their" configuration files and them diffed or uniqed to the original 
> with that being saved and then the newly updated config file to be 
> copied over the old one and nagios reloaded, etc., etc.. BUT, I figure 
> there has to be a better way. What I have for host config files are:
> 
> windows.cfg
> net.cfg
> resources.cfg
> unix.cfg
> security.cfg
> 
> Each of those host config files has a group of people associated with 
> them - and I'll need to break out the services.cfg file the same way.
> 
> I haven't added a user to the system either - and I'm not even sure what 
> the best way of doing that!
> 
> The end result of what ever I do allows, for instance, people in the 
> security group to modify /etc/nagios/security_hosts.cfg and 
> /etc/nagios/security_svcs.cfg, and the changes would be saved somewhere 
> (repository or log file or whatever), and then nagios service would be 
> reloaded.
> 
> Suggestions? Solutions? It'd be great if this could be done via a/the 
> web interface but I haven't found one that works that well yet - and I 
> still am not sure how to provide users with a login/pw that they can 
> change upon the next log on (obviously I'm not an expert linux admin)!


-- 
http://my-plugin.de/check_multi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null