[Nagiosplug-devel] [RFC] Plugins config file

[sean finney]

On Wed, 2006-10-18 at 09:43 +0100, Ton Voon wrote:
> 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.

this was one of my biggest concerns.  if the most of the configuration
sections mapped directly to plugin arguments i don't think i'd have any
objection to them.

however, if we are going this route, it might be worth discussing if we
can migrate/consolidate/remove the utils.pm settings as well.

> 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").

just for the record, i don't think you'd actually have to worry about
this, since the arguments are never seen by the shell.

> 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).

if we could configure the default location of this file at ./configure
time it would be extra nice for packagers.

> 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.

agreed.

> 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!).

yes, this sounds very nice.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20061018/ae9d65cc/attachment.sig>