A.3 Configuring SNMP Support for Solaris 10 OS

By default, SNMP monitoring is disabled within Messaging Server. This default is chosen in an attempt to minimize the number of services presented by a default Messaging Server configuration. Do not interpret this default as meaning that there is a performance penalty incurred by using SNMP monitoring. Indeed, Messaging Server's SNMP support consumes very little resources and is intended to have minimal impact upon messaging server. The upshot of all of this is, of course, that one time configuration steps are required before using Messaging Server's SNMP support. Additionally, the default configuration of the platform's Net-SNMP master agent, snmpd, typically needs to be changed in order to run subagents such as Messaging Servers. This change is the topic of the next section.

A.3.1 Net-SNMP Configuration

Messaging Server's Net-SNMP based SNMP subagent uses the AgentX protocol to communicate with the platform's SNMP master agent (RFC 2741). The Net-SNMP master agent, snmpd, must be configured to permit the use of the AgentX protocol. To do this, ensure that the platform's snmpd.conf file contains the line

master agentx

If that line is not present, then add it and then restart the snmpd daemon. Note that sending a SIGHUP signal to the daemon is not sufficient. Once the snmpd daemon has been restarted, look for the UNIX domain socket which snmpd creates for AgentX communications. On Solaris and Linux systems, this socket by default appears as the special file /var/agentx/master; however, its location and name may be changed via the snmpd.confile.

The Solaris 10 OS snmpd configuration is show below:

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
^D
% cat >> /etc/sma/snmp/snmpd.conf
% ls -al /var/agentx/
srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

Additionally, on Red Hat Enterprise Linux AS 3 systems, the default snmpd.conf file restricts the information which may be viewed by the "public" SNMP community. It is therefore necessary to either remove that restriction or to extend it to include the MIBs served out by Messaging Server's subagent. For initial testing, doing the latter is recommended. This is accomplished by including the OID subtrees mib-2.27 and mib-2.28 in view named "systemview" as shown in below. For actual deployment, each site must take their overall security policy into consideration. Note that the information provided by the SNMP subagent is "read only".

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save
% cat >>/etc/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
# Messaging Server's subagent exports mib-2.27 and .28
# Add the mib-2.27 and .28 OID subtrees to the systemview
view systemview included .1.3.6.1.2.1.27
view systemview included .1.3.6.1.2.1.28
^D
% /sbin/service snmpd restart
% ls -al /var/agentx/master
srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

If you will be using SNMP v3 context names to distinguish between the MIBs of different instances of Messaging Server concurrently running on the same host computer, then you will also need to configure at least one SNMP v3 username and password for use with your SNMP v3 queries.

A.3.2 Messaging Server Subagent Configuration

For basic operation of Messaging Server's SNMP subagent, you need only enable it and issue a one time manual start command. Henceforth, whenever Messaging Server is started or stopped, the subagent will likewise be started or stopped. The necessary commands to effect this configuration on both Solaris and Linux are as follows:

% configutil -o local.snmp.enable -v 1
% start-msg snmp

Once running, you can test the subagent from the command line with the snmpwalk command. See the screen shots below an example appropriate to Solaris and Linux. Note that the files rfc2248.txt and rfc2249.txt are copies of the Network Services and MTA MIBs. On Solaris systems, these files may also be found in the /etc/sma/snmp/mibs/ directory under the names NETWORK-SERVICES-MIB.txt and MTA-MIB.txt. It is not necessary provide these files to the snmpwalk tool; however, doing so permits snmpwalk to print names for each of the MIB variables rather than their numeric object identifiers (OIDs).

Basic testing on Solaris:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
    -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27

NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com
...
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28

MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452
MTA-MIB::mtaStoredMessages.1 = Gauge32: 21
...

Basic testing on Linux:

% export D=/opt/sun/messaging/examples/mibs
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com
...
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278
MTA-MIB::mtaStoredMessages.1 = Gauge32: 7
...

A.3.3 Running as a Standalone SNMP Agent

Before configuring Messaging Server's SNMP subagent to run as a standalone SNMP agent, you must first decide which Ethernet interface and UDP port you wish for it to listen on for SNMP requests. By default, it will listen on all available Ethernet interfaces using UDP port 161. In most cases, you will want to change the port number so as to not interfere with the platform's SNMP master agent, snmpd. In some circumstances such as HA failover you will also want to change the Ethernet interface from all available interfaces -- INADDR_ANY -- to a specific interface identified by its IP address. These two concepts, Ethernet interface and UDP port, are controlled via the local.snmp.listenaddr and local.snmp.port options.

