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.

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

Could you elaborate on why the com2sec, com2sec6 and com2secunix items
already in the vacm module aren't useful? Maybe this should be included

> - 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.
Additionally I do consider all transports equal so I'd like to know why
the TCP, IPX, AAL5PVC, etc. transports should be excluded?

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

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

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

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

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


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
Net-snmp-coders mailing list