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

[Ton Voon]

Hi!

Gavin wrote:

>> 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).
>>
> [snipped]
> So +1 from me for (3) + order preservation.

No objections in the last few days, so I think we're going with (3).  
I'll have to re-word the RFC (again) :(

I'll adapt the test cases to reflect.


On 8 Feb 2007, at 09:44, sean finney wrote:

>> You still need to explicitly say --default-opts= to kick the default
>> options in. This provides backwards compatibility with current  
>> syntax.
>
> when i wrote the routines i assumed the opposite: that the defaults
> would be read by, well, default :).  so in the current parse_ini code
> you would disable default option reading by specifying an empty
> string for the defaults location.  personally i'm more in favor of
> this because "defaults should on by default".
>
> if we're shipping a blank/commented ini file, it won't cause that
> much confusion.  oh, btw a minor detail: we should make sure that  
> "make
> install" doesn't override the default file if it already exists.  but
> in any event i'll acquiesce to the majority opinion if you guys
> disagree.  however in that case i'd suggest "--default-opts" without
> the "=" (making it an optional argument).

If we're doing (3) instead of (2), can I suggest we change the name  
back to --extra-opts? I thought --default-opts was a better name for  
(2) because of the "remove duplicates" logic, but since we changing  
to (3), --extra-opts makes sense again.

I'm thinking that this functionality is an advanced feature so  
reading of the config file should be done on demand, as opposed to  
every time.

Agree with --extra-opts without the "=" to trigger using the config  
file.


Gavin wrote:
>>> And as an aside, how do I source ${config-prefix} on the perl side?
>>>
>>
>> it would be built-in at build time.  if you were building from the
>> nagios tarball you could just use autofoo substitutions, but if it's
>> being done outside i'd probably just deafult to whatever the ./ 
>> configure
>> script would default to (one of the two directories i mentioned
>> above, i forget which).  and of course provide a way to override it
>> at build time as well.
>>
>
> The issue with Nagios::Plugin is that it's distributed via CPAN as  
> well
> as (?) via tarball/packages i.e. it won't necessarily be installed at
> regular 'build time'. So it probably needs to be a run-time thing for
> N::P - is $config-prefix available anywhere post-install at the  
> moment?

That old chicken-egg thing again :(. Looking at DBD::Oracle (http:// 
search.cpan.org/dist/DBD-Oracle/ 
Oracle.pm#Oracle_Environment_Variables), it seems they use  
environment variables to find the location of Oracle libraries.

What about using an environment variable if set. Otherwise look in a  
set of "common" locations. Given that we use the same prefix as  
nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini  
is a decent default. I guess other common locations are:
  /etc/plugins.ini
  /etc/nagios/plugins.ini
  /usr/local/etc/nagios/plugins.ini
  /usr/local/etc/plugins.ini

Or we could say you have to set the env var, otherwise fully specify  
the filename on command line.

Ton

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