The Common Information Model (CIM) Object Manager is software that transfers CIM data between WBEM client applications and managed resources.
This chapter discusses the following topics:
The CIM Object Manager (CIMOM) manages CIM objects on a WBEM-enabled system. A CIM object is a representation, or model, of a managed resource, such as a printer, disk drive, or CPU. CIM objects are stored internally as classes that are written in the Java programming language.
When a WBEM client application accesses information about an object, the CIMOM contacts either the provider for that object or the CIM Object Manager Repository. Providers are classes that communicate with managed objects to access data. A WBEM client application might request data from a managed resource that is not available from the CIM Object Manager Repository. In this case, the CIM Object Manager forwards the request to the provider for that managed resource. The provider dynamically retrieves the information.
At startup, the CIM Object Manager performs the following functions:
Listens for RMI connections on port 5987 and for XML over HTTP connections on port 5988
Waits for incoming requests
The CIM Object Manager:
Performs security checks to authenticate user login and authorization to access namespaces
Performs syntactical and semantic checking of CIM data operations to ensure that the operations comply with the latest CIM specification
Routes requests to the appropriate provider or to the CIM Object Manager Repository
Delivers data from providers and from the CIM Object Manager Repository to WBEM client applications
A WBEM client application contacts the CIMOM to establish a connection when the client needs to perform WBEM operations. Examples of such operations include creating a CIM class or updating a CIM instance. When a WBEM client application connects to the CIMOM, the client application gets a reference to the CIMOM. The client application uses that reference to request services and operations.
The init.wbem command is automatically run during installation, and then each time you reboot a system. The init.wbem command starts the CIM Object Manager and Solaris Management Console server, both of which run combined in a single process. You can also use init.wbem to stop the CIM Object Manager, to stop the Solaris Management Console server, or to retrieve status from a server. You can find additional information about this command in the init.wbem(1M) man page.
Generally, you do not need to stop the CIM Object Manager. However, if you change an existing provider, you must stop and restart the CIM Object Manager before using the updated provider.
You can specify three options with init.wbem:
start – Starts the CIM Object Manager or Solaris Management Console server on the local host
stop – Stops the CIM Object Manager and Solaris Management Console server on the local host
status – Gets status for the CIM Object Manager and Solaris Management Console server on the local host
The Solaris Management Console software provides Solaris platform management applications such as User Manager, Disk Manager, and Log Viewer. The Solaris Management Console server provides tools that the console can download. The server also performs common services for the console and its tools, such as authentication, authorization, logging, messaging, and persistence.
The Solaris Management Console is described in other chapters in this document. For more information see the System Administration Guide: Basic Administration.
The init.wbem command is located in the /etc/init.d directory. The file /etc/rc2.d/S90wbem runs with the start option when initialization state 2 is entered, normally at boot time. The files /etc/rc0.d/K36wbem, /etc/rc1.d/K36wbem, and /etc/rcS.d/K36wbem are run with the stop option when initialization states 0, 1, and S are entered.
If you change a provider, you must stop and restart the CIM Object Manager before using the updated provider.
If you have upgraded to the Solaris 10 platform from a previous version of the Solaris software, you must update any proprietary custom Managed Object Format (MOF) data to the new repository format that was introduced in Solaris 9. Any CIM and Solaris platform MOF data that you modified prior to the upgrade is destroyed by the upgrade. As a result, you will either need to recompile your MOF files or merge the WBEM data after you upgrade.
Failure to recompile or merge the modified data results in data loss.
Use the following table to determine whether to recompile or merge the WBEM data after you upgrade to the Solaris 10 OS.
Table 2–1 Determining Whether to Recompile or Merge WBEM Data
Environment Before Upgrade |
Recompile Proprietary Managed Object Format (MOF) Files? | |
---|---|---|
Solaris 8 (Solaris WBEM Services 2.0) Solaris 8 6/00 (WBEM Services 2.0) Solaris 8 10/00 (WBEM Services 2.2) |
Yes | |
Solaris 8 1/01 (WBEM Services 2.3) Solaris 8 4/01 (WBEM Services 2.4) Solaris 8 7/01 (WBEM Services 2.4) Solaris 8 10/01 (WBEM Services 2.4) Solaris 9 Any release (WBEM Services 2.5) |
No. However, you need to merge the data into an upgraded repository. |
Upgrade your system to the Solaris 10 OS.
Become superuser.
Change directory to the location of your proprietary MOF files.
Use the mofcomp command to compile each of your proprietary MOF files.
# /usr/sadm/bin/mofcomp root root-passwd MOF-filename |
For more information on the MOF compiler, see mofcomp(1M).
Stop the CIM Object Manager.
# /etc/init.d/init.wbem stop |
Start the CIM Object Manager.
# /etc/init.d/init.wbem start |
The CIMOM adds repository files that contain the converted data to the directory /var/sadm/wbem/logr/. This directory was created when you upgraded your system to the Solaris 10 OS.
Upgrade your system to the Solaris 10 OS.
Become superuser.
Stop the CIM Object Manager.
# /etc/init.d/init.wbem stop |
Failure to stop the CIM Object Manager before you run wbemconfig convert might corrupt your data.
Merge the original data in the previous Reliable Log with the data in the Solaris 10 Reliable Log.
# /usr/sadm/lib/wbem/wbemconfig convert |
The wbemconfig convert command successfully converts any proprietary custom MOF data, but not any CIM or Solaris MOF data that you have modified. CIM and Solaris platform MOF data that you have modified is destroyed. To recompile any modified CIM or Solaris platform MOF data in the new repository, use the mofcomp command to compile the MOF files that contain the class definitions.
The CIM Object Manager generates exception messages to indicate incorrect MOF syntax and semantics. Chapter 9, Troubleshooting contains information about exception messages.