[Nagiosplug-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros)

[John P. Rouillard]

In message <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD at altinity.com>,
Ton Voon writes:

>I'm trying to wrap up this RFC from October last year (http:// 
>thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we  
>can have some text written in the developer-guidelines before  
>starting work on implementing it.
>
>This is a summary of the thread on it. I think I have all the angles  
>covered, but please let me know if not.
>
>
>PROBLEM
>
>There are security issues with passing user authentication  
>information into some plugins via the command line. We would like the  
>use of configuration files, secured at the file level, allowing  
>configuration variables on a per-plugin basis.
>
>PROPOSED SOLUTION
>
>A new option is allowed: --extra-opts. The idea is this option is  
>"replaced" with configuration options within a configuration file.

Well, one thing that was discussed on the nagios list for nagios 3 was
the ability to use host object specific macros
(e.g. _snmp_community=private) to keep this data associated with the
host as different hosts may have different info. My idea was to flag
some of these macros to be sent on stdin and not passed in the
environment. So the plugin would get:

  _snmp--community=private
  _snmp--username=fred

on standard in to set '--community=private' and '--username=fred'.

Could the RFC be extended to allow:

  --extra_opts=-

that will read on stdin lines of the form above and parse them using
the last -- seperated segment as the option name.

It seems that there is a 1:1 correspondance between arguments to a
plugin and the host object macro so that each macro would be used for
only one plugin invocation. If there was a case where the same
username had to be passed as various parameters: --name, --username,
--account etc for different plugins then a small shell filter could be
used:

   define host {
      name foo
      _admin-login-account nagios
      ...
   }

   define command {
     command_line filter mysql | check_mysql --extra-opts=- ....
     ...
     command_input _admin-login-account
     }

   define command {
     command_line filter snmp | check_snmp -v 3 --extra-opts=- ....
     ...
     command_input _admin-login-account
     }


where "filter" is responsible for changing an input value of:

  _admin-login-account=nagios

to '--username=nagios' when given the "mysql" argument,
'--secname=nagios' when given the argument snmp etc. (or we may be
able to define some mapping mechanism that can be done by nagios
without the need for the filter:
e.g. secname=$_admin-login-account(default)$ would produce
secname=nagios if _admin-login-account is defined for the host or
secname=default if the mcro is undefined.)

Being able to inherit this info from nagios means that managemnt
interfaces developed for nagios can display (and change) this info
without having to develop an add on mechanism. The data is kept with
the host allowing nice printouts of the data and automatic generation
from higher level management tools (e.g. inventory databases).

Granted using --extra-opts=$HOSTNAME$ also allows for per host
definitions files, but being able to use the nagios provided
capability when they are available would also be a big win.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.