Solaris WBEM Services Administrator's Guide

Chapter 2 CIM Object Manager

The Common Information Model (CIM) Object Manager is software that transfers CIM data between WBEM client applications and managed resources.

This chapter includes the following topics:

About the CIM Object Manager

The CIM Object Manager 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 Java classes.

When a WBEM client application accesses information about a CIM object, the CIM Object Manager contacts either the appropriate provider for that object or the CIM Object Manager Repository. Providers are classes that communicate with managed objects to access data. When a WBEM client application requests data from a managed resource that is not available from the CIM Object Manager Repository, 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 RMI port 5987 and for XML/HTTP connections on HTTP port 80
Sets up a connection to the CIM Object Manager Repository
Waits for incoming requests

During normal operations, the CIM Object Manager performs these functions:

Performs security checks to authenticate user login and authorization to access namespaces.
Performs syntactical and semantic checking of CIM data operations to ensure that they 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 CIM Object Manager to establish a connection when it needs to perform WBEM operations, such as creating a CIM class or updating a CIM instance. When a WBEM client application connects to the CIM Object Manager, it gets a reference to the CIM Object Manager, which it then uses to request services and operations.

The `init.wbem` Command

/etc/init.d/init.wbem start | stop | status

The init.wbem utility is run automatically during installation and each time the system is rebooted. This utility starts the CIM Object Manager and Solaris Management Console (SMC) server, both of which run combined in a single process. It can be also be used to stop the CIM Object Manager and SMC server, or to retrieve status from the server.

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.

The init.wbem command has three options:

start - Starts the CIM Object Manager and SMC server on the local host.
stop - Stops the CIM Object Manager and SMC server on the local host.
status - Gets status for the CIM Object Manager and SMC server on the local host.

Solaris Management Console Server

The Solaris Management Console (SMC) server is the back end to the front-end GUI, smc(1M). The SMC front-end GUI provides Solaris management applications such as a User Manager, Disk Manager, and Log Viewer. The SMC server provides tools for the console to download and performs common services for the console and its tools, such as authentication, authorization, logging, messaging, and persistence.

System Booting

The init.wbem script is installed in the /etc/init.d directory. A link to the script exists in /etc/rc2.d/S90wbem, which is run with the start option when init state 2 is entered (normally at boot time). Other links to it exist in /etc/rc0.d/K36wbem, /etc/rc1.d/K36wbem, and /etc/rcS.d/K36wbem, which are run with the stop option when init states 0, 1, and S are entered (normally at system halt, or when entering "system administrator mode" or single-user mode).

Stopping and Restarting the CIM Object Manager

If you change a provider, you must stop and restart the CIM Object Manager before using the updated provider.

To Stop the CIM Object Manager

Become root by typing the following command at the system prompt:

% su

Type the root password when you are prompted.

Stop the CIM Object Manager by typing the following command:

# /etc/init.d/init.wbem stop

To Restart the CIM Object Manager

Become root by typing the following command at the system prompt:

% su

Type the root password when you are prompted.

Restart the CIM Object Manager by typing the following command:

# /etc/init.d/init.wbem start

Upgrading the CIM Object Manager Repository

If you are upgrading from Solaris 8 10/00 (WBEM Services 2.2) or earlier to Solaris 8 1/01 (WBEM Services 2.3) , you must upgrade the CIM Object Manager Repository datastore format.

Datastore Format forSolaris 8 10/00 (WBEM Services 2.2) or earlier	Datastore Format forSolaris 8 1/01 (WBEM Services 2.3)
JavaSpaces^TM	Reliable Log

To upgrade a JavaSpaces datastore to the newer Reliable Log repository format, you use the wbemconfig convert command. This command successfully converts any proprietary custom MOF data, but not any CIM or Solaris MOF data you have modified--these will be destroyed. To recompile any modified CIM or Solaris MOF data into the new repository, run the mofcomp compiler on the MOF files containing the class definitions.

The wbemconfig convert command creates a directory named /var/sadm/wbem/logr/ that contains the converted data.

Caution -

To prevent corruption of your data, only use the wbemconfig convert command after stopping the CIM Object Manager with the init.wbem stop command.

