12. Appendix¶

This section contains information that is referenced from other sections, and that does not really need to be read in sequence.

12.1. Special type names¶

This documentation uses a few special terms to refer to Python types:

string

a unicode string or a byte string

unicode string

a Unicode string type (unicode in Python 2, and str in Python 3)

byte string

a byte string type (str in Python 2, and bytes in Python 3). Unless otherwise indicated, byte strings in pywbem are always UTF-8 encoded.

connection id

a string (string) that uniquely identifies each pywbem.WBEMConnection object created. The connection id is immutable and is accessible from pywbem.WBEMConnection.conn_id. It is included in of each log record created for pywbem log output and may be used to correlate pywbem log records for a single connection.

number

one of the number types int, long (Python 2 only), or float.

integer

one of the integer types int or long (Python 2 only).

callable

a callable object; for example a function, a class (calling it returns a new object of the class), or an object with a __call__() method.

hashable

a hashable object. Hashability requires an object not only to be able to produce a hash value with the hash() function, but in addition that objects that are equal (as per the == operator) produce equal hash values, and that the produced hash value remains unchanged across the lifetime of the object. See term “hashable” in the Python glossary, although the definition there is not very crisp. A more exhaustive discussion of these requirements is in “What happens when you mess with hashing in Python” by Aaron Meurer.

unchanged-hashable

an object that is hashable with the exception that its hash value may change over the lifetime of the object. Therefore, it is hashable only for periods in which its hash value remains unchanged. CIM objects are examples of unchanged-hashable objects in pywbem.

DeprecationWarning

a standard Python warning that indicates a deprecated functionality. See section Deprecation and compatibility policy and the standard Python module warnings for details.

Element

class xml.dom.minidom.Element. Its methods are described in section Element Objects of module xml.dom, with minidom specifics described in section DOM Objects of module xml.dom.minidom.

CIM data type

one of the types listed in CIM data types.

CIM object

one of the types listed in CIM objects.

CIM namespace

an object that is accessible through a WBEM server and is a naming space for CIM classes, CIM instances and CIM qualifier declarations. The namespace is a component of other elements like namespace path used to access objects in the WBEM server.

NocaseList

A case-insensitive list class provided by the nocaselist package.

interop namespace

A CIM namespace is the interop namespace if it has one of the following names: DMTF definition; (‘interop’, ‘root/interop’) pywbem implementation; (‘interop’, ‘root/interop’, ‘root/PG_Interop’), Only one interop namespace is allowed in a WBEM Server. The interop namespace contains CIM classes that the client needs to discover characteristics of the WBEM server (namespaces, coniguration of server components like indications) and the registered profiles implemented by that server.

keybindings input object

a Python object used as input for initializing an ordered list of keybindings in a parent object (i.e. a CIMInstanceName object).

None will result in an an empty list of keybindings.

Otherwise, the type of the input object must be one of:

iterable of CIMProperty
iterable of tuple(key, value)
OrderedDict with key and value
dict with key and value (will not preserve order)

with the following definitions for key and value:

key (string): Keybinding name.

Must not be None.

The lexical case of the string is preserved. Object comparison and hash value calculation are performed case-insensitively.
value (CIM data type or number or CIMProperty): Keybinding value.

If specified as CIM data type or number, the provided object will be stored unchanged as the keybinding value.

If specified as a CIMProperty object, its name attribute must match the key (case insensitively), and a copy of its value (a CIM data type) will be stored as the keybinding value.

None for the keybinding value will be stored unchanged.

If the WBEM server requires the TYPE attribute on KEYVALUE elements to be set in operation requests, this can be achieved by specifying the keybinding value as CIM data type (either directly, or via a CIMProperty object).

The order of keybindings in the parent object is preserved if the input object is an iterable or a OrderedDict object, but not when it is a dict object.

The resulting set of keybindings in the parent object is independent of the input object (except for unmutable objects), so that subsequent modifications of the input object by the caller do not affect the parent object.

methods input object

a Python object used as input for initializing an ordered list of methods represented as CIMMethod objects in a parent object that is a CIMClass.

None will result in an an empty list of methods.

