Chapter 1 Introduction to the System Management Agent

The System Management Agent is a Simple Network Management Protocol (SNMP) agent. This chapter contains the following topics:

• Overview of SNMP Agents

• Overview of the System Management Agent

• Contents of the SMA for Developers

Overview of SNMP Agents

SNMP uses the term manager for the client application that accesses the data about a managed device or system. The manager usually runs on a system that is different from the managed system. The term agent is used for the program that implements the protocol stack for servicing the requests from the manager. The SNMP agent typically runs on the managed device. The agent offers services on a designated TCP/IP port. The default SNMP port is 161.

Information about the target device is contained in a Management Information Base (MIB). MIBs are used by agents and managers so that both programs have knowledge of the data available. The MIB tells the manager about the device's functions and data. The MIB also tells the manager how to address or access that information in the form of managed objects. To access this management information, the manager issues requests to the agent. The requests contain identifiers for the MIB's data objects that are of interest to the manager. If the request can be successfully completed, the agent returns a response that contains the values for the required data objects.

Most SNMP agents support the basic SNMP protocol stack, and some minimal MIBs. However, to make management of a device more effective, additional MIBs must be supported on the managed device. The additional MIBs are provided by device vendors to provide management information about custom features of the managed device.

A MIB that is added to an SNMP agent is commonly known as an extension because the MIB extends the capabilities of the agent. An agent that can accept extensions is extensible. The System Management Agent (SMA), described in this manual, is an extensible agent. The extensions to the System Management Agent are called extension modules.

Overview of the System Management Agent

The System Management Agent (SMA) is an SNMP agent that is based on an open source project, Net-SNMP at http://www.net-snmp.org. This base agent supports SNMPv1, v2c, and v3 protocols.

---

Note –

The Net-SNMP version used in SMA is 5.0.9.

---

The following diagram shows the structure of the Net-SNMP agent, and is followed by an explanation of the components.

Figure 1–1 Net-SNMP Architecture

The components of the Net-SNMP agent are:

• Transport domains

  The Net-SNMP agent currently supports the transports TCP, UDP, and UNIX Domain Sockets. The agent can receive and transmit SNMP messages through these transports. The agent's implementation of each transport implements functions to send and receive raw SNMP data. The raw messages received by the transport domains are passed to the message processor for further processing. The message processor also transfers raw SNMP messages to the transport domain for sending.

• Message processor

  The message processor decodes raw SNMP messages into internal PDU structures. The processor also encodes PDUs into raw SNMP messages. The SNMP messages are encoded by using Binary Encoding Rules, which are described in RFC 3416 and RFC 1157. The message processor also handles the security parameters in the SNMP messages. If the messages include User-based Security Model (USM) security parameters, the message processor passes the required parameters to the USM module. Additionally, trap messages from modules can be sent to the message processor for transmission.

• USM module

  The USM module handles all processing that is required by the User-based Security Model as defined in RFC 3414. The module also implements the SNMP-USER-BASED-SM-MIB as defined in the same RFC. The USM module, when initialized, registers with the agent infrastructure. The message processor invokes the USM module through this registration.

  The USM module decrypts incoming messages. The module then verifies authentication data and creates the PDUs. For outgoing messages, the USM module encrypts PDUs and generates authentication data. The module then passes the PDUs to the message processor, which then invokes the dispatcher.

  The USM module's implementation of the SNMP-USER-BASED-SM-MIB enables the SNMP manager to issue commands to manage users and security keys. The MIB also enables the agent to ensure that a requesting user exists and has the proper authentication information. When authentication is done, the request is carried out by the agent.

  The various keys that the USM module needs to perform encryption and authentication operations are stored persistently.

  See Chapter 4, Managing Security, in Solaris System Management Agent Administration Guide for more information about USM.

• Dispatcher

  The dispatcher is responsible for routing messages to appropriate destinations. After the USM module processes an incoming message into PDUs, the dispatcher performs an authorization check. This authorization check is done by the registered access control module, which is the VACM module. If the check succeeds, the dispatcher uses the agent registry to determine the module that has registered for the relevant object identifier. The dispatcher then invokes appropriate operations on the module. A particular request might cause the dispatcher to invoke several modules if the SNMP request contains multiple variables. The dispatcher keeps track of outstanding requests through session objects. Responses from the modules are then dispatched to the transports that are associated with the session objects. The message processor performs the appropriate message encoding.

