Magnus Fromreide wrote:
>On tor, 2006-11-30 at 16:35 -0500, Dana Burns wrote:
>
>
>>If one was to implement the snmp-community-mib, would the following be a
>>reasonable approach?
>>
>>
>
>I do not like it.
>On the other hand it should be noted that I think net-snmp is altogether
>to tangled up in abstraction levels already.
>
>
Be that as it may, I was working with existing code structure, rather
than swimming
against the tide. Defense of a large succesful project struggling to
move a codebase forward could be taken up in a separate thread.
>
>
>>- define formats for new snmpd.conf directives for each of the
>>implemented transports corrosponding to
>> the nonVolatile com2sec rows, e.g. comm2SecUdp, comm2SecUdp6,
>>comm2SecUnix, or a single
>> "commCommunity" with bits to specify the transport info (extensible?)
>>
>>
>
>Possibly.
>Could you elaborate on why the com2sec, com2sec6 and com2secunix items
>already in the vacm module aren't useful? Maybe this should be included
>there?
>
>
Consider the differences between "group" and "vacmGroup", "access" and
"vacmAccess", etc... The formers are written by human admins and end up
being
of permanent storageType, while the latters are written by snmpd itself
in its'
persistent store and end up being nonVolatile. Shouldn't there be
a corrosponding latter form to the com2sec former form?
>
>
>>- in each snmplib/snmp{UDP,UDP6,Unix}Domain.c, add a call to
>>register_app_config_handler(),
>> e.g. "comm2SecUdp", comm_parse_com2secUdp
>>
>>- for a given transport, whenever *either* config parser finsihes
>>succesfully, set a "changed" flag (see blow)
>>
>>
>
>This feels odd - the purpose of the *Domain.c files are to provide
>transport services, nothing else.
>
>
That sounds right. I imagined that they may have ended up there because
no community mib
had been implemented yet, and maybe there was some future plan to migrate?
Your point is well taken. Let me rephrase my question. By "reasonable",
I mean to
say, "would this be a good step towards the best and most fully
compliant implementation",
and perhaps that is an unfair question. Now to be more concrete:
There are currently separate com2sec, com2sec6 and com2secunix directives.
Transport-specific com2sec's seem subtly different than rfc2576
snmpCommunityEntry's.Specifically, they "punt" on the whole transportTag
thing
by containing elements appropriate for each, i.e.
udp: ulong network, ulong mask
udp6: struct sockaddr_in6 network, struct sockaddr_in6 mask
unix: char sockpath[sizeof(struct sockaddr_un)], unsigned long pathlen
My approach was a "backfilling" one. Would then a "best" approach be to
have one central com2sec list with additional elements referencing
targetAddrTable
(and snmpTargetAddrExt) data-store elements somehow, rather than
containing transport-
specific elements? One needs to think through how the auth-checking maps
back the
other way, and how the "parse_simple" config directives would be
effected (i.e.
"rocommunity", "rwcommunity" etc...)
>Additionally I do consider all transports equal so I'd like to know why
>the TCP, IPX, AAL5PVC, etc. transports should be excluded?
>
>
I didn't mean to sound like I was excluding them by listing the short
list of example transports.
The should not be excluded. The better question is, should they be required?
>
>
>>- add a new agent/mibgroup/mibII/comm.c that would
>> - have the requisite config_*() stuff
>> - call the various (new)
>>
>>
>
>Seems reasonable.
>
>
>
>>snmplib/snmp{UDP,UDP6,Unix}Domain.c:store_comm_{udp,udp6,unix}
>> - have the REGISTER_MIB("mibII/comm...",var_comm_) init stuff
>> - implement the mib access routines var_comm_..., write_comm* etc...
>> which check the above flag to see if the community list needs
>>to be rebuilt from the various
>> transport -specific com2sec lists. I think this is needed
>>since a read-config could have been
>> done without us knowing and we need to get the ordering of
>>our community list right
>>
>>
>
>As there is a callback that informs when a read_configs is done I fail
>to see how we could miss it.
>
>
If you mean the register_app_config_handler("com2sec",
netsnmp_udp_parse_security,...
that is done in each transport-specific module. I wasn't clear about
this, but what I was
imagining, was a central non-transport-specific list of com2sec's, in
addition to (and largely
duplicating) the separate lists that would still be maintained in the
transport modules.
Again, just a step towards "best".
If there is some mechanism that simply notifies when read-config's are
done, it would
be better to take the expected hit at that time rather than during the
next snmpget/set.
>
>
>>- snmplib/comm.c seems like the right place to put the list, i.e.
>>comm_{get,create,destroy}CommunityEntry...
>> This "layer" would in turn call the various
>>snmplib/snmp{UDP,UDP6,Unix}Domain.c routines as needed.
>>
>>
>
>I think that sounds dubious.
>Why can't the list be placed in mibgroup/mibII/comm.c as that is where
>it is used?
>
>
Again, I think I was unclear about the duplication of information and
the need to
keep it in sync.
>
>
>>- add an apps/snmpcomm with create and delete functions and arguments
>>for communityname, secname,
>> source, transport (or merge the last two like the snmpd listening
>>address), and optional context and
>> context engineid
>>
>>
>
>What can apps/snmpcomm do that snmpset can't do if we assume that your
>mib module is available?
>
>
Probably nothing other than conveniently packing the needed snmpsets
together?
Does snmpvacm do anything that snmpset's can not? I should go try to
construct
the equivalent snmpset's for each snmpvacm operation and answer my own
question.
In either case, I threw it into the email as an after-thought, and it is
not required.
>
>
>>I'm still working out:
>>- is this impossible to do without changing snmplib, i.e. as a dlmod()
>>module? I would need to store
>> (persistently) any nonVolatile communities myself, yes?
>>
>>
>
>I think this looks as if it would like to hook into the already present
>read_config store modules.
>Additionally the vacm module seems to hold all the data you are asking
>for so I think this should be integrated there.
>
>
Right. So maybe the larger question here, is if an extensibility
mechanism does or
should exist that causes snmpd to read/write additional directives
from/to its'
persistent store? I was assuming not, and that one would then be required to
change agent and snmplib code.
>
>
>>- where the TargetAddrExtTable data goes and how it is accessed/mutated,
>>and if/how the targetTable
>> would interact.
>>
>>
>
>That one is interesting - it seems as if it should interact with the
>maximum packet size, so a callback would be needed at about line 4874 in
>snmp_api.c - it should be a callback in order to allow decoupling of
>this module if it isn't desired in the application.
>
>As this table is supposed to augument the snmpTargetAddrTable I think
>the simplest thing would be to put the data in the same data structure
>as the snmpTargetAddrTable uses and add a secondary walk routine, this
>would also link the destinies of the tables and that seems appropriate
>here.
>
>
Maybe one could punt and make it all transport-specific ;)
Seriously, thanks for your comments, you really nailed the central issue.
Or, maybe the central issue is really about being ok with forward stepwise
progress that is not complete, because to deal with the complications
completeness
brings might make the results not worth the effort. Of course, "forward"
is an
awkward word to use when discussing community-based auth, and it is
understandable why this mib hasn't been implemented to date.
>/MF
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
