Inherited custom object vars using definitionsinresource.cfg

Steffen Poulsen step at tdc.dk
Tue Oct 9 15:46:13 CEST 2007


Hi,
 
Thanks for the detailed reply, Tony - the original reponse from Ethan must have escaped my mailbox, sorry.
 
I am not comfortable patching nagios, but I might be able to do an errata for the manual - I will look into it.
 
Best regards,
Steffen Poulsen


________________________________

	Fra: nagios-devel-bounces at lists.sourceforge.net [mailto:nagios-devel-bounces at lists.sourceforge.net] På vegne af Anthony Montibello
	Sendt: 9. oktober 2007 15:20
	Til: Nagios Developers List
	Emne: Re: [Nagios-devel] Inherited custom object vars using definitionsinresource.cfg
	
	
	I do not think it is a bug, have you reviewed the manual?
	 
	It has been a while since I read the manual, However I thought the manual was clear about using custom variables.
	Also I thought the manual is clear that the object definitions have a discrete number of published fields and they cannot be expanded in the way you desire.
	 
	I would suggest you patch Nagios to handle this at your organization, then submit the patch, as a feature request or patch. 
	 
	Please note: that the original response from Ethan; He is the primary developer of Nagios.  
	His comments represent that he did not believe this was a bug. but was per spec.
	 
	 
	Good luck,
	 
	TOny (author of NC_Net) 


	 
	On 10/9/07, Steffen Poulsen <step at tdc.dk> wrote: 

		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 <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/
		_______________________________________________ 
		Nagios-devel mailing list
		Nagios-devel at lists.sourceforge.net
		https://lists.sourceforge.net/lists/listinfo/nagios-devel 
		


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20071009/0f888e5a/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
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/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list