[Nagiosplug-devel] [RFC] Plugins config file

[Ton Voon]

On 18 Oct 2006, at 02:08, Gavin Carr wrote:
>>> 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.

I'm coming round to the idea of the config file - it has been well  
argued here.

I don't like the idea of having the "extra level of indirection" with  
another set of "standard" parameters (Where are they defined? Why are  
the different?). So, I think the ini file should just hold the  
current options, but in a more secure/readable format.

I don't think a file that holds:

-u username -p password

is sufficient, because if it is generalised to other arguments, shell  
quoting/expansion may cause a problem (--regex="this string").

Can I make a slight refinement to the current proposal?

Plugins that support this new config file parsing of options take the  
option (as Sean suggested) of

   --extra-opts=[configfile][:stanzaname]

The config file is ini style. You can default configfile to $HOME/ 
np.conf (or maybe /usr/local/nagios/etc/np.conf). The [:stanzaname]  
defines a stanza within the config file, otherwise defaults to name  
of plugin (maybe reserve "main" as a stanza name - this config file  
has given me some ideas for future stuff).

An example stanza:

[check_mysql]
username=tonvoon
password=secret

So running "check_mysql -S --extra-opts=" should give the same result  
as running "check_mysql -S --username=tonvoon --password=secret". If  
fact, the variable names could just be the short option form:

[check_mysql]
u=tonvoon
p=password

But I'm guessing using that long names will be preferred. I think a  
plugin invocation with -v -v should show the command line options  
with the extra parameters added in, so a user knows what has been run.

In terms of implementation on the C side, I think we could create a  
new utils function called np_getopt_long which basically calls  
getopt_long. But if it finds --extra-opts, then it reads the ini file  
and then returns parameters to the plugin as if they were from the  
command line, so there shouldn't be many changes required at the  
plugin level. This allows us to then run tests against this function  
to prove it works as expected (did I just hawk testing again? Sorry!).

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20061018/b4f88715/attachment.html>