Coders,
Following a suggestion from Robert, I implemented an extension to snmp.conf
that would allow host specific configuration in snmp.conf
For example a (very simple) snmp.conf could be:
defCommunity public
The idea was to extend this so one could have a single snmp.conf and the
default community could be overridden based on the hostname.
When writing the code I saw there were a couple of ways to implement this
(both with pro's and con's). I implemented (3) because I thought it looked
like the best solution, given the pros and cons outlined below.
Any preferences for which path the choose (or maybe objections against doing
this) ?
Cheers,
-- Geert
1. Overload the context in snmp.conf
====================================
Example:
defCommunity public
[myhost1]
defCommunity whatever
[myhost2]
defCommunity whatelse
PROS:
- Looks natural
- Multiple options can be specified in a single block.
CONS:
- In case someone has a host called [snmp] or another hostname that would
clash with an existing context problems will occur
- For each directive we want to support, additional handlers will have to be
installed.
The implementation:
- After determining the hostname, add handlers for the [hostname] context
for each of the directives we would like to support to be overridden.
- After the [hostname]->directive has been hit in the config file, call the
parser for [snmp]->directive and reregister the [snmp]->directive with a
stub. Removing the old registration is done so the [hostname] section can
appear before the default [snmp] section. We have to reregister the
[snmp]->directive so parsing errors are suppressed).
2. Add an "Override" directive
==============================
Example:
defCommunity public
Override myhost1 defCommunity whatever
Override myhost2 defCommunity whatelse
PROS:
- No host collision possible
- Only one handler needs to be installed (the one that listens for
Override), but that handler will be called and needs to validate the
hostname for each line.
CONS:
- Doesn't look very intuitive
The implementation:
- Add a default handler for Override
- When Override is called, compare it with the hostname and see if the
Directive is supported for override
- If host matches and override is supported, then call the parser for the
[snmp]->directive
(Similar logic for making sure the Override line can appear anywhere in the
file)
3. Add a "magic" directive
==========================
Example:
defCommunity public
<myhost1> defCommunity whatever
<myhost2> defCommunity whatelse
PROS:
- No host collision possible
- Only one "magic" handler needs to be installed (the one crafted by
concatinating "<".hostname.">")
- The "magic" handler only needs to forward to config line to the
[snmp]->directive parser.
CONS:
- Need to modify the tokenizer, so that warnings are suppressed for tokens
starting with "<" (therefore I call it magic). The reason is that only the
directive for that specific host will be active, and the others will
otherwise be considers errors in the config file.
The implementation:
- Add a handler for "<".hostname.">"
- When handler is called, check if directive is suppored
- If directive is supported, then call the parser for the [snmp]->directive
(Similar logic for making sure the <hostname> line can appear anywhere in
the file)
-------------------------------------------------------
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
