|Skip Navigation Links|
|Exit Print View|
|man pages section 1M: System Administration Commands Oracle Solaris 10 1/13 Information Library|
- register MOF classes with WBEM services
/usr/sadm/bin/mofreg -r tag file
/usr/sadm/bin/mofreg -u tag [file]
The mofreg command is used by package and patch install scripts, or by any applications that wish to register managed object format (MOF) classes with Sun The Web-Based Enterprise Management (WBEM) services.
The WBEM services daemon (Common Information Model or CIM object manager) processes at start up the files that are specified by mofreg commands. Files are processed in the order that the individual mofreg commands are executed.
As an alternative to using the mofreg command, MOFs can be registered or unregistered by manipulating directories in /var/sadm/wbem/logr. Instead of running the mofreg -r tag file version fo the command you can create a directory named tag under /var/sadm/wbem/logr/preReg and copy file to the tag directory.
Similarly, instead of running the mofreg -u tag [file] command, you can create a directory named tag under /var/sadm/wbem/logr/preUnreg and copy the optional file to the tag directory.
The entries are processed in increasing order of last modification time of the tag directories. If you issue mofreg commands in rapid succession, the timestamps might be the same. If you have a situation where the timestamp order is critical, you can place appropriate sleeps between the successive registration or unregistration operations. As with the mofreg command, processing is done at next restart or by using the -s option.
This alternative mechanism is typically used in package install scripts which do not have access to /usr, and therefore do not have access to the mofreg command. This case arises when packages are installed for diskless clients.
The following options are supported:
The file argument is the actual MOF registration file. Its form is identical to the MOF syntax as defined by the Distributed Management Task Force (DMTF). The only difference is the addition of the following 3 new pseudo-pragmas, which are variations of the namespace pragma. The name of file cannot end in .unreg.
#pragma namespace("__create") #pragma namespace("__delete") #pragma namespace("__modify")
These three pragmas are used specify if the elements following the pragmas should be created, deleted, or modified by the CIM object manager. The __delete pragma can currently only be applied for a mofreg -u command.
The tag argument is a unique string that specifies the identity of the registry action. This tag can be set to the package name or the patch number if the mofreg script is being invoked through packages/patches, though any tag can be specified.
Errors and warnings that are encountered when the CIM object manager handles the mofreg script are logged. Processing of the mofreg script stops at the first error. Specific warnings include:
Element already defined - the element already exists and cannot be created. Element not found - the element does not exist and cannot be modified.
The error conditions are:
Key modification - A class cannot be modified if its keys are being changed. Other mod compilation errors.
Forces the CIM object manager to immediately process outstanding registry requests, instead of at the next restart. This currently requires Java.
Undoes the operations performed during mof registry.
The tag argument must correspond to the value set during the original mofreg invocation. If no mofreg was done with the original tag, the command does not succeed.
If required, an unreg file can be specified. If no unreg file is specified, the CIM object manager automatically undoes the actions of the registry. Any class created by the registry process is removed and any classes modified by the registry revert to the old state.
The mofreg command does not take care of cases where packages and patches make conflicting changes to classes. This should be taken care of by the standard patch and package conflict resolution.
The following exit values are returned:
An error occurred. The reason for error is displayed.
See attributes(5) for descriptions of the following attributes: