© Aaron Amat, 123RF

“Ich bin Mr. Wolf. Ich löse Probleme.” Ob Zitate wie dieses hilfsbereite von Harvey Keitel aus Tarantinos “Pulp Fiction” die Macher der im Folgenden vorgestellten Softwareverteilung inspiriert haben, lässt sich nicht sicher sagen. Was das Red-Hat-Community-Projekt Pulp ausmacht aber schon.

Yum[1] mildert die Leiden von Administratoren, die RPM-basierte Systeme pflegen, erheblich. Mit Hilfe von Yum-Repositories installiert der Admin das Zielpaket wie bei Debian oder Gentoo und das Paketmanagement löst alle Abhängigkeiten eigenständig auf. Auch Updates und das Installieren aus mehreren Quellen unterstützt Yum.

Aber was macht der Admin, wenn er nicht ein paar, sondern 10, 50 oder 1000 Rechner verwaltet, die möglichst gleich oder in Gruppen gleicher Systeme installiert sein sollen? Dazu kommt vielleicht noch eine Mischung aus Centos, Fedora und Red Hat Enterprise Linux. Entweder steht viel Handarbeit an oder es entsteht eine bunte Skriptsammlung.

Einen Ausweg schafft das Pulp-Projekt [2], eine Softwareverteilung für Red Hat Enterprise Linux 5 und 6, Fedora 15 und 16 sowie Centos. Das Prinzip der Software (seit Februar 2012 mit der Versionsnummer 1.0) ist es, dass der Administrator die RPM-Sammlungen lokal vor- und aktuell hält und dass sich angeschlossene Clients daraus bedienen.

In das System eingebundene Clients verwenden es einfach als Yum-Repository, ihnen stehen dann alle Pakete aus den Quellen, für die sie sich beim Server registriert haben, zur Verfügung. Der Clou des Systemes ist aber, dass der Server Pakete auch an die Clients verteilen kann und für bereits installierte Pakete Updates einspielt. Somit lässt sich der Softwarestand auf allen angeschlossenen Systemen zentral administrieren.

Pulp eröffnet Möglichkeiten, Systeme zu Gruppen zusammenzufassen, um zum Beispiel alle Systeme der Buchhaltung mit einem Kommando mit dem Update der Buchhaltungssoftware auszustatten; auf dem Webserver, der in einer anderen Gruppe gelistet ist, landet die Buchhaltungssoftware damit nicht. Zudem besitzt das System die für Software-Inventarisierungen typischen Abfragemöglichkeiten, zum Beispiel welche Systeme welche Pakete verwenden.

Dreiteilige Architektur

Pulp ist in Python programmiert und enthält drei logische Komponenten:

• Den Yum-Server, der die Pakete und die Verwaltungsinformationen vorhält und die Installationen steuert.
• Den Yum-Client beziehungsweise Consumer, er bezieht seine RPM-Pakete vom Yum-Server oder bekommt sie von ihm zugeteilt.
• Optional gibt es noch den Yum Content Delivery Server (CDS), der in verteilten Installationen die Last und den Netzwerktraffic entzerrt. Dazu hält er eine lokale Kopie der RPMs vor, damit diese gegebenenfalls nicht über eine langsame WAN-Leitung auf dem Client landen.

Seine Verwaltungsinformationen speichert das System in einer Mongo DB [3]. Die Kommunikation der Komponenten erfolgt zum einen über HTTPS, zum anderen über einen eigenen Messagebus auf Basis von Apache Qpid [4]. Es ist vorgesehen, diese Kommunikation mit SSL abzusichern, wobei sich der Server beim Client und auch der Client beim Server authentisiert. Abbildung 1 zeigt die Zusammenhänge.

Abbildung 1: Logische Struktur einer Pulp-Architektur. (Quelle: Pulp-Projekt)

Paketquellen zuweisen

Repositories, also Paketquellen von zum Beispiel einer Version der Fedora-Distribution, sind für Pulp zentral. Dass Pulp auch für den eigentlichen Installationsprozess Yum verwendet, macht die Zuordnung einfach: Jedes Repository entspricht einem Yum-Repository, das der Pulp-Server aus einer externen Quelle füllt (und aktuell hält) und aus dem sich die Clients oder Consumer bedienen oder betankt werden.

