It's a very good idea too.=20
It shouldn't be very difficult to implement this using my patch, but =
what
I've done already is enough for me (I just need snmp info). As very few
people (you and me ?) are interested by this kind of feature I won't go =
any
further.
Patrick
nagios AT proy.org
> -----Message d'origine-----
> De : [email protected]=20
> [mailto:[email protected]] De la part=20
> de Michael Medin
> Envoy=E9 : mercredi 12 janvier 2005 09:42
> =C0 : Andreas Ericsson; Patrick Proy
> Cc : nagios-devel
> Objet : RE: [Nagios-devel] RE: SNMP community in host=20
> configuration (add a generic userarg command ?)
>=20
> Hi,
>=20
> How about adding some form of prefix to settings like:
>=20
> define host{
> ...
> userargs MYOWNKEY "This is a value"
> ...
> }
>=20
> That gets translated into: $MYOWNKEY$ when a command is executed?
> That would allow people that have a need for user settings to=20
> use them and still not fill up the namespace. I know this=20
> might be useful for me as I have certain keys that are used=20
> changing based on "host groups" (read templates). For=20
> instance snmp community strings (and for that matter=20
> authorization tokens). Then I could derive all hosts using a=20
> certain snmp community from the same template? Also along=20
> this line something I have been wanting is "multiple=20
> inheritance" (don't laugh
. This would allow me to cross=20> 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=20
> same support group).
> 2, check frequency (test/verification systems need to be=20
> check less then ones that are serving users).
>=20
> This is two aspects that could be inherited but are distinct=20
> (as in not the same) as we have notes-servers that are test=20
> and ones that are serving users. We also have the same=20
> aspects on other server groups.
>=20
> Now this might be possible already (haven't tired, I just=20
> assumed that it couldn't be done)
>=20
> If it sounds like a reasonable thing to do I could look into=20
> implementing it for nagios 2.0 but if it just me being=20
> deluded I can also manage this in my config files
>=20
> // Michael Medin
>=20
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf=20
> 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
>=20
> Patrick Proy wrote:
> > Hi,
> >=20
> > Did anybody test the patch ?=20
> >=20
>=20
> Like I told you before you went along hacking up this patch,=20
> it addresses a very limited usergroup. I believe most=20
> networks have at the most two or three snmp=20
> communities/username-password-pairs.
>=20
> >=20
> > Patrick
> >=20
> >=20
> >>Envoy=E9 : mardi 21 d=E9cembre 2004 16:04
> >>=C0 : '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=20
> >>$SNMPCOMMUNITY$ macro.
> >>
> >>- Changed the "hostuser" macro in "hostmacro" :=20
> >> - in host/template definition : "hostmacro SomeData"
> >> - In services : "$HOSTMACRO$"
> >>
> >>- In nagios.cfg, the option is now named "host_snmp_login", same=20
> >>syntax.
> >>
> >>As usual, feedbacks are welcome !
> >>
> >>Patrick
> >>nagios AT proy.org
> >>=20
> >>
> >>>How to patch :=20
> >>> - 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=20
> >>>specific, it should be OK.
> >>>Here are the modified files (if a new CVS version is out) :=20
> >>>-
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]