Die Paketverwaltung gilt als einer der Kernbestandteile moderner Distributionen. Einer der Vorreiter und gleichzeitig wichtigsten Vertreter kommt von Red Hat und nennt sich RPM.

Bevor es Paketmanager gab, stand Software häufig nur als Quelltext zur Verfügung. Das bedeutete für den Anwender, dass er jedes Programm von Hand kompilieren und auf dem System einrichten musste. Erst Paketmanager erlauben den bequemeren Umgang mit Software.

Im Lauf der Zeit etablierten sich zwei Formate als Quasi-Standard: Auf Debian basierende Distributionen verwenden mehrheitlich DEB, während die Abkömmlinge von Red Hat und viele andere das RPM-Format bevorzugen. Dieses Format wurde ursprünglich von der Firma Red Hat als Red Hat Packet Manager [1] entwickelt und unter die GNU General Public License (GPL) gestellt. Heute ist das Tool unter dem Namen RPM Paket Manager (ein rekursives Akronym) bekannt. Zum Einsatz kommt es in der Red-Hat-eigenen Distribution Red Hat Enterprise Linux (RHEL) sowie deren Ablegern, wie etwa CentOS. Jedoch setzen auch andere Distributionen wie Fedora, Suse oder Mandriva auf RPM.

Installation und Deinstallation

Zur Kernaufgabe von RPM gehört das Installieren und Deinstallieren von Software. Das Einrichten eines lokal vorliegenden Pakets erledigt der Befehl

# rpm -i Paketname.rpm

Die beiden Optionen -v und -h veranlassen den Paketmanager, mehr Informationen über den Status und Fortschritt der Installation anzuzeigen. Um Pakete zu installieren, die sich auf FTP- oder HTTP-Servern befinden, lautet die Installationssyntax

# rpm -ihv "http://Domain/Paketname.rpm"

Mit dem Schalter -U aktualisieren Sie bereits installierte Software. Dabei hängt es vom Entwickler des Pakets ab, ob RPM die alten Konfigurationsdateien beibehält und die neuen mit der Endung .rpmnew im Dateisystem ablegt, oder die alten Konfigurationen mit der Endung .rpmsave sichert. Die meisten RPM-Pakete verwenden jedoch die erste Variante. Das Löschen von Paketen erfolgt über den Schalter -e. Dabei reicht es meist, nur den Paketnamen ohne Versionsnummer anzugeben.

Um zu verstehen, was bei der Installation von RPM-Paketen geschieht, gilt es, deren Aufbau zu kennen. Das Paket selbst besteht aus mehreren Teilen. Es enthält neben den ausführbaren Dateien der Software sowie die dazugehörigen Bibliotheken (Shared Libraries) auch die Konfigurations- und Dokumentationsdateien wie beispielsweise die Man-Pages. Für jede Datei enthält das Paket zusätzlich Informationen darüber, an welcher Stelle im Dateisystem es gespeichert wird. Darüber hinaus verfügt das Paket über Meta-Informationen der Software, beispielsweise eine Beschreibung, von welchem Projekt sie stammt oder unter welcher Lizenz sie steht.

Daneben ist ein RPM-Paket auch in der Lage, Skripte vor oder nach der Installation auszuführen. Beispielsweise benötigt der Webserver Apache einen bestimmten Benutzer, unter dem der Prozess startet. Sollte dieser auf dem System nicht existieren, legt RPM ihn bei der Installation des Paketes mit an. Auch enthält ein Paket Informationen zu Abhängigkeiten mit anderen Programmen und Bibliotheken. Sind diese nicht vorhanden, bricht der Paketmanager die Installation ab: Der Benutzer muss dann die Abhängigkeiten auflösen.

Der Paketmanager kopiert also die enthaltenen Dateien an die festgelegte Stelle im System, führt alle notwendigen Skripte aus dem RPM-Paket aus, und aktualisiert schließlich die RPM-Datenbank mit den Informationen über die neu installierte Software. Bei der RPM-Datenbank handelt es sich um eine handvoll Dateien auf BDB-Basis. Diese liegen üblicherweise im Verzeichnis /var/lib/rpm. Diese Datenbank ermöglicht es, nachträglich Informationen über installierte Software auf dem System abzurufen.

Abfragen

Abfragen an die RPM-Datenbank beginnen mit dem Schalter -q, gefolgt vom Paketnamen oder einer weiteren Option. Um die Liste aller Dateien aus dem Webserver-Paket anzuzeigen, genügt die Eingabe rpm -ql httpd (Listing 1). Die Option -l steht dabei für das Auflisten aller Dateien des Paketes. Der Schalter -c schränkt die Anzeige auf die enthaltenen Konfigurationsdateien ein, -d zeigt lediglich die enthaltenen Dokumente, etwa Man-Pages.

# rpm -ql httpd
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d/welcome.conf
/etc/httpd/conf/httpd.conf
[…]