Der Administrator weist dem Pulp-Consumer ein oder mehrere Repositories zu (Datei »pulp.repo« ). Für den Consumer sind sie alle per Yum erreichbar. Verbleiben die Originaleinträge aus der Installation in »/etc/yum.repos.d« oder stehen sie auf »enabled« , so führt auch eine zentrale Installation dazu, dass sich der Client – auf dem ja »yum install« periodisch läuft – gegebenenfalls das Paket über die Repository-Quelle aus dem Internet lädt.

Repositories automatisch zu synchronisieren beherrscht Pulp von sich aus. Der Administrator gibt einfach ein Schedule vor, das definiert, wie oft der Server sich mit der externen Quelle abgleicht. Dabei kann er Bandbreitenlimits vorgeben oder DVDs sowie andere Dateiquellen als Repository-Gegenüber bestimmen. Der Administrator darf zudem mehrere Repositories als Gruppe deklarieren, zum Beispiel alle Versionen von Fedora. Ebenso kann er Gruppen von Consumern bilden und dort mit nur einem Kommando ein Patch auf allen Gruppenmitgliedern ausrollen.

Last verteilen

Die Content Delivery Server eröffnen eine Möglichkeit, Repositories auszulagern, und sorgen für Lastverteilung und Ausfallsicherheit. Ein CDS bekommt Repositories zugewiesen – welche darf der Admin konfigurieren. Mehrere CDS lassen sich zu logischen Clustern zusammenfassen. Die Clients bekommen bei der Registrierung zu einem Repository einen CDS zugeordnet. Der Pulp-Server synchronisiert die Repositories auf die CDS. Der Administrator darf wieder einen Zeitplan angeben, wann dies sinnvollerweise geschehen soll, etwa um Nebenzeiten auszunutzen.

Die Benutzer kann der Admin in Pulp lokal anlegen und authentisieren oder sie auch gegen einen externen LDAP-Server authentisieren. Benutzer bekommen dann Rollen zugeordnet und diese wiederum Rechte (Permissions).

Pulp-Server installieren

Wer einen Pulp-Rechner aufsetzen will, tut dies, wie könnte es anders sein, per Yum. Für einen Pulp-Server legt der Admin in »/etc/yum.repos.d/« ein »pulp.repo« ab. Auf der Installationswebseite finden sich je nach Distribution und deren Version gleich die passenden Wget-Kommandos, mit denen die Datei auch an den richtigen Ort gelangt.

Einiges ist allerdings zu beachten, wie mehrere Testinstallationen ergaben:

• Die Hardware sollte nicht zu schwach dimensioniert sein, da viel I/O anfällt, die Mongo DB CPU-Leistung benötigt und die Repositories viel Festplattenplatz belegen.
• Auf dem Server soll ein Apache-Webserver mit »mod_wsgi« laufen. (Das verträgt sich meist nicht mit »mod_python« .) Die Firewall muss die Ports 443, 5672 und 5674 offenhalten.
• Der Pulp-Server benötigt ein gültiges SSL-Zertifikat, das auf den Full Qualified Domain Name ausgestellt ist; dies kann selbst erzeugt sein. Achtung: Jene von Apache auf »localhost.localdomain« verhindern die Kommunikation zwischen Consumern und dem Server und auch zwischen dem Administrationstool und dem Server. Für Content Delivery Server gilt das Gleiche, sollen sich alle Consumer mit Clientzertifikaten authentisieren.
• Die Repositories landen unter »/var/lib/pulp« – dabei kommen schnell mehrere Gigabyte zusammen. Der Admin sollte rechtzeitig prüfen, ob genug Platz ist.
• Die Daten für die Verwaltung liegen in der Mongo DB unter »/var/lib/mongodb« . Auch hierfür sollte ausreichend Platz sein, wenn auch nicht so viel wie für die Repositories.

Beim Planen muss anfangs nicht feststehen, ob es Content Delivery Server geben soll, die lassen sich nämlich später einfach hinzugefügen. Die Installation beginnt auf dem Server mit »yum install pulp« . Unter Fedora braucht nichts weiter zu passieren. Bei RHEL 5 und 6 installiert der Admin noch das »epel« -Paket, die Installationsanleitung auf der Webseite nennt hierfür das Kommando.

