[Nagiosplug-devel] [RFC] Plugins config file

Gavin Carr gavin at openfusion.com.au
Tue Oct 17 04:56:08 CEST 2006


On Mon, Oct 16, 2006 at 12:24:40PM -0400, John P. Rouillard wrote:
> In message <20061016111350.GB15099 at openfusion.com.au>,
> Gavin Carr writes:
> >This must be a problem for lots of other kinds of plugin too - 
> >anywhere you need to pass any kind of secret to a plugin. Is there a
> >good way of dealing with this that I'm not aware of?
> 
> The way I do it is to use a small shell script to parse a password
> config file and create a temp file. Then I pass the temp file to the
> plugin. Obviously this works only with my own plugins, but it does
> allow formatting and other changes. E.G. I can:
> 
>     pass URL's in a file
>     create curl config files
>     create user:passwd authentication formatted entries
> 
> and the input file tries to reuse plugins's normal authentication
> mechanism setting the internal variable from a file rather than on the
> command line.
> 
> Also I can run the command inside a here document in a shell script and
> pass password info on stdin to the plugin if it accepts it.
> 
> wget -i << EOE
> https://`getpw /password/cache -`@example.com/ 
> EOE
> 
> which doesn't leave authentication info in the environment or on the
> command line.

Nice - that's more flexible, at the price of some additional complexity.

> >My suggestion is that we introduce a config file specifically for use
> >by plugins (e.g. /etc/nagios/plugins.cfg or 
> >$NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we 
> >don't want to have to pass at the command line. Perhaps an INI-style 
> >format would make sense, with per-plugin sections, or arbitrary 
> >section names specified explicitly e.g.
> >
> >  [ check_db_query_rowcount ]
> >  dsn = db:Pg:database=foo
> >  user = fred
> >  pass = secret
> >
> >or perhaps if I want to check multiple different databases, or share
> >the credentials across plugins:
> >
> >  [ foo_db ]
> >  dsn = db:Pg:database=foo
> >  user = fred
> >  pass = secret
> >  
> >Then my plugin could have a usage pattern like this:
> >
> >  Usage: check_db_query_rowcount [-v] -q <query> -w <warn-count> 
> >            -c <crit-count> [--auth=<auth-section>]
> >
> >where auth-section might default to the plugin name if not specified
> >(and the plugin would fail if an appropriate auth section could not 
> >be found).
> 
> Sounds like a good idea and it should be simple enough to code in
> perl, C, Bourne shell and python for starters. What may be better is
> for the <auth-section> to be:
> 
>     auth-section:/path/to/auth/file
> 
> since I can see multiple auth files for different people to
> maintain (e.g. oracle db's maintain the password for the test users
> using on their databases).

I agree. The perl api I've mocked this up in allows you to specify both
section and file.

Cheers,
Gavin





More information about the Devel mailing list