OpenPegasus new features

The cimcli command has been enhanced to complete the ability to execute the basic operations as much as possible with a command line tool. See Pegasus Enhancement Proposal (PEP) 283 for details.

This enhancement adds native support for the WS-Management (Web Services for Management) protocol in the Pegasus CIM Server. WS-Management server support is added as an option directly in the CIM Server. When it is enabled, WS-Management requests are accepted and processed using the same connection ports and authentication mechanisms as for CIM-XML. See Pegasus Enhancement Proposal (PEP) 311 for details.

This enhancement keeps trace information available in memory to allow for better tracing and debug of errors. See Pegasus Enhancement Proposal (PEP) 316 for details.

This enhancement replaces the current implementation of CIMObject and related CIM data structures into a single chunk memory implementation that reduces memory fragmentation. See Pegasus Enhancement Proposal (PEP) 341 and Pegasus Enhancement Proposal (PEP) 348 for details.

This enhancement creates a new libpeggeneral library for OpenPegasus, in order to reduce the size of the common library and lower the risk to external interfaces when implementing enhancements. See Pegasus Enhancement Proposal (PEP) 347 for details.

This enhancement helps to isolate the CIMOM from out-of-process providers that are not returning responses, thus improving the availability of the CIMOM. See Pegasus Enhancement Proposal (PEP) 349 for details.

This enhancement allows OpenPegasus to run different provider modules under the same provider-agent while running out-of-process. See Pegasus Enhancement Proposal (PEP) 356 for details.

This enhancement helps to ensure that indications are delivered through retry attempts after temporary network problems. See Pegasus Enhancement Proposal (PEP) 324 for details.

The existing CIMRepository implementation does not allow a non-leaf class (a class with at least one subclass) to be modified. It also does not allow a superclass designation to be changed. This limitation prevents the loading of a new schema revision in an existing repository. This enhancement allows modifyClass on a non-leaf class.

With this enhancement, entry enableIndicationService is made dynamic. This allows the administrator to explicitly enable or disable indication service based on requirements without restarting the CIM Server.

CIM_Error is a DMTF defined extension to the CIM Model and HTTP Operations that extends CIM operation errors from the simple set of errors defined today to a more general error processing model. In detail, in the new general error processing model, operation errors are encapsulated in a Class (CIM_Error class which is already in the model), and instances of this class are transmitted with the response, in addition to the simple error code that is transmitted today. This new capability must be backward compatible. The existing mechanism MUST BE kept in place and the CIM_Error reporting added to the existing functionality.

When 5722-UME was shipped, OpenPegasus 2.5.1 had no convenient way to query which indication subscriptions exist on the CIM Server, or to remove a subscription, filter or handler. 5722-UME shipped a command cimsubscribe to manage subscriptions. OpenPegasus 2.8 provides a command cimsub to query the Subscription State, to see which subscriptions are active, modify the SubscriptionState. 5770-UME follows OpenPegasus and the command cimsubscibe is removed for UME, and cimsub is shipped.

See PEP#257: Indication Subscription Management for detail of cimsub.

This new feature adds audit logging capability to CIM Server. Audit log data can provide a record of access, activity, and configuration change for a CIM server. The contents of the audit file include who, when, and what information of a request. It can be used to allow auditors to track activities of the various WBEM client operations and provider usages.

A log file named PegasusAudit.log will be created in the directory which the configuration property logdir specified to record server's operation. Like other log files (such as PegasusStandard.log) which have size limit of 32M, and will be saved after grows out of the bound.

In 5722-UME CIM Server an audit log feature exists too. But it is for different purpose. It records all declined operations (such as authentication failure) and write information to IBM i system audit journal. It is an IBM i system security request. User can use command DSPJRN JRN(QAUDJRN) ENTTYP(AF) to see the system's audit journal.

In 5770-UME of CIM Server, the original audit log is kept and the OpenPegasus audit log is also enabled. OpenPegasus audit log function can be controlled by dynamic configuration property enableAuditLog.

See PEP#258: Audit Logging for detail.

