Managing remote Linux systems with OpenLMI

OpenLMI stands for Open Linux Management Infrastructure. It aims at improving productivity of system administrators by providing a standardized remote API to management functions. OpenLMI was introduced as part of RHEL 7 beta & can be used to manage systems running RHEL, Centos & fedora. Support for other linux variants might be added in the future.

It has the following key features:

• Configure, manage and monitor storage (local & remote)
• Configure and manage networks.
• Install and manage software.
• Add and manage users.
• Manage system services.
• Manage power state.
• Query system and hardware configuration.
• System Logging.
• Active firewall management.
• Join IPA and MS Active Directory domains.

OpenLMI consists of two components:

1. LMI metacommand (A command line utility to perform discovery and operations on remote managed systems. For example, it can start a printing service on remote system)
2. LMIShell (A high-level python-based WBEM client, that can be used for scripting or as an interactive shell to manage remote systems)

When configured OpenLMI works in a server-client model. We configure the server component in the management host & use it to administrator client hosts.

Since this is a lab setup I've shutdown firewalld & set SELinux to permissive.

Installation & configuration:

For the purpose of this demonstration I spun up two CentOS hosts, one to be the server & other to be the client.

Configuring the server/management node:

Install the openlmi-tools & openlmi-scripts packages.

#yum install openlmi-tools openlmi-scripts* -y

you need to have EPEL repository enabled before attempting to install these packages.

Configuring the client node:

On the client to be managed by the server node install the openlmi package.

#yum install openlmi -y

This is a metapackage that installs the OpenLMI infrastructure and a base set of OpenLMI Providers.

Now start the component in charge of receiving instructions (the object broker pegasus)

#systemctl start tog-pegasus.service

To have the service automatically started when the system boots, use the command:

# systemctl enable tog-pegasus.service

We need to give a password to the pegasus user:

#passwd pegasus 


Server client connectivity:

In order to allow the management node to connect to the client node we need to get the certificate for the client node:

# scp 192.168.44.137:/etc/Pegasus/ca.crt /etc/pki/ca-trust/source/anchors/devbox-cert.pem

Add the certificate to the management nodes' trust store:

#[root@instructor ~]# update-ca-trust extract
p11-kit: the CKA_X_CRITICAL attribute is not valid for the object
p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit
p11-kit: the CKA_X_CRITICAL attribute is not valid for the object
p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit
p11-kit: the CKA_X_CRITICAL attribute is not valid for the object
p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit
p11-kit: the CKA_X_CRITICAL attribute is not valid for the object
p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit
p11-kit: the CKA_X_CRITICAL attribute is not valid for the object
p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.supplement.p11-kit

You can ignore the errors.

Testing:

To test the configuration, type the following command to connect to the client node (devbox in this example)) from the management node (instructor in this example):

[root@instructor ~]# lmi -h devbox

Once connected we are brought into the LMIShell & from here we can gather information about the client node & also perform a plethora of administrative functions on the client.

When we run the first command from the LMIShell we'll need to authenticate with the pegasus user but that's a one time thing.

So, if we need to check the status of sshd service type the following command:

lmi> service show sshd.service
username: pegasus
password:
Name=sshd
Caption=OpenSSH server daemon
Enabled=Yes
Status=Running

If we want to stop & start a service we do by typing service stop <service name> followed by service start <service name>

lmi> service show crond.service

Name=crond

Caption=Command Scheduler

Enabled=Yes

Status=Running

lmi> service stop crond.service

lmi> service show crond.service

Name=crond

Caption=Command Scheduler

Enabled=Yes

Status=Stopped - OK

lmi> service start crond.service

lmi> service show crond.service

Name=crond

Caption=Command Scheduler

Enabled=Yes

Status=Running

lmi>

To list out local storage devices present on a client node type:

lmi> storage list

Name                  Size        Format

/dev/sda              21474836480 MS-DOS partition table

/dev/sdb              5368709120  physical volume (LVM)

/dev/sr0              5368709120  Unknown

/dev/mapper/repo-epel 5364514816  xfs

/dev/sda1             314572800   xfs

/dev/sda2             2147483648  swap

/dev/sda3             19011731456 xfs

To get a list of available commands type ? 

lmi> ?

Static commands

===============

EOF  exit  help

Application commands (type help <topic>):

=========================================

file   hwinfo    locale  power   selinux  sssd     sw      user

group  journald  net     realmd  service  storage  system

Built-in commands (type :help):

===============================

:..  :cd  :pwd  :help

Conclusion:

I've read about OpenLMI being compared to Puppet in some places. I'm not sure how apt is this comparison. More information about OpenLMI can be found on its official website. Some documentation on OpenLMI can be found here.