Solstice Enterprise Manager 4.1 Developing C++ Applications

Chapter 17

Writing RPC Agents for Solstice EM

Solstice Enterprise Manager (Solstice EM) supports agents written to the Site/SunNet/Domain Manager (SNM) interfaces and libraries. SNM agents can communicate with the Solstice EM MIS via the Solstice EM MIS RPC interface. The Solstice EM MIS RPC interface translates from SNM ONC RPC to the Solstice EM PMI.

This chapter explains how to write RPC agents for Solstice EM.

• Section 17.1 Manager-Agent Model
• Section 17.2 Types of Agents
• Section 17.3 Steps for Writing an Agent
• Section 17.4 Solstice EM Integration

17.1 Manager-Agent Model

The SNM design is based on the manager/agent model in the Open Systems Interconnection (OSI) management framework. The manager is a process started by the user (for example, the Solstice EM MIS). The agent is a process that collects data from the managed resource and reports it to the manager.

The Manager/Agent Services libraries provide the management infrastructure and handle the communication services. The agent and manager need not be concerned with the underlying networking involved in their communication. The agent process is concerned only with collecting data from the managed resource. The manager and agent processes make use of the Services through Application Programming Interfaces (APIs).

Another aspect of the manager/agent model involves the definition of management data. Open management standards--for example, OSI and the Simple Network Management Protocol (SNMP)--specify that agents abstract the properties (or attributes) of managed resources into data items (for example, "how busy a CPU is" becomes a value between 0 and 100). In SNM, the attributes for a managed resource are described in the agent schema. The agent is able to respond to the manager's request, because both use the same data definitions for the managed resource.

17.2 Types of Agents

All SNM agents communicate with the manager in the manner just described. Agent types differ in the relationship with their respective managed resources.

Agents can directly or indirectly access managed resources. Most of the SNM agents provided with Solstice EM manage resources on the Sun workstations where they are installed. For example, the hostmem agent uses the same mechanism as netstat -m to get memory utilization data.

The second type of agent provides the ability to manage objects that are not directly accessible. Such agents are called proxy agents. Proxy agents run on Sun workstations, called proxy systems, and use protocol translation mechanisms to provide the necessary access to the managed resources. The proxy system may be the workstation on which the Solstice EM MIS is running or another workstation on the network.

The ping proxy agent provides the ability to test the reachability of Internet Protocol (IP) devices, translating manager requests into Internet Control Message Protocol (ICMP) echo requests. Similarly, the hostperf proxy agent uses the rstat protocol to gather host statistics.

Proxy agents provide a mechanism allowing SNM to extend into virtually any domain. The Simple Network Management Protocol (SNMP) proxy agent provides the ability to manage any device that supports SNMP, the widely accepted standard management protocol for the TCP/IP world.

17.3 Steps for Writing an Agent

Before an agent is written, access to the managed resource must exist (that is, code must be written to get the required management data).

---

Note – The prefixes NETMGT, Netmgt, and netmgt are reserved for network management functions.

---

From a high-level viewpoint, the steps involved in implementing an agent are as follows:

• Assigning a name to each discrete management data item--attribute. For instance, if the input packet count is an attribute, an appropriate name is ipkts.
• Determining the data type for each attribute. In the example, ipkts is an integer.
• Using the attribute information to form the agent schema file, which will be specific to the particular agent.

  ---

  Note – The conversion of SNM schema files into GDMO files for use with the Solstice EM MIS requires that only alphanumeric characters be used for names. Therefore, use special characters with caution.

  ---

• Expanding the original code written for accessing the managed resource to incorporate the agent schema definitions.
• Writing the code that uses the SNM Agent Services library. This includes code for agent initialization, request handling, and error reporting.
• Incorporating any agent-specific error messages into the agent schema file.
• Testing and integrating the completed agent code and schema file with Solstice EM.

17.4 Solstice EM Integration

Once you are satisfied your agent is performing correctly, install it where you want it to run on the systems, then integrate it with the Solstice EM MIS database.

17.4.1 Installing the Agent

For each system where you want your agent to run,

• Copy your agent to the directory where the other SNM agents are installed. If no SNM agents have been installed on the system, first run the SNM utility getagents.
• Add the following entry to snm.conf:

  na.my-agent-name 0

This will set your agent security level on this host to zero (no security checking). Optionally, you can set your agent to any value between 1 and 5.

• Add an entry for your agent to /etc/inetd.conf to allow inetd to automatically start your agent when a manager sends a request to your agent. Here's a summary of the inetd.conf(5) file format.

  na.agent-name/10 tli rpc/udp wait root agent program absolute pathname agent- name arguments

For example, the entry for the iproutes agent (on a Solaris 2.x machine) is:

na.hostmem/10 tli rpc/udp wait root /opt/SUNWconn/snm/agents/na.iproutes na.iproutes

• Force inetd to reread its configuration file by sending it a SIGHUP signal:

  hostname% kill -HUP inetd's process ID

17.4.2 Updating the Solstice EM MIS Database

Solstice EM uses GDMO descriptions, rather than the schema files used by SNM products, to represent the managed object classes available to the management database. Thus, the Solstice EM Schema compiler (em_snm2gdmo) is used as the first step in converting the SNM schema files into GDMO descriptions used in Solstice EM.

To translate an SNM schema file, run the Schema compiler with the file to be translated as an argument (filename).

hostname% em_snm2gdmo < filename

The output of the translation is a GDMO document, with a name of the form filename.gdmo, and an ASN.1 document, with a name of the form filename.asn1. You must then pass the GDMO file through the GDMO compiler.