Once choices for the Ethernet interface and UPD port have been made, the local.snmp.standalone option should have its value set to one and the subagent restarted. Once restarted, it will operate as a SNMP agent independent of snmpd and any subagents.

For example, to run as a standalone agent listening on UDP port 9161 of the Ethernet interface with IP address 10.53.1.37, issue the commands shown below.

Configuring to run as a standalone agent:

% configutil -o local.snmp.port -v 9161
% configutil -o local.snmp.listenaddr -v 10.53.1.37
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public 10.53.1.37:9161 .
SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"
...

A.3.4 Monitoring Multiple Instances of Messaging Server

Two techniques for monitoring multiple instances of Messaging Server running on the same host computer are herein discussed. The first technique, running the subagent in standalone mode, is well suited to high-availability failover (HA) configurations in which the individual instances of Messaging Server may dynamically move between host computers. The second technique, the use of SNMP v3 context names, has some limited benefit in situations where multiple instances of Messaging Server are confined to a single system and it is desirable to limit the number of IP addresses polled by SNMP monitoring software (for example, when licensing of the monitoring software has a per IP address cost component). This latter technique may also be used in HA failover settings but would require polling just as many IP addresses as the standalone mode technique.

A.3.5 Using Standalone Agents for High-availability Failover

In a high-availability failover setting where SNMP monitoring of Messaging Server is desired, it is recommended that you run Messaging Server's SNMP subagent as a standalone agent as described in A.3.3 Running as a Standalone SNMP Agent. When the subagents are run in standalone mode, each HA instance of Messaging Server should have its local.snmp.listenaddr option set to the value of that instance's failover IP address. To simplify management, each instance should use the same UDP port, but that port should be distinct from those used by the snmpd daemons running on each of the physical cluster hosts. Typically those daemons will be using UDP port 161 so explicitly specify a different port number with the local.snmp.port option.

When Messaging Server's SNMP support is configured as recommended here, a monitoring station can monitor each instance of Messaging Server via its failover IP address or hostname regardless of which physical cluster host the instance is running on. Moreover, you are assured that Messaging Server's standalone SNMP agents will not conflict with one another as each listens only on its own virtual Ethernet interface identified by that instance's unique failover IP address. (These virtual Ethernet interfaces are automatically created by the HA failover framework.) Owing to the careful selection of a UDP port, the agents do not conflict with the snmpd daemons running on systems within the cluster.

A.3.6 Distinguishing Multiple Instances Through SNMP v3 Context Names

While there is no downside to using Messaging Server's SNMP support in standalone mode as described in A.3.3 Running as a Standalone SNMP Agent, it is recognized that some sites may prefer to use a more traditional subagent mode while still maintaining the capability of monitoring multiple instances of Messaging Server running concurrently on the same system. For instance, an SNMP monitoring system whose licensing model limits the number of IP addresses which may be polled. To achieve this goal, continue to run Messaging Server's SNMP subagent with local.snmp.standalone set to zero. Additionally, configure each instance of Messaging Server to use a distinct SNMP v3 context name by specifying a non-zero value for the local.snmp.enablecontextname option. If a context name different than the value of service.defaultdomain is desired, then set the desired name with the local.snmp.contextname option. Once each instance of Messaging Server's SNMP subagent is restarted, they can then be monitored via SNMP v3 queries which include the proper context names. The MIBs of two instances of Messaging Server running on the same system are distinguished by the instance's SNMP v3 context name and so no MIB object identifier (OID) conflicts will arise.

A.3.7 Messaging Server's Net-SNMP-based SNMP Subagent Options

The following options apply only to Messaging Server's Net-SNMP based SNMP subagent. That subagent is used on Solaris platforms running Solaris 10 and later as well as Linux platforms. The options described below do not apply to the legacy SNMP subagent supplied for Solaris platforms running Solaris 9 and earlier operating systems.

The options described below are configutil options. As such, their values are inspected with a command of the form:

% configutil -o option-name

where option-name is the name of the option to display the value of. To set or change an option's value, use a command of the form

% configutil -o option-name -v option-value

where option-value is the value to be set. Changes to these options require a restart to take effect:

% stop-msg snmp
% start-msg snmp

What follows is a description of each option along with its default value.