Dieser Beitrag stammt von http://www.linux-magazin.de


Softwareinstallation unter Linux mit RPM

Paketweise

von Ludger Berse

Ich

Bei vielen aktuellen Linux-Distributionen hat sich der RedHat Paket Manager zur Software-Installation und -Deinstallation durchgesetzt. Wir zeigen in diesem Artikel den Umgang mit diesem praktischen Werkezug.


Das Einspielen von Software ist nicht immer spielend leicht. Im einfachsten Fall ruft man unter Windows 95/NT/98/2000 setup.exe auf und beantwortet ein paar (mehr oder weniger) sinnvolle Fragen und schon läuft der neue Bildschirmschoner. Soweit so gut, aber was ist bei einem Update (noch mehr Farben und Animationen), was passiert wenn man sich an dem Bildschirmschoner satt gesehen hat? Softwareinstallation ist mehr als nur Dateien kopieren. Eine Lösung für dieses Problem unter Linux ist der Redhat Paket Manager, kurz rpm. Besonders bei Mehrbenutzersystemem sind bei der Installation von Programmen einige Punkte zu beachten:

  • Datei-Berechtigungen
  • Versionsstände
  • Dokumentationen
  • Konfigurationsdateien
  • Abhängigkeiten
  • Deinstallation

Die Komplexität wird durch Setup-Tools z.B. YaST bei SuSE-Linux versteckt. Wer sich näher mit seinem Linux-System beschäftigt, möchte aber auch mal Programme installieren, die nicht auf den Orginal-Medien mitgeliefert werden. Ab diesen Punkt kommt man bei den meisten Systemen nicht mehr am Redhat Paket Manager rpm vorbei.

Installieren

Beim Surfen entdeckt man häufig Tools, auf die man schon immer gewartet hat. Diese stehen oft als fertige RPM-Pakete zum Download bereit. Als Beispiel nehmen wir einfach die Datei supertool-1.2-4.rpm. Der Name setzt sich aus dem Namen des Pakets supertool, der Versionsnummer 1.2 und dem Releasestand, hier 4, zusammen. Auf nicht-Intel-Plattformen kommt zudem der Plattformname (alpha, ppc, ...) hinzu. In unserem Beispiel sähe dies dann etwa wie supertool-1.2-4.alpha. rpm oder supertool-1.2-4.ppc.rpm aus. Die Endung rpm ist sinnvoll, muß aber nicht sein. Wir können nun die Datei downloaden, oder falls das Paket auf einem FTP-Server liegt, direkt von dort installieren. Man muß als root angemeldet sein und je nachdem folgenden Befehl eingeben:

rpm -i supertool-1.2-4.rpm
rpm -i ftp://url.des.ftp-servers.de/pub/linux/rpms/supertool-1.2-4.rpm

Falls es keine Probleme mit den Installationsvoraussetzungen (Abhängigkeiten von Bibliotheken) gab und der FTP-Proxy mitspielt, kann man mit dem frisch installierten supertool arbeiten. Es werden die Dateien aus dem Paket auf die Festplatte kopiert und je nach Paket werden während der Installation auch Skripte ausgeführt. Dadurch können neue User angelegt oder neue Libraries über ldconfig aktiviert werden etc.

Parameter

Falls es Schwierigkeiten gab können die zahlreichen Parameter von rpm helfen:

-v oder -vv
Der verbose-Mode gibt weitere Informationen bei der Installation auf der Konsole aus.
-h oder --hash
Besonders bei großen Paketen kann dieser Fortschrittsanzeiger in Form eines Hashs "#" sinnvoll sein.
--test
Es wird nur getestet ob alle Voraussetzungen zur Installation gegeben sind. Das System wird nicht verändert.
--excludedocs
Die Dokumentation wird nicht mit installiert (falls man wenig Plattenplatz hat).
--ftproxy und --ftpport
nur für die Installation über FTP-Server notwendig.
--nodeps
Installiert das Packet obwohl z.B. notwendige Libraries fehlen (Sinnvoll falls Bibliotheken ohne rpm installiert wurden).
--noscripts
Installiert das Packet ohne Installationsskripts ablaufen zu lassen (nur für Profis!)
--replacepkgs
Das Paket wird nochmals installiert (falls man aus Versehen eine wichtige Datei gelöscht hat)
--root
Das Paket wird in ein anders Rootverzeichnis installiert (eventuell sinnvoll für Wechselplatten-Systeme).

