SelfLinux Systemverwaltung Software-Installation Abschnitt 2 | SelfLinux-0.13.0

| Software-Installation | Autoren Formatierung GFDL

#### 3 RPM

Das RPM-Format, das von RedHat für ihre Distribution entwickelt wurde, enthält zusammen mit einigen Verwaltungsdaten das compilierte Programm-Paket. Erkennbar sind RPM-Dateien an der Endung .rpm, wobei zusätzlich die Architektur (z. B. i386 oder alpha) im Namen der Datei enthalten ist. So kennzeichnet

kaffe-1.0.6-2.i386.rpm

das Kaffe-Paket für die Intel386-Architektur. Pakete, die nicht an eine bestimmte Architektur gebunden sind (z. B. manche Java-Pakete) erhalten die Endung .noarch.rpm. Handelt es sich um ein Paket in Source-Form, so wird dies durch .src.rpm gekennzeichnet.

Folgende Eigenschaften kennzeichnen das RPM-Format:

- Prüfung, ob die Voraussetzung für ein Paket vorhanden ist
- lokale Installation
- Installation per FTP möglich
- Deinstallation

Wer über FTP installieren will, kann als Paket-Name eine URL angeben, z. B.

user@linux ~$ rpm -ih ftp://ftp.redhat.com/pub/redhat/i386/RedHat/RPMS/kaffe-1.0.6-2.i386.rpm

Das Schöne an der Installation per FTP ist, dass die Abhängigkeiten vor der eigentlichen Installation überprüft werden, d. h. das restliche Paket wird erst heruntergeladen, wenn die Abhängigkeiten erfüllt sind. Dazu teilt sich der eigentliche Installations-Vorgang in drei Phasen auf:

1. das Pre-Install-Skript wird ausgeführt (falls vorhanden)
2. das eigentliche Archiv wird ausgepackt und in das Dateisystem kopiert
3. das Post-Install-Skript wird ausgeführt (falls vorhanden)

Ein ähnliches Schema wird bei der Deinstallation angewandt, auch hier gibt es häufig ein Pre-Uninstall- und Post-Uninstall-Skript.

Andere Distributoren, wie z. B. SuSE oder Mandrake, sind mittlerweile auch auf den RPM-Zug aufgesprungen, so dass dieses Format recht häufig im Internet anzutreffen ist. Allerdings kann man nicht einfach ein SuSE rpm unter Mandrake installieren oder umgekehrt, da die Pakete von den verschiedenen Distributoren teilweise unterschiedlich zusammengebaut werden.

Mit rpm kann man Pakete einzeln, aber auch mehrere auf einmal installieren, erneuern oder entfernen. Sind Pakete dabei, die voneinander abhängig sind, sortiert sie rpm in der richtigen Reihenfolge für die Installation. Dies bedeutet eine erhebliche Erleichterung für den Administrator, da er sich keine Gedanken darüber zu machen braucht, welche Pakete er zuerst installieren muss -- er gibt einfach alle in Frage kommenden Pakete an.

Kommando | Kurzbeschreibung
rpm -ih x.rpm | Installation; die Option -h (oder auch -vh) gibt zusätzlich noch einen Fortschrittsbalken aus
rpm -U x.rpm | Update; werden Konfigurationsdaten verändert, werden sie vorher unter der Endung .rpmsave gesichert. Alternativ wird die neue Version einer Konfigurationsdatei mit der Endung .rpmnew angelegt. Während des Updates macht der RedHat Package Manager auf diese Aktionen aufmerksam.
rpm -qa | Query -- Abfrage aller Pakete; ohne die Option -a kann man gezielt nach einem Paket nachfragen (z.B. rpm -q fileutils) Hilfreich ist auch die Option -f, mit der man abfragen kann, zu welchem Paket eine Datei (z. B. /bin/ls) gehört.
rpm -e x.rpm | Erase -- zum Deinstallieren eines Paketes
rmp -V x | Verify -- ist das Paket noch ordnungsgemäß installiert oder hat da etwa jemand dran manipuliert?

Die Manual-Page von rpm ist recht umfangreich, entsprechend dem Umfang dieses Kommandos. In der Tabelle sind deswegen nur die wichtigsten Befehle aufgelistet, um einen schnellen Einstieg zu ermöglichen. Tiefergehende Information sind über man rpm abrufbar. Eine sehr ausführliche Beschreibung der Möglichkeiten von rpm findet sich unter http://www.rpm.org/max-rpm/.

#### 3.1 Kompilieren von Source-RPMs

Hat man ein Paket nur in Source-Form vorliegen (xxx.src.rpm), ist die Option --rebuild ganz hilfreich. Sie sorgt dafür, dass das Paket nach dem Auspacken auch gleich kompiliert wird. Während hierfür bei RPM-Versionen bis 4.0.X auch der Befehl rpm zuständig ist, gibt es seit der Version 4.1 den Befehl rpmbuild.

Das Kompilieren eines Source-RPMs auf dem eigenen Rechner hat auch den Vorteil, dass die Programme auf jeden Fall zu den installierten Bibliotheken passen.

Generell ist es empfehlenswert, diesen Kompilationsvorgang nicht als Benutzer root durchzuführen. Um als normaler Benutzer einen rebuild durchzuführen, muß als erstes eine Datei .rpmmacros im Homeverzeichnis angelegt werden:

user@linux ~$ cat ~/.rpmmacros %_topdir /tmp/mirko-redhat user@linux ~$

Nun müssen noch einige Verzeichnisse angelegt werden:

