> 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: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]