Georg's Homepage

Das Paketmanagement RPM

commandline


RPM.gif

Einleitung

Zur Einführung etwas Geschichte über das Red Hat Paketmanagement

Das erste von RedHat gebildete Paketmanagement war RPP, jedoch gab es sogenannte "wilde RedHat" - Distributionen die das Paketmanagement PMS verwendeten. Beide Paketmanager wurden zur gleichen Zeit entwickelt. Was konnten diese Paketmanager

RPP (RedHat Release 1 - 1.1)
PMS

Später wurde das Paketmanagment PM von den entwiklern von RPP und PMS unter RedHat erstellt.
Welches die Vorteile beider Paketmanagment-Systeme unter einen Hut bringen sollte.

RPM

Der Red Hat Paketmanager RPM wurde 1995 mit der 2.0er Distribution von RedHat das erste mal veröffentlicht.
Das RedHat Paketmanagement-System der ersten Version hatte schon viele Vorteile die wir heute kennen.
RPM Version 1 ( Redhat 2.0 - ?3.0.3 ) (Erschien 1995)

+ Automatische Behandlung der Konfigurationsakten
+ Einfach, viele Pakete umzubauen
- Langsam und groszlig; (war in Perl geschrieben)
- Kaum Unterstützung für mehrere Architekturen
- Paketaktformat war nicht ausdehnbar

Schon wesentlich Verbessert war das 2er Release von RPM

RPM Version 2 (Red Hat ?4.0 - 5.2 )

+ Viel schneller, da es in C neu geschrieben war (und benötigte daher kein Perl)
+ Neue verbesserte Geschwindigkeit und Zuverlässigkeit des Datenbankentwurfs
+ rpmlib
+ Bessere Unterstützung für mehrere Architekturen
+ Ausdehnbares Paketaktformat

RPM Version 3 (Red Hat 6.0 - 6.2)

+ Verbesserte Datenbank
+ Automake

RPM Version 4 (Red Hat 7.0 - * )

+ neues Datenbankformat (schneller)
- rpmBuild (ist jetzt ein eigenstängiges Paket)
+ Athlon (wurde zuerst als intel-Kompatibler Prozessor behandelt) und 64-Bit Unterstützung
+ Multilinguale Ausgaben

Die derzeit aktuelle stabile Version ist RPM 4.0.4 (4.1)
Während der Erstellung dieses Dokumentes wurde RedHat 8.0 mit rpm 4.1-1 ausgeliefert welches einige Veränderungen mit sich brachte

Wozu dient RPM

RPM ist ein Paket-Management-System. Im speziellen Fall von RPM dient es dazu Pakete zu installieren,
deinstallieren, upgraden, downgraden, überprüfen, das Abfragen der Paketinformationen und sogar zum
erstellen von Paketen.

Was ist RPM

Dieses Paketmanagement ist Open Source und unter GPL (Dies muss ich leider einbringen,
da viele glauben, dass RPM nicht Open-Source ist). Den Quellcode von dem RPM erhält man auf
diversen Ftp- Servern von RedHat, RPM, oder dessen Mirrors.
Wenn man ein neues Linux-System aufbaut den Quellcode als Tarball
(kompriemiertes und verpacktes Verzeichniss) downzuloaden. Jedoch werden die wenigsten von uns
damit in Berührung kommen.

Im Normalfall reicht es, das vorhandene RPM upzugraden, in speziellen Fällen ist es nötig
den das Paket neu einzukompilieren, das jedoch auch mit einem *.src.rpm möglich ist.
(siehe Abschnit *.src.rpm)
Das RedHat Paket Management, ist eines der ältesten Paketmanagement-Systeme auf der Linux Plattform.
Heute gibt es mehrere Paketmanagmet-Programme die ein komfortables Arbeiten beim Installations-,
Deinstallations-, Upgrade- und Verifizierungsprozess unter Linux ermöglichen.
Das wohl Bekannteste von den anderen Paket-Management Systemen ist das Debian-Paketmanagement,
welches sehr hoch geschätzt wird.
Im Grossen und Ganzen werden drei Paketsysteme von den grossen Distributoren verwendet.
(Es gibt natürlich mehr)

Beispiele für RPM-basierende Systeme sind:
Beispiele für Deb-basiernde Systeme
Beispiele für Source-Bezogene Distributionen
Es gibt so eine Vielzahl von Distributionen, dass es mir nicht möglich ist jede aufzuzählen.

Warum commandline RPM

