Management mit OpenLMI

Die meisten Administratoren haben sich im Lauf der Zeit ihre eigenen Toolboxen aus Skripten zusammengestellt. Mit deren Hilfe und etwas SSH-Magie wird dann der ausufernde System-Zoo in Schach gehalten. Neue Software oder Funktionen erfordern es jedoch immer wieder, diese Toolbox anzupassen und auf den neuesten Stand zu bringen. Einsteiger haben es aber oft schwer, sich überhaupt auf neuen Systemen zurechtzufinden – gerade auch dann, wenn der eigene System-Zoo eine Vielzahl von unterschiedlichen Linux-Derivaten enthält. Eine einheitliche Methode und Schnittstelle zur Verwaltung der Systeme wäre also wünschenswert.

OpenLMI stellt eine solche Schnittstelle zur Verfügung. Das Kürzel steht für Open Linux Management Infrastructure und basiert auf einem offenen Industrie-Standard.

Struktur im Management

Das Framework stellt eine Vielzahl von Low-Level-Funktionen zur Verfügung, mit denen sich unterschiedliche Aufgaben auf einem System ausführen lassen – lokal wie auch remote. Ob es sich hierbei um ein Bare-Metal- oder ein virtualisiertes System handelt, spielt erst mal keine Rolle. Zu den möglichen Aufgaben zählen dabei die Konfiguration des Betriebssystems und dessen Komponenten, die Verwaltung von System-Services, das Management und Monitoring von Hardware und die Software-Verwaltung, um nur einige zu nennen.

OpenLMI basiert dabei auf einem DMTF-Standard (Distributed Management Task Force) mit dem Namen WBEM (Web-Based Enterprise Management) (siehe [1]). Der Standard setzt sich aus verschiedenen Komponenten zusammen und beschreibt eine Reihe von Technologien zur einheitlichen Verwaltung von Computer-Systemen. Eine der verwendeten Komponenten nennt sich CIM (Common Information Model) und beschreibt in einer Art Schema typische Objekte, die auf einem Computer-System zum Einsatz kommen (Hardware, Software, Benutzer, Konfigurations-Subsysteme und so weiter). Überlicherweise wird der Begriff CIM jedoch nicht nur für das Schema eines Objekts verwendet, sondern bezieht sich auch auf die eingesetzten Tools und Technologien.

Das OpenLMI-Framework setzt sich aus einem CIM-Client und vielen CIM-Servern zusammen. Der Client stellt in diesem Zusammenhang ein Management-System dar, das via XMLRPC mit einem CIM-Object-Manager (CIMOM) – manchmal auch Object-Broker genannt – mit dem CIM-Server spricht. Der Client versendet dabei CIM-/XML-Dokumente, die der CIMOM an die zuständigen CIM-Provider weiterreicht. Die Provider decken dabei bestimmte Aufgabenbereiche ab. Beispielsweise existieren CIM-Provider für Netzwerk, Speicher, System-Services, Software, Monitoring, Benutzer und so weiter. Die XML-Dokumente eines Clients beschreiben die Art der Aufgabe, die von einem CIM-Provider – also auf dem zu verwaltenden System – durchzuführen ist. Die Dokumente werden anhand von Skripten oder Meta-Kommandos auf der Client-Seite erzeugt. Die Provider (auch CIM-Agenten genannt) auf einem System sind dann dafür verantwortlich, dass die gewünschten Aufgaben entsprechend durchgeführt werden. Die Agenten können dabei von einer Vielzahl von Herstellern zur Verfügung gestellt werden. [2] beschreibt die Anforderungen, die bei der Entwicklung eines CIM-Agenten zu beachten sind.

Auf den Clients existieren eine Vielzahl unterschiedlicher Interfaces, die über den CIM-Object-Manager mit den Agenten auf den Servern kommunizieren können. Es gibt ein High-Level-Kommandozeilentool, eine programmierbare LMI-Shell sowie APIs für unterschiedliche Sprachen (Python, C/C++, Java), sodass Admins ihre LMI-Skripte in einer dieser Sprachen entwickeln können. Zur Kommunikation zwischen Client und Servern sollte auf den Servern der Port 5989 (»wbem-https« ) geöffnet sein. Über diesen läuft die gesicherte Verbindung zwischen den Client-Interfaces und dem Object-Broker auf den Servern.

Installation

OpenLMI ist seit Fedora 18 in den Standard-Repositories der Distribution enthalten. Ich empfehle jedoch, Fedora 20 und die darin enthaltenen Pakete einzusetzen. Im letzten Jahr gab es gravierende Änderungen an der OpenLMI-Software, sodass es unbedingt sinnvoll ist, die neueste Version einzusetzen. Für andere Distributionen steht unter [3] der OpenLMI-Quellcode zur Verfügung. Auf den zu verwaltenden Server-Systemen sind der OpenLMI-Object-Broker OpenPegasus sowie die gewünschten OpenLMI-Agenten zu installieren:

