test

Solaris System Management Agent Administration Guide

Chapter 5 Migrating From Other Agents

This chapter provides information and procedures on how to migrate handling of processes and tasks from other management agents to the System Management Agent. Migration of applications is explained in the Solaris System Management Agent Developer’s Guide. Migrating your applications to the SMA from any other agents you are using within the Solaris OS is not urgent. The exception to this rule is that of the Solstice Enterprise Agents software.

This chapter contains information on these topics:

Migration From Solstice Enterprise Agents Software

Support for the Solstice Enterprise Agents software is to be discontinued in a future Solaris release. The Solstice Enterprise Agents software master agent is snmpdx, located at /usr/lib/snmp/. Its functions are to be replaced by the System Management Agent master agent, snmpd. This agent is located in /usr/sfw/sbin/. For this reason, any Solstice Enterprise Agents subagents that developers have created must at some point be migrated to use the System Management Agent.

You can run the Solstice Enterprise Agents software and associated subagents concurrently with the SMA provided that SMA has been configured to load the seaProxy module. This purpose of this module is explained in Proxy Handling for Solstice Enterprise Agents Requests.

The Solstice Enterprise Agents software includes a subagent, mibiisa, that implements MIB-II and the sun.mib. In the System Management Agent, the functionality of mibiisa is implemented by the MIB-II portion of the System Management Agent.

Note –

In this Solaris release, the Solstice Enterprise Agents mibiisa subagent is disabled. All SNMP requests that are intended for mibiisa are handled by the MIB-II implementation in the System Management Agent.

ProcedureTo Prevent The System Management Agent Initializing at Boot Time

During the boot of the Solaris software, the SMA starts by default after the snmpdx has started. If you do not want to migrate your agent to the SMA, stop the SMA if it is running and edit the startup scripts. This editing prevents the System Management Agent from automatically starting at reboot.

  1. Open the snmpd.conf file.

    This file is located at /etc/sma/snmp/snmpd.conf

  2. Edit the snmpd.conf file.

    Instructions are included within the file for your convenience:


    ######################################
# SECTION: Admins who want to disable the snmpd daemon from 
# starting at boot time.
# Change DISABLE=NO to DISABLE=YES 
# DO NOT DELETE 
# DO NOT UNCOMMENT 
# DISABLE=NO 
#
# end ADMIN

    Change the NO for the DISABLE flag to YES, to prevent the snmpd daemon from starting at boot time.


    ######################################
# SECTION: Admins who want to disable the snmpd daemon from 
# starting at boot time.
# Change DISABLE=NO to DISABLE=YES 
# DO NOT DELETE 
# DO NOT UNCOMMENT 
# DISABLE=YES 
#
# end ADMIN

Proxy Handling for Solstice Enterprise Agents Requests

You do not have to migrate those SNMP subagents developed using the Solstice Enterprise Agents software to the SMA if the SMA has been configured to load the seaProxy module. The seaProxy module allows the Solstice Enterprise Agents software and associated subagents to run concurrently with the SMA.

Note –

The System Management Agent has been specifically customized to allow you to proxy incoming requests from the SMA to the Solstice Enterprise Agents software. This customization is a point of difference between the System Management Agent and the standard Net-SNMP implementation, version 5.0.9, on which the SMA is based.

Figure 5–1 Routing of Requests and Responses in the SEA Software

Diagram shows the interaction of SEA master agent, SMA master agent and subagents.

After the System Management Agent has been installed, requests that would have originally been handled solely by the Solstice Enterprise Agents software are handled differently.

These statements are not true if you have prevented the System Management Agent from initializing at boot time. For more information, see To Prevent The System Management Agent Initializing at Boot Time.

A proxy token is available to specify that any incoming requests under a particular OID are proxied to another host. See the snmpd.conf(4) man page for a description of this proxy statement.

Enabling the seaProxy Module

On arrival at port 161, incoming requests that are intended for the Solstice Enterprise Agents software are received by the SMA. If a proxy exists for the request, the request is passed to the snmpdx daemon. From the snmpdx daemon, the request is passed to the Solstice Enterprise Agents software subagents. The seaProxy module generates dynamic proxies, which are not found in snmpd.conf. Dynamic proxies are based on static and dynamic Solstice Enterprise Agents subagent registrations. The seaProxy module uses Solstice Enterprise Agents subagent registration details to generate dynamic proxies.

