>>>>> On Fri, 21 Oct 2005 10:42:00 +0100, Dave Shield <[EMAIL PROTECTED]> said:
>> setaccess limitedgroup "" v2c noAuthNoPriv prefix log anything Dave> What is this access view being applied to? Dave> The OID of the trap? Dave> The OIDs of the payload varbinds? Dave> Or both? Sorry. That would be in the missing docs: currently just the OID of the trap. >> # wrapper scripts to let xyzzy community log and execute >> ipv4logcommunity -v execute xyzzy Dave> I don't understand this one. Dave> I thought you were proposing something along the lines of: Dave> logcommunity xyzzy Dave> execcommunity xyzzy Dave> A little more explanation would be useful. Well, it's not that trivial it turns out. In the same way that rocommunity and rwcommunity can't both be specified with the same community, it's true for this as well. The problem comes from the way these wrappers always assume generation of a new group as well as just the access line. ipv4logcommunity mycommunity Adds a view for allowing traps from 'mycommunity' to be logged. But adding this next: ipv4executecommunity mycommunity Will not work. This is true for snmpd rocommunity/rwcommunity as well where you can't specify rwcommunity twice with the same community and two different OIDS to merge them together. If you want to do something that complex you need to use the real VACM tokens instead of the easier wrappers. The above example is a bad choice, my bad. But all the wrapper tokens have an additional flag that lets you add "extra" views into the current view list. IE this: ipv4logcommunity -v execute xyzzy Means add xyzzy as a community string that is good for both log (in the token name) and execute (the -v flag). A better example would have been: ipv4authcommunity -v log -v execute xyzzy which is the exact same thing. I realized the confusion of the other one wasn't worth it, so the last example I think is more clear. I'm not sure I wanted the flag syntax (-v) or to use something like log|execute or something... All of the tokens are parsed by the same thing, so the -v flag actually works across them all. We probably shouldn't advertise them for some of them though. This is the one thing I'm not happy with generally, but the options are all bad in different ways. There are ipv4 and ipv6 prefixes to indicate what the community is to be used under for which transport, in the same way that we have rocommunity and rocommunity6 today. I think these names are nicer than the snmpd equivalents though since they're more explicit. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- 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
