Suntrademark SNMP Management Agent Administration Guide for Sun Supported Servers Table Of Contents Previous ChapterNext ChapterNo Book Index



C H A P T E R  2

Configuration Files

This chapter describes how to configure the SNMP agent.

Overview

Configure the SNMP agent with the following file:

/etc/opt/SUNWmasf/conf/snmpd.conf

This file defines the ports where the agent can be accessed, the access controls that the agent is to apply to management information, and destinations for traps. By default, only the port number requires configuring after installation if:

The default configuration used by the agent enables read-only access for the community public. If the default configuration is not required, or it is inappropriate for a particular environment, configure access control as follows:

Setting Up the Port Number

Configure the port number using the agentaddress keyword. By default, a port number is specified as follows:


agentaddress 9000

This instructs the agent to listen to UDP port 9000 on all interfaces configured in the system. Change the port number if you want to listen on a different port.


Note - This port number must not be used by any other application.


The agent can be made to listen to a specific address by specifying an agent address of the form:


hostname[:port]

or


IPv4-address[:port]

This forces the agent to listen on only that address. Also the agent can listen on multiple ports by using an agent address in the following form:


agentaddress 8161,localaddress:9161

This makes the agent listen on UDP port 8161 on all IPv4 interfaces and UDP port 9161 only on the interface associated with the local host address.

The agent must have a port number configured before it starts.


Note - By using ports other than 161 and 162 for SNMP agent access, you can ensure that these ports are available for use by other agents, such as snmpdx or Sun Management Center, which use them by default.


Setting Up Trap Destinations

Syntax


trapsink transportAddr community
trap2sink transportAddr community

This defines a trap destination, a community string used for the MIB view, and the destination port. All trap destinations must have an entry like this, and starting with SNMP 1.6 software, all of these fields must be specified. These commands define the hosts to receive traps:

You can use multiple trapsink, trap2sink lines to specify multiple destinations. You can also specify a host multiple times, in which case a trap is sent for each of the commands listed.

The SNMP daemon (snmpd) sends a cold start trap when it starts. If enabled, it also sends traps on authentication failures.


EXAMPLE 2-1   Using the trapsink and trap2sink Commands 
....
agentaddress 8161,localhost:9161
###########################################################
# SECTION: Trap Destinations
#
# Here we defined who the agent will send traps to.
 
# trapsink: A SNMPv1 trap receiver
# arguments host community portnum
trapsink merlin:32768 public
 
# trap2sink: A SNMPv2 trap receiver
# arguments host community portnum
trap2sink arthur:162 public

This results in SNMPv1 traps being sent to the system merlin on port 32768, and SNMPv2 traps being sent to arthur using the default port for traps of 162.

Configuring Access Control

The agent supports the view-based access control model (VACM) as defined in RFC 2575. It, therefore, recognizes the following keywords in the configuration file:

It also recognizes some easier-to-use wrapper directives:

Syntax

rocommunity and rwcommmunity


rocommunity community[source] [OID]
rwcommunity community[source] [OID]

These wrapper directives create read-only and read-write communities that can be used to access the agent. They are a simple wrapper around the more complex and powerful com2sec, group, access, and view directive lines. Also, they are not as efficient, because groups are not created, and the tables can be larger as a consequence. It is, therefore, better not to use these wrappers if you have complex situations to set up, and to reserve their use where your setup is simple.

  • community token specifies the community string for which access is to be granted

  • format of the source is token and is described in the com2sec directive section.

  • OID token restricts access for that community to everything below the given OID.

You can apply only one rwcommunity or rocommunity directive for each source and community combination.

rouser and rwuser


rouser username [noauth|auth|priv] [OID]
rwuser username [noauth|auth|priv] [OID]

These wrapper directives configure access permissions for the specified user in the VACM configuration tables. It is more efficient and powerful to use the combined group, access, and view directives instead, but these wrapper directives are much simpler.

  • username specifies the SNMPv3 security name to which these permissions apply.

  • Minimum level of authentication and privacy for the username is specified by the first token, which defaults to auth.

  • OID token restricts access for that user to everything below the given OID.

These directives have no effect unless the corresponding user has been created. See SNMPv3 Configuration.

You can apply only one rwuser or rouser directive for each user.

com2sec


com2sec username source community

This wrapper directive specifies the mapping from a source/community pair to a security name.

  • username specifies the security name to which this source and community string are to be mapped.

  • source can be:

    • Host name

    • Subnet, which is specified as IP/mask; for example, 129.156.203.56/255.255.255.0; or IP/bits; for example, 129.156.203.56/24.

    • The word default, which specifies that access is to be provided to all hosts with the specified community.