Otherwise, the type of the input object must be one of:

iterable of CIMMethod
iterable of tuple(key, value)
OrderedDict with key and value
dict with key and value (will not preserve order)

with the following definitions for key and value:

key (string): Method name.

Must not be None.

The lexical case of the string is preserved. Object comparison and hash value calculation are performed case-insensitively.
value (CIMMethod): Method declaration.

Must not be None.

The name attribute of the CIMMethod object must match the key (case insensitively).

The provided object is stored in the parent object without making a copy of it.

The order of methods in the parent object is preserved if the input object is an iterable or a OrderedDict object, but not when it is a dict object.

The resulting set of methods in the parent object is independent of the input collection object, but consists of the same CIMMethod objects that were provided in the input collection. Therefore, a caller must be careful to not accidentally modify the provided CIMMethod objects.

parameters input object

a Python object used as input for initializing an ordered list of parameters represented as CIMParameter objects in a parent object that is a CIMMethod.

None will result in an an empty list of parameters.

Otherwise, the type of the input object must be one of:

iterable of CIMParameter
iterable of tuple(key, value)
OrderedDict with key and value
dict with key and value (will not preserve order)

with the following definitions for key and value:

key (string): Parameter name.

Must not be None.

The lexical case of the string is preserved. Object comparison and hash value calculation are performed case-insensitively.
value (CIMParameter): Parameter (declaration).

Must not be None.

The name attribute of the CIMParameter object must match the key (case insensitively).

The provided object is stored in the parent object without making a copy of it.

The order of parameters in the parent object is preserved if the input object is an iterable or a OrderedDict object, but not when it is a dict object.

The resulting set of parameters in the parent object is independent of the input collection object, but consists of the same CIMParameter objects that were provided in the input collection. Therefore, a caller must be careful to not accidentally modify the provided CIMParameter objects.

properties input object

a Python object used as input for initializing an ordered list of properties represented as CIMProperty objects, in a parent object.

The CIMProperty objects represent property values when the parent object is a CIMInstance, and property declarations when the parent object is a CIMClass.

None will result in an an empty list of properties.

Otherwise, the type of the input object must be one of:

iterable of CIMProperty
iterable of tuple(key, value)
OrderedDict with key and value
dict with key and value (will not preserve order)

with the following definitions for key and value:

key (string): Property name.

Must not be None.

The lexical case of the string is preserved. Object comparison and hash value calculation are performed case-insensitively.
value (CIM data type or CIMProperty): Property (value or declaration).

Must not be None.

CIMProperty objects can be used as input for both property values and property declarations. CIM data type objects can only be used for property values.

If specified as a CIM data type, a new CIMProperty object will be created from the provided value, inferring its CIM data type from the provided value.

If specified as a CIMProperty object, its name attribute must match the key (case insensitively), and the provided object is stored in the parent object without making a copy of it.

The order of properties in the parent object is preserved if the input object is an iterable or a OrderedDict object, but not when it is a dict object.

The resulting set of properties in the parent object is independent of the input collection object, but consists of the same CIMProperty objects that were provided in the input collection. Therefore, a caller must be careful to not accidentally modify the provided CIMProperty objects.

provider

An element of a WBEM server that responds to requests for selected classes. A WBEM server normally contains a main provider that may interface with a CIM respository and provides responses to client requests for which no specific provider is defined and providers which providers that allow specialized responses for selected classes and request types (communicate with managed components) or manipulate the objects being managed.

NOTE: In the SNIA terminology, a provider may also be a complete WBEM server implementation.

user-defined provider

A :term:provider that can be defined independently of the WBEM server and attached dynamically to the WBEM server. In pywbem, user-defined providers can be defined as subclasses of specific default provider types and attached to the server by registering them with the connection.

qualifiers input object

a Python object used as input for initializing an ordered list of qualifiers represented as CIMQualifier objects in a parent object (e.g. in a CIMClass object).

None will result in an an empty list of qualifiers.

Otherwise, the type of the input object must be one of:

iterable of CIMQualifier
iterable of tuple(key, value)
OrderedDict with key and value
dict with key and value (will not preserve order)