• VACM module

  The View-based Access Control Model is described in RFC 3415. This RFC also defines the SNMP-VIEW-BASED-ACM-MIB. The MIB specifies objects that are needed to control access to all MIB data that is accessible through the SNMP agent. Upon initialization, the VACM module registers as the access control module with the agent infrastructure. The VACM module implements access control checks according to several parameters that are derived from the SNMP message. These parameters specify:

  • The security model being used, which can be USM, v1 communities, or v2 communities

  • The security name, which is user name in USM, and community string in v1 and v2

  • The context

  • The object being accessed

  • The operation being performed

  By implementing the SNMP-VIEW-BASED-ACM-MIB, the VACM module handles manipulation of various table entries that are mandated by VACM. These table entries are looked up in performing the VACM check and are maintained persistently in the agent configuration file.

  See Chapter 4, Managing Security, in Solaris System Management Agent Administration Guide for more information about VACM.

• Repository

  The agent configuration file, snmpd.conf, is the repository for the agent. Configuration tokens for various modules are stored in the repository. The modules have access to these configuration tokens when the modules are initialized. Modules can also register callback routines with the repository. The callbacks are invoked when the module state needs to be persisted, or written to disk to be retrieved later. Within the callbacks, each module is allowed to output its state. When the agent shuts down, the callbacks are used to save the modules' state. An SNMP SET command can also be used to cause a module's state to be persisted.

• OID registration handler

  The OID registration handler, or agent registry, handles the registration of object identifiers that are specified by modules.

• Proxy module

  The proxy module handles proxy forwarding of SNMP messages to and from other SNMP agents. The proxy module can also map between SNMPv1 and SNMPv2 protocols according to the rules specified in RFC 2576.

  The proxy module stores its configuration tokens in the agent configuration file. A particular configuration entry can associate OIDs within a context with another SNMP agent. The configuration file also specifies community strings and destination transport end points. By using these configuration tokens, the proxy module registers as the handler for the specific OIDs. When an incoming request for any of the proxy module's OIDs reaches the dispatcher, the dispatcher invokes the proxy module. The proxy module then issues appropriate SNMP requests to the target agents. Responses are returned back to the dispatcher.

  The System Management Agent uses the proxy module for interaction with the Solstice Enterprise Agents.

• AgentX module

  The AgentX module implements RFCs 2741 and 2742. The AgentX module registers as the handler for the AgentX-related registration tables defined in the AGENTX-MIB. The transports that are used for the AgentX protocol interactions are specified in the agent configuration file. In the Net-SNMP agent, the transports are typically UNIX domain sockets. When the AgentX module is initialized, the module creates sessions on these transports and registers as the handler for these sessions. In the System Management Agent, the only allowable AgentX transport is UNIX domain sockets, so only sessions on UNIX domain sockets are created.

  When an AgentX subagent starts, the subagent sends its registration requests with messages that use the AgentX protocol to the master agent. The requests are received by the sessions that have been created by the AgentX module. The message processor decodes the message, then invokes the AgentX module. The AgentX module, rather than the dispatcher module, is the handler for these sessions.

  The AgentX module then registers as the handler for OIDs that are specified in the subagent registration message. When requests for these OIDs are received by the dispatcher, the requests are directed to the AgentX module, which in turn connects to the required subagent. Requests to unregister OIDs are handled similarly.

• Extension modules

  Extension modules, which are depicted at the bottom of Figure 1–1, are the means by which MIBs are implemented in the agent. An extension module registers with the agent all the object identifiers that the module manages. The module also implements functionality to perform SNMP operations on the module's objects. As shown in Figure 1–1, helper routines or handlers in the API can be inserted between a module and the agent infrastructure. These handlers can have various functions, such as handling details of table iterations or providing debug output.

Extending the Agent

The Net-SNMP agent can be extended in the following ways:

