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 [email protected] 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