yum install tog-pegasus openlmi-providers openlmi-storage openlmi-networking openlmi-powermanagementopenlmi-service openlmi-account

Das SBLIM-Projekt [4] stellt ebenfalls viele CIM-Provider zur Verfügung. Viele davon sind im Fedora-Software-Repository enthalten und lassen sich mittels Yum installieren.

Da Server und Client über eine gesicherte Verbindung kommunizieren, wird im Rahmen der Installation des OpenLMI-Object-Broker ein selbstsigniertes X.509-Zertifikat erzeugt. Hierfür ist das Skript »/usr/share/Pegasus/scripts/genOpenPegasusSSLCerts« verantwortlich. Das Zertifikat lässt sich nach der Installation des Servers mittels »openssl x509 -in /etc/Pegasus/server.pem -noout -text« ansehen. In produktiven Umgebungen ist es natürlich ratsam, ein Zertifikat von einer Certificate Authority (CA) ausstellen zu lassen. Hierfür kann beispielsweise FreeIPA zum Einsatz kommen. Auf dem Client- beziehungsweise Management-System ist dann entweder das selbstsignierte oder CA-Zertifikat zur Verfügung zu stellen und entsprechend einzubinden:

# scp server:/etc/Pegasus/server.pem/etc/pki/ca-trust/source/anchors/remote- server.pem
# update-ca-trust

Fehlt dieser Schritt, so ist auf den Clients die Zertifikats-Verifizierung zu deaktivieren, wovon ich jedoch ausdrücklich abrate. Neben dem Zertifikat wurde als Teil der Installation ebenfalls ein Benutzer »pegasus« erzeugt. Dieser kann für authentifizierte Zugriffe auf den Server zum Einsatz kommen. Hierfür ist für den Benutzer jedoch mittels »passwd pegasus« zuerst ein Passwort zu setzen. Schließlich bleibt noch der Object Broker auf dem Server zu starten:

# systemctl start tog-pegasus.service

Auf dem Client sollte für erste Tests die OpenLMI-Shell oder das Kommandozeilentool lmi zum Einsatz kommen. Diese installiert man mittels:

# yum install openlmi-toolsopenlmi-scripts

Die OpenLMI-Shell basiert auf Python und kann sowohl interaktiv wie auch im Batch-Mode verwendet werden. Jede CIM-/XML-Anweisung wird über einen sicheren HTTPS-Kanal an den Object Broker auf den Servern gesendet und dort von den zuständigen CIM-Agenten verarbeitet. Um die Arbeit mit der Shell zu vereinfachen, wandelt diese einfach jedes OpenLMI-Objekt in ein Python-Objekt um. Wer etwas Python beherrscht, kann somit sehr schnell OpenLMI-Skripte schreiben. Eine Anleitung findet sich unter [5].

Wer etwas schneller ans Ziel kommen möchte, greift auf das CLI-Tool »lmi« zurück. Dieses arbeitet mit Meta-Kommandos, die auf den OpenLMI-Client-Bibliotheken aufsetzen. Diese kann man ebenfalls aus dem Fedora-Repository heraus auf den Clients beziehungsweise dem Management-System installieren: »yum install openlmi-scripts-*« .

Das folgende Beispiel zeigt, wie sich ein beliebiger systemd-Service auf einem CLI-Server mithilfe des Tools »lmi« von einem zentralen Management-System aus steuern lässt:

# lmi -h fedora.virt.tuxgeek.de service show httpd.service | grep Status
Status=OK
# lmi -h fedora.virt.tuxgeek.de service stop httpd.service
# lmi -h fedora.virt.tuxgeek.de serviceshow httpd.service | grep Status
Status=Stopped

Genauso einfach lassen sich auch die Software-Pakete eines Systems mittels lmi verwalten. Diesmal im interaktiven Modus:

# lmi -h fedora.virt.tuxgeek.de
lmi> sw install zsh
lmi> sw list pkgs zsh
NEVRA                     Summary
zsh-0:5.0.2-6.fc20.x86_64 Powerfulinteractive shell

Konfigurationsoptionen, wie beispielsweise der Benutzername und das Passwort zur Authentifizierung am Object Broker, liest das Tool aus der globalen Datei »/etc/openlmi/lmi.conf« aus. Wie üblich können Benutzer eine eigene »~/.lmirc« anlegen.

Rund um OpenLMI ist mittlerweile eine aktive Community entstanden. Wer Gefallen an dem Management-Framework gefunden hat, findet unter [3] Hinweise dazu, wie man sich an der Weiterentwicklung beteiligen kann.

Abbildung 1: OpenLMI basiert auf einem Management-System (CIM-Client) und den zu verwaltenden Systemen (CIM-Server).