On Wed, 06 Oct 2004 10:02:44 +0100 Dave wrote:
DS> Geert> 1. Overload the context in snmp.conf
DS> Geert> ====================================
DS> Geert> Example:
DS> Geert> defCommunity public
DS> Geert> [myhost1]
DS> Geert> defCommunity whatever
DS>
DS> Robert> This is what my original idea was, and I like it better than
DS> Robert> the other two. Not only does it match our exising conf file
DS> Robert> special tokens, the idea of a header is fairly common in conf
DS> files.
DS>
DS> I like the idea of having host-specific configuration, but I'm not
DS> at all keen on this syntax. I very rarely remember that we support
DS> this "[snmp]" trick, never use it, and have no idea how you'd switch
DS> back to "common" settings.
I think the idea would be that these 'overrides' would go in the bottom of the
file.
DS> I'd also question whether this is common in conf files anyway.
DS> It's common in the Windows world, sure - but I can't recall coming
DS> across it much in Unix-based applications.
DS> (A quick bit of poking around reveals that KDE uses this style,
DS> but Gnome uses XML-based syntax).
I also found several examples in etc ('grep -E "^\[" /etc/*') on my redhat box.
DS> I'd like to propose a fourth alternative, [...] to use a separate config
DS> file(with the usual syntax) - using the hostname as a suffix.
DS>
DS> snmp.conf
DS> ---------
DS> defCommunity public
DS>
DS> snmp.conf.myhost1
DS> -----------------
DS> defCommunity whatever
DS>
DS> That's a technique we've been using for years, and would really only
DS> require a minor tweak to the code for building the config search path.
DS> It wouldn't need any changes to the config parsing code.
Ugh. I did consider that, but don't like it for several reasons.
1) I don't like the multiple path searching in the first place
a) more overhead, testing for another file in every directory
b) multiple possible locations for files is too confusing
2) for lots of hosts, adds to the proliferation of lots of tiny files
3) extending it to the applications means ever more files to search for
(snmp.conf, snmp.conf.myhost1, snmptrapd.conf, snmptrapd.conf.myhost1
The only benefit, I will begrudgingly admit would be that with a large number
of hosts, having them all in a file that is parsed by all the tools might
impact performance. But for what I'd consider to be the normal case (a dozen
or so hosts), jumping around stating files in multiple directories is probably
more overhead than a few extra lines in snmpd.conf. And for what would
probably be the most common case (no special config), there is no overhead at
all.
DS> Of the three "in-line" approaches, the "[host]" is the least worst,
DS> but I question whether it would be appropriate to adopt this for the
DS> 5.2 release. But using a separate config file should be safe enough.
This one has been on my to-do list long enough that I'd really like to see it
go in. I have seen Geert's code for this particular feature, but based on his
udp-buffer patch, I expect it to be well written and tested.
I also think it is a great feature for the users (the people who use snmp a
lot, and are conscious enough to not use a public community for all their
hosts).
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
