Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Kapitel 3. Erstellung von angepassten Paketen

Es gibt viele Fallstricke beim Erstellen von Software-Paketen. Dies ist speziell dann der Fall, wenn diese Pakete via Red Hat Network verteilt und installiert werden müssen. Dieses Kapitel gibt einen Überblick über das Erstellen von Paketen zur erfolgreichen Verteilung via Red Hat Network. Dabei wird unter anderem darauf eingegangen, warum RPM verwendet werden sollte, wie Pakete für RHN erstellt werden sollten und wie Pakete richtig signiert werden können.

3.1. Erstellen von Paketen für Red Hat Network

Red Hat Network verwendet die RPM Paketmanager (RPM) Technologie, um festzustellen, welche zusätzliche Software und Updates auf jedes Client-System anwendbar sind. Pakete, die von Red Hat Network abgefragt werden, liegen üblicherweise im RPM-Format vor. ISO-Images sind dagegen über den Software-Reiter auf der Red Hat Network Website erhältlich, sind jedoch nicht für RHN Satellite Server verfügbar. Wenn Ihr Satellite-Server Solaris-Support aktiviert hat, können Sie RHN Push dazu verwenden, Solaris-Pakete in angepasste Channels hochzuladen, die von Solaris-Clients verwendet werden.
RPM ist ein Tool, welches das Installieren, Deinstallieren, Aktualisieren und Verifizieren von Software-Paketen erleichtern soll. Software-Entwickler können damit auch den Quellcode und die kompilierte Version eines Programms für Endbenutzer und Entwickler paketieren.

3.1.1. Vorteile von RPM

RPM hat folgende Vorteile:
Einfache Aktualisierungen
Durch die Verwendung von RPM aktualisieren Sie individuelle Komponenten eines Systems, ohne dabei neu installieren zu müssen. Wenn Red Hat eine neue Version von Red Hat Enterprise Linux veröffentlicht, müssen Benutzer nicht von Grund auf neu installieren. RPM ermöglicht 'intelligente' und vollautomatische Aktualisierungen Ihres Systems. Konfigurationsdateien in Paketen gehen nicht während der Aktualisierungen verloren. Benutzer verlieren daher keine benutzerspezifischen Anpassungen. Es werden keine speziellen Aktualisierungsdateien benötigt, um ein Paket zu aktualisieren, da dieselbe RPM-Datei dazu benutzt wird, das Paket zu installieren und zu aktualisieren.
Paketabfragen
RPM bietet Abfrageoptionen, um die gesamte RPM-Datenbank nach allen Paketen oder auch nur nach bestimmten Dateien zu durchsuchen. Sie können auch auf einfachste Weise den Ursprung des Pakets herausfinden und zu welchem Paket eine Datei gehört. Die Dateien im Paket befinden sich in einem komprimierten Archiv mit einem angepassten Binär-Header, der nützliche Informationen über die Pakete und deren Inhalte enthält. RPM durchsucht die Header auf rasche und einfache Weise.
Systemverifizierung
Ein weiteres Feature ist die Paketverifizierung. Wenn Sie glauben, dass eine Datei eines Pakets versehentlich gelöscht wurde, können Sie das Paket durchsehen und den Status der darin enthaltenen Dateien überprüfen. Diese Verifizierung benachrichtigt Sie über alle Anomalien. Wenn ein Fehler vorhanden ist, können Sie die Dateien auf einfachste Weise nochmals installieren. Modifizierte Konfigurationsdateien werden während der Neuinstallation nicht verändert.
Unverfälschte Quellen
Ein äußerst wichtiges Merkmal von RPM ist die Möglichkeit der Verwendung unverfälschter Software-Quellen, wie Sie von den ursprünglichen Autoren herausgegeben wurden. Mit RPM können die ursprünglichen Quelldateien gemeinsam mit jeglichen Patches und den kompletten Build-Instruktionen paketiert werden. Dies ist aus mehreren Gründen wichtig. Wenn nämlich beispielsweise eine neue Version eines Programms herausgegeben wird, müssen Sie nicht unbedingt wieder ganz von vorne anfangen, um es zu kompilieren. Sie können sich den Patch ansehen und dann eine Entscheidung darüber treffen, was Sie vielleicht unternehmen sollten. Alle mitkompilierten Standards und Änderungen, die einen einwandfreien Build gewährleisten sollen, können mithilfe dieser Technik auf einfache Weise sichtbar gemacht werden.
Quellen unverfälscht zu erhalten mag nur für Entwickler wichtig erscheinen, resultiert jedoch letztendlich auch in einer besseren Software-Qualität für den Endbenutzer.

3.1.2. RHN RPM-Richtlinien