Die Manualseite von rpm oder ein Aufruf von rpm ohne Paramter listet noch weitere Optionen auf, wahrscheinlich benötigt man aber nur die oben genannten Optionen.

Konfigurationsdateien

Dateien mit lokalen Einstellungen (INI- oder RC-Dateien) werden von rpm gesondert behandelt. Es kann z.B. passieren, das eine Konfigurationsdatei schon vor der Paket-Installation vorhanden war. rpm sichert in diesem Fall die ursprüngliche Fassung mit der Endung .rpmbackup. Clever oder?

Packete entfernen

Jeder Windows 95/98/NT/2000-Userkennt das Problem: Programme, selbst wenn sie mit einem Setup-Tool installiert wurden, hinterlassen Spuren auf der Platte und in der Registry. Mit rpm kann man fast immer alle Spuren von gelöschten Paketen vernichten. Falls unser supertool aus dem Beispiel oben, durch das megatool ersetzt werden soll, müssen wir als root einfach:

rpm -e supertool

eingeben. Alle nicht mehr benötigten Dateien werden von der Platte gelöscht, außer einige Konfigurationsdateien. Warum? Programm- und Dokumentationsfiles können durch eine Neuinstallation des Paketes wieder hergestellt werden. Bei der die Arbeit, die wir in die Konfiguration der Software gesteckt haben, sieht dies allerdings etwas anders aus. Daher werden Konfigurationsdateien die nach der Installation verändert wurden beim Löschen eines Pakets umbenannt. Diese Dateien erhalten die Endung .rpmsave. Ein cleverer Administrator sichert diese Dateien! Es lohnt sich, ich spreche aus (schmerzhafter) Erfahrung.

Manche Paket dürfen nicht gelöscht werden, weil sie notwendige Libraries oder Dateien für andere Pakete beinhalten. rpm warnt deshalb wenn eine Deinstallation eine "Dependency" (Abhängigkeit) zerstören würde. Die meisten o.g. Parameter gelten auch hier. Ein vorsichtiger Administrator prüft die Deinstallation mit dem Parameter --test , bevor er ein Produktionssystem aus Versehen lahmlegt. Nicht mehr benötigte Verzeichnisse werden auch gelöscht, nachdem alle Dateien aus dem Packet entfernt wurden. Für den Fall daß Anwender zusätzliche Dateien in die betroffenen Directories kopiert haben, gibt rpm eine Warnung aus und löscht die Verzeichnisse natürlich nicht.

Upgrade

Nicht nur der Linux-Kernel ändert sich in kurzen Intervallen. Viele populäre Anwendungen werden ständig weiterentwickelt. Wenn man dem Leitsatz "Never touch a runnning system" nicht treu bleiben kann, muß man ab und zu einige Pakete updaten. Das ist mit rpm kein Problem, vorausgesetzt, die Pakete sind sauber gebaut und enthalten keine distributionsabhägigen Anpassungen. Der folgende Befehl macht ein Update von der aktuellen Version auf die Version 2.0 Release 1 von unserem supertool:

rpm -U supertool-2.0-1.rpm

Ein Upgrade sieht auf dem ersten Blick so aus wie das Löschen der alten und das Einspielen der neuen Version. Etwas mehr steckt doch dahinter, insbesondere die Konfigurationsdateien werden von rpm gesondert behandelt. Wenn z.B. eine Konfigurationsdatei im Orginalzustand ist, kann mit gutem Gewissen die neue Version eingespielt werden. Falls Änderungen anhand einer MD5-Checksumme festgestellt wurden, wird die neue Version eingespielt und die aktive Version umbenannt. Zum Glück brauchen wir uns um nichts kümmern. Wer auf Nummer sicher gehen will, kann auch statt des Installationsmodus einfach immer den Updatemodus von rpm aufrufen. Nicht nur deswegen gelten alle oben genannten Option auch hier.