Wie unter sehr vielen Linuxprogrammen gilt es hier auch, dass das Programm auf der Commandline
noch stärker ist, als die grafische Software.
Aber dies allein ist nicht der einzige Vorteil eines nicht grafischen Installationssystems,
sondern auch die Fähigkeit es auf Servern ohne grafische Oberfläche einzusetzten.
Sicherlich sind installatinsprogramme wie z.B.: gnoRPM, kpackage und wie sie alle heissen
auf der grafischen Oberfläche relativ leicht zu bedienen, jedoch bieten sie nicht alle Features
des Commandline-RPM's.

Arbeiten mit RPM auf der Commandline

Wenn man ein neues Paket installieren will, möchte man natürlich zuvor wissen ob es in Ordnung ist,
(denn ein download kann auch mal fehlschlagen) und eventuell was der Inhalt des Paketes ist.

z.Bsp.:
Wenn man ein Linux-Neuling bin kann man sich unter Namen wie samba, (Was eher nach einem Tanz klingt
und nicht nach Service Message Block (SMB wie es unter NT heisst))
oder XFree (könnte eXtreme Free heissen) nicht viel vorstellen , deßhalb möchte man ja wissen was
diese Software beinhaltet. Eine Kurzbeschreibung der Software tut Gutes daran.

Prüfen der MD5 sum

Die MD5-SUM ist eine Prüfsumme die mit dem Inhalt übereinsimmen muss, ansonsten ist die Datei beschädigt.
Das RPM erlaubt es ein Paket mittels md5 sum zu prüfen.

[user@myhost RPM]$ rpm -K paketname-x.y.z.rpm
paketname-x.y.z.rpm: md5 GPG NOT OK
[user@myhost RPM]$/
bei rpm 4.1

[user@myhost RPM]$ rpm -K paketname-x.y.z.rpm
paketname-x.y.z.rpm: md5 OK
[user@myhost RPM]$/
rpm -k paketname.rpm

Hier tritt bei rpm 4.0.* meist eine Fehlermeldung auf die aber des weiteren nicht tragisch ist,
denn die Version 4.0.* beinhaltet auch eine GPG-Abfrage, die aber nicht alle Pakete beinhalten.
um doch das Paket zu prüfen und keine Fehlermeldung zu erhalten schalten wir einfach die GPG - Abfrage ab.

aktuelle RedHat Pakete beinhalten dieses Feature jedoch habe ich mich selbst im Augenblick damit nicht
beschäftigt eine Beschreibung dieses Feature zu verwenden befindet sich auf div. RedHat Seiten

[user@myhost RPM]$ rpm -K --nogpg paketname-x.y.z.rpm
paketname-x.y.z.rpm: md5  OK
[user@myhost RPM]$ 
Diese Funktion ist in 4.1 nicht enthalten, jedoch gibt rpm 4.1 eine Ausgabe für den Key und für die md5 sum extra
rpm -k --nogpg paketname.rpm

Hier gibt es auch die Möglichkeit mehrere Pakete unter einmal zu Prüfen der auch dafür Wildcards1 zu verwenden.

1Wildcards sind Zeichen die es ermöglichen unvollständige Dateinamen zu verwenden. Das gebräuchlichtste ist der Joker
der mit einem Mal-Zeichen (*) definiert wird und die Dateinamen Automatich vervollständigt.

[root@myhost RPM]# rpm -K --nogpg paketname1-x.y.z.rpm paketname2-x.y.z.rpm

rpm -k --nogpg paketname1.rpm paketname2.rpm ...

oder auch
[root@myhost RPM]# rpm -K --nogpg *.rpm

rpm -k --nogpg *.rpm ...

Ich selbst bevorzuge es neue Pakete in ein gesondertes Verzeichniss zu kopieren und dort zu Prüfen und das
Prüfergebniss in eine Datei zu Schreiben.

rpm -k --nogpg *.rpm > testdatei

rpm -k --nogpg *.rpm > testdatei + cat testdatei

Im Fehlerfall:
Fehler: Paketname.rpm rpmReadSignature fehlgeschlagen

paketname.rpm: MD5 NOT OK
Ich persönlich würde diese Pakete nicht installieren.

Abfragen des Paketinhaltes

Manchmal möchte man wissen was das Paket beinhaltet sei es eine Kurzbeschreibung oder welche Dateien
auf den Datenträger auf dem installiert bzw. kopiert werden.
Kurzbeschreibung:
[user@myhost RPM]$ rpm -qpi paketname-x.y.z.rpm

rpm -qip paketname.rpm