Die Stärke von RPM liegt in der Fähigkeit, Abhängigkeiten zu bestimmen und Konflikte richtig zu identifizieren. Red Hat Network verlässt sich auf diesen Aspekt von RPM. Red Hat Network bietet eine automatisierte Umgebung, was bedeutet, dass kein manueller Eingriff während der Installation eines Pakets stattfinden kann. Wenn daher RPMs zur Verteilung durch Red Hat Network erstellt werden, ist es zwingend notwendig, sich an folgende Regeln zu halten:
  1. Erwerben Sie RPM-Kenntnisse. Es ist äußerst wichtig, ein fundamentales Verständnis der wichtigen Features von RPM zu besitzen, um Pakete richtig erstellen zu können. Für nähere Information verweisen wir für den Anfang auf folgende Informationsquellen:
  2. Wenn Sie eine RPM-Datei für einen Sub-Channel erstellen, dann erstellen Sie das Paket auf einer 'frischen' Installation von Red Hat Enterprise Linux mit derselben Version, wie der Basis-Channel des Sub-Channels. Stellen Sie sicher, dass Sie zuerst alle Updates von Red Hat Network anwenden.
  3. Das RPM-Paket muss ohne Verwendung der Optionen --force oder --nodeps installiert werden können. Wenn Sie ein RPM auf Ihrem Build-System nicht sauber installieren können, dann kann dieses auch von Red Hat Network nicht automatisch auf einem System installiert werden.
  4. Der Dateiname des RPM-Pakets muss dem NVR-Format (Name, Version, Release) entsprechen und die Architektur für das Paket beinhalten. Das richtige Format ist name-version-release.arch.rpm. Beispielsweise ist pkgname-0.84-1.i386.rpm ein gültiger Dateiname für ein RPM-Paket, wobei pkgname der Paketname ist, 0.84 die Version, 1 das Release und i386 die Architektur.
  5. Das RPM-Paket sollte vom Maintainer des Pakets signiert werden. Nicht signierte Pakete können zwar über das Red Hat Network verteilt werden, jedoch muss yum dazu gezwungen werden, diese zu akzeptieren. Das Signieren von Paketen wird dringend empfohlen und wird in Abschnitt 3.2, »Digitale Signaturen für RHN-Pakete« im Detail behandelt.
  6. Wenn die Version in irgendeiner Form verändert wird, inklusive Änderung der Signatur oder Neukompilierung, muss die Version oder das Release inkrementell erhöht werden. Mit anderen Worten muss NVRA (inkl. Architektur) für jedes RPM, das durch RHN verteilt wird, einem individuellen Build entsprechen, um Unklarheiten zu vermeiden.
  7. Kein RPM-Paket darf sich selbst als veraltet kennzeichnen.
  8. Wenn ein Paket in separate Pakete aufgeteilt wird, dann sollten Sie extrem vorsichtig mit den Abhängigkeiten sein. Teilen Sie kein bestehendes Paket auf, wenn nicht ein zwingender Grund dazu besteht.
  9. Kein Paket darf auf interaktive Pre-Installations-, Post-Installations, Pre-Deinstallations oder Post-Deinstallations-Skripte angewiesen sein. Wenn das Paket einen direkten Benutzereingriff während der Installation benötigt, funktioniert es nicht mit Red Hat Network.
  10. Jegliche Pre-Installations-, Post-Installations, Pre-Deinstallations oder Post-Deinstallations-Skripte sollten niemals etwas auf Standardfehler (stderr) oder Standardausgabe (stoud) ausgeben. Lenken Sie die Mitteilungen auf /dev/null um, wenn sie nicht notwendig sind. Andernfalls schreiben Sie diese in eine Datei.
  11. Wenn Sie die spec-Datei erstellen, verwenden Sie die Gruppendefinitionen von /usr/share/doc/rpm-<version>/GROUPS. Wenn Sie keine genaue Übereinstimmung finden, dann wählen Sie den nächstbesten Treffer aus.
  12. Verwenden Sie das RPM-Abhängigkeiten-Feature um sicherzugehen, dass das Programm auch nach der Installation läuft.

Wichtig

Erstellen Sie kein RPM, indem Sie Dateien archivieren und diese dann im Post-Installationsskript wieder dearchivieren. Dies entspricht in keiner Weise dem Zweck von RPMs.
Wenn die Dateien im Archiv nicht in der Dateiliste enthalten sind, dann können diese nicht auf Konflikte hin überprüft werden. In den meisten Fällen kann RPM selbst mit Archiven am effektivsten umgehen (Archive packen und entpacken). Erstellen Sie beispielsweise keine Dateien in %post, die Sie nicht in %postun entfernen können.