[Nagiosplug-devel] RFC: Plugins config file (final proposal)
Gavin Carr
gavin at openfusion.com.au
Fri Feb 9 00:09:04 CET 2007
On Thu, Feb 08, 2007 at 09:20:36AM +0000, Ton Voon wrote:
> 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.
Okay, sounds reasonable.
> I'm not too fussed about location. ${config-prefix}/nagios-plugins/
> plugins.ini sounds as good as any.
What are some typical ${config-prefix}-es? i.e. what would a full-path
look like?
And as an aside, how do I source ${config-prefix} on the perl side?
> >> 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.
Ah, ok. I read it like Sean, and have coded things so far to always
load the defaults if a [plugin] section exists. I think with Sean I
slightly prefer that reading, but it does mean you need a way of turning
that off. I don't much mind though - which way do you want to go?
> >> 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).
I'm certainly advocating 'move-to-front' - that was the main thing I
didn't like with your (1).
> 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.
Yes, I like (3).
> 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).
Yes, I agree with you. I'm fine with order preservation, as long as we
do move-defaults-to-front first.
So +1 from me for (3) + order preservation.
> 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.
Other opinions?
Cheers,
Gavin
More information about the Devel
mailing list