• The agent can be recompiled to include a static module, which becomes part of the agent infrastructure. Static modules are initialized on agent start up. Examples of static modules include the VACM and USM modules. The System Management Agent was developed by compiling several static modules for MIBs that are not included in the Net-SNMP agent. See Features Added in System Management Agent for a list of the MIBs included in SMA.

  You cannot deploy your own modules as static modules with SMA because you cannot recompile the SMA code.

• Modules can be loaded into the master agent's process image. A shared object is dynamically loaded into the agent when the agent is running. The shared object registers the OIDs for the MIB that is supported by the shared object. The location of the shared object libraries for the module can be specified through SNMP requests or in the agent configuration file.

• Modules can be loaded into secondary SNMP subagents. Subagents are separate executable programs that can dynamically register themselves with the agent that is running on the designated SNMP port. The monitoring agent processes any SNMP request that comes to the SNMP port, and can send a request to a subagent, if needed. In this scenario, the agent on the designated port is called the master agent. The AgentX RFCs 2741 and 2742 define the protocols between the subagent and master agent as well as the MIBs that contain details of the registrations. For more information on master agents and subagents, see Chapter 6, Deploying Modules.

• A module can be delivered as an SNMP agent. The master agent can interact with such agents through a proxy mechanism.

---

Note –

The System Management Agent supports module deployment in the form of dynamically loaded modules or subagents. The agent also provides a proxy mechanism. You cannot recompile the System Management Agent.

---

See Chapter 6, Deploying Modules for information about how to deploy modules as dynamic modules and in subagents.

Features Added in System Management Agent

The SMA product includes the Net-SNMP agent, Net-SNMP developer tools, and Net-SNMP API libraries that enable the agent to be extended through modules. You can use the tools and APIs to create a module to support the custom features of a managed device. A management program can then be used for monitoring and managing the device.

The SMA extends the Net-SNMP agent to support the following MIBs:

• MIB II, described in http://www.ietf.org/rfc/rfc1213.txt, defines the structure of management information and the network management protocol for TCP/IP-based networks. The SMA implements all the object groups of MIB II except the EGP group.

• Host Resources MIB, described in http://www.ietf.org/rfc/rfc2790.txt, defines the structure of management information for managing host systems. The SMA implements the same host resources MIB that is included in the base Net-SNMP agent.

• Sun MIB is the MIB II with Sun-specific object groups added. Sun MIB was originally provided in the Solstice Enterprise Agents product beginning with the Solaris 2.6 operating system. The SMA implements the following groups from the Sun MIB:

  • Sun System group

  • Sun Processes group

  • Sun Host Performance group

Support for these MIBs is provided as static modules that run in the SMA agent. The agent was created by recompiling the Net-SNMP agent to include these modules.

The SMA provides an additional MIB for hardware, the Entity MIB, in an external dynamically loaded module. The Entity MIB is described in RFC 2737 at http://www.ietf.org/rfc/rfc2737.txt. The Entity MIB is implemented as a skeleton MIB, so that module developers can populate the various tables of the MIB. The Entity MIB can be used by a single agent for managing multiple logical entities and physical entities. For more information about the Entity MIB, see Chapter 9, Entity MIB.

Contents of the SMA for Developers

SMA includes the following content for developers:

• Developer tools, and Perl modules needed by the tools

• API libraries for using Net-SNMP functions

• API library for using the Entity MIB functions

• Demo modules, for demonstrating how to implement some types of data modeling

In addition, you can install the SUNWsmaS package, which contains the source code for Net-SNMP. See the Solaris System Management Agent Administration Guide for installation instructions.

File Locations of Developer Files

The developer files are installed in the locations that are shown in the following table.

Table 1–1 File Locations for Developer Content