Alte Versionen

Falls die Version 2.0 von supertool nicht so fehlerfrei wie erhofft ist, können wir natürlich wieder eine alte Version einspielen, dazu muß man rpm über den Paramter --oldpackage mitteilen, das man es ernst meint.

Abfragen

Welche Pakete habe ich schon installiert? Woher stammt diese Datei? Wie lautet die Version von libxxx.so? Fragen über Fragen. rpm hat die Antwort! In einer internen Datenbank sind alle wichtigen Informationen über die installierten Pakete enthalten. Wir können auch Infos über noch nicht installierte Pakete abfragen, hier muß man den Parameter -p in Verbindung mit dem Filenamen angeben. Wir schauen uns nun ein paar Beispiele an:

Welche Informationen stehen im Paket xxx?

Mit dem Befehl

rpm -qi supertool

bei einem installierten Paket oder mit

rpm -qpi supertool-1.2-4.rpm

für eine Datei im Filesystem (oder auf einem FTP-Server) findet man die gewünschte information. Wer Mühe hat, sich die ganzen Optionen zu merken, lese den Befehl beim Eintippen in Gedanken laut vor (Query Package List = qpl, Query Package Info =qpi, Query Info, entsprechend für alle weiteren Befehle).

Output: rpm -qpi supertool-1.2-4.rpm

Name        : supertool              Distribution: superdist (i386)
Version     : 1.2                    Vendor: supertool GmbH
Release     : 4                      Build Date: Sam 01 Mai 1999 20:51:25 CEST
Install date: (not installed)        Build Host: localhost
Group       : Application/Graphics   Source RPM: supertool.src.rpm
Size        : 4711                   License: GPL
Packager    : feedback@localhost
Summary     : A super tool
Description :
Use it with foo to provide bar

Authors:
--------
    super programmer <superman@super.site.com>

Besonders die Angaben beim Punkt Description sind als Vorbereitung für eine Installation wichtig. Hier sollte die Funktion der Software beschrieben sein. Das Feld Group beinhaltet normalerweise die Kategorie zu der das Paket gehört, z.B. Development oder Application etc. Grafische rpm-Aufsätze (z.B. [3],[4]) nutzen diese Information als Mittel zur Stukturierung der Darstellung (siehe Abb. 1 und 2).


Abb. 1: Das graphische rpm-Tool gnoRPM im Einsatz

Welche Pakete sind installiert?

Der Befehl rpm -qa gibt eine Liste mit allen installierten Paketen aus. grep, nl, sort etc. können die Liste aufbereiten:

rpm -qa | grep gnome

Welche Dateien stammen aus dem Paket supertool?

Hier verwendet man die Option -l (list):

rpm -ql supertool

Bei unserem Beispiel könnte die Ausgabe wie folgt aussehen:

Output: rpm -ql supertool

/usr/sbin/supertool
/usr/doc/supertool-1.2/README
/etc/supertoolrcd

Der Parameter -v listet ebenfalls die Rechte der Dateien auf. Weil rpm zwischen "normalen", Konfigurations- und Dokumentationsdateien unterscheidet, kann man mit dem Parametern -c bzw. -d die speziellen Dateien herausfiltern. Dabei wird der Schalter -l implizit gesetzt, d.h. die Befehle

rpm -qdl supertool (Query Documentation List)
rpm -qcl supertool (Query Configuration List)

sind gleichbedeutend mit

rpm -qd supertool (Query Documentation)
rpm -qc supertool (Query Configuration)

Aus welchem Paket stammt die Datei /usr/sbin/xxx?

Hierzu dient der folgende Befehl:

rpm -qf /usr/sbin/xxx