with the following definitions for key and value:

key (string): Qualifier name.

Must not be None.

The lexical case of the string is preserved. Object comparison and hash value calculation are performed case-insensitively.
value (CIM data type or CIMQualifier): Qualifier (value).

Must not be None.

If specified as a CIM data type, a new CIMQualifier object will be created from the provided value, inferring its CIM data type from the provided value.

If specified as a CIMQualifier object, its name attribute must match the key (case insensitively), and the provided object is stored in the parent object without making a copy of it.

The order of qualifiers in the parent object is preserved if the input object is an iterable or a OrderedDict object, but not when it is a dict object.

The resulting set of qualifiers in the parent object is independent of the input collection object, but consists of the same CIMQualifier objects that were provided in the input collection. Therefore, a caller must be careful to not accidentally modify the provided CIMQualifier objects.

12.2. Profile advertisement methodologies¶

This section briefly explains the profile advertisement methodologies defined by DMTF. A full description can be found in DSP1033.

These methodologies describe how a client can discover the central instances of a management profile. Discovering the central instances through a management profile is the recommended approach for clients, over simply enumerating a CIM class of choice. The reason is that this approach enables clients to work seamlessly with different server implementations, even when they have implemented a different set of management profiles.

DMTF defines three profile advertisement methodologies in DSP1033:

GetCentralInstances methodology (new in DSP1033 1.1)
Central class methodology
Scoping class methodology

At this point, the GetCentralInstances methodology has not widely been implemented, but pywbem supports it nevertheless.

All three profile advertisement methodologies start from the CIM_RegisteredProfile instance that identifies the management profile, by means of registered organisation, registered name, and registered version.

It is important to understand that the CIM_RegisteredProfile instance not only identifies the management profile, but represents a particular use of the management profile within its scoping profiles. For an autonomous profile, there are no scoping profiles, so in that case, there is only one use of the autonomous profile in a server. However, component profiles do have scoping profiles, and it is well possible that a component profile is used multiple times in a server, in different scoping contexts. If that is the case, and if discovery of central instances using any of the profile advertisement methodologies is supposed to work, then each such use of the profile needs to have its own separate CIM_RegisteredProfile instance, because each such use of the profile will also have its own separate set of central instances.

Unfortunately, neither the DMTF standards nor the SMI-S standards are clear about that requirement, and so there are plenty of implementations that share a single CIM_RegisteredProfile instance identifying a particular component profile, for multiple distinct uses of the profile by its scoping profiles. In such a case, the profile advertisement methodologies will not be able to distinguish the distinct sets of central instances alone, and other means need to be used to distinguish them.

It is also important to understand that the choice which profile advertisement methodology to implement, is done by the WBEM server side. Therefore, a WBEM client such as pywbem needs to support all methodologies and needs to try them one by one until one succeeds. Pywbem tries the three methodologies in the order listed above.

In the GetCentralInstances methodology, the CIM_RegisteredProfile instance has a CIM method named GetCentralInstances that returns the instance paths of the central instances of the use of the profile.

In the central class methodology, the CIM_RegisteredProfile instance is associated directly with the set of central instances of the use of the profile, via a CIM_ElementConformsToProfile association.

In the scoping class methodology, the CIM_RegisteredProfile instance is not associated directly with the set of central instances of the use of the profile, but delegates that to its scoping profile. The client navigates up to the CIM_RegisteredProfile instance representing the (use of the) scoping profile, looks up its central instances, and from each of those, navigates down along the reversed scoping path to the central instances of the profile in question. The scoping path of a component profile describes the traversal across associations and ordinary classes from the central class to the scoping class of the profile. This profile advertisement methodology is obviously the most complex one of the three.

Pywbem encapsulates the complexity and choice of these methodologies into a single invocation of an easy-to use method get_central_instances().

Profile implementations in a WBEM server are not entirely free when making a choice of which methodology to implement:

Autonomous profiles in a WBEM server must implement the central class methodology, and may in addition implement the new GetCentralInstances methodology.

Note that the scoping class methodology falls together with the central class methodology for autonomous profiles, because their scoping class is also their central class.
Component profiles in a WBEM server may implement the central class methodology and the new GetCentralInstances methodology, and must support the scoping class methodology.