Directory	Developer Content
/usr/demo/sma_snmp	Sample modules for demonstration purposes. See Demonstration Modules for more information.
/usr/sfw/bin	Command line tools that are useful for developers. For more information on these tools, see SMA Tools.
/usr/sfw/sbin	Executable files for the snmpd agent daemon and snmptrapd trap daemon, which provide the SNMP services.
/usr/sfw/lib	The 32-bit shared libraries that contain the API functions from Net-SNMP, and the libentity.so library, which defines functions for using the Entity MIB. This directory is supplied on all Solaris platforms. See API Libraries for more information.
/usr/sfw/lib/sparcv9	The 64-bit shared libraries that contain the API functions from Net-SNMP, and the libentity.so library, which defines functions for using the Entity MIB. This directory is supplied only on 64-bit Solaris on SPARC® platforms. See API Libraries for more information.
/usr/sfw/include	Header files needed by API libraries.
/usr/sfw/doc/sma_snmp/html	HTML documentation for Net-SNMP API functions.
/etc/sma/snmp	Configuration files that are used by the mib2c tool.
/etc/sma/snmp/mibs	The MIBs supported by the System Management Agent.
/usr/perl5/vendor_perl/5.8.3/sun4-solaris-64int	Perl modules needed by the mib2c tool.
/usr/share/sma_snmp	Source code for Net-SNMP. The code is provided in the SUNWsmaS package, which is not installed by default during Solaris installation. The package must be installed manually from the Solaris media. For instructions for installing the SUNWsmaS package, see the Solaris System Management Agent Administration Guide.

SMA Tools

The SMA includes many command-line tools, which are described in the sma_snmp(5) man page.

Each tool has an associated man page. Links to all the man pages for the product are included in Appendix A, SMA Resources. The tools are located in /usr/sfw/bin.

The snmp commands can be used to query the agent to test your modules. Read the man pages for detailed usage information.

API Libraries

The following API libraries are included with the SMA product:

• libnetsnmp

• libnetsnmpagent

• libnetsnmpmibs

• libnetsnmphelpers

• libentity

The libentity library is not part of Net-SNMP, but is a customization for the SMA product.

On SPARC platforms, the 32–bit Net-SNMP libraries are contained in the /usr/sfw/lib directory. The 64–bit Net-SNMP libraries are contained in the /usr/sfw/lib/sparcv9 subdirectory.

On x86 platforms, only the 32–bit Net-SNMP libraries are available in the /usr/sfw/lib directory.

The functions contained in the Net-SNMP libraries are used in the MIB modules that you create, as well as in the agent. Documentation from Net-SNMP for using the API functions is contained in /usr/sfw/doc/sma_snmp/html.

The SMA includes the same Net-SNMP API functions that are available with the open source Net-SNMP agent. API Functions includes a list of functions that are certified to work with the System Management Agent.

Demonstration Modules

The /usr/demo/sma_snmp directory contains several demonstration modules. The demo modules illustrate methods for creating modules to solve various kinds of information-gathering problems. Later chapters in this manual discuss the demo modules in detail. The following table lists and describes the demo modules. The table also provides cross-references to the sections that discuss the demos.

Table 1–2 Descriptions of Demonstration Modules

Module Name	Demonstrates	Discussed in Section
demo_module_1	Data modeling for scalar objects	Scalar Objects
demo_module_2	Data modeling for a simple table with writable objects	Simple Tables
demo_module_3	Data modeling for a general table	General Tables
demo_module_4	Implementing alarms	demo_module_4 Code Example for Alarms
demo_module_5	Persistence of module data across agent restarts	demo_module_5 Code Example for Persistent Data
demo_module_6	Running multiple instances of a module on a single host	Implementing Multiple Instances of a Module
demo_module_7	Dynamically updating multi-instance modules	Enabling Dynamic Updates to a Multiple Instance Module
demo_module_8	Implementing a module as an AgentX subagent	Deploying a Module as a Subagent
demo_module_9	Implementing objects that wait for external events without blocking the agent	SNMP Alarm Method for Data Collection
demo_module_10	Module design that handles long running data collections so that their values can be polled by an SNMP manager	SNMP Manager Polling Method for Data Collection
demo_module_11	How to use the Entity MIB API functions	SMA Entity MIB Implementation
demo_module_12	How use Solstice Enterprise Agents code templates and SMA code templates to help re-implement Solstice Enterprise Agents subagents as SMA modules	Migrating Solstice Enterprise Agent Subagents to SMA

Technical Support for Developers

Technical support for developers of modules for the System Management Agent is provided through the Net-SNMP open source community at http://www.net-snmp.org. You might find the developers discussion mailing list net-snmp-coders@lists.sourceforge.net to be helpful. An archive for the mailing list is located at http://sourceforge.net/mailarchive/forum.php?forum_id=7152.