Breaking up hosts.cfg into manageable files, possible?

[Matt Pounsett]

On Wed, 5 Nov 2003, MT Morales wrote:

> 
> Is it possible to break up the hosts.cfg (and services.cfg) in to 
> small, more manageable files (like for different types of systems)? 
> i.e. do the hosts.cfg and service.cfg object files support some sort 
> of "include <unix-hosts.cfg>" statement?

The config files defined in the default nagios.cfg are arbitrary.  Using the
cfg_file and cfg_dir commands you can load config files named anything you
wish.  Additionally, any nagios directive you choose can appear in any config
file (except for the directives specific to cgi.cfg .. that's special).

So basically you can structure your config layout any way that makes sense to
you.

I've got my check commands and notify commands in two separate files, a file
for templates, and  a set of directories, one for each site monitored, which
contain a set of files, one per host, which contain both the host and service
definitions for the particular host.

I'm sure if other people throw in their $0.02 you'll find there are a myriad
of other config layouts people have chosen to use.


-- 
Matt Pounsett                 CIRA - Canadian Internet Registration Authority
Technical Support Programmer                    350 Sparks Street, Suite 1110
matt.pounsett at cira.ca                                 Ottawa, Ontario, Canada
613.237.5335 ext. 231                                      http://www.cira.ca



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
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