5722-UME shipped commandssltrustmgr provides an interface to manage X509 certificates in a trust store or X509 Certificate Revocation Lists in a CRL store. OpenPegasus2.8 offers truststore management and CRL management functionality by two separate commands cimtrust and cimcrl. cimtrust command provides an interface to manage X509 certificates in a trust store. cimcrl command provides an interface to manage X509 CRLs in a CRL store. 5770-UME decides to follow OpenPegasus. In 5770-UME command ssltrustmgr is removed and cimtrust and cimcrl are shipped.

See PEP#259: SSL Certificate Management Command Interfacesfor detail of cimtrust and cimcrl.

In 5722-UME, CMPI provider manager supports CMPI (Common Manageability Programming Interface) standard 1.0. Now support of CMPI standard version 2.0 has been added to OpenPegasus. The areas addressed by the newest CMPI standard are:

• Standardized header files are now part of the specification:tog_cmpidt.h, tog_cmpift.h, tog_cmpios.h, tog_cmpipl.h. These header files include conditional compiler directives for many Operating Systems.
• Standardized CMPI Macro header (which was originally removed from the 1.0 spec via TC 1),tog_cmpimacs.h .
• Introduction of an enhanced messaging API in the CMPIBrokerEncFT interface: openMessageFile(), closeMessageFile(), getMessage2().
• CMPIInstanceFT.setPropertyWithOrigin() allows providers to set the origin on an instance property, rather than relying on the Management Broker.
• CMPIInstanceFT.setObjectPath()may be used to set the keys of an instance.
• Detailed explanation of use of the CMPISelectExp, CMPISelectCond, CMPISubCond, and CMPIPredOpstructures in query parsing. Addition of COD/DOC Query Normalization.
• Introduction of the CMPIError, CMPIErrorSrcFormatstructure.
• CMPIBrokerExtFT Operating system abstraction interface is now required.
• Introduction of the optional interface CMPIBrokerMemFT, addition of memory functions.
• CMPICount replaces unsigned intin function return values and index-based parameters.
• Many typographical errors and inconsistencies with the headers have been corrected since the 1.0 version.
• Incorporate changes from Technical Corrigendas

The enhancement has no impact on existing providers, but adds support of providers using new CMPI interface.

See PEP#260: CMPI 2.0 Currency for detail.

See PEP#302: Enhanced logfile support for detail.

In 5770-UME CIM Server, PEP 302 implementation is adopted to keep UME CIM Server's behavior consistent with OpenPegasus CIM Server on other platforms. 5770-UME CIM Server solves the OOP provider log lost problem in OpenPegasus CIM Server by another enhancement: separate OOP logs. See 5770–UME Updates for detail.

The Profile Registration defines the classes used to describe the DMTF profile registration and the version information of the profiles advertised as implemented for a managed system and components of the system. The Profile Registration extends the management capability of the referencing profiles by adding the capability to describe the registration and versioning of CIM profiles that are implemented by CIM-based system and component-management instrumentation.

See PEP#319: DMTF Profile Registration Profile (DSP1033) support in OpenPegasus

OpenPegasushas made improvement on tracing and logging function and has changed some of their usage.

See PEP#315: Tracing in OpenPegasus for detail.

The trace destination can be configured by a new configuration property "traceFacility". The values are not case sensitive.

If the configure property "traceFacility".is set to "File" the behavior is the same as before. If the "traceFacility".is set to Log the trace messages are written to the CIM server Logger to combine the log message stream with the trace message stream to get all traces. The implementation has to take care about not to issuing log messages more than once. The messages are written using the CIM server Logger::TRACE level and Logger::TRACE_LOG as log destination.

The Trace Levels of 0 and 1 are redefined and extending the original mechanism to switch off tracing by not specifying components.

It is desirable to keep the trace components between a run with or with out traces. You do not have to remind the trace components between trace on/off runs.

Trace Level 1 is for severe messages and used for messages send to the CIM server Logger. Messages written to the CIM server Logger are additionally written to the CIM server Tracer with Trace Level 1. The Trace Level 1 is also allowed to be used for individual written traces, which are rated as very severe. A severe situation can be e.g. at loosing data or closing connections. It should be used with caution.

Trace Level 2 to 4 remain the same.

