Dave> I like the idea of having host-specific configuration, but I'm not
Dave> at all keen on this syntax. I very rarely remember that we support
Dave> this "[snmp]" trick, never use it, and have no idea how you'd switch
Dave> back to "common" settings.
Robert> I think the idea would be that these 'overrides' would go in the
Robert> bottom of the file.
You might expect that, but never underestimate the power of the
Net-SNMP community to surprise you :-) Unless it's very clearly
documented that such entries *must* go at the end, then the need
is bound to arise
(e.g. "echo new global directive >> snmpd.conf" )
In fact, having now checked the 'snmp_config' man page, I see that
the context can be switched back to the original value using
some app-specific directives
[snmp]
some library directives
[app]
some more app-specific directives
which is a fairly obvious approach, I suppose.
It raises the question of what would/should happen if you changed from
app1 -> snmp -> app2
in the course of a single config file, but I digress.
In the context of this host-specific idea, that widens the potential
for confusion and clashes. If I develop a management application
"netman" which runs on a host "netman", with a backup copy running
on "netman2" - how should the following structure be interpreted:
netman.conf
-----------
app-specific directives
[snmp]
library directives
[netman]
app- or host-specific directives?
If this file is present on the host "netman2", should the last block
of settings be applied (treating [netman] as an application-context
specifier), or not (treating it as a host-context specifier) ?
At the very least, there needs to be some way to distinguish between
the two.
Dave> I'd like to propose a fourth alternative, [...] to use a separate config
Dave> file(with the usual syntax) - using the hostname as a suffix.
Robert> Ugh. I did consider that, but don't like it for several reasons.
Robert>
Robert> 1) I don't like the multiple path searching in the first place
Tough!
There are many things about this project that I don't like either,
but have just had to accept. Life's like that - get used to it.
:-) :-) :-)
Robert> 2) for lots of hosts, adds to the proliferation of lots of tiny files
Most of which don't actually have to be present on every system.
Robert> 3) extending it to the applications means ever more files to search
Robert> for (snmp.conf, snmp.conf.myhost1, snmptrapd.conf,
Robert> snmptrapd.conf.myhost1,
Not to mention the other files that effectively implement very similar
functionality already ( snmp.conf.local, snmptrapd.conf.local )
A 'file.conf.hostname' approach is in line with the model we currently use.
Robert> what I'd consider to be the normal case (a dozen or so hosts),
Robert> jumping around stating files in multiple directories is probably
Robert> more overhead than a few extra lines in snmpd.conf.
I'd actually question that.
What is the actual cost of 'stat'ing a file?
I'd be surprised if it was significant - particularly not when compared with
the amount of processing that the suite does already (all those MIB files!)
Another problem with all three "in-line" approaches is that they don't
really scale very well to "identical subsets" of machines.
I've got two or three dozen student Linux boxes to look after, and a
similar number of staff systems. The student boxes are all meant to be
configured identically, and the staff boxes are mostly very similar as well.
It's much easier for me to take a single file and push it over to several
machines (changing the name as I do so), than to repeat the same block
of configuration settings several times. It's also easier to maintain
if I have to tweak these settings, or add in a new machine.
Plus it means almost no new code to write or (more importantly) maintain.
Dave
-------------------------------------------------------
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