Bei Red Hat 5 muss er zudem eine Subscription zu den Channels “MRG Messaging” und “Messaging Base” einrichten. Beim für diesen Artikel getesteten Centos 6.2 hat es gereicht, das Paket »qpid-server« mit Yum ins System zu holen. Alternativ installiert der Admin Apache Qpid aus den Source-RPMs, wie dies bei älteren Centos-Versionen notwendig war. Dabei muss er Geduld oder eine kräftige Maschine mitbringen, da das Kompilieren eine Weile dauert.

Liegt Pulp auf der Platte, ersetzt der Admin in der Datei »/etc/pulp/pulp.conf« zumindest »localhost« durch den individuellen Namen des Systems. Für ihn sollte auch das Webserver-Zertifikat ausgestellt sein. In derselben Datei ist auch der Default-Administrator »admin« mit Passwort »admin« hinterlegt. Vor dem Produktivbetrieb sollte man Letzteres ändern.

Film ab!

Mangels einer Policydatei für Pulp müssen RHEL-5-Admins noch die SE-Linux-Policy deaktivieren oder auf »permissive« stellen, es gibt ja keine. Spätestens jetzt kann’s losgehen: »service pulp-server init« initialisiert den Dienst und »service pulp-server start« startet ihn.

Der Systemverantwortliche wird auf Dauer mit einer Admin-Clientsoftware arbeiten, deren Paket »pulp-admin« mit Yum auf seinem PC landet. Der Rechner muss nicht mal Pulp-versorgt sein, sogar der Pulp-Server selber eignet sich. Damit der Admin-Client den Server findet, gehört der Hostname des Servers in die »/etc/pulp/admin/admin.conf« .

Auf den Clients führt der Administrator jetzt »yum install pulp-consumer« aus und ersetzt in der Datei »/etc/pulp/consumer/consumer.conf« abermals »localhost« durch den Namen des Pulp-Servers. Jetzt kann er auf den Clients »service pulp-agent start« aktivieren.

Der Logik folgend bekommen eventuelle Content Delivery Server mit »yum install pulp-cds« ihre Software verpasst. In deren »/etc/pulp/cds.conf« -Datei gehört der Pulp-Server ebenso wie der Speicherort für die Repositories. Auch der CDS muss beim Pulp-Server angemeldet sein.

Konfigurieren

Der Administrator meldet sich beim Pulp-Server entweder mit »-u Benutzername -p Passwort« an oder indem er mit dem Kommando »pulp-admin auth login« die Zugangsdaten im Homedirectory speichern lässt – ein nur auf vertrauenswürdigen Systemen akzeptables Vorgehen. Der erste Schritt erzeugt und synchronisiert die Repositories. Bei Centos sieht dies folgendermaßen aus:

pulp-admin repo create --arch x86_64--name Centos6.2 --id centos6.2_64 --feedhttp://centos.bio.lmu.de/6.2/os/x86_64/
pulp-admin repo sync --id centos6.2_64sync -F

Der Parameter »–id« taucht bei allen Kommandos auf, die etwas mit Repositories zu tun haben, und gibt dieses an. Die Option »-F« bestimmt, dass das Kommando im Vordergrund abläuft, normalerweise läuft das Synchronisieren im Hintergrund. URLs bei »–feed« dürfen auch dem »file:« -Schema folgen, wenn eine DVD einzubinden ist. Es folgt das Anmelden des Clients am Server. Dies geschieht auf dem Clientsystem, im Beispiel ist das »centoshost.localnet« :

pulp-consumer -u admin -p adminconsumer register --id=centos.localnet

Der Befehl antwortet mit einer harmlosen Warnung:

this client is not known to the pulpserver; run 'pulp-consumer consumerregister' to register it
Successfully registered consumer[ centos.localnet ]

Nun bekommt der Client ein oder mehrere Repositories zugewiesen. Dies stößt der Admin entweder vom Client aus an oder erledigt die Zuordnung am Server. Im Sinne der zentralen Administration ist es klug, den zweiten Weg zu gehen:

pulp-admin consumer bind--id centos.localnet --repoid centos6.2_64

Der letzte Schritt legt auf dem Client eine neue Datei in »/etc/yum.repos.d« an, die ausreicht, um das System mit den synchronisierten Paketen zu versorgen.

