Quickly changing the network configuration on a system should not really be a problem. But how did that work on a Debian system? If you mainly deal with other distributions, you often need to invest a few minutes more for what are actually simple tasks. Seasoned admins will of course have established their own toolboxes over time with useful scripts and tools. Thanks to these toolboxes, most of the routine tasks can be done in next to no time. However, maintaining and improving the toolbox also takes time.

Multiple Distributions

What happens if your employer wants to introduce a new Linux distribution? Will the scripts work the new distribution? Maybe not. You thus need to maintain different versions of a script. Alternatively, the script can be adjusted so that it performs the desired work on different systems. But this costs the admin more time, and because time is a scarce commodity, you might want to look for other solutions.

Furthermore, this approach does not scale very well. Why would anyone want to reinvent the wheel, if we could simply agree on a standard for performing the same work on different systems? In the area of system management, the Open Linux Management Infrastructure (OpenLMI) [1] is trying to define such a standard.

OpenLMI is based on the Common Information Model (CIM) standards. CIM in turn is a Web-Based Enterprise Management (WBEM) component [2], another standard of the Distributed Management Task Force (DMTF) that is made up of various components (such as CIM) and defines various technologies and methods for unified management of computer systems.

The CIM component describes the typical object classes to be used on a system to be managed (hardware, software, users, and a variety of subsystems) in a kind of schema. CIM determines what an instance of a particular class looks like and how it relates to other objects of the class. In the everyday use of WBEM, the term CIM is used, most of the time, not only for the schema description itself, but for the technology and associated tools. However, CIM is only a portion of the larger WBEM specification.

Figure 1: A broker receives requests from a management system and forwards these to the appropriate providers.

Architecture

Each system for which the OpenLMI framework is responsible must have a CIM Object Manager (CIMOM), which is a broker that communicates with a management system (in the article, this system always represented as a client). The broker receives the requests and forwards them to providers, which then do the actual work. This work takes place on the system's various object classes. Providers exist for different types of objects, which in turn individually describe a system.

Communication with the client systems (i.e., the systems from which the brokers receive their requests) takes place via a protocol standardized by the DMTF. The protocol, known as CIM Operations over HTTP, was most recently revised in December 2013 [3]. Basically, this is an XML document that is transmitted between the broker and the client in both directions using HTTP. Client authentication against the broker is required before you can exchange data between systems. After this, the client can then query, and also change, certain objects' properties by means of predefined methods.

The provider responsible for a particular object decides which methods are used. One example is the CIM network provider, which has a Network Port class. Multiple instances of this class can exist that then reflect the individual network cards in the system. A property of the class could be, for example, MaxSpeed . If you query this, the maximum speed of the card will be displayed. This is possible for all instances of the Network Port class.

Installation

The following section looks at the setup and configuration of a CIMOM and a client system. A recent version of Fedora, which is used on both systems, provides the required packages via the distribution's standard repositories. As the broker, Fedora uses the OpenPegasus WBEM service; a number of providers are available for various subsystems. A WBEM client and interpreter are used on the client system; they can address the desired CIM objects on the broker. Client authentication is necessary when accessing the broker. This is based on user names and passwords, which are defined previously on the broker. Because communication is via the insecure HTTP protocol, the use of X.509 certificates is recommended for production use. This supports data encryption using the secure HTTPS protocol. In my example, both systems belong to a FreeIPA domain so that the broker can easily retrieve a certificate from the identity management framework. The use of self-signed certificates is also possible for test purposes.

On systems running the CIM broker, the OpenPegasus WBEM services and the most important CIM providers then can be easily installed using the distribution's dnf package manager:

# dnf install tog-pegasus
# dnf install openlmi-{storage,networking,service,account,hardware,powermanagement}

More providers can be installed, if required. For testing purposes, however, the newly installed packages are all you need. As an alternative to this procedure, the source code is available on the OpenLMI project website. Although the OpenPegasus CIMOM is now the de facto standard in the open source environment, there are a few other brokers – for example, the Small Footprint CIM Broker (SFCB), which is often used in the embedded Linux industry.

In the file /etc/Pegasus/access.conf, you define which users have access to the broker. You need to set a password for the broker on the system. Since HTTP Basic authentication is used to log in the users, and thus all data are transferred in the clear, a corresponding X.509 certificate should be used on the CIMOM systems to support client system access via HTTPS.

In this article, I assume that all systems are part of a FreeIPA domain – this is not a requirement. Another Kerberos principal can be easily created on the broker for the CIMOM service to then request an X.509 certificate for this service (Listing 1). This also has the advantage that the certificates can be managed by the FreeIPA client service, certmonger. This ensures, for example, that the certificates are renewed when their expiration dates mature and they become be invalid.

# ipa service-add CIMOM/`hostname`
-------------------------------------------------------------------------------
Added service "CIMOM/broker.example.com@EXAMPLE.COM"
-------------------------------------------------------------------------------
  Principal: CIMOM/broker.example.com@EXAMPLE.COM
  Managed by: broker.example.com
# ipa-getcert request -f /etc/Pegasus/server.pem -k /etc/Pegasus/file.pem -N CN=`hostname` -K CIMOM/`hostname`

Also note that there is currently a problem in connection with SELinux, if you want certmonger to store the certificate in the default path below /etc/Pegasus, since access to these folders is prevented by an enabled SELinux policy. Unfortunately, the path cannot be changed by means of a configuration statement, so the only available approach is to write your own SELinux policy module that permits access to the folder or to run the certmonger service in SELinux's permissive mode. Since the first option would go beyond the scope of this article [4], I am simply assuming that the service is in permissive mode. This can be easily implemented using the following command:

# semanage permissive -a certmonger_t

Dropping the certificate in the /etc/Pegasus folder will then work, although the audited service still displays SELinux error messages. Of course, you can also obtain a certificate from a different certificate authority (CA). In any case, you need to ensure that the CA certificate is also available, in addition to the certificate and the corresponding key for the broker. Save this in /etc/Pegasus/client.pem. The CA certificate naturally also needs to be available in the X. 509 trust store on the client systems so that the connection to the broker is validated. Finally, you need to launch and permanently enable the CIMOM service:

# systemctl start tog-pegasus.service
# systemctl enable tog-pegasus.service

On the client systems, the openlmi-tools package must be in place. It contains the lmi meta-tool, which can send the generic high-level commands to a broker. There is also lmishell, which is based on a Python interpreter.

It can be used both interactively and non-interactively. To be able to work with the tools, you also need to install the OpenLMI scripts. These are Python libraries that provide access to the various CIMOM objects. The installation again relies on the dnf package manager:

# dnf install openlmi-tools "openlmi-scripts-*"