To enable the seaProxy module provided with the System Management Agent, verify that in the /etc/sma/snmp/snmpd.conf file, for systems running on x86 platforms, the following line is configured:


dlmod seaProxy /usr/sfw/lib/libseaProxy.so

To enable the seaProxy module provided with the System Management Agent, verify that in the /etc/sma/snmp/snmpd.conf file, for systems running on SPARC platforms, the following line is configured:


dlmod seaProxy /usr/sfw/lib/sparcv9/libseaProxy.so

When the seaProxy module loads, the seaProxy module immediately begins collecting information from the Solstice Enterprise Agents subagent. For this reason, among others, the snmpd daemon must start up after the snmpdx daemon. If the snmpd daemon starts up before snmpdx daemon, the SMA re-reads the Solstice Enterprise Agents software subagent registration table. The snmpdx daemon can be running before the snmpd daemon if, for example, you stop and restart the snmpd daemon.

The seaProxy module uses the information in the software subagent registration table to generate proxies for those Solstice Enterprise Agents software subagents that have already registered.

The seaProxy module does not generate proxies for the mibiisa subagent.

Proxy Statements for Incoming Requests

This section describes proxy statements for requests from the System Management Agent that are intended for the Solstice Enterprise Agents software.

When dynamic proxies have been generated, the System Management Agent proxy mechanism handles the forwarding of those requests to snmpdx. The seaProxy module generates dynamic proxies for any Solstice Enterprise Agents subagents that have to register with snmpdx. Therefore, Solstice Enterprise Agents subagents can still be used with the SMA. Note that support of the Solstice Enterprise Agents software, including snmpdx, is for a limited transitional time. Migrate as early as possible those subagents that you implemented with the Solstice Enterprise Agents, to use the System Management Agent.

Migration from Solstice Enterprise Agents software to the System Management Agent is done through the AgentX subagent. If you have Solstice Enterprise Agents modules that you specifically want to migrate to the System Management Agent, see the Solaris System Management Agent Developer’s Guide. This contains information on migrating modules, and explains the demo modules that are shipped with the System Management Agent. One of these demo modules is specifically designed to illustrate the migration process for Solstice Enterprise Agents modules.

If both the System Management Agent and the Solstice Enterprise Agents software are running, snmpd, the SMA master agent, should occupy port 161. During the boot process, the SMA service obtains an anonymous port. The service configures snmpdx to run on this port through the port entry in the Solstice Enterprise Agents configuration file, snmpd.conf, at /etc/snmp/conf/. After the change, the last few lines of the /etc/snmp/conf/snmpdx.reg file contain the new port number.

In this example, the new port number is 16161. The last few lines of the /etc/snmp/conf/snmpdx.reg file also contain other details:


agents =
{           
  {  name = "relay-agent"
     subtrees = { sun.2.15 }
     timeout = 900000000   
     port = 16161  
  }        
}

When Solstice Enterprise Agents subagents such as the DMI subagent start, they send requests to port 161 with a “private” community string. This “private” community string must be defined in the System Management Agent configuration file that was read at startup. Otherwise, Solstice Enterprise Agents subagents do not register successfully and die.

The SMA checks that a proxy statement is generated for the OID of the incoming request. The SMA performs this check if the “private” community string that the Solstice Enterprise Agents subagents hold in their requests is defined in the SMA configuration file that was read at startup. Once these strings are verified, the SMA changes the port of the incoming request to the port configured as described in this section. In this example, the port that is configured is port 16161.

Note –

After the seaProxy module has been enabled, you do not need to restart the Solstice Enterprise Agents software master agent, snmpdx, after restarting the SMA master agent, snmpd.

Figure 5–2 Routing of Requests With both SEA and SMA Present, Using the seaProxy Module and Proxy Statements

Graphic shows interaction of SMA and SEA software running together, with SEA proxy enabling SEA master agent to act as a subagent of the SMA.

Migration From the Sun Fire Management Agent

The Sun SNMP Management Agent for Sun FireTM and NetraTM Systems is a standalone SNMP agent that supports the following servers:

The Sun SNMP Management Agent for Sun Fire and Netra Systems provides SNMP–based access to hardware inventory and environmental monitoring. For more information, see the SNMP Management Agent Guide for the Sun Fire and Netra Systems. If you are running your Solaris 10 Operating System on any of the above servers, you should migrate from the Sun SNMP Management Agent for Sun Fire and Netra Systems to the SMA.