Möchten Sie die Anfrage nicht an die RPM-Datenbank stellen, sondern direkt an ein RPM-Paket, verwenden Sie die Option -p. Alle weiteren Abfrage-Optionen bleiben unverändert. Der Aufruf

rpm -qpl httpd-2.2.13-4.fc12.i686.rpm

listet entsprechend alle Dateien des noch nicht installierten Webserver-Pakets auf. Die Meta-Information eines Pakets gibt RPM mit -i preis, etwa # rpm -qi httpd. Um in Erfahrung zu bringen, was eventuell enthaltene Skripte bei der (De)Installation bewerkstelligen, hängen Sie das Kommando --scripts an (Listing 2).

# rpm -q --scripts httpd
preinstall scriptlet (using /bin/sh):
# Add the "apache" user
/usr/sbin/useradd -c "Apache" -u 48 \
 -s /sbin/nologin -r -d /var/www apache 2> /dev/null || :
[…]
posttrans scriptlet (using /bin/sh):
/sbin/service httpd condrestart >/dev/null 2>&1 || :

Besitzt ein RPM-Paket einen Vorgänger, enthält es häufig eine Pakethistorie. Diese erweist sich als nützlich, um die Versionsunterschiede anzuzeigen. Die Abfrage starten Sie mit dem Schalter --changelog.

Der Paketmanager hält aber auch andere Eigenschaften vor, wie etwa die Größe, den Installationszeitpunkt oder eine MD5-basierte Signatur der einzelnen Dateien. Veränderungen an diesen nach der Installation bringt die Abfrage # rpm -V httpd ans Licht. RPM vergleicht dabei sowohl die MD5-Prüfsumme als auch den Zeitstempel im Inode. Eine Zusammenfassung aller verfügbaren Abkürzungen zeigt die Man-Page von RPM.

Der Versuch, ein Paket zu löschen, misslingt, wenn andere installierte Pakete dieses als Abhängigkeit benötigen (Listing 3). Eine Liste aller Pakete, die das fragliche Paket benötigen, zeigt der Schalter --whatrequires. Entsprechend gilt es, vor dem Löschen des eigentlichen Pakets diejenigen zu entfernen, die davon abhängen.

# rpm -e httpd
error: Failed dependencies:
  httpd-mmn = 20051115 is needed by (installed) mod_python-3.3.1-11.i686
  httpd-mmn = 20051115 is needed by (installed) mod_security-2.5.9-2.fc12.i686
  httpd-mmn = 20051115 is needed by (installed) mod_ssl-1:2.2.13-4.fc12.i686
[…]

Alternativ verwenden Sie den Schalter --nodeps, womit RPM die Abhängigkeiten ignoriert. Allerdings kann das dazu führen, die abhängige Software danach nicht mehr einwandfrei funktioniert. Dieser Schalter eignet sich jedoch nicht nur beim Entfernen von Paketen, sondern auch zu deren Installation. Zwar lässt sich RPM auch über die Option --force überreden, das Paket trotzdem zu (de)installieren, jedoch funktioniert das höchstwahrscheinlich nicht. Diese Abhängigkeitsprobleme führten schon früh zu dem Wunsch, dass ein RPM-Frontend sich darum kümmert. Davon gibt es inzwischen mehrere, das bekannteste davon nennt sich Yum (Yellowdog Updater Modified).

RPM-Frontend Yum

Das Python-Tool Yum [2] wurde ursprünglich von Seth Vidal an der Duke Universität in den USA entwickelt. Viele Linux-Distributionen setzten es mittlerweile als RPM-Frontend ein. Yum kümmert sich transparent um die Abhängigkeiten zwischen verschiedenen Paketen und löst diese beim Installieren und Deinstallieren selbständig auf. Das gilt sowohl für lokal vorliegende Pakete als auch solche aus den Software-Repositories. Yum greift auf diese über die Netzwerkprotokolle FTP und HTTP zu. Jedes eingebundene Repository besitzt auf dem Client eine Konfigurationsdatei, die es beschreibt. Dieses liegt üblicherweise im Verzeichnis /etc/yum.repos.d/. Die Konfigurationsdatei des Fedora-Repositories sieht aus wie in Listing 4 zu sehen.

# cat /etc/yum.repos.d/fedora.repo
[fedora]
name=Fedora Repository
baseurl=http://Pfad_zum_Verzeichnis/
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=http://fedoraproject.org/static/57BBCCBA.txt

Sie dient Yum als Grundlage zum Verwalten der Onlinedatenquellen. Die Option gpgcheck legt fest, dass Yum jedes Paket vor der Installation auf Integrität und Authentizität überprüft. Das geschieht mithilfe einer digitalen GPG-Signatur, die dem RPM-Paket optional beiliegt. Der zur Authentisierung notwendige Schlüssel muss in der lokalen RPM-Datenbank vorhanden sein. Ist das nicht der Fall, so lädt Yum diesen von der unter gpgkey angegeben URL herunter, und importiert ihn in die Datenbank. Manuell importieren Sie den Schlüssel mit # rpm --import Keydatei. Der Authentitätscheck erfolgt über rpm -K Paket.

