Inherited custom object vars using definitions in resource.cfg

[Ethan Galstad]

Steffen Poulsen wrote:
> Hi, 
> 
> We would like to utilize resource.cfg for holding secrets, and we are
> trying to do something like this:
> 
> Passwords in resource.cfg:
> 
> $USER20$=secret1
> $USER21$=secret2
> 
> Each host use one of the passwords in hosts.cfg:
> 
> define host {
>         use                 generic-host
>         host_name           host1
>         alias               host1
>         address             ip1
>         _snmp_community     $USER20$
>         }
> 
> Services use the community in services.cfg:
> 
> define service {
>         use                 generic-service
>         host_name           host1
>         service_description snmp_check_load
>         check_command       check_snmp_11187
>         }
> 
> define command {
>         command_name          check_snmp_11187
>         command_line          $USER1$/check_snmp -H $HOSTADDRESS$ -C
> $_HOSTSNMP_COMMUNITY$ -o .1.3.6.1.... -w 70 
>         }
> 
> But $_HOSTSNMP_COMMUNITY$ appears to be not set once it reaches the
> command_line?
> 
> Using something like this (defining the password directly in hosts.cfg,
> without going through resource.cfg):
> 
>         _snmp_community     secret3
> 
> Appears to work ok - so what is hindering the other approach? Is there
> an undocumented expansion order preventing the hierarchical use? And,
> more importantly - is this per spec or in error? :-)
> 
> Best regards,
> Steffen Poulsen
> 

Custom variables are not currently pre-processed to see if they contain 
other macros.  This could add to overhead, so I'm not sure if it would 
be good idea to add support for it.  You could use a command definition 
like this to achieve the same functionality:

define command {
	command_name          check_snmp_11187
	command_line          $USER1$/check_snmp -H $HOSTADDRESS$ -C $USER20$ 
-o .1.3.6.1.... -w 70
	}


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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/