On fre, 2006-12-01 at 10:20 -0500, Dana Burns wrote:
> Magnus Fromreide wrote:
>
> >On tor, 2006-11-30 at 16:35 -0500, Dana Burns wrote:


> >
> >>- 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?


Ok, I see - so your new directives will be a specialist version needed
for persistency. I think you should give them less catchy names as, as
far as I understand you, the new attributes are intended to mainly be
read and written by the implementation, so human radability is of less
concern.

> >>- 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.


I would say that shuffling bits onto network connections have so little
in common with any certain mibs that they should be kept separate.

> 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 transportspecific 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?


I do not think they should be required.
I do not even think that the UDP and Unix transports should be required.

> >>snmplib/snmp{UDP,UDP6,Unix}Domain.c:store_comm_{udp,udp6,u nix}
> >> - 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.


Sigh. I do see the code.
I would prefer to move the whole mess out of the Domain file, but now it
is as it is.

> 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.


There is such a mechanism.

snmp_register_callback(SNMP_CALLBACK_LIBRARY,
SNMP_CALLBACK_POST_READ_CONFIG,
your_callback,
your_pointer);

and then whenever the config have been reread

your_callback(SNMP_CALLBACK_LIBRARY,
SNMP_CALLBACK_POST_READ_CONFIG,
NULL,
your_pointer)

will be called.

> >>- 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.


In that case I feel assured. I was worried that it was more than
sugarcoating.

> >
> >>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.


There is such an extensibility mechanism.
Look at the doxygen documentation for snmplib/read_config.c.
There is a callback named SNMP_CALLBACK_STORE_DATA that seems to be
intended for your purpose.

> >
> >
> >>- 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.


I'll admit that I have been critizised on that ground before. :-)

/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?p...rge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders