This chapter describes how to manage common operations with the System Management Agent. This chapter contains material on the following topics:
Start or stop the SMA by starting or stopping the snmpd daemon. Numerous options are available for starting or stopping the daemon, but several of these options override the snmpd.conf and snmp.conf files. The recommended way to start and stop the System Management Agent is to use the svcadm command as described in this section. Further information on the snmpd daemon can be found in the snmpd(1M) man page.
As a standard SNMP agent, the System Management Agent must run on port 161. If another process is running on port 161, the System Management Agent does not start.
Once the svcadm command has launched the System Management Agent on your system, the snmpd daemon always starts at boot time during the Solaris system boot. If you are using other agents, you might want to prevent the snmpd daemon from starting at boot time, which initializes the System Management Agent. If you want to prevent the snmpd daemon from starting at boot time, see To Prevent The System Management Agent Initializing at Boot Time.
As root, start the SMA service.
# svcadm enable svc:/application/management/sma:default |
Check whether errors occurred in attempting to start the System Management Agent by examining the /var/log/snmpd.log file.
If the log file reports that the port 161 is occupied, follow the procedure described in To Check Whether Another Process Is Running on the SMA Port.
To enable changes made to the main SMA configuration file, /etc/sma/snmp/snmpd.conf, a signal must be sent to the SMA daemon, snmpd. This signal reads the changes to snmpd.conf and restarts the System Management Agent.
As root, restart the SMA service.
# svcadm restart svc:/application/management/sma:default |
This method is the recommended way to restart the System Management Agent.
As root, stop the SMA service.
# svcadm disable svc:/application/management/sma:default |
Port 161 is reserved for the System Management Agent. For more information, see Managing Configuration With the Main Configuration File.
Use the netstat command:
# netstat -anv|grep 161 |
If a value of 161 is returned, a process is already bound to port 161.
As root, get the service status.
# svcs svc:/application/management/sma:default |
A typical response to this command is shown:
STATE STIME FMRI online Aug_24 svc:/application/management/sma:default |
First find the total disk space of the disk, then find how much of this space is used. The difference between these two totals is the available disk space.
Find the number of disks that are available on a given host.
# snmpwalk -v1 -c public hostname HOST-RESOURCES-MIB::hrStorageIndex |
This command returns a list of disks on the host, hostname:
HOST-RESOURCES-MIB::hrStorageIndex.1 = INTEGER: 1 HOST-RESOURCES-MIB::hrStorageIndex.2 = INTEGER: 2 HOST-RESOURCES-MIB::hrStorageIndex.3 = INTEGER: 3 HOST-RESOURCES-MIB::hrStorageIndex.4 = INTEGER: 4 HOST-RESOURCES-MIB::hrStorageIndex.5 = INTEGER: 5 HOST-RESOURCES-MIB::hrStorageIndex.6 = INTEGER: 6 HOST-RESOURCES-MIB::hrStorageIndex.7 = INTEGER: 7 HOST-RESOURCES-MIB::hrStorageIndex.8 = INTEGER: 8 HOST-RESOURCES-MIB::hrStorageIndex.9 = INTEGER: 9 HOST-RESOURCES-MIB::hrStorageIndex.10 = INTEGER: 10 HOST-RESOURCES-MIB::hrStorageIndex.101 = INTEGER: 101 HOST-RESOURCES-MIB::hrStorageIndex.102 = INTEGER: 102 |
The disk is indicated by the index number:
HOST-RESOURCES-MIB::hrStorageIndex.1 = INTEGER: 1 |
This output represents disk 1, /dev/dsk/c0t0d0s0
Use the snmpget command to retrieve the total storage space for that disk.
The following command would retrieve the total storage space for disk 1:
# snmpget -v1 -c public hostname HOST-RESOURCES-MIB::hrStorageSize.1 |
This command returns the total disk space at the end of the line:
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 2561695 |
View a list of the disk space used by each disk.
# snmpwalk -v1 -c public hostname HOST-RESOURCES-MIB::hrStorageUsed |
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 2121747 HOST-RESOURCES-MIB::hrStorageUsed.2 = INTEGER: 0 HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 0 HOST-RESOURCES-MIB::hrStorageUsed.4 = INTEGER: 0 HOST-RESOURCES-MIB::hrStorageUsed.5 = INTEGER: 11 HOST-RESOURCES-MIB::hrStorageUsed.6 = INTEGER: 48 HOST-RESOURCES-MIB::hrStorageUsed.7 = INTEGER: 1892576 HOST-RESOURCES-MIB::hrStorageUsed.8 = INTEGER: 0 HOST-RESOURCES-MIB::hrStorageUsed.9 = INTEGER: 130565552 HOST-RESOURCES-MIB::hrStorageUsed.10 = INTEGER: 26036932 HOST-RESOURCES-MIB::hrStorageUsed.101 = INTEGER: 55995 HOST-RESOURCES-MIB::hrStorageUsed.102 = INTEGER: 17171 |
Use the snmpget command to view the storage used by the disk in question.
# snmpget -v1 -c public hostname HOST-RESOURCES-MIB::hrStorageUsed.1 |
This command returns the disk space used on disk 1:
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 2121747 |
Subtract this figure from the total disk space to find the available disk space:
2561695 – 2121747 = 439948
In the same way as you would use the netstat command, you can check the status of the network using the System Management Agent with the snmpnetstat command.
To show the state of all sockets, use the snmpnetstat command with the –a option. This option provides the default display, showing all active sockets, except those used by server processes.
# snmpnetstat -v 2c -c public -a testhost |
The following information, including local and remote addresses, and protocols, is typically displayed:
Active Internet (tcp) Connections (including servers) Proto Local Address Foreign Address (state) tcp *.echo *.* LISTEN tcp *.discard *.* LISTEN tcp *.daytime *.* LISTEN tcp *.chargen *.* LISTEN tcp *.ftp *.* LISTEN tcp *.telnet *.* LISTEN tcp *.smtp *.* LISTEN Active Internet (udp) Connections Proto Local Address udp *.echo udp *.discard udp *.daytime udp *.chargen udp *.time |
To show the state of network interfaces, use the snmpnetstat command with the –i option. This option provides a statistics table that shows packets transferred, errors, and collisions as well as network addresses of the interface and the maximum transmission units (MTU).
# snmpnetstat -v 2c -c public -i testhost |
The following table, including local and remote addresses, and protocols, is typically displayed:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Queue eri0 1500 10.6.9/24 testhost 170548881 245601 687976 0 0 lo0 8232 127 localhost 7530982 0 7530982 0 0 |
The Ipkts, or incoming packets, value reported by the snmpnetstat command is not identical to that reported by the netstat command. The snmpnetstat command displays the total number of unicast, multicast and broadcast packets. The netstat command displays the total number of unicast and multicast packets, omitting broadcast packets.
The resident size of the snmpd daemon depends on how the SMA is used.
The snmpd daemon dynamically allocates memory for certain MIB table data, for example, when you have defined printers, and then walk the Host Resource MIB. The resident size of the snmpd daemon can increase by up to 100Kbytes depending upon the number of printers you have defined.
JavaTM Development Management Kit (JDMK) implements the JMX specifications and in addition, enables SNMP based instrumentation within the JDMK agent infrastructure. Like the System Management Agent, JDMK also supports the following standards:
SNMPv3
SNMPv2c
SNMPv1
USM
Proxying
Though both JDMK and the SMA address SNMP instrumentation, JDMK is very suited to Java based environments. The SMA is more suited to native C based implementations.
In Sun systems where both JDMK and the SMA are present, the SMA by default resides on port 161. JDMK agents can publish their SNMP MIBs by being proxied from the SMA. Proxying can be set up using the proxy forwarding mechanism within the SMA. See Example 3–1.
Security must to be handled by the master agent, which is the SMA, and by the proxied JDMK agent. Security parameters that are contained in the proxy definition are forwarded to the proxied JDMK agent. If the request passes the SMA authentication and authorization and is forwarded to its proxy handler, then the dispatched request is proxied to the JDMK agent. The JDMK agent has its own local datastore that authorizes or rejects the message.
If several JDMK agents have the same MIB, SNMP contexts must be used in conjunction with proxying to differentiate between different instances of the same MIB. The context name can be based on the process ID. Alternatively, the context name can be based on the port on which the JDMK agent is running.
Incoming requests for the JDMK agent can be received by the System Management Agent and then proxied to the JDMK agent. Set JDMK proxy entries using the proxy token in the main snmpd.conf configuration file. Add a proxy statement, such as the following:
# proxy --Cn jdmkMib -v3 -a MD5 -u SecureUser -l authNopriv -A 12345678 localhost:10161 1.3.6.1.4.1.42.5000.2 |
In this example, a MIB is running on port 10161 and registers the MIB region 1.3.6.1.4.1.42.5000 under the context jdmkMib. The user, who is named SecureUser, must also exist in the JDMK USM. The SecureUser user must allow a security level of auth with HMACMD5 as the authentication algorithm. For more information on authentication algorithms, see Authentication Protocol Algorithms.
See the snmpd.conf(4) man page for more information. For more information about how proxying is set up, see Proxy Handling for Solstice Enterprise Agents Requests.