Möchten Sie beispielsweise das Paket cobbler aus dem Fedora-Repository installieren, tippen Sie in der Konsole yum install cobbler. Da Cobbler das Paket httpd als Abhängigkeit benötigt, lädt Yum es direkt mit herunter und installiert es.

Um ein Paket mithilfe eines Schlagworts zu suchen, verwenden Sie den Aufruf # yum search Schlagwort. Um die Paketbeschreibung zu erhalten tippen Sie # yum info Paketname (Abbildung 1). Yum berücksichtigt dabei alle eingetragenen Repositories.

yum search suchen Sie nach einem bestimmten Paket, yum info zeigt die Informationen dazu an.” width=”300″ height=”184″ /> Abbildung 1: Über yum search suchen Sie nach einem bestimmten Paket, yum info zeigt die Informationen dazu an.

Damit Yum nicht bei jeder Abfrage eine neue Netzwerkverbindung aufbauen muss, lädt es beim ersten Kontakt mit einem Repository bestimmte Metadateien herunter und speichert diese lokal im Verzeichnis /var/cache/yum. Diese Metadateien enthalten Informationen über die Pakete, die das Repository bereitstellt. Dazu zählt unter anderem die Angabe, zu welchen Paketgruppen die einzelnen Pakete gehören. Diese Daten hält Yum einen festgelegten Zeitraum im Cache vor. Wie lange der ausfällt, legt die Option metadata_expire in der Konfigurationsdatei fest. Nach Erreichen des Zeitraums fragt Yum beim nächsten Kontakt mit dem Repository aktualisierte Metadateien ab und speichert sie erneut.

Yum eignet sich auch zum Installieren ganzer Paketgruppen. Der Aufruf yum grouplist zeigt alle verfügbaren Gruppen an, yum groupinstall Gruppenname installiert die gewünschte. Welche Pakete zu einen Gruppe gehören, verrät der Schalter groupinfo.

Um ein lokales Paket zu installieren, verwenden Sie die Option localinstall. Auch in diesem Fall löst der Paketmanager die Abhängigkeiten auf, und lädt diese wenn nötig aus den Online-Repositories nach. Um Pakete und Gruppen vom System zu entfernen, verwenden Sie die Schalter remove und groupremove.

Als grafisches Frontend für RPM setzt Suse beispielsweise YaST ein, aktuelle Fedora-Systeme stellen das GPK-Tool (Package Manager for Gnome) bereit (Abbildung 2). Es bietet den gleichen Funktionsumfang wie Yum.

Abbildung 2: Fedora verwendet als grafische Benutzeroberfläche für RPM den Gnome Package Manager, kurz GPK.

Do it yourself

Um selbst Pakete im eigenen Repository anzubieten, benötigen Sie lediglich einen Web- oder FTP-Server. Kopieren Sie alle Dateien, die Sie anbieten möchten, in ein Verzeichnis – beispielsweise /var/ftp/pub. Damit Benutzer auch über HTTP auf die Dateien zugreifen können, erzeugen Sie im Document-Root des Webservers mit dem Aufruf # ln -s /var/ftp/pub/ /var/www/html symbolischen Link darauf.

Die notwendigen Yum-Metadateien erzeugt der Befehl # createrepo /var/ftp/pub/. Danach enthält das angegebene Verzeichnis einen Unterordner namens repodata. In diesem befinden sich verschiedene Metadateien, die der Client beim ersten Kontakt mit dem Repository herunterlädt und lokal speichert. Damit ein Client nun Pakete aus dem Repository beziehen kann, muss dieser noch über eine entsprechende Yum-Konfigurationsdatei im Verzeichnis /etc/yum.repos.d/ verfügen.

Da Yum lediglich Dateien mit der Endung .repo beachtet, nennen Sie die eigene Konfigurationsdatei myrpms.repo. Diese muss mindestens die folgenden Zeilen enthalten:

[myrpms]
baseurl=ftp://foo.bar.de/pub/
enabled=1
gpgcheck=1

Bei baseurl tragen Sie den Namen oder die IP-Adresse des eigenen Servers ein. Alternativ verwenden Sie als Übertragungsprotokoll HTTP. Benutzer können jetzt auf Yum-Repository zugreifen, und es in ihren Client einbinden.

Fazit

RPM bietet eine solide Basis zum flexiblen Verwalten von Software-Paketen. Mehr Komfort bieten Frontends wie Yum – vor allem durch das selbständige Auflösen von Abhängigkeiten. Wer eine grafische Anwendung bevorzugt, findet mit dem Gnome Package Manager oder einer vergleichbaren Lösung wie Pirut [3] ansprechende und leistungsstarke Tools.