The Object Data Manager (ODM) on AIX
Jeff Courington The Object Data Manager, or ODM, is a set of utilities that AIX uses to keep track of configuration information. The complexity of the ODM command set is masked by the configuration utility called SMIT. SMIT -- the System Management Interface Tool -- is a user-friendly menuing system used to configure almost everything on AIX. System administrators new to AIX may not even have heard of the ODM -- if they have, they are probably not aware of its uses. Since a major concern about AIX is that it is so different from other UNIX systems, and since much of this difference can be attributed to SMIT and the ODM, a proper understanding of these utilities can ease some of the fears of working on AIX. Defining the Object Data Manager The ODM is a set of utilities that can be used to create, edit, and delete a set of objects in a file. Only in a very few cases should the ODM be altered manually. Typically, such cases result from bugs related to operating system upgrades. The ODM consists of three types of files: predefined, custom, and miscellaneous. The predefined files contain all of the known configurable devices, device drivers, and services. The customized files contain information about which devices are configured on the specific system. These files are referenced and may be modified during a system boot. The miscellaneous files contain information such as configuration rules, licensed program products (lpp), system inventory, configuration information for the inet server, list of services control led by the System Resource Control (SRC), and even the menu information for SMIT. In this article I concentrate on the first two classifications, the predefined and custom objects. AIX comes with a wide array of predefined objects. Hardware manufacturers even add items to the ODM for their devices if an appropriate entry does not already exist. These objects are stored in the predefined files until the actual device is configured on the system, at which point information is added to the customized files. This means that configuration information for a device is kept in any number of predefined and customized files. To piece together the complete configuration, it is necessary to follow the structure through these files. The default directory for the ODM is /etc/objrepos. On 3.1.x of AIX all of the files were kept in the directory and its subdirectories. On 3.2 some of the files have been moved to /usr/lib/objrepos and are represented as symbolic links. The ODM commands use the ODMDIR environment variable to access the correct ODM directory. Even though on 3.2 some of the files have been moved to /usr/lib/objrepos, the default ODMDIR directory is still /etc/objrepos. By changing the ODMDIR directory in your environment, you can set up an alternate directory for customized applications using the ODM commands. IBM warns that the default directory is specifically for system data and should not be used for storing user defined object files. Getting Started A quick look at the /etc/objrepos directory shows that the ODM is really managing multiple files. Each of these files has a special meaning to the system; they should not be manually altered unless you are very sure of what you are doing. The Pd* Files The first set of files that you'll need to understand are the Pd* files, which contain the predefined system objects. The entries in these files are loaded from the installation tape; under normal use, they should not be edited. PdDv -- The Predefined Device object class file contains an entry for every known device on the system. It includes definitions for all of the configurable printers, expansion cards, device drivers, logical volumes, volume groups, and many more. Figure 1 shows output from the ODM editor, odme, for the PdDv entry for the ethernet adapter. Table 1 lists the fields included in a PdDv entry. PdAt -- The Predefined Attribute object class file contains device-dependent information not found in the PdDv file but relevant to device configuration. These attributes become the default values if they are not modified. Modified attributes are written to the CuAt. The uniquetype field actually consists of the first three entries in the PdDv: type, class, and subclass. These entries are used to link the attributes to the specified device. This mechanism ensures a unique name for each device. Figure 2 shows output from using the ODM editor, odme, for the PdAt entry for the ethernet adapter. PdCn -- The Predefined Connection object class file contains information about how devices physically connect to the system. Figure 3 shows output from the ODM editor, odme, for the PdCn entry for the ethernet adapter. The Cu* Files The second set of files to understand are the Cu* files, which contain the customized system objects. CuAt -- The Customize Attribute files contain non-default values for the specified device. The default values are kept in the PdAt file. Both files must be searched to find all of a device's attributes. A defined ethernet adapter entry would look like that in the PdAt file; otherwise the entry would not exist. CuDep -- The Customize Dependency object class file contains logical dependencies between devices. The file does not contain customized dependencies between two physical devices. If present, these would be in the CuDv file. Figure 4 shows output from the ODM editor, odme, for the CuAt entry for the ethernet adapter. CuDv -- The Customize Device object class file contains physical dependencies. Figure 5 shows output from the ODM editor, odme, for the CuDv entry for the ethernet adapter. Table 2 lists the fields for a file entry. CuDvDr -- The Customized Device Driver object class file is managed through special device configuration library routines to guarantee atomic changes. Figure 6 shows odme output for the CuDvDr entry for the ethernet adapter. CuVPD -- The Customized Vital Product Data object class contains customized data recorded on the topology disk for use by IBM Customer Engineers. Viewing ODM Data The lsdev command can be used to safely query the ODM database. This command lists the device configuration of the system, though some objects in the ODM do not show up on this report. For instance, the CuAt file displays details about the configuration of inet0, while the lsdev report shows only the name, current state, and description. The lsdev command actually gets its information from the PdDv and CuDv files. The lsdev syntax is as follows:
Usage: lsdev -C [-c Class][-s Subclass] \ [-t Type][-S State][-l Name] [-r ColumnName| -F Format][-H] \ [-f File ] lsdev -P [-c Class][-s Subclass]\ [-t Type][-r ColumnName| -F Format] [-H][-f File ] lsdev -h
The lsdev command format closely resembles the fields from the ODM. The class, subclass, and type options are the same as the field definitions for the PdDv and the CuDv. The previous data can be verified by running the lsdev command.
lsdev -C -l ent0 ent0 Available 00-06 Ethernet High-Performance LAN Adapter
The lsattr command can also be used to view the ODM in more detail. This command actually queries the PdAt and CuAt files. The syntax for the lsattr command is as follows:
Usage:
lsattr {-D[-O]| -E[-O] | -F Format}
-l Name [-a Attribute]...[-H]
[-f File]
lsattr {-D[-O]| -F Format}{[-c Class]
[-s Subclass][-t Type]}
[-a Attribute]...
[-H][-f File]
lsattr -R {-l Name | [-c Class]
[-s Subclass][-t Type]}
-a Attribute [-H]
[-f File]
lsattr -h
Again the previous data about the PdAt and CuAt files can be verified by running the lsattr command (see sample output in Figure 7). A Reporting Tool All system administrators must prepare for a system crash, with the worst possible conclusion contingency being to rebuild the system from scratch. The utility program list.dev (Listing 1) will help gather the device configuration information into one organized report. This report can be modified to show customized configuration information for all of the devices on the system. I only included customized entries for the tty, lp, and rmt devices. A sample listing for a tty device from this report will look like this:
Terminal = tty1 speed 9600 BAUD rate True parity odd PARITY True bpc 7 BITS per character True
If you need more information about the tty, simply edit the -a option on the lsattr. Conclusion I find the lsdev and lsattr commands very useful for a quick look-up of device configuration. If you have used SMIT, you will probably agree that it is great for configuration but overkill for a simple query. Only once have I found it necessary to manually edit the ODM. It happened when I was updating the operating system from 3.1.5 to 3.1.8. The update deleted the static routes that had been set up so that they did not show in SMIT but still existed in the CuAt file. This did not cause a problem until I deleted one of the hosts from the /etc/hosts file. Then, whenever we rebooted, the en0 interface to the ethernet adapter would be in a DOWN state. The /tmp/rc.net.out file showed that this "GHOST" system was the problem. After I used odme to edit out the culprits, all of the problems went away. The benefit of the ODM is that configuration information is kept in a well-defined place. A second benefit is that IBM includes a nice set of utility programs for displaying and changing this information. These utilities make a detailed knowledge of the ODM unnecessary in most cases. One of the reasons UNIX systems are considered less than user-friendly is the difficulty of configuring them. AIX removes much of the difficulty through the use of SMIT and the ODM. At first, this may seem like extra work to system administrators accustomed to editing the configuration files, relinking the kernel, and praying during a reboot, but after the initial surprise, they will understand that AIX takes UNIX a step in the right direction.
About the Author
Jeff Courington has worked on various forms of UNIX over the past 8 years, including AIX, SCO, HP/UX, and SVR3 variants from Silicon Valley Software and Versyss Corporation. He presently has a network of 11 IBM RS/6000s and various HP/UX machines connected over the wide area with TCP/IP through the use of Cisco routers. Jeff graduated from Virginia Polytechnical Institute and State University with a BS in Computer Science. He is currently working on his MS in Computer Science at Virginia Commonwealth University and can be reached from the Internet at attmail.com!aix!jeff.
|