Providing System Management Information:
A DMI Tutorial

Clemente Izurieta
mailto:wombat@fc.hp.com
phone: (970) 898-2423)

Andrew Nielsen
andrew_nielsen@hp.com
phone: (970) 898-7893)
Fax: (970) 898-2423

Hewlett-Packard Co.
3404 East Harmony Rd.
Ft. Collins, CO 80525

Abstract

One of the biggest challenges presented to systems administrators and systems integrators is the ability to access distributed heterogeneous system management data from a single point. Today, the Desktop Management Interface (DMI) provides a consistent RPC-based set of interfaces for retrieving system management information. The calls are the same regardless of whether a remote machine or a local machine is being accessed. A component interface is also available to developers of instrumentation data. Other DMI components include a format (Management Information Format – MIF) for describing the characteristics of managed information, and a service provider entity that manages communications between components and management applications.

DMI is readily available on Win9x, NT, and many Unix platforms. This paper focuses on the current implementation of DMI on HP-UX. We discuss information made available by HP-UX’s two components, namely, the HP-UX component instrumentation, and the software component instrumentation. We cover the benefits provided to systems administrators by existing tools such as the log viewer, the browser, and the OpenView ITO integration kit, and by emerging technologies such as the System Configuration Repository (SCR). Part of HP-UX’s DMI offering is the Software Development Kit (SDK) which provides all the necessary libraries, header files, and tools that allow a software developer to create either management applications or component instrumentation. We provide an overview of the DMI architecture and how the SDK is used to develop DMI-enabled software.

Introduction

The purpose of this paper is to introduce the reader to Hewlett-Packard Company’s offering of the Desktop Management Interface (DMI) technology. Originally designed as a standard for managing desktop computers, DMI has emerged as one of the essential and most widely used industry standards in management middleware today. The Desktop Management Task Force (DMTF) is chartered with the development and support of the DMI standard, which today covers not only the desktop space, but also hardware, software, and peripheral specifications being implemented on Unix environments.

Developing DMI-enabled applications has allowed vendors to concentrate on providing value-add to their products without the additional worry of identifying a suitable middleware technology. With DMI, vendors are assured of providing the most agnostic instrumentation possible today.

We first describe the DMI architecture as defined by the DMTF. This provides a solid base of the technology to the reader. We then go on to expand on the architecture to describe what Hewlett-Packard Company provides in terms of component instrumentation, support for software developers, and tools for systems administrators.

DMI Architecture

DMI is a layer of abstraction between management applications, and instrumentation providers. Management applications fall under many categories, including configuration management tools that allow the administrator to view and change information on systems, as well as reactive monitoring and operations tools that allow administrators to be notified of events and act on them. DMI supports both. Components are the logical entities on a system such as hardware, software, etc. that can be managed by DMI.

Developers use the Component Interface (CI) to describe access to management information, thus enabling the component to be managed by DMI management applications. Likewise, developers use the Management Interface (MI) to access and manage components. These interfaces provide the necessary abstraction mechanism that shields developers from knowing how to access or provide information on different operating systems. All DMI-enabled management applications can access any component on any system that implements DMI.

Mediation between these interfaces is provided by resident code (a daemon), which handles communications (local or remote), security, serialization of requests, registration, delivery of events, and any other services that control the flow of information between them. On HP-UX this daemon is called dmisp and is started at boot time and respawned by init. All the components, and dmisp exist within a single system. Management applications can run on any DMI-enabled system, and communicate with dmisp via DCE RPC. The dmisp can handle many-to-many relationships. Any number of management applications can post requests to a dmisp, which in turn can access any number of components registered on the system.

Within DMI, all information about components is represented using the Management Information Format (MIF), and stored within DMI in a lightweight database. Each component has a corresponding MIF file that describes its manageable characteristics and how to obtain this data. The dmisp uses this model to make sense of the available data, and thus understand how to get at this data.

HP-UX DMI Architecture

Data Model

This section describes the data model that DMI uses, and the two types of data that the Component Interface (CI) supports. The CI is an optional procedural interface implemented by HP. It is fully synchronous, and serializes all requests to components, thus alleviating the need to produce re-entrant code by component developers.

Component developers create a model of the entity they want to manage and describe it using the Management Information Format (MIF) syntax. This model is referred to as a component. For every component, there is a MIF file. Much like in the object model, the attributes that represent the managed entity are collected into named groups, however, none of the typical characteristics associated with object oriented models such as references, inheritance, or polymorphism, are supported by the MIF language.

