Softwarepakete mit rpm

Transkript

1 5 Softwarepakete mit rpm Inhalt 5.1 rpm und RPM-Pakete Das RPM-Paket Voraussetzungen zum Bau eines RPM-Pakets Die spec-datei Erstellen des RPM-Pakets Die Buildroot-Direktive Paketabhängigkeiten Hinzufügen von Signaturen Einfaches Erstellen von Paketen mit checkinstall Lernziele Die Funktionsweise von rpm und den Aufbau von RPM-Paketen verstehen Neue RPM-Pakete für im Quellcode vorliegende Software erzeugen können Abhängigkeiten für Pakete verstehen und definieren können RPM-Pakete mit GnuPG signieren können Spezialwerkzeuge wie alien oder checkinstall kennen Vorkenntnisse Erfahrung mit Linux-Systemadministration Kenntnisse über Softwareinstallation unter Linux (Kapitel 4) syap-rpm.tex (60748ba32487f646)

2 82 5 Softwarepakete mit rpm 5.1 rpm und RPM-Pakete Konfiguration Warum eigene RPM-Pakete? Viele Linux-Distributionen verwenden den RPM Package Manager (RPM) [Bai97] als Werkzeug zur Verwaltung von Software-Paketen. Das Programm rpm ermöglicht auf einfache Weise Installation (Option -i), Update (Option -U bzw. Option -F) und Deinstallation (Option -e) von Software, wobei dafür gesorgt wird, dass sich unterschiedliche Pakete nicht in die Quere kommen bzw. dass Abhängigkeiten zwischen den Paketen berücksichtigt werden. Außerdem erlaubt es RPM Ihnen, weitgehende Anfragen an Pakete zu formulieren (Option -q) sowie die Integrität von Paketen sicherzustellen (Option -K). Der Kern von RPM ist eine Datenbank. Bei ihr melden sich Software-Pakete beim Installieren und Deinstallieren an bzw. ab. Dazu müssen die Software-Pakete in einer standardisierten Form vorliegen, eben RPM-Pakete. Die Datenbank finden Sie, je nach RPM-Version in unterschiedlichen Datenbankformaten, im Verzeichnis /var/lib/rpm/. Die Konfiguration von RPM befindet sich im Verzeichnis /usr/lib/rpm/; lokale oder individuelle Anpassungen erfolgen in /etc/rpmrc bzw. ~/.rpmrc, dürften aber für den Normalbetrieb nicht notwendig sein. Installation und Deinstallation von RPM-Paketen sowie die Abfrage diverser Metadaten aus Paketen und Datenbank werden ausführlich in der Linup-Front- Kursunterlage»Linux-Systemadministration I«besprochen. Der folgende Abschnitt beschränkt sich auf die Informationen, die notwendig sind, eigene RPM- Pakete aus Software-Quellcode zu bauen. An dieser Stelle stellt sich die berechtigte Frage nach dem»warum«. Entweder es existiert ein passendes RPM-Paket oder Sie installieren aus dem Quellcode. Warum also der Umweg über ein eigenes RPM-Paket? Dafür kann es verschiedene Gründe geben: Der regelmäßige Update von Software, insbesondere in einem Netzwerk, ist mit RPM viel einfacher als mit Quellen. Bei einem Update werden veränderte Konfigurationsdateien nicht einfach gelöscht, sondern mit der Endung.rpmold abgespeichert. Die installierten Dateien können dank der RPM-Datenbank besser verwaltet und vor allen Dingen deinstalliert werden. Es ist sehr einfach, Veränderungen an installierten Dateien zu erkennen (rpm -V). Nicht zuletzt: Die Vorteile einer Paketverwaltung lassen sich dauerhaft nur nutzen, wenn man sie konsequent verwendet, d.h. man installiert nur RPM- Pakete. Im den folgenden Abschnitten erfahren Sie alle Einzelheiten, die Sie zu einem erfolgreichen RPM-Bauherrn machen. In [RPM-HOWTO] und der Anleitung Maximum RPM von Ed Bailey [Bai97] finden Sie weiterführende Informationen. 5.2 Das RPM-Paket Paketnamen Ein RPM-Paket hat einen zusammengesetzten Paketnamen (engl. label), beispielsweise $ rpm -q openssh openssh-3.7.1p2-1 Dateiname Der Paketname dient zur internen Identifizierung des Pakets, wenn es installiert ist. Er setzt sich zusammen aus dem Namen der Software (openssh), der Version der Software, so wie die Entwickler sie ihr gegeben haben (3.7.1p2), gefolgt von einer Release-Nummer (1), die ihr der Paket-Bauer, d. h. meist der Distributor gegeben hat. Der Name der Paket-Datei, zum Beispiel

