RE: overwrite standard mib2/interfaces

Hi Dave,

Thanks for the response.

We have used "my_context" and registered new nodes for interface/iftable rmon and bridge on standard mibs.
what should vi change in our configuration below to allow cust1_grp and cust2_grp see our added mibs with context "my_context"?

we created the users:
createUser myuser
createUser myuser1 MD5 "my_password1"
createUser myuser2 MD5 "private_pass"

####
# First, map the community name (COMMUNITY) into a security name
# (mynetwork, depending on where the request is coming
# from):

# sec.name source community
com2sec local 127.0.0.1 secret42
com2sec cust1_sec 192.168.55.0/24 public
com2sec cust2_sec 192.168.56.0/24 public

####
# Second, map the security names into group names:

# sec.model sec.name
group MyRWGroup v1 local
group MyRWGroup v2c local

group cust1_grp v1 cust1_sec
group cust1_grp v2c cust1_sec
group cust2_grp v1 cust2_sec
group cust2_grp v2c cust2_sec

group v3_user_grp usm myuser # SNMPv3 username ==
sec.name#
group v3_user_grp_auth usm myuser1 # SNMPv3 username == sec.name#
group v3_user_grp_private usm myuser2 # SNMPv3 username == sec.name#
# Third, create a view for us to let the groups have rights to:

# incl/excl subtree
#---------------------------------------------------------------
view all included

view cust1_v excluded .1
view cust1_v included .1.3.6.1.2.1.1.3.0
view cust1_v included .1.3.6.1.2.1.2.2.1.1.1

view cust2_v excluded .1
view cust2_v included .1.3.6.1.2.1.1.3.0
view cust2_v included .1.3.6.1.2.1.2.2.1.1.2

view mini_view excluded .1
view mini_view included 1.3.6.1.2.1.1.3.0

view if_view excluded .1
view if_view included .1.3.6.1.2.1.1.3.0
view if_view included .1.3.6.1.2.1.2.2

####
# Finally, grant the groups access to their views:

# context sec.model sec.level match read write
notif
#------------------------------------------------------------------------
access MyRWGroup "" any noauth exact all all none
access cust1_grp "" any noauth exact cust1_v none none
access cust2_grp "" any noauth exact cust2_v none none

#---------------------------------------------------------------------------------------
# context sec.model sec.level match read write notif
#---------------------------------------------------------------------------------------
access v3_user_grp "" usm noauth exact mini_view none none
access v3_user_grp_auth "" usm auth exact if_view none none
access v3_user_grp_private my_context usm auth exact all none none


Thanks,

/Masoud

-----Original Message-----
From: net-snmp-users-bounces@lists.sourceforge.net [mailto:net-snmp-users-bounces@lists.sourceforge.net] On Behalf Of Dave Shield
Sent: den 18 mars 2008 10:18
To: Masoud Fatollahy
Cc: net-snmp-coders@lists.sourceforge.net; net-snmp-users@lists.sourceforge.net
Subject: Re: overwrite standard mib2/interfaces

On 17/03/2008, Masoud Fatollahy <masoud.fatollahy@t2data.se> wrote:
> Is it possible to give read access to all registered mibs (both with default
> context and other context) to a group/user?

Yes.

> If yes, how can it be done?

Firstly, you'll need to set up a working access control configuration using
the "com2sec/group/view/access" directives, rather than the shorthand
"r[ow]community/r[ow]user" directives.
That will typically include an access line of the form:

access {group} "" .... exact .....

If you change the token "exact" to read "prefix", then this will extend
the access rights to *all* prefixes.


> Is it any way to give read access to mibs with different context to a client
> which is running v1/v2c snmp?

Yes.
Again, you need to be using the full "com2sec/group/view/access" directives.

Normally, you would have a line of the form

com2sec {someUser} default {community}

which would be part of allowing that community to access information
in the default context. To allow access to information in a different
context, you should amend this to read

com2sec -Cn {context} {someUser} default {community}

Note that each context will require a different community name.

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users