DMI Data Model

Groups may be scalar, where all the attribute values represent a single instantiation of the group itself, or they may have multiple instantiations. In the latter case, groups are called tables, and certain attributes are designated as key attributes in order to differentiate between the rows of the table.

Data stored by attributes can be either dynamic or static. Dynamic data constantly changes, for example, the number of users logged into a system. Dynamic data requires component instrumentation, and the values of the attributes do not reside in the DMI database. When the data is requested by a management application, dmisp knows to query the correct component. Static data never or rarely changes, for example, the name of the company manufacturing a particular component. Static data does not require component instrumentation, and all attribute values reside in the database. When the data is requested by a management application, dmisp only needs to access the MIF database.

HP-UX Components

At this time, HP provides two components with its DMI offering. They are the "HP-UX Standard Groups Definition" Component and the "HP-UX Installed Software" Component.

HP-UX Component Instrumentation (hpuxci)

It is beyond the scope of this paper to describe all the groups and attributes in the HP-UX Standard Groups Definition MIF. For detailed information on the definition of this component refer to http://www.dmtf.org/tech/apps.html which contains links to all DMTF standard components including the UNIX Standard Groups Definition.

The purpose of this component is to provide base information about the HPUX system. This component provides the following groups. A brief description follows each group name telling the information provided in the group.

Group

Description

ComponentID

Component information (required)

General Information

System general information; system name, etc.

System Contact Information

System contacts; list of contacts

Operating System

Operating system information; OS name, version, etc.

Host System

Dynamic system information; uptime, number of users, number of processors etc.

Host Physical Memory

Main memory size

Host Storage

Logical storage devices; list of storage information

Host Device

Device information; list of devices

Processor

Processor information; list of processors

System Cache

Main System Caches; cache level, speed, size, etc.

Host Disk

Disk information; list of disk devices

Host File System

File system configuration; list of file systems

Network Adapter Port

Attributes associated with a system’s network adapater; list of network adaptor ports

Network Adapter Device Driver

Attributes associated with a system’s network adapter device driver; list of device drivers related to above

Process Information

Information on running processes; list of all processes on the system

Table 1. HPUXCI Information

HP-UX Software Component Instrumentation (swci)

Again, it is beyond the scope of this paper to describe all the groups and attributes of this component.

The purpose of this component is to provide information found in the POSIX.1387.2 software distributor. The "sw" suite of commands found on HP-UX is used to install, update, and remove software. This component provides a standard (DMI) way to get at most of the information found using the swlist command. The following lists all the groups in the HP-UX Installed Software MIF and a brief description of the group.

Group

Description

ComponentID

Component information (required)

Software Location

The installed location of the software

Vendors

List of vendors associated with installed software

Bundles

List of bundles installed on this system

Bundle Contents

Software specifications of installed bundles

Products

List of products installed on this system

Product Contents

Software specifications of installed products

Product Control Files

List of each products control files

Subproducts

List of subproducts installed on this system

Filesets

List of filesets installed on this system

Fileset Contents

Control file names that make up the fileset definition

Fileset Dependancies

List of fileset dependancies

Fileset Control files

List of vendor-supplied control files.

Fileset Files

List of all installed files

Table 2. SWCI Information

The Software Development Kit

The software development kit provides all the necessary support required by developers to implement either management applications, or component instrumentation. It is comprised of a set of libraries, namely libdmi_mi.sl, which contains the management and indication interfaces, and libdmi_ci.sl, which contains the component interfaces. The SDK also contains all the necessary header files, and some example code to help developers understand the basic skeleton of these applications. The following sections cover the major areas pertaining to developing either components or applications.

Writing MIF Files

Component developers are required to create a MIF file that describes the entity they want managed. Application developers benefit from looking at MIF files so that they can get a good understanding of what a component provides. For application developers, this is not essential, as most administrative tools allow the browsing of components. During initialization, dmisp detects if the database is corrupt o not there, and creates a new database containing the dmisp MIF file (default), and any other MIF files in the /usr/dmi/mif/C directory. If a component has MIF files residing on other directories, then it is the developer’s responsibility to re-register the MIF files withdmisp.

Each MIF file contains one, and only one component definition, which has the following syntax:

    Start Component
         Name = "Component Name"
         [description = "Description String"]
         [pragma = "Pragma String"]
         [component definition goes here]
    End Component

