[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