user@linux ~$ mkdir /tmp/mirko-redhat
user@linux ~$ mkdir /tmp/mirko-redhat/SPECS
user@linux ~$ mkdir /tmp/mirko-redhat/BUILD
user@linux ~$ mkdir /tmp/mirko-redhat/SOURCES
user@linux ~$ mkdir /tmp/mirko-redhat/RPMS
user@linux ~$ mkdir /tmp/mirko-redhat/RPMS/i386
user@linux ~$ mkdir /tmp/mirko-redhat/RPMS/i686
user@linux ~$ mkdir /tmp/mirko-redhat/RPMS/noarch
user@linux ~$ mkdir /tmp/mirko-redhat/SRPMS

oder in einem Einzeiler:

user@linux ~$ mkdir -p /tmp/mirko-redhat/{RPMS/i386,RPMS/noarch,BUILD,SOURCES,SPECS,SRPMS}

Jetzt kann man ein vorhandenes Source-RPM einfach wie folgt kompilieren:

user@linux ~$ rpm --rebuild mod_auth_pam-1.0a-1.src.rpm

oder aber bei RPM-Versionen ab 4.1:

user@linux ~$ rpmbuild --rebuild mod_auth_pam-1.0a-1.src.rpm

Nach Ausführen des Befehls wird der Kompilationsvorgang durchgeführt:

- Die unter SOURCES abgelegten Quellen werden unterhalb von BUILD ausgepackt.
- Eventuell vorhandene Patches (Quelltext-Änderungen, die der Fehlerkorrektur oder dem Anpassen an das System dienen) verändern den Quelltext.
- Dann wird meistens automatisch der unter Die klassische Installation beschriebene Ablauf aus ./configure, make, make install ausgeführt. Allerdings werden die Dateien hierbei temporär unter /var/tmp/PAKET-root installiert, da man als normaler Benutzer ja keine Zugriffsrechte auf die Standardverzeichnisse /usr, /etc usw. hat.
- Nun werden noch automatisch eventuell auftretende Abhängigkeiten aufgelöst.
- Die dem Programm zugehörigen Dateien werden komprimiert und in einem RPM zusammengefasst.

Am Ende findet sich dann unter RPMS/i386 das fertige RPM-Paket, welches man dann als root installieren kann.

#### 3.2 Anfragen der RPM-Datenbank

Neben den eigentlichen Programm- oder Source-Dateien, die gepackt vorliegen, enthalten RPM-Dateien zusätzliche Informationen, welche bei der Installation in einer Datenbank gespeichert werden. So umfasst ein RPM zusätzlich eine kurze Beschreibung des Programmes, den Installationszeitpunkt, die Zeit zu dem es kompiliert wurde, eine Auflistung aller dem Programm zugehörigen Dateien nebst Informationen über die Größe dieser Dateien und einen MD5-Hash, durch den sich nachträglich überprüfen lässt, ob die Dateien geändert wurden.

Auch sind in einem RPM die Abhängigkeiten von anderen Bibliotheken abgespeichert, so dass das Aufspielen einer neuen, inkompatiblen Bibliotheksversion durch den RedHat Package Manager verhindert wird. Außerdem lassen sich in einer RPM-Datei Skripte unterbringen, die vor bzw. nach der Installation bzw. Deinstallation eines Programmes automatisch ausgeführt werden. Diese können dann z.B. einen Dienst automatisch als zu startendes Programm eintragen oder einen neuen Benutzer hinzufügen (bei Datenbanken, Web- und Mailservern gebräuchlich) bzw. diese Aktionen bei der Deinstallation rückgängig machen.

Die in der Datenbank während der Installation eingetragenen Informationen lassen sich jederzeit abfragen (s. Tabelle)

Option/Argument | Bedeutung | Beispiel
--- | --- | ---
-q query = Abfrage, | ob ein Paket installiert ist | rpm -q fileutils
-qa | Anzeige aller installierten Pakete
-qf Dateiname | zu welchem Paket gehört die Datei? | rpm -qf /bin/ls => fileutils-4.1-4
-ql Paketname | listet alle zum Paket gehörenden Dateien | rpm -ql fileutils oder rpm -qlf /bin/ls
-qi Paketname | Infos zur Version, Inhaltsangabe, Installationsdatum, etc. | rpm -qi fileutils
-qd Paketname | zeigt nur die zum Paket gehörenden Dokumentationsdateien an | rpm -qd xinetd
-qc Paketname | zum Paket gehörende Konfigurationsdateien | rpm -qc xinetd
-q --changelog Paketname | Anzeigen des RPM-ChangeLog, dieses muss nicht gleichbedeutend mit dem der Software sein, da die Distributoren die Sourcen oft noch patchen. | rpm -q --changelog openssl

Viele dieser Abfrageoptionen lassen sich auch auf noch nicht installierte RPM-Pakete anwenden, hierzu dient die Option -p:

user@linux ~$ rpm -qip /mnt/cdrom/RedHat/RPMS/pinfo-0.5-1.i386.rpm

#### 3.3 Graphische RPM-Frontends

gnorpm, kpackage und xrpm

Wer mit der Kommandozeile des rpm-Kommandos auf Kriegsfuß steht oder Probleme hat, sich die wichtigsten Optionen zu behalten, hat die Auswahl zwischen mehreren graphischen Frontends, die aber nicht alle Optionen von rpm abdecken.

kpackage ist bei KDE dabei und unterstützt Drag & Drop, d. h. man kann ein heruntergeladenes Paket aus dem Datei-Manager heraus in kpackage hineinschieben und fallen lassen. Es versteht auch das Debian-Paketformat, das an der Endung .deb erkennbar ist.

GnoRPM ist für Freunde des Gnome-Desktops.

xrpm ist ein in Python geschriebenes Frontend, das einfach zu bedienen ist und alle wichtigen Funktionen enthält.

mc -- der Midnight Commander ist zwar kein graphisches RPM-Frontend, kann aber RPM-Archive lesen und anzeigen