> Dave> So I presume we're looking at 5.3.pre1 being next Friday,
> Dave> rather than tomorrow then? Which suits me fine - I just
> Dave> wasn't sure what had been decided.
>
> I think I can have it done by tomorrow.
Yes - but the rest of us need some time to look at what you've
done, and offer our input. I don't think it's fair to add
this sort of new functionality, and then *immediately* go into
pre-release mode.
> Dave> a) the code used to implement this filtering
> Dave> b) the configure directives used to control it (locally)
> Dave> c) the MIB interface used to control it (remotely)
> I don't plan on hitting (c) by tomorrow. I think remote access can be
> done later. Sure, it'd be nice to have deployed at the same time but
> there is no technical reason why it can't come later and thus delaying
> the other benefits doesn't seem worth it.
Yup - that sounds sensible to me.
A MIB interface is desirable but not essential, and is *definitely*
the hardest to fix problems with. We should not be trying to
rush into that. Look at the problems we've had with correcting
the relocatable "exec" MIB structure - which isn't even valid!
I'd have been *very* uncomfortable about trying to do (c) in time
for 5.3.
> b) I'll post a better list of tokens a bit later. But functionally:
>
> A new token for setting access for a single acm entry:
>
> Previously we had this:
> access name context model level prefx read write notify
> I'd be adding this:
> setaccess name context model level prefx viewname viewval
> where view name would be one of read, write, notify, log, execute, net
Hmmm....
I see the idea, and it's probably OK-ish.
But I can't help feel that we've tended to be too constrained
by the structure of the VACM MIB tables.
I'd suggest that we should be trying to make the configuration
as simple as possible for the most common cases, and keep things
as natural and consistent as possible.
Most of the fields listed above tend to have the same fixed
values in 99% of "access" lines. So why not let them default
to the normal values, and only specify them when they're different?
Either using optional positional parameters (just re-ordering the
fields above), or (better) using the equivalent 'snmpcmd' options?
For example:
setaccess read publicName
setaccess write privateName -l auth
setaccess execute adminName -Cn context
setaccess log _all
> And there would be wrapper tokens equivalent to the rocommunity like
> tokens to quick-create access for a given community for a given type
> (eg "logcommunity").
That's one approach, certainly.
An alternative would be to generalise the xxCommunity directive:
community read-only public
community read-write private
community execute admin
community log _all
It's still one line, and would avoid a proliferation of new
configure directives.
> Dave> The other relevant question is how much granularity are
> Dave> you planning for the initial 5.3 release?
> Filtering on the actions called for an incoming trap. IE, the
> community of "public" may only be granted the right to log it but not
> execute. The snmpv3 user "wes" might be allowed to do all actions.
Ummm.... OK. I was slightly surprised you didn't have a
"pre-decision" filter as well:
"Non-authenticated traps won't be processed at all"
But I s'pose that's effectively the same as not listing
them in any of the "post-decision" filters. I think....
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
