Wes, I'm getting the impression that you may have slightly misunderstood my objections. I quite recognise the need for some form of protection for the trap daemon. And having looked briefly at the new VACM code, I think you've come up with a very sensible framework. I haven't looked at the trapd code yet, but I've already got various ideas about how this new mechanism could be used. This definitely addresses my comments from a month or so back.
You're quite correct - my concerns this time round have basically been focused on the configuration tokens. As long as we can get those right, any internal changes should be effectively transparent to the user. Wes> I've now done this which I think should make you happier: >> createUser wesx MD5 abcdefgh DES >> authuser log,execute,net wesx noAuthNoPriv >> authcommunity log,execute supercomm >> authcommunity log onlycold localhost .1.3.6.1.6.3.1.1.5.1 Yes - that's much better. I've some minor suggestions (see below), but they're really just tweaks to a sensible basic model. Wes> The host name specifications don't quite do what they're Wes> supposed to yet. .... But it leaves Wes> the flexibility you want Yup - that's fine. Future development would just be filling in the gaps there. Wes> I left "auth" in front of the tokens because I think it's Wes> more descriptive. Fair enough. I wouldn't have done it quite the same way, but I can live with that. A few comments regarding these directives: >> authuser log,execute,net wesx That could presumably default to 'authNoPriv' (by analogy with r[ow]user) >> authcommunity log onlycold * .1.3.6.1.6.3.1.1.5.1 (or similar) could be used to specify a particular OID subtree, but with any remote source. It might also be useful to specify a named view (rather than an OID subtree). Perhaps something like >> authcommunity -v someView log onlycold [localhost] What about applying this to groups? Maybe something like: >> authgroup log someGroup ?? Wes> IMHO, I don't think we should bend *too* far to make it Wes> significantly easier for the user. We shouldn't sacrifice full flexibility for the sake of easier directives, certainly. But I don't see the point of deliberately making things harder to use than need be! Wes> The convenience wrappers are for the 95% cases where they Wes> don't need anything too powerful. That's fine - but I'd like to see if we could stretch them to cover 97 or 98% of cases :-) Wes> sorry if I was a bit short earlier. No problem - you've been on the receiving end of several Shield tantrums in the past! Dave ------------------------------------------------------- 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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