In addition, a MIF file contains additional definitions for groups, paths, enumeration, and attributes. For example, the following is a MIF file from one of the examples provided with the SDK.

    Start Component
      Name = "HP Component Instrumentation Example MIF"
      Description = "This is an example MIF"
		 
      Start Group
        Name = "ComponentID"
        Class   = "DMTF|ComponentID|001"
        Description = "This group defines common attributes"
                      "This group is required."

        Start Attribute
            Name    = "Manufacturer"
            ID      = 1
            Description = "Org. that produced this component."
            Access  = Read-Only
            Storage = Common
            Type    = String(64)
            Value   = "Hewlett-Packard."
        End Attribute
            //====================================================
            // Component ID attributes 2-6 deleted for clarity
            //====================================================
        End Group

        Start Group
          Name = "System Group"
          Class = "HP|System Group|001"
          ID = 2
          Description = "System Group"

          Start Attribute
              Name = "Total Physical Memory"
              ID = 1
              Description = "Physical memory on this system."
              Type = int64
              Access = Read-Only
              Storage = Specific
              Value = 0
          End Attribute
        End Group
      End Component

Writing Components

Developers have the option of developing direct interface components, or overlay components. Direct interface components are separate applications that run in their own process space, and are loaded into memory independently of dmisp. On HP-UX these are daemon applications, and are the recommended method for developing instrumentation, especially when the amounts of dynamic data are high. Overlay components are implemented as shared libraries that are loaded by dmisp into the same process space. All overlay components must reside in /usr/dmi/overlay to run. Overlay components are advantageous when the overhead to get and set attributes is low, however they can cause dmisp to crash if they receive segmentation violations, or perform illegal operations.

The following is a simple pseudo code algorithm that describes the major steps in building a component. For a thorough understanding we recommend that you look through the examples provided by Hewlett-Packard.

    // Register with the local service provider.
    DmiRegister();
    // Set up a number of data structures to support the next call.
    // Add the component to the MIF database.
    DmiAddComponent();
    // Set up the necessary data structures to support callbacks.
    // Register a callable interface for components that have resident
	// instrumentation code.
    DmiRegisterCi();
    // Wait on the socket communications thread for CI calls, or the
	// indications server thread for management applications.
    DmiMainLoop();
    // The service provider can now call the corresponding functions
	// implemented by the component.

To develop components, the developer must link its instrumentation with libdmi_mi.sl, and with libdmi_ci.sl.

Writing Management Applications

To write management applications a developer needs to have a system that is DCE RPC enabled. The interface is procedural, and allows developers to access, set, and manage any system that has DMI capabilities.

The following is a simple pseudo code algorithm that describes the major steps in building management applications. For a thorough understanding we recommend that you look through the examples provided by Hewlett-Packard.

    // Set up the data structure that contains information about the
	// node we want to register with.
    DmiSetDefaultNode();
    // Register with dmisp on the local or remote node.
    DmiRemoteRegister();
    // Set up this application to be an indications server if desired.
    // The following section explains this procedure.
    … code to set up an indication server…
    // List components to obtain the component ID we want.
    DmiListComponents();
    // Perform desired get/set operations.

Event Management

DMI allows components to generate events, and applications to catch those events of interest. Events are known as indications and make up part of the management interface API. In order for a management application to receive indications, it must first register with the dmisp running on the host of interest. Registration is accomplished by calling the DmiRemoteRegister() API, then creating a DCE endpoint via DmiIndicationListen(), adding the correct entries in the appropriate dmisp tables, and finally registering the procedural entry points for the monitored indications.

When dmisp running on the host generating indications needs to communicate such an event, it needs certain information. First, dmisp needs addressing information of management applications registered to receive indications, and second, dmisp needs to know the components and groups that are of interest to the management applications.

All the information needed by dmisp is available under two tables. The "SP Indication Subscription" table contains addressing information of management applications registered with this node, and the "SP Filter Information" table contains a certain number of component and group entries that are associated to entries in the former.

When a management application registers to receive indications it sets up a set of callbacks that the indication server calls in response to the remote events sent via the indication client. A management application can register for any one of the following types of events:

The management application sets up a DmiIndicationsFuncs_t data structure that has pointers to callback functions to handle each of the events. Once the structure is filled out, a call to DmiSetIndicationCallbacks() is issued to complete the process.

Security

Hewlett-Packard provides three levels of security as part of its solution for DMI 2.0. First, you must be the root user when administering dmisp, or any essential DMI files such as the database. Second, as the root user, you must set up the /var/dmi/dmiMachines file to provide access to remote systems. In this file you essentially provide machine level access to remote hosts by just adding their fully qualified domain names, or IP addresses. And finally, there is a group level security mechanism for finer granularity within components.

