>>>>> On Sat, 22 Oct 2005 00:02:06 +0100, Dave Shield <[EMAIL PROTECTED]> said:

Dave> Personally, I'd probably go for a mandatory positional
Dave> field - something like:

Dave> ipv4authcommunity   log,execute   xyzzy

...

Dave> A more natural (and flexible) approach would be to use the
Dave> existing transport-prefix mechanism:

Dave> community    read-only   myNetwork  udp:10.0.0.0/8
Dave> community    read-write  myLoopback callback:*
Dave> community    execute     myTraps    ipv4:10/8,ipv6:10/8
Dave> community    log         myTraps

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

The host name specifications don't quite do what they're supposed to
yet.  It currently does pass to both v4 and v6 though (and unix, which
actually breaks naturally unless it's a proper path).  But it leaves
the flexibility you want to make it work more perfectly in the future
within the same config tokens.  Currently, you still can't duplicate
community names across multiple simple lines like the above, but it
otherwise works like you expect.

I left "auth" in front of the tokens because I think it's more
descriptive.  I know your examples have all used a straight
"community" but I don't think that's really descriptive about *what*
you're doing with the community.

IMHO, I don't think we should bend *too* far to make it significantly
easier for the user.  Having them learn the more powerful VACM tokens
has always been our recommendation for more serious setups.  The
convenience wrappers are for the 95% cases where they don't need
anything too powerful.

[sorry if I was a bit short earlier.  I got a very long set of, um,
stuff about real work from someone who, ironically, failed to read the
important part of the documentation we'd given out...  Bad end to a
week I thought was shaping up.]

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

Reply via email to