Trace Level 5 is trace level 4 plus the method enter & exit trace messages. If PEGASUS_REMOVE_METHODTRACE was specified with true at compile time, this trace level is still valid but will not bring additional method enter & exit trace messages.

Duplicate log messages to the CIM server Tracer

Log messages with the level Logger::INFORMATION until Logger::FATAL are also written to the CIM server trace using Trace Level 1. This is helpful to shrink static code size in all those places where currently a log and trace message macro with similar or very close text and content are coded.

The category Logger::TRACEfor log messages will be removed from the Logger API to remove the redundancy with the Trace.

The replacement for this log level is the CIM server Tracer ability to route the trace messages into the log. For this, the Logger::TRACEand Logger::TRACE_LOGlevel will be used only internal for messages routed from the CIM server Tracer to the Logger.

The trace messages of the CIM server Tracer are written to the CIM server Logger with Logger::TRACElevel andLogger::TRACE_LOG destination.

Logger::DEBUG_LOG Logger destination is removed, and should not be used any more.

The Indications Profile defines the CIM elements that are used to subscribe for indications of unsolicited events and a server-side implementation uses to advertise the possible indications, as well as the content of an indication used to report events in a managed system. The central class of this profile is CIM_IndicationServiceand Scoping instance shall be instance of CIM_System.

For more information on profiles refer to DSP1054:

PEP 323 is the PEP to implement all the mandatory classes from DSP1054 in OpenPegasus. As part of PEP 323 CIM_IndicationService is implemented and the properties DeliveryRetryAttempts and DeliveryRetryInterval are not considered to implement the delivery retry.

See PEP#323: DMTF Indications Profile (DSP1054) Implementation, stage 1 for detail.

In order to support Reliable Indication, PEP 324: DMTF Indications Profile (DSP1054) Implementation, stage 2.is also needed. It implements indication delivery retry using CIM_IndicationService DeliveryRetryAttemtsand DeliveryRetryInterval properties when indication delivery has failed because of temporary errors in the protocol. PEP 324 has not been approved by OpenPegasus architect team now. And it will not be a feature of OpenPegasus.2.8.0 CIM Server.

Reliable indication delivery means indications delivery within the reasonable amount of time limits under given constraints (defined by standards).

OpenPegasus PEP 324 adds retry mechanism to the existing indication delivery framework, in order to avoid indication delivery failure caused by temporary errors. Two properties of DSP1054 central class CIM_IndicationService, DeliveryRetryAttempts and DeliveryRetryInterval, are used to implement indication delivery retry.

See PEP#324: DMTF Indications Profile (DSP1054) Implementation, stage 2. for details.

The delivery retry function will sleep for DeliveryRetryInterval (currently 20) seconds between every two adjacent retry attempts.

Running providers in Out-Of-Process mode adds a significant path length overhead compare to running them In-Process. Enhancement is made to the communications between the CIM Server and out-of-process providers.

The latest stage of the OOP enhancement work is documented in OpenPegasus PEP#303: Out-Of-Process Performance Optimizations.

The OpenPegasusbinary protocol, which allows client programs to communicate with the OpenPegasus server over local domain and TCP sockets. This protocol provides a faster alternative to the existing XML protocol. The binary protocol support has been added to 5770-UME.

The latest stage of The OpenPegasus Binary Protocol is documented in OpenPegasus PEP#340: The OpenPegasus Binary Protocol

This enhancement is to load provider managers from a config-specified, well-known directory, rather than from a static list in code that must be modified to add a new type. This directory will be enumerated and found files will be tested to see if they are ProviderManagers (if they are properly named, and provide the required entry-points). If so, their information will be stored for later lookup so as to not require a rescan of the directory. When a CIM operation request is received, the lookup table will be queried to find which ProviderManager provides the specified interface type and version. The path to the ProviderManager will then be passed to the cimprovagt via the ProviderIDContainer, so that cimprovagt can load the appropriate ProviderManager.

A new configure property providerManagerDiris added. It is a static configure property, specifies the names of the directory that contains ProviderManager plugin libraries.

See PEP#313: Pluggable Provider Managers for detail.