The first source/community combination that matches the incoming packet is selected

group


group groupname model username

This directive defines the mapping from a given security model and security name to a particular group.

  • groupname defines the name of the group to which this combination of model and security name belongs.

  • model is the security model and can be any one of v1, v2c, or usm.

  • username specifies the security name, which is defined elsewhere either in a com2sec or createUser directive.

access


access groupname context model level match read write notify

The access directive specifies the access permissions to be given to a particular group/security model combination.

  • groupname specifies the name of the group to which the directive applies.

  • model is the SNMP security model to which the access directive applies. It can take the values of any, v1, v2c, or usm.

  • level specifies the minimum level of authentication and encryption of the incoming requests for which this directive applies. It can take the values noauth, auth, or priv.

  • match specifies how context should be matched against the context of the incoming protocol data unit (PDU), or packet, and takes the values exact or prefix.

    • exact specifies that context must be matched exactly.

    • prefix specifies that the context must begin with context.

  • read, write, and notify specify the view to be used for the corresponding access.


    Note - The notify field is ignored for the purposes of access control. All access control for traps and informs is configured by means of the trapsink, trap2sink, and informsink directives. See Setting Up Trap Destinations.


  • When model is v1 or v2c, set level to noauth, and context to the empty string ““.

  • When access for a particular group with a given security model is requested, the agent determines access in the following order:

  1. Entries with a specific matching security model, as opposed to those matching against the value of any.

  2. If there is still more than one match, the most exact context match.

  3. If there is still more than one match, the entry with the highest security level.

view


view viewname type subtree [mask]

This defines the named view.

  • viewname defines the name of the view, which you can then use to reference the view in an access directive.

  • type takes the values included or excluded. It specifies whether the OID subtree specified in subtree should be included or excluded from the corresponding view.

  • mask is a list of hex octets, separated by a period (.) or a colon (:). The mask defaults to all 1s (matching is performed against all digits in the subtree) if it is not specified.

A bit value of 0 in the mask acts as a wildcard for the corresponding value in the OID. A bit value of 1 in the mask indicates that the corresponding value in the subtree OID is fixed.

The mask enables you to control access to one row in a table in a relatively simple way.


view cust1 included 1.3.6.1.2.1.2.2.1.1.1 ff.a0
view cust2 included 1.3.6.1.2.1.2.2.1.1.2 ff.a0

In the example above, the hex value ff.a0 has a binary equivalent of 11111111.10100000. The bit position of the first 0 is position 10, which means that the view cust1 provides access to all the objects with OIDs that match 1.3.6.1.2.1.2.2.1.x.1, where x is an integer value.

Similarly, the view cust2 provides access to all the objects with OIDs that match 1.3.6.1.2.1.2.2.1.x.2.

VACM Example


EXAMPLE 2-2   VACM Example 
#     sec.name  source   community
com2sec local  localhost  private
com2sec mynet  10.10.10.0/24  public
com2sec public  default  public
 
#    group.name sec.model sec.name
group mygroup v1     mynet
group mygroup v2c     mynet
group mygroup usm     mynet
group local  v1     local
group local  v2c     local
group local  usm     local
group public v1     public
group public v2c     public
group public usm     public
 
#   view.name incl/excl subtree mask
view all  included .1       80
view system included system      fe
 
# group.name context sec.model sec.level prefix read  write notify
access mygroup ""    any    noauth  exact mib2  none none
access public ""    any    noauth  exact system none none
access local  ""    any    noauth  exact all  all  all

Default VACM Model

The default configuration of the agent, as shipped, is functionally equivalent to the following entries:


EXAMPLE 2-3   Default VACM Model 
com2sec public  default  public
group public  v1  public
group public  v2c public
group public  usm public
view all included .1
access public  ""  any noauth  exact all none none

SNMPv3 Configuration

This section describes the command that enables the agent to respond to SNM_v3 messages.

Syntax


engineID string

You must configure the snmpd agent with an engineID, so that it can respond to SNMPv3 messages. If you do not configure an engineID, the agent uses a default value of the engineID based on the first IP address found for the host name of the machine. If this is inappropriate (for example, if another agent is also using the same engineID), you must configure an engineID explicitly. This line configures the engineID to the value of string.


createUser username MD5 authpassphrase

MD5 enables the authentication of SNMP users. When you create an SNMPv3 user, you must also update the VACM access control tables to provide an explicit declaration of what the user can access.


Note - This entry is made in the /var/opt/SUNWmasf/snmpd.dat file rather than in the /etc/opt/SUNWmasf/conf/snmpd.conf file.


The minimum pass phrase length is 8 characters.


Note - When the specified user has been created, the createUser statement provided in the file is removed.


Setting System Information

This section describes the commands that you use to configure the system information in MIB-II.

Syntax


syslocation string
syscontact string
sysname string

These parameters set the system location, system contact, or system name for the agent. This information is reported in the system group in the MIB-II tree. Normally, these objects (sysLocation.0, sysContact.0, and sysName.0) are read-write. However, if you specify the value for one of these objects by giving the appropriate token, the corresponding object becomes read-only, and subsequent attempts to set the value of the object result in a notWritable error response.


sysservices number

This parameter sets the value of the system.sysServices.0 object. For a host, an acceptable value is 72.

The value of sysservices is a sum based on the network layers for which the node performs transactions. For each layer, L, in the range 1 through 7, for which this node performs transactions, 2 raised to (L - 1) is added to the sum. For example, a node that performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node that is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)).


Note - In the context of the Internet suite of protocols, values should be calculated accordingly.


TABLE 2-1 provides these layer values.


TABLE 2-1   Internet Protocol Layer Functionality
Layer Functionality
1 Physical (for example, repeaters)
2 Datalink/subnetwork (for example, bridges)
3 Internet (for example, IP gateways)
4 End-to-end (for example, IP hosts)
7 Applications (for example, mail relays)

For systems including OSI protocols, layers 5 and 6 can also be counted.

General Configuration

This section describes the commands that enable general configuration of the agent.

Syntax


agentgroup groupid

Change to this groupid after opening the port. The groupid can refer to a group by name, or a number if the group number starts with #. For example, specifying agentgroup snmp causes the agent to run as the snmp group, and specifying agentgroup #10 causes the agent to run as the group with groupid 10.


agentuser uid

Change to this uid after opening the port. The uid can refer to a user by name, or a number if the user number starts with #. For example, specifying agentuser snmp causes the agent to run as the snmp user, and specifying agentuser #10 causes the agent to run as the user with uid 10.


authtrapenable number

Setting authtrapenable to 1 enables generation of authentication failure traps. The default value is disabled(2). Normally, the corresponding object (snmpEnableAuthenTraps.0) is read-write, but setting its value with this token makes the object read-only, and subsequent attempts to set the value of the object result in a notWritable error response.

Updating the SNMP Agent When It Is Running

You can update the configuration file at any time, either before starting the agent or once the agent has started. If the agent is running, it does not update its running configuration unless explicitly requested to do so.

procedure icon  Force the SNMP Agent to Update

Co-Existence With Other Agents

The SNMP agent must be configured to use a specific network port, and this port cannot be shared with any other component on the system. However, master agent technologies can enable multiple SNMP agents on a system to appear as a single entity to management applications. To use such solutions, configure this agent to use a port that is known to the master agent, which then presents an aggregated OID space.

Configuring SNMP to Work With SMA

You can configure the Management Agent for Sun Fire (MASF) and the System Management Agent (SMA) configuration files to work together. The following procedures have been tested with Sun’s SMA.


Note - Any trapsink or trap2sink lines present in the /etc/opt/SUNWmasf/conf/snmpd.conf file must be added to the SMA snmpd.conf file.


procedure icon  Change the Subagent (MASF) Configuration File

  1. Modify the /etc/opt/SUNWmasf/conf/snmpd.conf file as follows.

    1. Change agentuser to agentuser root.

    2. Change agentgroup to agentgroup root.

  2. Modify the /etc/init.d/masfd script by including -X in the line that starts the agent, so that the line now reads


    snmpd -X -Lsd

procedure icon  Change the SMA Configuration File

  •   Modify the SMA /etc/sma/snmpd.conf file as follows:

    1. Add the following lines if not present:


      master agentx
agentXTimeout 600

    2. Comment out the following lines by inserting a pound sign (#) as the first character on these lines:


      # dlmod seaProxy /usr/sfw/lib/sparcv9/libseaProxy.so
# dlmod seaExtensions /usr/sfw/lib/sparcv9/libseaExtensions.so

procedure icon  Restart SMA and MASF

  1. Restart the System Management Agent.

    For more information, refer to “Starting and Stopping the System Management Agent” in the Solaris System Management Agent Administration Guide.


    # svcadm restart svc:/application/management/sma:default

  2. Stop and restart MASF.


    # /etc/init.d/masfd stop
# /etc/init.d/masfd start

    After both agents start, MASF should now respond to requests directed to the agentaddress as specified in the SMA.



Suntrademark SNMP Management Agent Administration Guide for Sun Supported Servers 821-0655-10Table Of Contents Previous ChapterNext ChapterNo Book Index

Copyright © 2009, Sun Microsystems, Inc. All rights reserved.