[Nagiosplug-devel] RFC: Plugins config file (final proposal)

[Ton Voon]

Hi all,


On 7 Feb 2007, at 23:21, Gavin Carr wrote:

> And the default configuration file name is ....
>
> plugins.cfg?

I agree with Sean that the suffix should be .ini to distinguish from  
Nagios type files.

I'm not too fussed about location. ${config-prefix}/nagios-plugins/ 
plugins.ini sounds as good as any.


>> IMPLEMENTATION DETAILS
>>
>> The C routine is to be called np_getopt_long and has the same
>> interface as getopt_long (from gnulib).
>>
>> The perl routine in Nagios::Plugin will not require any changes at
>> the plugin level.
>>
>> Both the C and the perl routines do not require specification of --
>> default-opts to process that option - it is implicitly checked and
>> processed.
>
> Ok. Three things:
>
> - for packages, we probably want to make sure we ship with an empty
>   (or all commented out) config file, because otherwise I imagine  
> we'll
>   get some very confused people wondering where these 'magic' extra
>   options come from

Agreed. A commented out initial config file with some sensible  
examples is a good idea.

> - does a --default-opts=foobar override this implicit check? i.e.
>   we don't check --default-opts=plugin_name if --defauult-opts=foobar
>   is set?

Sorry, this is my bad wording in the RFC. The idea of the text is  
that a plugin developer does not have to define --default-opts using  
getopt_long or Nagios::Plugin::Getopts to have that option available  
- it should come for free, such as with --version and --help.

I can see this being okay with Nagios::Plugin, but I'm not sure if it  
is best if the C implementation does it transparently (it is  
technically possible because if you are calling np_getopt_long, this  
routine could tack on the required information). Sean?

You still need to explicitly say --default-opts= to kick the default  
options in. This provides backwards compatibility with current syntax.


> - how do we turn this off? e.g. if I've got some default options
>   defined for a random plugin in the [plugin_name] stanza, how do I
>   do a special invocation _without_ those options? I can't do
>   --default-opts=bogus, because that's an error. Do we need a
>   --no-default-opts?

So, by the above, no --default-opts= on the command line will stay  
the same with current behaviour.


>> When processing options, there needs to be a first pass to extract
>> all the --default-opts options and process the config files.
>> Duplicate config options are removed, last one wins. Any options on
>> command line will remove the default.
>>
>> Duplicates removal would include equivalent short and long options.
>> For instance, a default config file of username=manager with a -u
>> admin on command line would produce the equivalent of -u admin.
>
> I'm not sure about this duplicate removal stuff, on two fronts:
>
> 1. I think duplicate arguments might be useful sometimes. e.g. how
>    about a plugin that takes a --path argument, indicating places
>    to search for some file. Allowing multiple paths do be defined
>    additively (some default, some test-specific) seems very nice
>    behaviour.

> 2. It significantly complicates the processing, and it requires that
>    the we _understand_ the arguments (especially the shortname/ 
> longname
>    equivalence). I think it's cleaner if the default-opts handler can
>    just be dumb, load all the arguments from the config files, and
>    dump them on the front of the argv list to be processed. It's then
>    handled by the conventional argument processing as defined by the
>    plugin, rather than removed by fiat. i.e. if your plugin says
>    multiple usernames are okay, you get them all; if it says username
>    is single, the argument processing only gives you the last one.
>    Is that sufficient/acceptable?

Firstly, Config::Tiny will not allow duplicate options. I guess we  
can overcome this with a different module, or we write our own.

Secondly, this is the difference between my initial "replacement  
options" (1) idea versus the current "overrideable options" (2).

I think you're advocating a variation of "replacement options", which  
is "replacement options, default-opts moved to front" (3).


Consider this:

[check_disk]
   path=/var
   path=/home
   units=GB

./check_disk --warning=10% --critical=5% --default-opts= --path=/usr

   (1) would give: ./check_disk --warning=10% --critical=5% --path=/ 
var --path=/home --units=GB --path=/usr
   (2) would give: ./check_disk --warning=10% --critical=5% --path=/ 
usr --units=GB (order not necessarily preserved)
   (3) would give: ./check_disk --path=/var --path=/home --units=GB -- 
warning=10% --critical=5% --path=/usr (order not necessarily preserved)

With (2) where there is extra processing to remove options, I don't  
think there is a way of retaining order information. Obviously, you  
cannot preserve duplications.

With (3), duplications can be retained, but order is not currently.  
This could be done with a different ini parsing routine that pulls  
out duplicates and order.


Another, more likely, example:

[check_snmp]
   username=root
   password=secret

./check_mysql --username=fred --default-opts= --warning=10 --critical=20

   (1) would give: ./check_mysql --username=fred --username=root -- 
password=secret --warning=10 --critical=20
   (2) would give: ./check_mysql --username=fred --password=secret -- 
warning=10 --critical=20 (order not necessarily preserved)
   (3) would give: ./check_mysql --username=root --password=secret -- 
username=fred --warning=10 --critical=20 (order not necessarily  
preserved)

Note, (1) and (3) will cause different behaviour in the plugin.

Gavin, I personally agree with you that we should retain duplicates  
and pass responsibility over to the plugins. However, I also think we  
should retain order (an additional rule of moving default-opts to  
front is fine).

In the end, I don't mind which one we do. The initial use is for  
secure username/passwords, which would work in any of the  
implementations. But we do have to agree and make it consistent. I  
thought the consensus was to do (2).

However, I think it is fair to revisit a design if there are  
implementation difficulties, so I'd like any other views on this.


> <snip>
>> If default-opts is not found, return state unknown with appropriate
>> message.
>
> I think you mean 'config file' rather than 'default-opts' here.

Yes. Thanks. I haven't updated the dev guidelines yet and I'll hold  
back due to this.

Ton


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