Pulp benutzen

Der Server kann nun Pakete auf dem Client (nach-)installieren, beispielsweise einen Webserver mit dem »pulp-admin« -Kommando aus Listing 1. Will der Admin dagegen Updates einspielen, nimmt er statt »install« das Kommando »update« . Wer das Deployment auf Niedriglast-Zeiten verschieben will, gibt der Option »–when« einen Installationszeitpunkt mit auf den Weg.

01 $ pulp-admin package install -n httpd --consumerid centos.localnet
02
03 Created task id: 3a002d8f-6b7f-11e1-9cd9-0800278fe6fd
04 Waiting: [\]
05 Consumer ID: centos.localnet [ SUCCEEDED ]
06 ==================================================
07 Package Arch Version Repository
08 ==================================================
09 Installed:
10 httpd x86_64 2.2.15 updates
11
12 Installed for dependencies:
13 apr x86_64 1.3.9 base
14 apr-util x86_64 1.3.9 base
15 apr-util-ldap x86_64 1.3.9 base
16 httpd-tools x86_64 2.2.15 updates
17 mailcap noarch 2.1.31 base

Hinter »-n« folgt der Name des gewünschten Pakets, mehrere übergibt der Admin mit mehrfachen »-n« . Ein »update« ohne »-n« aktualisiert alle Pakete des Hosts. Ist der Client nicht aktiv, puffert Pulp das Kommando und übermittelt es nach dem Aufbau der nächsten Verbindung zwischen Consumer und Pulp-Server. Statt der Option »–consumerid« eignet sich auch »–consumergroupid« , um eine Gruppe aus Hosts anzugeben. Hier die Definition einer Consumer-Gruppe:

pulp-admin consumergroup create--id fedora16
pulp-admin consumergroup add_consumer--id fedora16 --consumerid fedora
pulp-admin consumergroup add_consumer--id fedora16 --consumerid fed2

Nun lassen sich »install« – und »update« -Befehle auch auf Gruppen anwenden. Pulp geht dabei so intelligent vor, dass es etwa ein anstehendes Apache-Update nur auf den Systemen versucht, auf denen der Webserver auch installiert ist.

Auf dem Server listet »pulp-admin consumer info –id=Consumer-Name –show-profile« auf, welche Pakete auf dem mit »–id« angegebenen Consumer installiert sind. Der Systemverantwortliche bekommt so den Überblick über verteilte Pakete. Das Kommando erfasst allerdings nicht die manuell per »rpm« installierte und deinstallierte Software.

Schwache Dialoge

Eine kleiner Mangel trat zum Ende des Tests auf: Verwendet der Administrator »pulp-admin auth« , um die Zugangsdaten zu speichern, geschieht dies in Form eines Zertifikates mit Verfallsdatum. Wenn dies mitten beim Arbeiten abläuft, erscheint ein nicht gerade instruktives »Certificate Expired« . (Wem dies widerfährt, der braucht sich nur mit »pulp-admin auth« wieder anzumelden.)

Ähnlich schwach sind die meisten Meldungen auf der Konsole und seltsame Python-Stacktraces in den Logfiles – dabei könnten die fast so instruktiv wie in “Pulp Fiction” sein: “Also ich werde jetzt bis drei zählen. Wenn du bis dahin nicht den Koffer geöffnet hast, bleiben von deinem Gesicht nur noch die Ohren übrig!”

Abspann

Pulp 1.0 fehlt es noch an Genialität, als dass es zum Genreklassiker à la Tarantino reichen würde. Die Deploymentlösung erleichtert Administratoren größerer Umgebungen aber die Pflege und das automatische Nachinstallalieren von Paketen. Durch geschicktes Gruppieren von Servern gleicher Funktion lässt sich die Pflege noch optimieren.

Mit Pulp den Installationsserver für die Software-Erstbeschickung von betriebssystemlosen Rechnern abzulösen gelingt bislang nicht (siehe auch Tabelle 1). Auf der Roadmap steht jedoch ein Mechanismus, der Konfigurationsdateien über den Pulp-Server verteilt, was den Admins einen weiteren Teil der Routinearbeiten am Set abnehmen würde. (jk)