6.6.2 Terminating the Subagent

Normally, the snmpXdmid daemon runs forever, unless explicitly killed or a disastrous situation is encountered (for example, lack of memory).

6.6.3 MIF-to-MIB Mapping

The mapping of MIF to MIB involves the assignment of an OID from the MIF. A translator (miftomib.EXE) is available to build a file extension of .MAP and a .MIB file from a MIF definition. The translator may be used as a tool to generate the .MIB and the .MAP files. Or, the map file may be generated manually, using a text editor. All .MAP files located in the directory under /var/dmi/map are scanned and included in the subagent translation table.

Figure 6-2 MIF-to-MIB Mapping

The map file format is shown in Table 6-2.

Table 6-2 Map File Format

The design approach is to map the DMI component ID, group ID, and attribute ID to MIB object IDs. The managing entity must predetermine the MIB definition to be used by the mapper to map to the MIF definition. Using a miftomib translator to produce the MIB mapping file facilitates the mapping.

The map file is generated externally to the mapper. A mechanism is required to notify the mapper of new or updated files on the system in order to enable the new MIF definitions to be dynamically added. This is accomplished by using the DmiGroupAdded indication, delivered by dmispd, when the mapper rereads all the .MAP files.

See Figure 6-3 for examples of the OID prefix and the completed OID layout. The mapping file is used by the mapper to register the OID with the SNMP agent relay and to correlate the OID with the component name. It contains the component ID and the group keys, in case the group contains tabular data.

The mapper puts no restriction on what the OID prefix may be. That is controlled by the network administrator. Any OID may be entered into a .MAP file, provided the SNMP Master Agent allows the subtree registration. In the case of failure, the .MAP file needs to be changed for the OID correction.

Figure 6-3 MIB OID Layout

Parts of the object identifier are shown below:

• Object Identifier: OID-prefix: 1.3.6.1.4.1.42.2000.x

• OID for Groups: .1

• Object-type for Table: .iGroupID

• Object-type for Row: .1

• Attribute Identifier: .iAttributeId

• Instance Identifier: Indexes: .iComponentId <keys>

The example in Table 6-3 shows OIDs for client access attributes (no keys).

Table 6-3 OIDs for Client Access Attributes

Retrieving objects via the GetNext operation must be specially handled, since MIB tables are traversed column-by-column and MIF tables are traversed row-by-row.

6.6.4 Specific Mapping Considerations

The DMI specification has reserved ComponentId=1 for the DMI SP. The specification also defines the MIF file for the SP. The network administrator must take this into consideration when creating the .MAP files or when specifying the OID preference as a command-line parameter to the miftomib utility. Every MIF file must contain a standard group with ID 1.

Table 6-4 ComponentID Group Translated to DMI MIB

With this mapping, any MIF that is installed with the DMI has at minimum the ComponentID Group visible to management applications. All attributes within this group have read-only access. As MIFs become standard and are translated into MIBs, they become accessible but have additional anchor points in the DmtfGroups tree. For example, if the software MIF were defined, the translation would provide a DMISW MIB and be anchored as follows:

enterprise.sun.DmtfGroups.DMISW(2)

or

1.3.6.1.4.1.42.2000.3

Managing applications must be prepared for the same component to be visible in two different branches of the DmtfGroups tree.

Additional OID prefixes:

• DMIHW (3)

• DMIPRINTER (4)

6.7 The DMI Mapper Configuration File

The default configuration file snmpXdmid.conf is located in the directory /etc/dmi/conf. You may alternatively provide another path to this program as a command-line option for the location of the snmpXdmid.conf file.

6.7.1 WARNING_TIMESTAMP

snmpXdmid must subscribe to the DMI SP to receive indications. According to DMI 2.0 specifications, this subscription is valid only up to a particular timestamp. The SP issues a warning subscription notice before it ends the subscription. This timestamp indicates the time a subscription warning was issued.

The default value is:

WARNING_TIMESTAMP = 20101231110000.000000-420

6.7.2 EXPIRATION_TIMESTAMP

This indicates the time that a subscription actually expires. No indications are received after this time, unless they are re-subscribed. By default, a future timestamp is chosen so the subscription practically exists forever. This is done so that snmpXdmid always retains its indication subscription with the SP.

The default value is:

EXPIRATION_TIMESTAMP = 250101231120000.000000-420

6.7.3 FAILURE_THRESHOLD

This indicates the number of attempts by DMI SP in order to deliver the indications to snmpXdmid, in case it encounters errors before it drops the indication and clears the subscription entry.

The default value is:

FAILURE_THRESHOLD = 1

6.7.4 TRAP_FORWARD_TO_MAGENT

A non-zero value results in snmpXdmid generating an SNMP trap following an indication from the DMI SP. A zero value results in no SNMP trap generation following a DMI SP indication.

The default value is:

TRAP_FORWARD_TO_MAGENT = 1

6.8 Generating a MIB File

SNMP management applications typically require a MIB defining managed data. For each MIF file that you want to make accessible to an SNMP manager, you must generate an SNMP MIB that corresponds to the MIF file. The MIB must then be loaded at the management application that uses the definitions in the MIB to communicate with the DMI component. The management application may also make the MIB information available to browsers and other MIB-based applications.

To generate an SNMP MIB from a MIF file, use the miftomib utility at the command prompt. After you create the MIB file, you may transfer it to the SNMP management application.