> Hi,
>
> How about adding some form of prefix to settings like:
>
> define host{ ... userargs MYOWNKEY "This is a value" ... }
>
I believe something along those lines is scheduled for later inclusion
by Ethan. I don't know when though, but I suppose it'll be on a rainy day.
> That gets translated into: $MYOWNKEY$ when a command is executed?
> That would allow people that have a need for user settings to use
> them and still not fill up the namespace. I know this might be useful
> for me as I have certain keys that are used changing based on "host
> groups" (read templates). For instance snmp community strings (and
> for that matter authorization tokens). Then I could derive all hosts
> using a certain snmp community from the same template? Also along
> this line something I have been wanting is "multiple inheritance"
> (don't laugh
.I believe the docs say that objects can use several templates (I know
templates can use other templates, so it can be done anyway). Poke
around and try a little.
> This would allow me to cross inherit settings from
> various classes. To make an example of what I mean: A server have
> different aspects: 1, contact settings (all our notes servers are
> "owned" by the same support group). 2, check frequency
> (test/verification systems need to be check less then ones that are
> serving users).
>
> This is two aspects that could be inherited but are distinct (as in
> not the same) as we have notes-servers that are test and ones that
> are serving users. We also have the same aspects on other server
> groups.
>
> Now this might be possible already (haven't tired, I just assumed
> that it couldn't be done)
>
> If it sounds like a reasonable thing to do I could look into
> implementing it for nagios 2.0 but if it just me being deluded I can
> also manage this in my config files
>
> // Michael Medin
>
> -----Original Message----- From:
> [email protected]
> [mailto:[email protected]] On Behalf Of
> Andreas Ericsson Sent: den 11 januari 2005 16:33 To: Patrick Proy Cc:
> 'nagios-devel' Subject: Re: [Nagios-devel] RE: SNMP community in host
> configuration
>
> Patrick Proy wrote:
>
>> Hi,
>>
>> Did anybody test the patch ?
>>
>
>
> Like I told you before you went along hacking up this patch, it
> addresses a very limited usergroup. I believe most networks have at
> the most two or three snmp communities/username-password-pairs.
>
>
>> Patrick
>>
>>
>>
>>> Envoyé : mardi 21 décembre 2004 16:04 À : 'nagios-devel' Objet :
>>> [Nagios-devel] RE: SNMP community in host configuration
>>>
>>> Hi,
>>>
>>> I updated my patch. Works with today's CVS : "patch -p0 >> patch_nag_snmp_2004.12.21.patch" :
>>>
>>> - added "snmp_community" in host/template definition, accessed by
>>> $SNMPCOMMUNITY$ macro.
>>>
>>> - Changed the "hostuser" macro in "hostmacro" : - in
>>> host/template definition : "hostmacro SomeData" - In
>>> services : "$HOSTMACRO$"
>>>
>>> - In nagios.cfg, the option is now named "host_snmp_login", same
>>> syntax.
>>>
>>> As usual, feedbacks are welcome !
>>>
>>> Patrick nagios AT proy.org
>>>
>>>
>>>
>>>> How to patch : - it work with the CVS version of 19 Dec 2004 -
>>>> in the "nagios-cvs" directory : "patch -p0 >>
>>> patch_nag_snmp.patch"
>>>
>>>
>>>> Note : only works with template based config files.
>>>>
>>>> I tested it on Linux only for now, but as nothing is platform
>>>> specific, it should be OK. Here are the modified files (if a
>>>> new CVS version is out) : - common/objects.c base/config.c
>>>> base/nagios.c base/utils.c include/common.h include/objects.h
>>>> include/nagios.h.in xdata/xodtemplate.c xdata/xodtemplate.h
>>>>
>>>>
>>>> What it does :
>>>>
>>>> 1) SNMP for each host
>>>>
>>>> You can put snmp information in three ways : - In the host
>>>> definition : snmp_version # stores snmp version
>>>> snmp_login # stores snmp login (for v3) snmp_pass
>>>> # stores snmp password for v3 or community for v1
>>>> None of them are compulsory of course - In the host t
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]