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

[Gavin Carr]

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