[Nagiosplug-devel] [RFC] Plugins config file

[Gavin Carr]

On Tue, Oct 17, 2006 at 10:05:58AM +0200, sean finney wrote:
> > I think these two together argue that this would be useful infrastructure 
> > we could supply to plugin authors.
> 
> if we were to do this, i would say it should supercede/deprecate use of
> most stuff we currently have in utils.pm (that is the "settings" in
> utils.pm would be moved out).  
> 
> *but*... i still have strong reservations about this.  could you comment
> on the other proposal that was brought up about reading extra cmdline
> arguments are stored in a file?  i think that's a lot simpler, is just
> as general (more, even), and doesn't involve introducing a new point of
> configuration.

You mean William's comment here? :

>> Common way to deal with this is to have option that reads additional
>> arguments from specified file, i.e. it would be:
>>     Usage: check_db_query_rowcount [-v] -q <query> -w <warn-count>
>>               -c <crit-count> [--config <config-file>]
>> where the file would contain
>>    -d <dsn> -u user> -p <pass>

It clearly _does_ involve another point of configuration, as you've still
got a new file containing configuration data; but as least it's the same
kind of configation i.e. just a new place to put arguments - is that what
you mean here?

I'm not strongly opposed to something like this if people feel it's 
significantly simpler. There are two main differences between this and what 
I proposed:

- the config file here contains just a single item, where I was suggesting
  an ini-style config allowing multiple sections. This way I guess you end
  up with a lot of little config files (arbitrarily named, I guess) 
  containing argument snippets to various plugins; my way you end up with 
  multiple sections in a single well-known config file. You _can_ use
  multiple files in my proposal if it's motivated by other factors, like
  John's comment that he'd like to separate them out by permissions, but
  it's not required. I guess if we go this way we might want to a separate
  directory (e.g. /etc/nagios/plugins) to prevent these configs cluttering
  up the main nagios directory

- this way uses plugin arguments directly, where I was suggesting using 
  arbitrary name-value pairs that then get mapped back to plugin arguments.
  Using plugin arguments directly is simpler, but it means that each config
  is tightly coupled to a particular plugin's argument set - if another 
  plugin also wants to connect to that same database but happens to use 
  -P for password, you need to duplicate your config details, with all the
  associated maintenance issues. So I think the extra level of indirection 
  is worth it, but it's clearly arguable both ways.


Cheers,
Gavin