Dateien
[user@myhost RPM]$ rpm -qpl paketname-x.y.z.rpm

rpm -qlp paketname.rpm

natürlich kann man diese kombiniert verwenden
[user@myhost RPM]$ rpm -qpli paketname-x.y.z.rpm
oder nur Abfragen welche Dokumentation beinhaltet ist
[user@myhost RPM]$ rpm -qpld paketname-x.y.z.rpm

Abhängikeitsprüfung:

was wird benötigt
[user@myhost RPM]$ rpm -qp --requires paketname-x.y.z.rpm

rpm -qp --requires paketname.rpm

was steht in Konflikt
[user@myhost RPM]$ rpm -qp --conflicts paketname-x.y.z.rpm

rpm -qp --conflicts paketname.rpm

Hier in diesem Beipiel wird ausgesagt, dass das Paket ash-0.2-18 mit einer mkinitrd-Version die
kleiner od. gleich 1.7 im Konflikt steht. Wenn keine Zahl hier angegeben wird, steht das Paket im generellen
Konflikt und kann daher nicht ordnungsgemäs instaliert werden.

Im speziellen für RedHat gibt es noch die Optionen
redhatrequires, redhatconflicts
Da ich zur Zeit keine andere rpm-basierende Distribution habe kannich nicht sagen,
ob es zum Beispiel die Option SuSErequires oder mdkrequires oder so gibt
(es wäre möglich)

Installieren von neuen Paketen

Was geschieht beim Installationsprozess
Wenn ein neues Paket installiert wird, wird das Binärpaket entpackt und auf den jeweiligen Datenträger gerschrieben

Paketprüfung