Die Ausgabe kann ein Paketname oder die Meldung sein, daß diese Datei zu keinem Paket gehört.

Welche Skripte stehen in dem Paket?

Versuchen Sie doch einmal den Befehl zu erraten! Nein, leider ist es diesmal nicht rpm -qs supertool, sondern

rpm -q --scripts supertool

Die Option -s zeigt den Status der Dateien an (normal, nicht installiert, ersetzt).

Output: rpm -q --scripts supertool

preinstall
(none)
.
.
.

postinstall script (through /bin/sh):
touch /etc/suptertoolrc

Welche Version hat das Paket supertool?

rpm -q supertool

Die Rückmeldung ist irgend etwas in der Art von supertool-1.2-4. Der Name des Paketes supertool darf nicht abgekürzt oder mit falscher Groß/Kleinschreibung eingegeben werden. Ein Workaround ist:

rpm -qa | grep -i SuPeRt

Welche Voraussetzungen hat das Paket supertool?

rpm -q --requires supertool

Die Rückmeldung kann so aussehen:

libxxx.so.1
libyyy.so2

Damit supertool auf unserer Maschine laufen kann müssen wir also die oben genannten Dateien besorgen [1]. Es kann statt einer Liste mit Dateien auch ein Paketname erscheinen, das macht die Erfüllung der Voraussetzungen leichter.

Sonderfall

Eine besondere Art der Abfrage ist die Kontrolle von installierten Paketen.

rpm -V supertool

überprüft die Installation des Paketes supertool. Wenn keine Probleme gefunden wurden gibt es keine Rückmeldung. Sonst gibt es Informationen über versehentlich gelöschte Dateien oder nicht erfüllte Dependencies.

Tools

Nicht jeder möchte sich mit den Komandozeilen-Parametern von rpm beschäftigen. Es gibt eine große Zahl von Tools die den Umgang mit den Paketen erleichtern. Hier ist eine kleine Auswahl (siehe dazu auch die Abbildungen 1 und 2):

Midnight Commander
Dieser freie "Norton Commander"-Clone kann den Inhalt von rpm-Dateien darstellen ohne sie zu installieren. Er kann auch die Paket-Informationen (wie mit rpm -qi) darstellen ([2]).
kpackage
Ein grafischer Paketmanager mit KDE-Oberfläche ([3]).
GnoRPM
Die GNOME-Variante des rpm ([4]).
rpmfind
Ein Tool das die für Installation eines Paketes notwendigen Dateien sucht ([5]).


Abb. 2: Das graphische KDE-Werkzeug kpackage

Tricks

Mit dem Befehl

find / -name "*.rpmsave" -print

werden die Konfigurationsdateien die durch neue Pakete upgedatet werden aufgelistet. Konfigurationsdateien die beim Löschen eines Pakets übrig geblieben sind findet man mit

find / -name "*.rpmbackup" -print

Mit dieser kurzen Einführung haben wir die wichtigsten Optionen im Umgang mit rpm erläutert, die für das tägliche Arbeiten notwendig sind. In einer späteren Ausgabe werden wir zeigen, wie man selber rpm-Pakete baut.

Infos

[1] http://rpmfind.net/linux/RPM/
[2] http://mc.blackdown.org/mc/
[3] http://www.general.uwa.edu.au/u/toivo/kpackage/
[4] http://www.daa.com.au/~james/gnome
[5] http://rufus.w3.org/linux/rpm2html/rpmfind.html
[6] http://www.rpm.org

Der Autor

Ludger Berse ist ein alter ’67er (Baujahr). Nach seinem Zweitstudium fand er seinen aktuellen Brötchengeber (die Brötchen sind allerdings recht klein :-)), ein kommunales Rechenzentrum. Dort ist er der "König von ca. 4000 Usern". Zwischen den Kaffeepausen ist er für die NT- und Netware-Server zuständig. Nur in seiner Freizeit beschäftigt er sich mit etwas Vernünftigem: Linux.

Copyright © 1999 Linux-Magazin-Verlag