[Nagiosplug-devel] command.cfg.in

[Jeremy T. Bouse]

On Thu, Jun 12, 2003 at 08:10:37AM -0400, Subhendu Ghosh wrote:
> On Wed, 11 Jun 2003, Jeremy T. Bouse wrote:
> 
> > 	In working to get the nagios-plugins packages ready for Debian I was
> > running into the interesting problem that Nagios 1.1 was having problems reading
> > the command.cfg file saying it found unexpected commands... It seems that it was
> > wanting the commands in the template form instead... With this in mind would it
> > not be advantagous to go ahead and convert the command.cfg.in to use the
> > template format... Possibly also look at seperating the sample configs into
> > seperate files even so they could only be installed if the plugin itself was
> > installed... 
> > 
> 
> The generated makefile does not install command.cfg.  So I guess the 
> packages are adding that feature in.  I think the thought process was that 
> folks would have modified the commands and we didn't want to over-ride 
> them on upgrades.
>
	Yeah I believe the packages are what are installing
command.cfg... Actually speaking as the one taking over the maintainer
position for the plugins on Debian the command.cfg is not installed by
nagios-plugins but rather by the nagios package (I don't maintain that)
and it has no commands defined... The Nagios package maintainer places
it there as a default and no future package upgrade will touch it so it
is safe for local configurations...

	Now the nagios-plugins package (which I do maintain) reads the
command.cfg file and parses all the command[...]= entries into seperate
files based on the plugin called (ie- check_snmp.cfg would have all
command lines defined using check_snmp) and saves them into
/usr/share/nagios/pluginconfig/ which the update-nagios script (part of
the nagios package) reads and parses and produces the checkcommand.cfg
file in the nagios config directory. Then the nagios config just
includes using the cfg_file directive along with command.cfg... 

	I've managed to get around this issue however by working with
the nagios package maintainer and modifing the update-nagios script to
handle it appropriately... 

	I'm not aware of any issue with RPM packages as I don't run
RedHack^H^Ht...
 
> I like the idea of separating the configs into separate files. The cfg_dir 
> parameter should be able to suck in all the command definitions.
> 
> If we do separate them into files, then template format as default is 
> appropriate.
> 
	If we do move to a template format it would need to be seperate
files for each plugin because parsing like what is done now would be
even more of a headache... If the files are named appropriately then the
install could simply include only those config files that it actually
installs the plugin for... For example if check_blah plugin isn't
install'd then check_blah.cfg isn't either... I'm sure the install
processing of the Makefile could even be written so you wouldn't have to
list all config files available so if there isn't an example config now
one could be added later without having to make changes... 

	Regards,
	Jeremy