Die meisten Pakete beinhalten jedoch mehr als "nur" das Programm, wie zum Beispiel Konfigurationsscripte,
eine Einbindung in das Startscript des Systems, Dokumentation zum Paket und vieles mehr.
Wie dieses Beispiel zeigt wird ein Starscript (/etc/rc.d/init.d/winbind) und weitere Konfiguratoinsdateien
im Verzeichniss /etc abgelegt ein paar Bibliotheken im Verzeichniss /lib Binärdateien (Executables)
im Verzeichniss /usr/bin/ , Dokumentation in /usr/share/man und hier in diesem Beispiel werden auch noch
Zeichensätze nach /usr/share/codepages kopiert.
Nach dem Kopieren der Daten läuft meist ein Script ab, sodass manche Dienste automatisch gestartet werden.
(in diesem Fall wäre es /sbin/ldconfig und /etc/rc.d/init.d/winbind start das in dem script ablaufen würde).
Es ist zwar in diesem Aufruf lt. Bild nicht ersichtlich, jedoch wäre es logisch (im speziellen Fall wird es auch gemacht)
Die Installation selbst
Die normale Installation von neuen Paketen gestaltet sich recht einfach. Normalerweise reicht die Option -i aus.
Jedoch möchten viele die Meldungen sehen die während des Installationsprozesses auftreten,
oder eine Forschrittssanzeige oder beides.
Um ein paar Meldungen zu sehen langt die zusätzliche Option -v, um es detailierter zu sehen -vv.
Bei der Fortschrittsanzeige kann man wählen ob man Hash-Symbole (#) oder eine Prozentanzeige will
für die Hash Symbole -h für die Prozentanzeige --percent

also würde der Standardfall so aussehen

[root@myhost RPM]# rpm -ivh paketname-x.y.z.rpm

rpm -ivh paketname.rpm

oder so
[root@myhost RPM]# rpm -ivv --percent paketname-x.y.z.rpm

hier würde das Bild zu groß werden, desshalb habe ich darauf verzichtet

Natürlich kann es notwendig sein mehrere Pakete gleichzeitig installieren. Bei der Installationsfunktion
sind wiederum auch Wildcards oder Paketansammlungen erlaubt
[root@myhost RPM]# rpm -ivh paketname_nichtvollstaendig*.rpm

rpm -ivh paketname_nichtvollständig*.rpm

oder auch
[root@myhost RPM]# rpm -ivh paketname1-x.y.z.rpm paketname2-x.y.z.rpm

rpm -ivh paketname1-x.y.z.rpm   paketname2-x.y.z.rpm ...

Das Upgraden von Paketen

Hier gibt es zwei Versionen des Upgradens, die eine Option nennt sich Freshen die andere Upgrade.
Der Unterschied dieser Funktionen liegt darin dass Freshen (Option -F) voraussetzt,
daß ein Vorgängerpaket installiert ist, das man Upgraden kann.
Ist dies nicht der Fall so wird das Paket auch nicht installiert.
Bei Upgrade (-U) wird dieses Paket installiert solange kein gleich altes oder neueres Paket vorhanden ist.
Die erweiterten Funktionen sind fast gleich wie bei install (-i). auch hier sind wieder Wildcards und eine
Paketansammlung erlaubt.
[root@myhost RPM]# rpm -Fvh paketname1-x.y.z.rpm paketname2-x.y.z.rpm

rpm -Fvh paketname1-x.y.z.rpm   paketname2-x.y.z.rpm ...

Zum Besispiel sind hier fehlgeschlagene Abhängikeiten. Es wurde nur das Updaten von
samba, samba-client und samba-common versucht, da die Pakete libacl und libattr zuvor gar
nicht installiert waren.

rpm -Uvh paketname1-x.y.z.rpm   paketname2-x.y.z.rpm ...

Das Löschen von Paketen

Das Löschen von Paketen ist sehr simpel
[root@myhost RPM]# rpm -e paketname
Man beachte hier nur es gibt keine (negative)Fortschritsanzeige keine Versionsnummer und
das Suffix rpm wird hier auch nicht geschrieben.
Hier sind Wildcards nicht erlaubt jedoch Paketansammlungen

Das Downgraden von Paketen

Manchmal ist es notwendig ein Paket downzugraden, da man irgendwo her eine Software hat die nur
mit dem älteren Paketen zusammenarbeitet, man jedoch diese Software für die Produktivität benötigt
.
Downgraden:
[root@myhost RPM]# rpm -Uvh --oldpackage paketname1-x.y.z.rpm

rpm -Uvh --oldpackage paketname-x.y.z.rpm

Paketansammlungen u. Wildcards erlaubt auch hier gilt es sehr vorsichtig mit Wildcards umzugehen

Die rpm - Datenbank

Als rpm 4.0 herauskam gab es ein paar Probleme. Manche schimpften sogar dass rpm nicht
rückwärts-kompatibel war, was jedoch nicht der Wahrheit entsprach.
Leider wurde nach dem Upgrade auf 4.0 nur noch die neue Version der rpm-Datenbank ausgelesen,
waren es ältere Pakete so bekam man die Meldung dass dieses Pake inkompatibel mit dem neuen
rpm sei.
Abhilfe schaffte jedoch eine einfache rpm-Option.
rpm -rebuilddb
Das rpm veranlasste die Datenbank neu einzulesen, dannach fuktionierte es bei mir und auch bei
vielen anderen wieder einwandfrei. Die rpm-Datenbank dient vorallem dazu dem Paketmanagement
zu sagen welche Pakete inklusiver Versionsnummern installiert sind. Dies ist notwendig um eine
saubere Installation gewährleisten zu können.
Aber diese rpm-Datenbank kann noch wesentlich mehr.

Abfrage durch den Benutzer ob ein Paket installiert ist
[user@myhost RPM]$ rpm -q paketname

rpm -q paketname

Hier wird wenn das Paket installiert ist Paketname und Versionsnummer ausgegeben

Abfrage welche Dateien hier installiert wurden
[user@myhost RPM]$ rpm -ql paketname

rpm -ql paketname

Abfrage welche Pakete von diesem Paket abhängig sind
[user@myhost RPM]$ rpm -q --whatrequires paketname

rpm -q --whatrequires paketname

Abfrage zu welchen Paket gehört eine Datei:
[user@myhost RPM]$ rpm -qf  Dateiname
rpm -qf paketname

Es gibt noch mehrere Datenbankfunktionen die ich hier nicht erlätern will da Sie in den Hilfe-,
Manual- und HOWTO-Seiten beschrieben sind.

Das Handhaben von *.src.rpm

Diese *.src.rpm sind die Source-Pakete und werden ein wenig anders gehandhabt wie die normalen
*.i386.rpm *.i686.rpm *.sparc.rpm usw..(also *.arch.rpm oder auch *.noarch.rpm).
In *.src.rpm Paketen sind nicht nur der Quellcode sondern auch die Installationshinweise enthalten.
Das *.spec File im *.src.rpm enthält die Anweisungen wie und wo ein Paket installiert wird und von
welchen Paketen dieses Paket abhängig ist, welches Paket damit im Konflikt steht und mehr.
Somit ist es möglich auch ein *.src.rpm Paket direkt zu installieren
 [root@myhost RPM]# rpm --rebuild  paketname.src.rpm
bei rpm 4.1 übernimmt das das rpmbuild Paket
[root@myhost RPM]# rpmbuild --rebuild  paketname.src.rpm
Hier wird das Paket entpakt und installiert
Wenn man es auf einen tarball mit Source vergleicht

z.Bsp:

cd $installdirectoy
tar -xzvf filename.tgz
rm filename.tgz
./configure
make
make install
make clean
rm $sourcedirectory

Nur muss nicht jede Software compiliert werden, es könnte auch ein Script sein
Wie komme ich zur Source
Der einfachste Weg ist einfach mit rpm -i

Jedoch bei einem Source-paket gibt es die optionen -v -h --percent nicht, auch mit
rpm -q kann man nicht abfragen ob ein *.src.rpm installiert ist.

giltet natürlich nicht für erzeugte Pakete (--rebuild)

Die meisten Distributionen nehmen einen Default-Pfad um dort die *.src.rpm's zu kopieren
und entpacken. Dieser ist meist /usr/src/$Distribution/

In diesem Verzeichniss sind weitere Unterverzeichnisse anzufinden.

RPM
SRPMS
SOURCES
BUILD
SPECS

Das gezippte File, in welchem der Quellcode enthalten ist wird in SOURCES gespeichert.
Das *.spec File welches zum installieren oder erstellen von binär-Paketen2 notwendig ist
wird im Verzeichniss SPECS abgelegt.
Ist rpm-build installiert kann aus einem *.src.rpm ein *.arch.rpm gemacht werden
zu dem aber im Kapitel erstellen von RPM's.

2 binär-Pakete sind Pakete, in welchen das Programm und die Installationsanweisungen enthalten sind, aber kein Quellcode

Erstellen von RPM-Paketen

Da dies eher eine Spezialisten-Funktion ist werde ich dieses Thema nur streifen, denn wer ein rpm-Paket für
andere zur Verfügung stellt sollte mit den RPM-Funktionen sehr Vertraut sein, sodass saubere Pakete entstehen.
Aber für sich selbst ist es ok wenn man ein *.rpm Paket erstellt das vielleicht nicht so sauber ist,
oder aus einem *.src.rpm ein *.arch.rpm macht.
Um ein *.arch.rpm und auch eine *.src.rpm(sofern nicht schon vorhanden) zu erstellen, benötigt man ein
*.spec File indem die Installations-Informationen und eine Quellcode Datei die entweder *.gz od *.bz2
gezippt ist.
[root@myhost RPM]# rpm -ba paketname.spec
rpm 4.1 (rpmbuild)
[root@myhost RPM]# rpmbuild -ba paketname.spec
Es ist nicht notwendig hier die Release (Revisonsnummer) anzugeben, dies wird aber in der *.spec File getan.

Sonderfunktionen von rpm

Es gibt ein paar Sonderfunktionen von rpm, die jedoch nur erfahrene Benützer verwenden sollen
--force(Mit Gewalt)
--nodeps (ohne Abhängikeitsprüfung)
--excludedocs(installiere keine Dokumentation)
--ignorearch(ignoriere Architektur)
--ignoreos(ignoriere Operating System)rpm wird auch auf anderen OS's verwendet
--ignoresize(prüfe nicht den Verfügbaren Fesplattenplatz)
.......

Programme die das Handhaben von RPM-Paketen erleichtern

Es gibt ein paar Programme die das Handhaben von RPM-Paketen erleichtern.
..... und noch ein paar mehr

Hilfreiche Links im Internet

http://www.rpm.org/
http://www.rpmfind.net/
http://www.linux-mandrake.com/en/doc/82/de/user.html/softwaremanager.html
http://rikers.org/rpmbook/
http://rpm.redhat.com/RPM-HOWTO/
http://www.redhat.com/docs/manuals/linux/RHL-7-Manual/ref-guide/ch-rpm.html
http://sdb.suse.de/de/sdb/html/ke_rpm.html

Danke für die Mitarbeit

Im besonderen möchte ich Florian Senn für die Durchsicht dieses Dokumentes bedanken,
Des weiteren meinem Bruder Richard, meiner Lebensgefährtin Angelika.
And last not least Andreas Eckhart, der mich ja ermuntert hat diese Dokumentation bei
einem LUGT Treffen vorzutragen.

Quellen

siehe Abschnitt Hilfreiche Links im Internet, und eigene Erfahrung
--
Der Verfasser
Georg Schneider

PS Version des Dokumentes
PDF Version des Dokumentes
OpenOffice(writer) Version des Dokumentes
RPM

Valid XHTML 1.0! Valid CSS 2.0!