The group level security mechanism is based on the management application providing a security token to the component instrumentation. The token is passed as part of the keylist for the operation. If the management application does not hold the correct token, then all access to the group is denied.

DMTF has released the new DMI 2.0s specification that accounts for the security shortcomings of the original release. DMI 2.0s implements all the interfaces of DMI 2.0 plus some additional logging interfaces and relies on the security mechanisms implemented by RPCs, and the operating system. Hewlett-Packard is currently investigating the implementation of this specification.

Administrative Tools

A number of administrative tools are available to help facilitate the management of components on a single system. These tools are intended to aid with simple tasks only. They are not enterprise tools per se, however some of these simple tools do provide remoting capabilities.

DMI Log Viewer

The DMI Log Viewer is a graphical application that allows a system administrator to view the many messages logged by dmisp. Messages can be viewed by time range, user range, or message levels. The actual location of the log file is /var/dmi/log/dmisp_log, and is invoked with the command /usr/dmi/bin/dmilog_viewer.

DMI Browser

The DMI Browser is a graphical application designed for viewing the contents of dmisp’s database. The administrator can connect to a local or remote database and view its contents. The browser is invoked by the /usr/dmi/bin/browser command. Initially, only the local system’s database is available for viewing, but by using the Actions menu, you can connect to multiple systems. Clicking on the icon that represents a system, displays the list of components on the system, and similarly clicking on a component lists its groups, which eventually allow the administrator to display attribute values.

The DMI Browser is a read-only application and does not permit any user to change the state of a system, nor the dmisp’s database.

OpenView ITO Integration Kit

The OpenView ITO Integration Kit is a set of files with static configuration information that allows an ITO administrator to launch the DMI Browser and the DMI Log Viewer remotely. The kit also allows the remote monitoring of dmisp via its log file, dmisp_log. An ITO agent runs on the system being monitored, and parses the log file to look for certain patterns using regular expressions. The agent is configured to detect component added, deleted, registered, and unregistered messages. When either of these messages is matched, the agent sends a message to the ITO Event Browser that displays the message along with a number of additional attributes. An administrator has the option to ignore, manually or automatically perform an action, or launch a tool such as the DMI Browser to further investigate the situation.

System Configuration Repository (SCR)

The System Configuration Repository (SCR) is an application that tracks changes in a system's configuration over time. SCR can take snapshots of system configuration information periodically or manually before and after major configuration changes. SCR provides tools to filter and compare snapshots from different times or from different machines.

The information that is stored in snapshots comes from DMI, and is stored in a database. Currently, the configuration information available through DMI includes system information such as devices, volume groups, file systems, kernel parameters, etc. and information about software products including information such as bundles and filesets. (Developers can write their own DMI instrumentation in order to expand the information stored in SCR.)

SCR is highly configurable and can be used in many ways. For example, SCR can be used to maintain c onsistency on a system or across systems, or to a recover a machine's configuration information in case of disaster, or to maintain consistency between test systems and production systems.

Summary

As DMI technology becomes more pervasive, we expect to provide more components and a more robust set of tools for administrators and developers. We also expect more partners to begin enabling their products for DMI. Both, providers of component instrumentation and management applications benefit from this middleware heterogeneous technology by investing time in their products, waning the need to worry about which APIs need to be supported, and which tools can access their technologies.

Examples of new technologies using DMI include the System Configuration Repository (SCR) as described in the previous section. The integration with ITO provides the ability to monitor events from an enterprise console, and more enhancements are possible to provide true indications monitoring. For developers, further enhancements are being investigated, such as a skeleton code generator, a MIF parser, command line interfaces, etc.

Hewlett-Packard Company is an active participant of the DMTF, and as new standards emerge, such as the security specification for DMI (version 2.0s), they will continue to be enforced in our offering of HP-UX.

References

"Desktop Management Interface Specification". Desktop Management Task Force, Inc. (1998). Version 2.0s.

"HP-UX DMI 2.0 Developer’s Guide". Hewlett-Packard Co. (1998).

John Shirley, Wei Hu, David Magid. (1994). "Guide to Writing DCE Applications". Second Edition. O’Reilly & Associates, Inc.

Robin Lee Peters. (1998). "Managing System Configuration Changes". InterWorks ’99.

Author | Title | Tutorial | Sessions | Home

Send email to Interex or to the Webmaster
@Copyright 1999 Interex. All rights reserved.