3 5.3 Voraussetzungen zum Bau eines RPM-Pakets 83 openssh-3.7.1p2-1.i586.rpm enthält in der Regel zusätzlich zum Paketnamen die Architektur (i586) und die Endung.rpm, kann aber natürlich auch ganz anders lauten. Der Inhalt eines RPM-Pakets besteht über die eigentlichen Bestandteile des be- Inhalt eines RPM-Pakets treffenden Softwarepakets hinaus üblicherweise aus folgenden Komponenten: Paketbezogene Daten enthalten den Namen des Pakets, das Datum der Erstellung, eine Kurzbeschreibung, den Namen der Lizenz, die Bezeichnung der Paketgruppe, der das Paket zugeordnet werden soll, Abhängigkeiten, eine MD5-Prüfsumme und eine PGP-Signatur zur Integritätsprüfung. Dateibezogene Daten für jede im Paket enthaltene Datei. Dazu gehören Name und Pfad zur Installation, Rechte, GID, UID, Abhängigkeiten, eine MD5- Prüfsumme und nicht zuletzt der Inhalt der Datei. Installationsskripte, die bei der Installation oder Deinstallation des Pakets zusätzlich ausgeführt werden sollen. Bei den Dateien eines RPM-Pakets handelt es sich in erster Linie um die ausführbaren Dateien, aber ebenso beispielsweise um Verzeichnisse, Konfigurationsdateien und Dokumentationsdateien. Die letzten beiden werden üblicherweise als solche gekennzeichnet, um sie gesondert behandeln zu können. So werden beim Deinstallieren alle Dateien entfernt, es sei denn, es handelt sich um Konfigurationsdateien, die Sie verändert haben. Dateien der Dokumentation können Sie zum Beispiel von der Installation ausnehmen. Das eben beschriebene typische RPM-Paket bezeichnet man auch als Binär- Binär-RPM-Paket RPM-Paket. Beim Erstellen eines RPM-Paketes entsteht typischerweise zusätzlich ein Source-RPM-Paket. Dieses kann wie ein»normales«rpm-paket mit rpm -i in- Source-RPM-Paket stalliert werden. Es enthält die Quelltexte und die spec-datei (siehe unten) des RPM-Paketes, die bei der Installation dort landen, wo sie sich bei der Erstellung des RPM-Paketes befanden. B Technisch gesehen sind RPM-Pakete cpio-archive mit einem Vorspann (variabler Länge). Wenn Sie einmal an den Inhalt eines RPM-Pakets heran wollen, ohne es gleich zu installieren, so können Sie es mit dem Programm rpm2cpio zunächst in ein normales cpio-archiv konvertieren, bevor Sie es mit cpio entpacken. 5.3 Voraussetzungen zum Bau eines RPM-Pakets Um ein RPM-Paket aus den Quellen einer Software zu bauen, benötigen Sie: die Originalquellen der betreffenden Software (in der Regel als komprimiertes tar-paket eventuelle Patches für die betreffende Software, ebenfalls als (komprimierten) Quelltext eine Datei mit genauen Anweisungen, wie das Paket ausgepackt, gepatcht, übersetzt und gebaut werden soll (die spec-datei) das Programm rpm bzw. rpmbuild. Ab RPM-Version 4 sollten Sie letzteres verwenden; die Syntax entspricht mehr oder weniger derjenigen von rpm für den Bau von Paketen. Für die LPI-Prüfungen ist rpmbuild relevant (Stand Frühjahr 2006).

4 84 5 Softwarepakete mit rpm RPM-Verzeichnis Ein»RPM-Verzeichnis«, in dem Sie Quelltext und spec-datei ablegen. In der Regel befindet sich das RPM-Verzeichnis unterhalb von /usr/src. Klassischerweise trägt es den Namen redhat, bei anderen Distributionen verständlicherweise einen anderen Namen, wie etwa packages bei SUSE. Den genauen Ort können Sie über eine der *rpmrc-dateien festlegen. Während der Name und der Ort des Verzeichnisses selbst eher unerheblich sind, ist der Inhalt des Verzeichnisses fest vorgegeben: $ ls /usr/src/packages BUILD RPMS SOURCES SPECS SRPMS Die Unterverzeichnisse haben folgende Aufgaben: SOURCES Hier werden vor der Paketerstellung die Quellarchive und Patches abgelegt SPECS BUILD RPMS SRPMS Hier kommen die spec-dateien zu liegen Hier werden die Quellen ausgepackt und übersetzt Enthält Unterverzeichnisse für verschieden Architekturen (386, ppc usw.); Ziel für die erstellten Binär-RPM-Pakete Ziel für die erstellten Source-RPM-Pakete 5.4 Die spec-datei Zum Erstellen eines RPM-Paketes benötigen Sie eine Datei mit detaillierten Informationen, wie das Paket gebaut werden soll. Eine solche paketspezifische Datei trägt üblicherweise die Endung.spec; RPM verwendet die Datei zum: 1. Entpacken des Quelltextpakets 2. Anwenden der Quelltext-Patches (sofern es sie gibt) 3. Übersetzen der Software 4. Erstellen des Binär-RPM-Pakets 5. Erstellen des Source-RPM-Pakets 6. Aufräumen Es gelten die üblichen Regeln: Leerzeilen und Zeilen, die mit dem Kommentarzeichen # versehen sind, werden nicht interpretiert. Ihren Aufgaben entsprechend ist die spec-datei in verschiedene Abschnitte aufgeteilt. Der Inhalt der meisten Abschnitte kann beliebigen Shell-Code enthalten: Die Präambel enthält die Informationen, die Sie mit»rpm -qi Paketname «zu sehen bekommen. Der prep-abschnitt enthält die Kommandos, die als Vorbereitung für das Übersetzen der Software notwendig sind, etwa Befehle zum Auspacken der Quellen. Der build-abschnitt enthält die Kommandos zum Übersetzen der Quellen (zum Beispiel»make«). Der install-abschnitt enthält die Kommandos, die für die Installation notwendig sind (zum Beispiel»make install«). Der files-abschnitt enthält eine Liste aller Dateien, die das RPM-Paket enthalten soll.

5 5.4 Die spec-datei 85 Der clean-abschnitt kann Kommandos zum Aufräumen nach dem Erstellen de RPM-Pakets enthalten. Der Changelog-Abschnitt enthält die Entwicklungsgeschichte der spec-datei. Während die oben beschriebenen Abschnitte beim Erstellen des RPM-Paketes abgearbeitet werden, kommen die folgenden Abschnitte erst auf den Zielrechnern bei der Installation bzw. Deinstallation eines Paketes zum Tragen. In der Praxis werden diese Abschnitte beispielsweise dazu verwendet, nach der Installation einer Bibliothek ldconfig aufzurufen: Der pre-abschnitt kann Kommandos enthalten, die vor der Installation des RPM- Pakets abgearbeitet werden sollen. Der post-abschnitt kann Kommandos enthalten, die nach der Installation des RPM-Pakets abgearbeitet werden sollen. Der preun-abschnitt kann Kommandos enthalten, die vor der Deinstallation des RPM-Pakets abgearbeitet werden sollen. Der postun-abschnitt kann Kommandos enthalten, die nach der Deinstallation des RPM-Pakets abgearbeitet werden sollen. In allen Abschnitten der spec-datei können Sie RPM-interne Variable verwen- Variable den, insbesondere, um einzelne Verzeichnisse zu adressieren: $RPM_BUILD_DIR $RPM_SOURCE_DIR das BUILD-Verzeichnis das SOURCE-Verzeichnis $RPM_PACKAGE_NAME der Paketname (ohne Versionsnummer) $RPM_ARCH das Kürzel der verwendeten Hardwareplattform Außerdem können Sie auch eigene Variable definieren, was insbesondere für Versionsnummern und ähnliches praktisch ist, wenn Sie für neue Softwareversionen immer neue RPM-Pakete schnüren müssen. Eigene Variable werden mit %define Variable Wert definiert und ihre Werte mit %{ Variable } benutzt, etwa: %define version Version: %{version} Im Folgenden sollen die relevanten Abschnitte anhand eines Beispiels näher Praxisbeispiel erläutert werden. Zuerst die Präambel und die Variablendefinitionen: ## Variablendefinitionen %define name bladeenc %define version %define release 1 ## Präambel Summary: Name: bladeenc - Encoder zum Erstellen von MP3-Dateien %{name}

6 86 5 Softwarepakete mit rpm Version: %{version} Release: %{release} License: LGPL Group: Applikationen/Multimedia/Musik Source: URL: Packager: Linup Front < %description bladeenc dient dem Erstellen von MP3-Dateien aus WAV-Dateien. Dabei können mp3-dateien unterschiedlicher Bitraten erstellt werden. Präambel Die Präambel sollte folgende Unterabschnitte aufweisen: Summary Ein Satz mit einer Kurzbeschreibung der Software Name Der Name der Software, wird später Bestandteil des Paket-Namens (label) und des Dateinamens des RPM-Paketes Version Release Versionsnummer der Software Versionsnummer des Pakets (Anzahl der Versuche ) License Name der Lizenz, der die Software unterliegt; wichtig, um später zwischen»freier«und»proprietärer«software unterscheiden zu können Group Ermöglicht das Gruppiern von Software; hier können Sie eine Gruppe in der Art Netzwerk/Dienste/Ftp definieren Source Enthält in erster Linie den Namen des Quellarchivs im Verzeichnis SOURCES; diese Information wird für den Bau des Paketes benötigt! Alles, was vor dem Dateinamen steht wird ignoriert; hier wird häufig die URL des FTP- Verzeichnisses angegeben, von der die Quellen stammen. URL URL der Dokumentation der Software Distribution Optional; enthält den Namen der Distribution Vendor Optional; Organisation, die das Paket vertreibt Packager Optional; Name und in»< >«gefasste -Adresse %description Erlaubt eine sich über mehrere Zeilen erstreckende Beschreibung des Paketes. Der %description-abschnitt versteht verschiedene Optionen, so können Sie beispielsweise Ihrem Paket mit einem Extraabschnitt %description -l de eine deutschsprachige Beschreibung ergänzend hinzufügen. Die meisten Informationen der Präambel sind ausschließlich für den Menschen bestimmt, lediglich Name, Version, Release und Source wirken sich auf das Ergebnis des Paketbau-Vorgangs aus. Der prep-abschnitt wird duch die Zeichenfolge %prep eingeleitet. Dem folgen al- le Kommandos, die zum Entpacken der Quelltexte notwendig sind. In der Regel handelt es sich um ein tar-archiv, für diesen Fall bringt RPM ein bereits vorgefertigtes Makro namens setup zum Auspacken der Quellen in das Verzeichnis BUILD mit. Das Makro wird mit %setup aufgerufen: prep-abschnitt ## Entpacken der Sourcen %prep %setup Makros Makros stehen für viele Standardvorgänge beim Bau eines RPM-Pakets zur Verfügung. Der Aufruf eines Makros erfolgt ähnlich wie der Aufruf der einzelnen Abschnitte durch den Namen des Makros mit einem vorangestellten Prozentzeichen. Viele Makros verstehen diverse Kommandozeilenparameter.

7 5.4 Die spec-datei 87 Beim Aufruf des setup-makros können Sie zum Beispiel mit der Option»setup -n Verzeichnis «das Verzeichnis angeben, das beim Auspacken des Quellarchivs im BUILD-Verzeichnis entsteht. Schließlich heißt das entstehende Verzeichnis nicht immer so wie das Archiv und RPM ist kein Hellseher. ## Entpacken der Sourcen %prep %setup -n %{name}-%{version} B Im prep-abschnitt können Sie auch die entsprechenden Kommandos für das Patchen des Quelltextes unterbringen. Zuerst müssen Sie den Patch in der Patches Präambel mit»patch0: Patchdatei «angegeben und dann im prep-abschnitt mittels %patch -p0 den Patchvorgang implementieren. Hier ein Beispiel: Patch0: patch-fiktivesprogramm-1.2.diff %patch -p0 In den build-abschnitt schreiben Sie die nötigen Kommandos zum Übersetzen build-abschnitt der Quellen. Es handelt sich im Prinzip um ein Shellskript, das im mit %setup erstellten Verzeichnis ausgeführt wird. Hier finden Sie in der Regel nur einen Aufruf von make bzw../configure und make: ## Übersetzen %build./configure --prefix=/usr --sysconfdir=/etc make Im install-abschnitt stehen die Kommandos, mit denen die Erzeugnisse des install-abschnitt build-abschnitts auf dem Build-System installiert werden. Häufig beschränkt sich der Inhalt auf ein einfaches make install. ## Installieren %install make install In Spezialfällen können Sie die Dateien auch von Hand per install oder cp an ihr Ziel befördern. Im file-abschnitt bringen Sie die Liste aller Dateien unter, die später im RPM- file-abschnitt Paket landen sollen. Die Datei, die Sie hier vergessen, wird auch auf dem Zielrechner nicht existieren! Die Angaben der Dateien erfolgen üblicherweise als absoluter Pfad, und zwar als der Pfad, unter dem RPM die Datei auf dem Build-Rechner findet. Gleichzeitig handelt es sich dabei auch um den Pfad, unter dem die Dateien auf dem Zielsystem landen. ## Liste der zu installierenden Dateien %files README INSTALL COPYING AUTHORS TODO /usr/bin/bladeenc Relative Pfadangaben beziehen sich auf das ausgepackte Quellen-Verzeichnis (unterhalb des Verzeichnisses BUILD). So angegebene Dateien landen auf dem Zielsystem im RPM-spezifischen Dokumentationsverzeichnis. Das könnte zum Beispiel /usr/doc oder (nach FHS) /usr/share/doc/packages sein. Auf die beschriebene Weise können Sie in Ihre RPM-Pakete die entsprechenden README-Dateien und COPYING-Dateien (Lizenz!) integrieren.

8 88 5 Softwarepakete mit rpm Kennzeichnen von Dateien Innerhalb des file-abschnitts besteht die Möglichkeit, Dateien ihrer Funktion nach zu kennzeichnen. Dafür setzen Sie vor die Pfadangabe ein mit einem Prozentzeichen eingeleitetes Schlüsselwort. Als Schlüsselwort stehen Ihnen unter anderem %doc (Dokumentations-Datei) und %config (Konfigurationsdatei) zur Verfügung. Die entsprechenden Informationen werden bei Installation und Deinstallation auf dem Zielsystem berücksichtigt und können mit»rpm -qd«respektive»rpm -qc«abgerufen werden: ## Liste der zu installierenden Dateien %files %doc README INSTALL COPYING AUTHORS TODO /usr/bin/bladeenc Dateiattribute Ein weiteres interessantes Schlüsselwort ist %attr: Hiermit können Sie für eine Datei explizit UID, GID und Zugriffsrechte definieren: %attr(640, root, root) testdatei.test Mit %defattr( Rechte, UID, GID ) können Sie die entsprechenden Werte für alle Dateien der Dateiliste gemeinsam festlegen. Achtung: Die Liste der Dateien im file-abschnitt wird nicht automatisch erstellt. Sie müssen sie von Hand in die Datei eintragen. Die Frage ist, wie Sie an eine Liste der im install-abschnitt installierten Dateien gelangen. Die Antwort: Sie müssen den Installationsvorgang nachvollziehen, etwa durch Lesen des make- Targets install in der Makefile. Netterweise reicht es bei Verzeichnissen, nur diese und nicht den Inhalt im Einzelnen anzugeben. 5.5 Erstellen des RPM-Pakets Übersetzen von Hand Bevor Sie sich an das Erstellen des RPM-Paketes wagen, sollten Sie die Quellen vorher schon einmal von Hand übersetzt haben. Schließlich passiert das auch bei der Erstellung des Paketes. Für den eigentlichen Build-Vorgang wechseln Sie sinnvollerweise in das RPM- Verzeichnis. Der Paketbau erfolgt mit dem Kommando rpm, etwa wie # cd /usr/src/packages/ # rpm -ba SPECS/bladeenc.spec Zur Erinnerung, ab RPM-Version 4 sollten Sie stattdessen rpmbuild verwenden, das aber genauso funktioniert: # rpmbuild -ba SPECS/bladeenc.spec Die Option -b versetzt rpm in den Paketbau-Modus, die Option -a bewirkt ein Erstellen von sowohl dem Binary-RPM als auch dem Source-RPM. Während des Bauvorgangs arbeitet rpm (bzw. rpmbuild) der Reihe nach die spec- Datei ab und wechselt dabei selbstständig in die einzelnen Verzeichnisse. Es überprüft mit ldd die Bibliotheken, die von den Programmen des Pakets benötigt werden und fügt sie der Liste der Abhängigkeiten hinzu. Anhand der Dateiliste im files-abschnitt und mit Hilfe von cpio tut rpm die erforderlichen Dateien ins RPM- Paket. Zum Schluss werden die entpackten Quellen aus BUILD beseitigt und der clean-abschnitt abgearbeitet, wenn vorhanden. Übungen C 5.1 [2] Holen Sie sich von die aktuelle Version von»gnu Hello«. Packen Sie das Archiv aus und compilieren und installieren Sie es zunächst»manuell«. Welche Dateien werden im System installiert und wo? Verwenden Sie»make uninstall«, um das Paket wieder zu entfernen.

9 5.6 Die Buildroot-Direktive 89 C 5.2 [!3] Erstellen Sie eine spec-datei für GNU Hello und erzeugen Sie damit ein RPM-Paket. Gehen Sie in das Arbeitsverzeichnis unter /usr/src/packages/ BUILD und verwenden Sie»make uninstall«, um die für die Paketerzeugung installierten Dateien wieder zu entfernen. Installieren Sie das RPM-Paket und vergewissern Sie sich, dass das Programm hello läuft die Manpage angezeigt wird (»man hello«) Ausgaben in anderen Sprachen funktionieren (probieren Sie etwas wie»lang=fr_fr hello«) 5.6 Die Buildroot-Direktive Das bisher beschriebene Verfahren hat einen gravierenden Nachteil: beim Bauen des RPM-Pakets wird ins laufende System installiert. Daraus folgt, dass 1. Sie zum Paketbauen Root-Rechte benötigen, 2. zentrale Komponenten des Systems nicht gebaut werden können (wie wollen Sie auf diese Weise ein RPM-Paket für RPM selbst bauen?), 3. es schwierig wird, die erforderliche Dateiliste zu erstellen. Alle diese Probleme können Sie mit Hilfe der Buildroot-Direktive umgehen, aber das sei ehrlicherweise angemerkt Sie handeln sich bei der Gelegenheit unter Umständen andere Probleme ein. Die Idee ist simpel: Sie installieren beim Bauen nicht ins System, sondern in ein neues Verzeichnis hinein, eben das durch die Buildroot-Direktive in der Präambel angegebene. RPM kümmert sich darum, die Dateien aus diesem Verzeichnis zu nehmen, um das RPM-Paket zu erstellen, im RPM-Paket wird das aber unterschlagen, so dass die Pfadangaben so aussehen, als hätten Sie das Paket ohne Buildroot gebaut. Und so geht s: Angenommen, Ihre spec-datei sieht bisher so aus: Summary: Bogus Server Name: bogod Version: 0.1 Release: 1 Group: Utilities/dispensable License: GPL Source: bogod-0.1.tar.gz URL: %description Dispensable and bogus server %prep %setup %build./configure --prefix=/usr --sysconfdir=/etc make %install make install ## %clean %files

10 90 5 Softwarepakete mit rpm /usr/sbin/bogod %config /etc/bogod.conf Ändern Sie die Datei wie folgt ab: Summary: Bogus Server Name: bogod Version: 0.1 Release: 1 Group: Utilities/dispensable License: GPL Source: bogod-0.1.tar.gz URL: Buildroot: /var/tmp/bogod-root %description Dispensable and bogus server %prep %setup %build./configure --prefix=/usr --sysconfdir=/etc make %install make DESTDIR="$RPM_BUILD_ROOT" install %clean test "$RPM_BUILD_ROOT"!= "/" && rm -rf "$RPM_BUILD_ROOT" %files /usr/sbin/bogod %config /etc/bogod.conf Änderungen finden also nur in der Präambel und in den Abschnitten %install und %clean statt. Was bedeuten diese Änderungen? Durch die Buildroot-Direktive aktivieren Sie den Buildroot-Mechanismus. RPM erwartet nun, dass sich beim Bauen des RPM-Pakets die Pfadangeben im %files-block relativ zur Buildroot gemeint sind. Beim Bauen sammelt RPM also die Datei /var/tmp/bogod- root/usr/sbin/ bogod ein; auf dem Zielsystem wird sie aber nach /usr/sbin/bogod installiert. Damit Sie sich in der Spec-Datei auf die Buildroot beziehen können, wird die Variable RPM_BUILD_ROOT entsprechend gesetzt. In das Verzeichnis /var/tmp/bogod- root gelangen die Dateien durch den modifizierten make install-aufruf: der Wert von DESTDIR wird beim Installieren jedem Pfad voran gestellt. Es ist von entscheidender Wichtigkeit, dass Sie es sich verkneifen, die Pfade schon beim./configure-aufruf zu verbiegen! Denn daduch würde bogod mit diesen Pfaden übersetzt. Das Ergebnis wäre, dass der Server seine Konfigurationsdatei unter /var/tmp/bogod/etc/bogod.conf suchen würde, sicherlich kein erwünschter Effekt. Durch das hier skizzierte Vorgehen wird nur beim Installieren»gemogelt«. Der %clean-abschnitt beseitigt das nur vorübergehend benötigte Buildroot- Verzeichnis. Da Sie jederzeit durch Aufruf-Parameter und die Konfigurationsdatei die Einstellungen in der spec-datei überstimmen können, empfiehlt sich hier ein wenig Vorsicht. Würde das Buildroot-Verzeichnis bedingungslos gelöscht, so könnten Sie sehr schnell Ihres Systems verlustig gehen. A Das hier beschriebene Verfahren funktioniert allerdings nur dann problemlos, wenn die Software zum Übersetzen die Autotools benutzt. Nur dann

11 5.7 Paketabhängigkeiten 91 A wird das Makefile mit den entsprechenden Variablen angelegt, so dass Sie sie verbiegen können. Andere Makefiles müssen Sie möglicherweise von Hand anpassen. Das Verfahren schlägt auch dann fehl, wenn die Pfade nicht in der Bau- Phase (make) sondern in der Installations-Phase (make install) in die Programme eingetragen werden. Das ist machmal bei Software der Fall, die ganz oder teilweise aus Skripten besteht, die daher nicht übersetzt werden müssen. Schauen Sie sich in solchen Fällen das Makefile an, und installieren Sie unter Umständen ohne Makefile, also von Hand. Durch das Verbiegen des Installations-Pfades auf /var/tmp/bogod- root ist es jetzt ganz leicht, die Datei-Liste zu erstellen:»find /var/tmp/bogod- root«listet alle Dateien auf; Sie müssen nur noch nachkorrigieren. Und Root-Rechte benötigen Sie natürlich auch nicht mehr, sofern Sie nur Schreibrechte im RPM-Verzeichnis haben (in ~/.rpmrc können Sie ein alternatives RPM-Verzeichnis angeben, so dass dies keine Einschränkung bedeutet). 5.7 Paketabhängigkeiten Kaum ein Programm funktioniert, ohne auf Hilfsdateien, Programme und insbesonders auf Bibliotheken zuzugreifen. Dabei kann es auch zu Konflikten kommen, wenn etwa zwei Programme dieselbe Konfigurationsdatei verwenden. Eine Hauptaufgabe eines Paketverwaltungssystems ist es, solche Abhängigkeiten und Konflikte zu lösen. Tritt bei der Installation bzw. Deinstallation eine der beschriebenen Problemsi- Problemsituationen tuationen auf, bricht RPM den Vorgang ab und gibt eine aussagekräftige Warnung ab: # rpm -e glibc Fehler: Failed dependencies: ld-linux.so.2 is needed by (installed) glibc-locale ld-linux.so.2 is needed by (installed) popt ld-linux.so.2 is needed by (installed) ash Auch selbstgebauten Paketen können Sie natürlich entsprechende Informationen mitgeben. Wie schon erwähnt werden einfache Bibliotheksabhängigkeiten verpackter Automatismen Programme automatisch per ldd erfasst und im RPM-Paket in der paketinternen Requires-Liste (englisch für»benötigt«) vermerkt. Das gilt auch für die entgegengesetzte Richtung; schnüren Sie ein Paket, das Bibliotheken enthält tauchen diese in der internen Provides-Liste (englisch für»bietet an«) auf. Abhängigkeiten von kompletten Paketen sowie Konflikte müssen Sie von Hand in der Präambel der spec-datei angeben. Dabei stehen Ihnen die folgenden Einträge zur Verfügung: Requires: Paket setzt das Vorhandensein eines bestimmten Paketes voraus. In der Art»Requires Paket >= 1.0«können auch Abhängigkeiten von verschiedenen Versionen formuliert werden. Provides: Fähigkeit ermöglicht es Ihnen, abstrakte Fähigkeiten eines Paketes zu formulieren. So ist es sinnvoll, einem MTA (»Mailserver«) eine Fähigkeit der Art»Provides: MTA«zuzugestehen, zumal es den meisten Programmen, die die Dienste eines MTAs benötigen, egal ist, um welchen genau es sich handelt. Requires: Fähigkeit ermöglicht es, das Vorhandensein eines Paketes, welches die entsprechende Fähigkeit zur Verfügung stellt, einzufordern.

12 92 5 Softwarepakete mit rpm Conflicts: Paket dokumentiert einen vorhandenen Konflikt mit einem anderen Paket. Obsoletes: Paket bezeichnet das andere Paket als obsolet (nicht mehr benötigt), etwa weil das aktuelle Paket die Fähigkeiten des anderen Paketes in der aktuellen Version bereits enthält. Was wird gebraucht? Welche Dateien und Dienstleistungen ein Paket benötigt, können Sie im übrigen mit der rpm-option --requires erfahren. Welche Pakete eine bestimmte Fähigkeit zur Verfügung stellen, verrät die Option --whatprovides: $ rpm -q --whatprovides web_browser w3m mozilla lynx Was wird geboten? In analoger Weise können mit --provides und --whatrequires die Fähigkeiten eines Pakets (nur Dienstleistungen; Dateien über -l) und die Abnehmer einer Dienstleistung erfragt werden. 5.8 Hinzufügen von Signaturen PGP-Signatur Möchten Sie die selbstgebauten Pakete öffentlich zugänglich machen, zum Beispiel per Internet, sollten Sie Ihr Paket mit einer PGP-Signatur versehen. Ihr Paket hat auf jeden Fall eine MD5-Prüfsumme, die dem Empfänger eine Überprüfung auf Vollständigkeit und Unverändertheit gestattet; die PGP-Signatur erlaubt es einem Anwender, herauszufinden, ob das Paket aus der originalen Quelle stammt. Die Verifizierung erfolgt in beiden Fällen mit»rpm -K«: $ rpm -K bladeenc i586.rpm bladeenc i586.rpm: md5 gpg OK Sollte zwar die MD5-Prüfsumme, aber nicht die Signatur korrekt sein, so sieht die Ausgabe entsprechend anders aus: $ rpm -K bladeenc i586.rpm bladeenc i586.rpm: md5 GPG NOT OK MD5-Prüfsumme Signieren des Paketes Schlüsselpaar erstellen Beachten Sie, dass im Fehlerfall das entsprechende Kürzel in Großbuchstaben geschrieben wird, etwa GPG statt gpg. Um die MD5-Prüfsumme brauchen Sie sich nicht zu kümmern, da rpm (bzw. rpmbuild) sie dem Paket bei der Erstellung automatisch hinfügt. Das Signieren des Paketes hingegen ist nicht ganz trivial, da es eine funktionierende PGP/GPG-Umgebung voraussetzt. Konkret müssen Sie das Paket mit Ihrem privaten PGP- oder GPG-Schlüssel signieren. Der Zielanwender kann dann mit Hilfe Ihres öffentlichen Schlüssels die Signatur überprüfen und sichergehen, dass das richtige Paket angekommen ist. Der Gesamtvorgang soll im Folgenden kurz beschrieben werden. Für Hintergründe zu PGP/GPG siehe unter anderem Als erster Schritt müssen Sie, falls noch nicht vorhanden, ein Schlüsselpaar erstellen. Dazu verwenden Sie das Kommando pgp, respektive gpg im Falle der Open- Source-PGP-Variante GPG: $ gpg --gen-key gpg (GnuPG) 1.2.2; Copyright (C) 2003 Free Software Foundation, Inc. Bitte wählen Sie, welche Art von Schlüssel Sie möchten: (1) DSA und ElGamal (voreingestellt) (2) DSA (nur signieren/beglaubigen)

13 5.8 Hinzufügen von Signaturen 93 (5) RSA (nur signieren/beglaubigen) Ihre Auswahl? 1 Welche Schlüssellänge wünschen Sie? (1024) 1024 Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll. 0 = Schlüssel verfällt nie <n> = Schlüssel verfällt nach n Tagen Wie lange bleibt der Schlüssel gültig? (0) 0 Key verfällt nie. Ist dies richtig? (j/n) j Ihr Name ("Vorname Nachname"): Hugo Schulz -Adresse: [email protected] Kommentar: Beehren Sie uns wieder! Sie haben diese User-ID gewählt: "Hugo Schulz (Beehren Sie uns wieder!) <[email protected]>" Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F Geben Sie die Passphrase ein: Sein oder Nichtsein ist eine dumme Frage Geben Sie die Passphrase nochmals ein: Sein oder Nichtsein ist eine dumme Frage Öffentlichen und geheimen Schlüssel erzeugt und signiert. In Ihrem Heimatverzeichnis wird dabei ein Unterverzeichnis.gnupg mit folgen- Unterverzeichnis.gnupg dem Inhalt erstellt: # ls ~/.gnupg/ gpg.conf pubring.gpg trustdb.gpg random_seed secring.gpg Als nächstes, vor dem Signieren der RPM-Pakete, muss das erstellte GPG-Verzeichnis RPM bekannt gemacht werden. Dazu verwenden Sie bei alten RPM-Versionen die RPM-Konfigurationsdatei; bei neueren Versionen steht Ihnen eine spezielle Makro-Konfigurationsdatei /etc/rpm/macros zur Verfügung, in der Sie folgende Einträge vornehmen: %_signature gpg %_gpg_path /root/.gnupg %_gpg_name Hugo Schulz (Beehren Sie uns wieder) <[email protected]> %_gpgbin /usr/bin/gpg Im dritten Schritt können Sie mit rpm (ältere RPM-Versionen) bzw. rpmsign das Paket signieren, jeweils mit der Option --addsign: Paket signieren # rpmsign --addsign RPMS/i586/bladeenc i586.rpm Enter pass phrase: Sein oder Nichtsein ist eine dumme Frage Pass phrase is good. RPMS/i586/bladeenc i586.rpm: Zu guter Letzt sollten Sie die Signatur testen: Signatur testen # rpm -K RPMS/i586/bladeenc i586.rpm RPMS/i586/bladeenc i586.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#4490e0a1) Das Auftauchen der Zeichenfolge GPG zeigt, dass das Paket zwar eine GPG-Signatur trägt, die Verifizierung derselben aber fehlschlägt. Warum? Ganz einfach: So

14 94 5 Softwarepakete mit rpm wie der Zielanwender müssen auch Sie erst einmal RPM Ihren öffentlichen Schlüssel bekanntmachen, und zwar mit rpm bzw. rpmsign und der Option --import. Doch zuvor müssen Sie sich den öffentlichen Schlüssel erst einmal selbst bekanntmachen und in Form einer ASCII-Datei exportieren: # gpg --list-public-keys /root/.gnupg/pubring.gpg pub 1024D/4490E0A Apu Nahasapimapetilan (Beehren Sie uns wieder) <[email protected]> sub 1024g/E51B28FA # gpg -a --export 4490E0A1 > /tmp/gpg-public-key Erst dann können Sie den Schlüssel auch RPM bekanntmachen: # rpmsign --import /tmp/gpg-public-key Diese Möglichkeit sollten Sie natürlich auch Ihren Zielanwendern ermöglichen und den öffentlichen Schlüssel auf Ihrer Website oder über einen Keyserver publik machen Wenn Sie jetzt noch einmal die Signatur des soeben signierten Paketes überprüfen, sollten Sie ein anderes Ergebnis als vorhin bekommen: # rpm -K RPMS/i586/bladeenc i586.rpm RPMS/i586/bladeenc i586.rpm: (sha1) dsa sha1 md5 gpg OK Übungen C 5.3 [3] Signieren Sie ein von Ihnen erstelltes RPM-Paket und überprüfen Sie seine Signatur. 5.9 Einfaches Erstellen von Paketen mit checkinstall Das Programm checkinstall von Felipe Eduardo Sánchez Díaz Durán erlaubt es, auf einfachste Weise RPM-Pakete zu bauen. Sie bekommen es unter Um aus den Quellen einer Software ein entsprechendes RPM-Paket zu erstellen, reicht es, die Quellen zu entpacken sowie./configure und checkinstall im entstehenden Verzeichnis auszuführen: # tar -xzf /data/programme/testdisk-5.3.tar.gz # cd testdisk-5.3/ #./configure checking build system type... i686-pc-linux-gnu # checkinstall Should I create a default set of package docs? [y]: y End your description with an empty line or EOF.>> testdisk >> ist ein Programm zur Rekonstruktion defekter >> Partitionstabellen >> This package will be built according to these values: 1 - Summary: [ testdisk ]2 - Name: [ testdisk ] 3 - Version: [ 5.3 ]4 - Release: [ 1 ]5 - License: [ GPL ] 6 - Group: [ Applications/System ]7 - Architecture: [ i386 ]

15 5.9 Literaturverzeichnis Source location: [ testdisk-5.3 ] 9 - Alternate source location: [ ]10 - Provides: [ ] 11 - Requires: [ ] Enter a number to change any of them or press ENTER to continue: Installing with make install... Building RPM package...ok Das Ganze funktioniert leider nur, wenn die Quellen dem bekannten»dreisprung«gehorchen, außerdem sind die entstehenden RPM-Pakete nicht gerade perfekt aber eben doch besser zu verwalten als direkt aus den Quellen installierte Software. Kommandos in diesem Kapitel checkinstall Konstruiert RPM-Pakete auf der Basis von Installationsvorgängen checkinstall(8) 94 gpg Verschlüsselt und signiert Dateien gpg(1) 92 rpm Dient zur Paketverwaltung in vielen Linux-Systemen (Red Hat, SUSE, ) rpm(8) 82 rpmbuild Erzeugt RPM-Pakete rpmbuild(8) 83 rpmsign Signiert RPM-Pakete (und verwaltet Schlüssel dafür) rpmsign(8) 93 Zusammenfassung Wenn möglich, sollten Sie Software in Quelltextform über den Umweg von RPM-Paketen installieren, um sie einfacher verwalten zu können Die Anleitungen zum Bau eines RPM-Paketes müssen in einer spec-datei hinterlegt werden. Ein RPM-Paket wird mit dem Kommando rpm -ba SPEC (bzw. rpmbuild -ba SPEC) gebaut. Die Buildroot-Direktive erlaubt es, RPM-Pakete ohne Gefährdung des Systems zu bauen. RPM-Pakete können manuell und automatisch mit Informationen über Abhängigkeiten versehen werden. Mittels gpg und rpmsign können RPM-Pakete signiert werden. Mit checkinstall können Sie einfache RPM-Pakete bauen. Literaturverzeichnis Bai97 Ed Bailey. Maximum RPM. MacMillan Publ. Comp., rpm/ RPM-HOWTO Donnie Barnes.»RPM-HOWTO«, November HOWTO/

16