Note -

Because the wbemconfig convert command invokes the JVM (Java Virtual Machine) to perform conversion of the repository, you must be running the same version of the JVM as was used to create the original JavaSpaces datastore. After the wbemconfig convert command is completed, you can change to any version of the JVM you want.

Upgrading the CIM Repository datastore format is a two-part process:

Steps you must perform before installing your new version of Solaris.
Steps you must perform after installing your new version of Solaris.

Before Installing Your New Version of Solaris

Log in as superuser (root) and save the JavaSpaces software. Type the following command:

# cp /usr/sadm/lib/wbem/outrigger.jar /usr/sadm/lib/wbem/outrigger.jar.tmp

Check and record the version of the JDK installed on your machine. For example:

# /usr/bin/java -version java version "1.2.1" Solaris VM (build Solaris_JDK_1.2.1_04c, native threads, sunwjit)

You must be running the same version of the JDK as was used when the original JavaSpaces datastore was created.

After Installing Your New Version of Solaris

Restore the JavaSpace software that you saved in Step 1 of "Before Installing Your New Version of Solaris".

# mv /usr/sadm/lib/wbem/outrigger.jar /usr/sadm/lib/wbem/outrigger.jar.2# mv /usr/sadm/lib/wbem/outrigger.jar.tmp /usr/sadm/lib/wbem/outrigger.jar

Install the old version of the JDK that was on your machine previously, in a separate location from the current (newly installed) JDK. You can download a JDK from http://java.sun.com/products/.

Change the symbolic link /usr/java to point to the location of the old version of the JDK. For example, if you installed Solaris_JDK_1.2.1_04c in /old_sdk:

# rm /usr/java# ln -s /old_sdk/Solaris_JDK_1.2.1_04c /usr/java

Convert the JavaSpaces datastore to Reliable Log format.

# /usr/sadm/lib/wbem/wbemconfig convert

Restore the outrigger.jar file included in the new version of Solaris.

# mv /usr/sadm/lib/wbem/outrigger.jar.2 /usr/sadm/lib/wbem/outrigger.jar

Change the symbolic link /usr/java to point to the location of the new JDK that came in the new version of Solaris:

# rm /usr/java# ln -s /usr/java1.2 /usr/java

Restart the CIM Object Manager.

# /etc/init.d/init.wbem start

Setting the Solaris Provider CLASSPATH

To set the Solaris provider's CLASSPATH, use the client APIs to create an instance of the Solaris_ProviderPath class and set its pathurl property to the location of your provider class files. The Solaris_ProviderPath class is stored in the \root\system namespace.

You can also set the provider CLASSPATH to the location of your provider class files. You can set the class path to the jar file or to any directory that contains the classes. Use the standard URL format that Java uses for CLASSPATHs.

Provider CLASSPATH	Syntax
Absolute path to directory	`file:///a/b/c/`
Relative path to directory from which the CIM Object Manager was started (`/)`. .	`file://a/b/c`

To Set the Provider CLASSPATH

Create an instance of the Solaris_ProviderPath class. For example:

/* Create a namespace object initialized with root\system  
(name of namespace) on the local host. */   
CIMNameSpace cns = new CIMNameSpace("", "root\system"); 

// Connect to the root\system namespace as root. 
cc = new CIMClient(cns, "root", "root_password");

// Get the Solaris_ProviderPath class 
cimclass = cc.getClass(new CIMObjectPath("Solaris_ProviderPath");

// Create a new instance of Solaris_ProviderPath. 
class ci = cimclass.newInstance();

Set the pathurl property to the location of your provider class files. For example:

...
/* Set the provider CLASSPATH to //com/mycomp/myproviders/.*/
ci.setProperty("pathurl", new CIMValue(new String("//com/mycomp/myproviders/")); 
...

Update the instance. For example:

// Pass the updated instance to the CIM Object Manager 
cc.setInstance(new CIMObjectPath(), ci);

Exception Messages

The CIM Object Manager generates exception messages to indicate incorrect MOF syntax and semantics. For an explanation of exception messages, see Chapter 6, CIM Exception Messages.