Sun Java System Messaging Server 6.3 Administration Guide

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/
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
% 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/
% 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 .
view systemview included .
% /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 mib-2.27

NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 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 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 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, 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
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public .
SNMPv2-SMI::mib- = STRING: "/opt/SUNWmsgsr MTA on"

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.

Table A–1 SNMP Subagent Options

Option (Default) 


local.snmp.enable (0)

The Messaging Server SNMP subagent will only run when this option is given a value of 1 or true in which case Messaging Server will automatically stop and start the subagent as part of its normal startup and shutdown procedures. By default this option is set to zero which disables operation of the subagent. Before enabling the subagent, ensure that the platform's master agent has been properly configured as described in A.3.3 Running as a Standalone SNMP Agent.

local.snmp.standalone (0)

Messaging Server's SNMP support normally runs as a SNMP subagent, receiving SNMP requests via the platform's SNMP master agent, snmpd. This operational mode is the default and is selected by giving this option a value of 0 or false. However, as described in A.3.3 Running as a Standalone SNMP Agent, the subagent may run in a "standalone" mode whereby it operates as a SNMP agent independent of snmpd. When run in standalone mode, the subagent--now a SNMP agent--listens directly for SNMP requests on the Ethernet interface and UDP port specified by, respectively, the local.snmp.listenaddr and local.snmp.port options. To run in this standalone mode, specify a value of 1 or TRUE for this option.

Running in standalone mode does not interfere with other SNMP master or subagents running on the system. 

local.snmp.listenaddr (INADDR_ANY)

Hostname or IP address of the Ethernet interface to listen for SNMP requests on when running in standalone mode. By default, all available interfaces are listened on. This corresponds to specifying the value INADDR_ANY. A specific interface may be selected by specifying either the IP address or hostname associated with that interface. The interface may be either a physical interface or a virtual interface.

This option is ignored when local.snmp.standalone is set to 0 or FALSE.

local.snmp.cachettl (30)

Time to live (TTL) in seconds for cached monitoring data. This option controls how long the subagent will report the same monitoring data before refreshing that data with new information obtained from Messaging Server. With the exception of message loop information, data is cached for no longer than 30 seconds by default. Loop information, as determined by scanning for .HELD files, is updated only once every 10 minutes. That because of the resource cost of scanning all the on-disk message queues.

Note that the subagent does not continually update its monitoring data: it is only updated upon receipt of an SNMP request and the cached data has expired (that is, outlived its TTL). If the TTL is set to 30 seconds and SNMP requests are made only every five minutes, then each SNMP request will cause the subagent to obtain fresh data from Messaging Server. That is, data from Messaging Server will be obtained only once every five minutes. If, on the other hand, SNMP requests are made every 10 seconds, then the subagent will respond to some of those requests with cached data as old as 29 seconds; Messaging Server will be polled only once every 30 seconds. 

local.snmp.servertimeout (5)

The subagent determines the operational status of each monitored service by actually opening TCP connections to each service and undergoing a protocol exchange. This timeout value, measured in seconds, controls how long the subagent will wait for a response to each step in the protocol exchange. By default, a timeout value of five seconds is used. 

local.snmp.directoryscan (1)

Use this option to control whether or not the subagent performs scans of the on-disk message queues for .HELD message files and the oldest message files. That information corresponds to the mtaGroupLoopsDetected, mtaGroupOldestMessageStored and mtaGroupOldestMessageId MIB variables. When this option has the value 1 or true, then a cache of this information is maintained and updated as needed. Sites with thousands of queued messages, that are not interested in these particular MIB variables should consider setting this option's value to 0 or false.

local.snmp.enablecontextname (0)

The subagent has the ability to register its MIBs under an SNMP v3 context name. When this is done, the MIBs may only be requested by a SNMP v3 client which specifies the context name in its SNMP request. Use of context names allows multiple, independent subagents to register Network Services and MTA MIBs under the same OID tree (that is, under the same SNMP master agent). See A.3.4 Monitoring Multiple Instances of Messaging Server for further information.

To enable the use of SNMP v3 context names, specify a value of 1 or true for this option. When that is done, the subagent will default to using the value of the service.defaultdomain option for its context name. To use a different value for the context name, use the local.snmp.contextname option.

local.snmp.contextname (service.defaultdomain)

When the use of SNMP v3 context names has been enabled with local.snmp.enablecontextname, this option may be used to explicitly set the context name used by the subagent for its MIBs. The values supplied for this option are string values and must be appropriate for use as a SNMP v3 context name. This option is ignored when local.snmp.enablecontextname has the value 0 or false.