As with the System Management Agent, the Sun SNMP Management Agent for Sun Fire and Netra Systems is an SNMP agent that also uses a daemon that is named snmpd. If these two separate snmpd daemons are both running, make sure when stopping the snmpd daemon used by the Sun SNMP Management Agent for Sun Fire and Netra Systems, that you are stopping the desired daemon. The System Management Agent's snmpd daemon is located at /usr/sfw/sbin/snmpd.

You must migrate to the System Management Agent from the Sun SNMP Management Agent for Sun Fire and Netra Systems. You can not run the Sun SNMP Management Agent for Sun Fire and Netra Systems on port 161 or port 162.

The masfcnv Migration Script

This section provides a procedure to migrate the configuration of the Sun SNMP Management Agent for Sun Fire and Netra Systems to the SMA. The procedure uses the masfcnv script. This script is designed specifically for migrating to the SMA SNMP agent from the Sun SNMP Management Agent for Sun Fire and Netra Systems.

The ./masfcnv migration script is located at /usr/sfw/lib/sma_snmp. The ./masfcnv migration script performs the following functions:

After migration, the SMA provides SNMP access on its standard ports 161/162. The SMA provides access on other ports if you configure it. The SMA also provides SNMP access on the ports previously used by the Sun SNMP Management Agent for Sun Fire and Netra Systems. All ports provide access to the same set of OIDs. These OIDs include OIDs used by the SUN-PLATFORM-MIB as used by the Sun SNMP Management Agent for Sun Fire and Netra Systems. You can configure additional access controls to limit the visibility of data on a user basis.

If you are migrating user names and passwords from the Sun SNMP Management Agent for Sun Fire and Netra Systems, the engineID used by the SMA must be the same as that previously used by the Sun SNMP Management Agent for Sun Fire and Netra Systems. USM, used by SNMPv3, embeds the engineID into the keys used for authentication. If you have configured the SMA to use a different engineID to that of the Sun SNMP Management Agent for Sun Fire and Netra Systems, you must determine which engineID to use. If the engineID is different to that originally used by the Sun SNMP Management Agent for Sun Fire and Netra Systems, reset those passwords used by migrated users. For more information on the USM, see Using USM for Authentication and Message Privacy.

For further information on the masfcnv script, see the masfcnv(1M) man page.

Note –

In all cases, the Sun SNMP Management Agent for Sun Fire and Netra Systems agent runs independently of the Solstice Enterprise Agents' executable, snmpdx. If you stop the Sun SNMP Management Agent for Sun Fire and Netra Systems agent, you do automatically stop the Solstice Enterprise Agents software. You must migrate to the System Management Agent from the Solstice Enterprise Agents software. For more information, see Migration From Solstice Enterprise Agents Software.

ProcedureTo Migrate From the Sun SNMP Management Agent for Sun Fire and Netra Systems to the SMA

  1. As root, stop both the System Management Agent and the masfd agents.


    # svcadm disable svc:/application/management/sma:default
# /etc/init.d/masfd stop

    Any other agents that have been configured as subagents of SMA also need to be stopped and restarted after the migration is complete.

  2. Perform a test migration to determine the effect of running the migration script.

    A test migration is useful if you have made significant configuration changes to the System Management Agent.


    # cd /usr/sfw/lib/sma_snmp
# ./masfcnv --dry-run -i -p enable --select-community=agent

    If this dry run completes successfully, the proposed SMA configuration files are be presented in the standard output. Review this output before proceeding. The configuration of the Sun SNMP Management Agent for Sun Fire and Netra Systems is migrated to the SMA by the ./masfcnv migration script. If a conflict arises in the configuration, see the masfcnv(1M) man page for information on its resolution.

  3. Run the migration script.


    # cd /usr/sfw/lib/sma_snmp
# ./masfcnv -i -p enable --select-community=agent

  4. As root, restart both the System Management Agent and the Sun SNMP Management Agent for Sun Fire and Netra Systems.


    # svcadm enable svc:/application/management/sma:default
# /etc/init.d/masfd start

    The Sun SNMP Management Agent for Sun Fire and Netra Systems is then reconfigured to run as a subagent under the System Management Agent. Any other agents that have been configured as subagents of the System Management Agent also need to be restarted after the migration is complete.

    After migration to the SMA from the Sun SNMP Management Agent for Sun Fire and Netra Systems, the Sun Fire hardware instrumentation becomes accessible to SNMP applications through the SMA. The SMA uses the same port that was previously used by the Sun SNMP Management Agent for Sun Fire and Netra Systems.