[Nagiosplug-devel] RFC: Plugins config file (final proposal)
Ton Voon
ton.voon at altinity.com
Thu Feb 8 10:20:36 CET 2007
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
More information about the Devel
mailing list