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

[Ethan Galstad]

John P. Rouillard wrote:
> 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

I prefer using the proposed config file solution to store passwords, 
etc. over the idea of passing this info via stdin.  In my opinion, the 
config file option is a much simpler/elegant solution.

It requires no mods to the Nagios daemon or plugin API.  Super-secret 
info can be stored in the config file and locked down with standard file 
permissions.   And a standard library/function set can be created to 
allow Perl/C plugins to grab their appropriate entries out of the config 
file.

Now that I'm thinking about it, this type of file format seems like it 
must be used by a number of apps.  There's probably a GPL'ed library out 
there that can read/write config entries to a file in the proposed format.

As for loosing the ability to keep private information in the Nagios 
host/service definitions...  I guess that's a good reason to make sure 
the monitoring server isn't used by normal users.  If its a dedicated 
box, it shouldn't matter what information is being passed on the command 
lines between the daemon and the plugins.


Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org