>>>>> On Sat, 22 Oct 2005 17:44:06 +0100, Dave Shield <[EMAIL PROTECTED]> said:
Dave> A few comments regarding these directives: >>> authuser log,execute,net wesx Dave> That could presumably default to 'authNoPriv' Dave> (by analogy with r[ow]user) It does, in fact, because it's the same parsing code as the rouser etc. That code was actually modified slightly and is called after the parsing of the log,execute,... token. >>> authcommunity log onlycold * .1.3.6.1.6.3.1.1.5.1 Dave> (or similar) could be used to specify a particular OID Dave> subtree, but with any remote source. We use the current mechanism. So whatever is allowed now for rocommunity hasn't changed. I think it's "any" or something like that? I forget. I wasn't planning on changing that... Dave> It might also be useful to specify a named view Dave> (rather than an OID subtree). Perhaps something like >>> authcommunity -v someView log onlycold [localhost] If you want to do that use the regular forms of vacm tokens (which you're welcome to rewrite if you don't like them). This one is just a wrapper in the same way that the old ones (rocommunity...) were. They easily wrap a single call into multiple VACM calls, each call sets up a new secname, a new group, a new access binding, and new views. Even if there are duplicates already. This is documented where it says if you want to do more complex settings you should learn to use the other more powerful tokens. Dave> That's fine - but I'd like to see if we could stretch them to Dave> cover 97 or 98% of cases :-) Feel free! In my opinion, binding multiple calls together means determining which existing views/etc need to be attached to and it's quite a bit more work (which is why I didn't go that route for the original rocommunity lines). i think you're real issue is not the wrappers, but your issues with usability of the more powerful vacm tokens and you probably should address those issues instead to make them more powerful? I don't mind adding extensions to the current stuff too, but my question left is do you have any issues that you see needing fixed with the current ones? IE, everything else you're saying now is down to extensions to the existing old or new ones right? -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
