Inherited custom object vars using definitions inresource.cfg

Steffen Poulsen step at tdc.dk
Tue Oct 9 10:41:30 CEST 2007


I would like to report this as a bug - what is the proper procedure?

Best regards,
Steffen Poulsen


> -----Oprindelig meddelelse-----
> Fra: nagios-devel-bounces at lists.sourceforge.net 
> [mailto:nagios-devel-bounces at lists.sourceforge.net] På vegne 
> af Steffen Poulsen
> Sendt: 1. oktober 2007 16:05
> Til: Nagios Developers List
> Emne: [Nagios-devel] Inherited custom object vars using 
> definitions inresource.cfg
> 
> 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
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

-------------------------------------------------------------------------
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/




More information about the Developers mailing list