Note that implementing the scoping class methodology in a WBEM server requires implementing the classes and associations of the scoping path, which are usually mandatory anyway. So while the scoping class methodology is more complex to use for clients than the central class methodology, it is easier to implement for servers.

Use of the scoping class methodology by a client requires knowing the central class, scoping class and scoping path defined by the component profile.

DSP1001 requires that conformant autonomous profiles specify a central class, and that conformant component profiles specify a central class, scoping class and a scoping path.

Older DMTF component profiles and older SNIA subprofiles do not always specify scoping class and scoping path. In such cases, the scoping class and scoping path can often be determined from the class diagram in the specification for the profile. Many times, CIM_System or CIM_ComputerSystem is the scoping class.

12.3. Troubleshooting¶

Here are some trouble shooting hints for the installation of pywbem.

12.3.1. Installation fails with “invalid command ‘bdist_wheel’”¶

The installation of some Python packages requires the Python “wheel” package. If that package is not installed in the current Python environment, the installation will fail with the following (or similar) symptom:

python setup.py bdist_wheel
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: invalid command 'bdist_wheel'

To fix this, install the Python “wheel” package:

pip install wheel

12.3.2. Installation of lxml misses include files on Python 3.4 on native Windows¶

On Python 3.4 on native Windows, the installation of the lxml Python package may fail during installation of the development prerequisites (i.e. during make develop), reporting missing include files such as libxml/xmlversion.h.

It has not been investigated what causes this on Python 3.4 (it works on other Python versions). If this issue shows up, try installing the Binary lxml package for Windows manually, with the lxml version >=4.2.4 and <4.4.0.

12.3.3. ConnectionError raised with [SSL: UNSUPPORTED_PROTOCOL]¶

On newer versions of the operating system running the pywbem client, communication with the WBEM server may fail with:

pywbem.exceptions.ConnectionError: SSL error <class 'ssl.SSLError'>:
  [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1056)

For example, this happened after an upgrade of the client OS to Debian buster using Python 3.7, with OpenSSL 1.1.1d.

This is an error that is created by the OpenSSL library and handed back up to the SSL module of Python which hands it up to pywbem. The error indicates that OpenSSL and the WBEM server do not agree about which SSL/TLS protocol level to use.

Pywbem specifies SSL parameters such that the highest SSL/TLS protocol version is used that both the client and server support. Thus, pywbem does not put any additional restrictions on top of OpenSSL.

Debian buster includes OpenSSL 1.1.1d and increased its security settings to require at least TLS 1.2 (see https://stackoverflow.com/a/53065682/1424462).

This error means most likely that the WBEM server side does not yet support TLS 1.2 or higher.

This can be fixed for example by adding TLS 1.2 support to the server side (preferred) or by lowering the minimum TLS level OpenSSL requires on the client side (which lowers security). The latter can be done by changing the MinProtocol parameter in the OpenSSL config file on the client OS (typically /etc/ssl/openssl.cnf on Linux and OS-X, and C:\OpenSSL-Win64\openssl.cnf on Windows). At the end of the file there is:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

12.3.4. ConnectionError raised with [SSL] EC lib¶

Using pywbem on Python 3.5 with OpenSSL 1.0.1e-fips against an IBM DS8000 raised the following exception:

pywbem.exceptions.ConnectionError: SSL error <class 'ssl.SSLError'>:
  [SSL] EC lib (_ssl.c:728)

This is an error that is created by the OpenSSL library and handed back up to the SSL module of Python which hands it up to pywbem. The error indicates that OpenSSL on the client side cannot deal with the cipher used by the server side. This was fixed by upgrading OpenSSL on the client OS to version 1.1.1.

12.4. Glossary¶

dynamic indication filter
dynamic filter: An indication filter in a WBEM server whose life cycle is managed by a client. See DSP1054 for an authoritative definition and for details.
static indication filter
static filter: An indication filter in a WBEM server that pre-exists and whose life cycle cannot be managed by a client. See DSP1054 for an authoritative definition and for details.