Red Hat Training

A Red Hat training course is available for Red Hat Satellite

12.4. Registrierung und Updates

Da Sie bereits RHN-spezifische Pakete installiert haben, SSL implementiert haben und Ihre Client-Systeme dahingehend rekonfiguriert haben, dass diese sich mit dem RHN Satellite verbinden, sind Sie nunmehr in der Lage, mit der Systemanmeldung zu beginnen und Updates zu erhalten.

12.4.1. Systeme anmelden

Dieser Abschnitt beschreibt den RHN-Registrierungsprozess für UNIX-Systeme. Dazu müssen Sie rhnreg_ks verwenden; die Verwendung von Aktivierungsschlüsseln zur Registrierung Ihrer Systeme ist optional. Diese Schlüssel ermöglichen es Ihnen, Einstellungen in RHN vorzubestimmen, wie beispielsweise Basis-Channels und Systemgruppen und diese zum Zeitpunkt der Registrierung automatisch auf den entsprechenden Systemen anzuwenden.
Da die Erstellung von Aktivierungsschlüsseln und deren Verwendung weitgehend in anderen Handbüchern behandelt wird, konzentriert sich dieser Abschnitt auf Unterschiede bei deren Anwendung auf UNIX-Varianten. Siehe Abschnitt 7.4.6.1, »Aktivierungsschlüssel verwalten« für eine vollständige Beschreibung dieses Vorgangs.
Um UNIX-Systeme mit Ihrem RHN Satellite zu registrieren, führen Sie folgende Aufgaben in dieser Reihenfolge durch:
  1. Melden Sie sich auf der RHN-Web-Oberfläche des Satellite an und klicken Sie den Systeme-Reiter in der oberen Navigationsleiste und danach Aktivierungsschlüssel in der linken Navigationsleiste. Klicken Sie dann den Link Neuen Schlüssel erstellen ganz rechts oben auf der Seite.
  2. Wählen Sie auf der folgenden Seite den Basis-Channel, den Sie am Ende von Abschnitt 12.2, »Satellite Server Vorbereitung/Konfiguration« erstellt haben.
  3. Nachdem Sie den Schlüssel erzeugt haben, klicken Sie auf dessen Name in der Aktivierungsschlüssel-Liste und erweitern dessen Einstellungen, indem Sie Software und Konfigurations-Channel und Systemgruppen verknüpfen.
  4. Öffnen Sie ein Terminal auf dem zu registrierenden Client-System und wechseln sie zu Benutzer Root.
  5. Verwenden Sie rhnreg_ks zusammen mit der Option --activationkey, um den Client beim Satellite zu registrieren. Die Zeichenkette, die den Schlüssel bildet, kann direkt von der Aktivierungsschlüssel-Liste auf der Website kopiert werden. Der Befehl sieht dann ungefähr so aus: 
    rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
  6. Gehen Sie zurück auf die Web-Site und klicken Sie auf den Namen des Aktivierungsschlüssels und überprüfen Sie, ob das neue System im Aktivierte Systeme-Reiter erscheint.

12.4.2. Updates erhalten

Paket-Updates werden unter UNIX anders abgewickelt als unter Linux. Beispielsweise benötigt Solaris Patch-Cluster, um mehrere Pakete auf einmal zu aktualisieren. Red Hat-Betriebssysteme verwenden hingegen Errata-Updates, um Upgrades mit spezifischen Paketen in Verbindung zu bringen. Zusätzlich dazu verwendet Solaris so genannte Antwortdateien, um interaktive Paketinstallationen zu automatisieren. Die ist etwas, das bei Linux keine Anwendung findet. Red Hat bietet dazu das Konzept von Quellpaketen an. Aus diesem Grund wird in diesem Abschnitt versucht, die Unterschiede bei der Verwendung von RHN-Tools auf UNIX-Systemen hervorzuheben. (Hinweis: Solaris Antwortdateien werden von RHN derzeit nicht unterstützt; dies ist jedoch für zukünftige Release geplant.)
Trotz der Unterschiede, wie beispielsweise dem Fehlen von Errata, weisen die Channel- und Paket-Management-Oberflächen auf der RHN-Website auf dem Satellite größtenteils die gleichen Funktionen für UNIX-Systeme auf. Alle Software-Channels für UNIX-Varianten können beinahe auf die gleiche Weise erstellt werden, wie die Custom-Channels (angepassten Channels), die im RHN Channel Management Guide (RHN Channel-Managementhandbuch) genauer behandelt werden. Der signifikanteste Unterschied ist wie zu erwartend die Architektur. Wenn Sie einen UNIX-Software-Channel erstellen, müssen Sie unbedingt die entsprechende Basis-Channel-Architektur auswählen.
Weiterhin empfiehlt Red Hat die Pakete in Basis- und Sub-Channels aufzuspalten. Beispielsweise sollten auf Solaris die Installationspakete in den Solaris-Basis-Channel kommen und Patches und Patch-Cluster in einen Sub-Channel des Solaris Basis-Channels. Extra-Installationspakete sollten in einen separaten Sub-Channel gelangen.
RHN behandelt Patches ähnlich wie Pakete; diese werden auf dieselbe Art und über dieselbe Oberfläche wie normale Pakete aufgelistet und installiert. Patches werden von Solaris 'nummeriert' und besitzen Namen wie z. B. "patch-solaris-108434". Die Version eines Solaris-Patch wird den original Solaris Metadaten entnommen, wobei das Release immer 1 ist.
Patch-Cluster sind ein Bündel von Patches, die als eine Einheit installiert werden. RHN beobachtet immer, wann das letzte mal ein Patch-Cluster auf einem System installiert worden ist. Diese erscheinen jedoch niemals in der Liste der auf dem System installierten Pakete, sogar nachdem diese installiert worden sind. Patch-Cluster-Namen lesen sich wie z. B. "patch-cluster-solaris-7_Recommended". Die Version ist eine Datumszeichenfolge wie beispielsweise "20040206", das Release ist immer 1 und der Zeitraum ist immer 0.

12.4.2.1. Hochladen der Pakete auf den Satellite

RHN liefert keinen UNIX-Inhalt; jedes Solaris-Paket, Patches oder Patch-Cluster müssen von einem Client-System auf den Satellite in einem Format hochgeladen werden, das dieser versteht. Das Paket kann anschließend verwaltet und an andere Systeme verteilt werden. RHN kreierte solaris2mpm um Solaris-Pakete, Patches und Patch-Cluster in ein Format zu übersetzen, das der Satellite verstehen kann.
12.4.2.1.1. solaris2mpm
Wie kurz in Abschnitt 12.1.4, »Unterschiede in der Funktionalität« erwähnt, ist solaris2mpm Teil von RHN Push für Solaris. Der Inhalt, der auf einen Solaris-Channel auf dem Satellite gepusht wird, muss zunächst im Format ".mpm" vorliegen.
Eine .mpm-Datei ist ein Archiv, das eine Beschreibung der Paketdaten, sowie des Pakets oder Patch selbst enthält. Der Befehl solaris2mpm muss auf dem Client ausgeführt werden, niemals auf dem Satellite.

Anmerkung

solaris2mpm benötigt den dreifachen Platz eines Paketes, Patches oder Patch-Clusters, das es konvertiert. Normalerweise wird der Platz in /tmp/ zu diesem Zweck verwendet. Mit der Option --tempdir kann jedoch ein anderes Verzeichnis angegeben werden, falls notwendig.
Mehrere Dateien können auf Kommandozeilenebene von solaris2mpm angegeben werden. Nachstehend finden Sie ein Anwendungsbeispiel: 
# solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm
Da kein anderes Verzeichnis angegeben wurde, werden die resultierenden .mpm-Dateien in das Verzeichnis /tmp/ geschrieben. Beachten Sie bitte, dass der Name der resultierenden .mpm-Dateien den Namen der Architektur des Clients, auf dem sie kreiert wurden, beinhaltet. In diesem Falls war dies Sparc Solaris. Das allgemeine Format von .mpm-Dateinamen ist: 
name-version-release.arch.mpm
Patch-Cluster sind "exploded" .mpm-Dateien, die für jeden Patch im Cluster generiert wurden. Weiterhin existiert eine "Meta"-.mpm-Datei auf höchster Ebene, die Informationen über das Cluster als Ganzes enthält.
Nachfolgend sind die Optionen von solaris2mpm aufgeführt:

Tabelle 12.2. solaris2mpm Optionen

Option Beschreibung
--version
Zeigt die Versionsnummer des Programms an und beendet sich
-h, --help
Zeigt diese Information an und beendet sich
-?, --usage
Gibt Informationen zur Verwendung des Programms an und beendet sich
--tempdir=<tempdir>
Temporäres Arbeitsverzeichnis
--select-arch=<arch>
Wählt die Architektur (i386 oder Sparc) für multi-arch-Pakete.
12.4.2.1.2. rhnpush mit .mpm-Dateien
Die Solarisversion von rhnpush funktioniert wie ein Standard-Hilfsprogramm mit der zusätzlichen Fähigkeit, mit .mpm-Dateien umzugehen. Nachfolgend ist ein Anwendungsbeispiel aufgeführt: 
% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \
RHATrpush-3.1.5-*.mpm
 Red Hat Network password:
 Connecting to http://testbox.example.com/APP
 Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm
 Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm

Anmerkung

Patch-Cluster .mpm-Dateien müssen entweder gleichzeitigt, oder nach — niemals vor — den .mpm-Dateien für die Patches, die in diesem Cluster enthalten sind, gepusht werden.
Verwenden Sie solaris2mpm bei jedem der Pakete, Patches oder Patch-Cluster, die Sie via Satellite verwalten möchten. Verwenden Sie anschließend RHN Push, um sie in den Channel hochzuladen, den Sie dafür kreiert haben.

12.4.2.2. Durch die Website aktualisieren

Um Pakete oder Patches auf einem individuellen System zu installieren, klicken Sie den Namen des Systems in der Systeme-Kategorie, wählen die Pakete von den Upgrade- oder Installationslisten des Pakete-Reiters aus und klicken Ausgewählte Pakete installieren/aktualisieren.
Um während der Installation einen Remote-Befehl auszuführen, klicken Sie auf Remote-Befehl ausführen und nicht auf Bestätigen. Siehe Abschnitt 12.5, »Remote-Befehle« für Instruktionen diesbezüglich.
Um Pakete oder Patches auf mehreren Systemen auf einmal zu installieren, wählen Sie die Systeme aus und klicken Sie System-Set-Manager in der linken Navigationsleiste. Auf dem Pakete-Reiter wählen Sie dann die Pakete von den Upgrade- oder Installationslisten aus und klicken Pakete installieren/aktualisieren. Schlussendlich planen Sie die Updates ein.

12.4.2.3. rhnsd

Auf Red Hat Enterprise Linux-Systemen startet der rhnsd-Daemon, der die Client-Systeme anweist, sich bei RHN anzumelden, automatisch zum Zeitpunkt des Bootens. Auf Solaris-Systemen startet der rhnsd standardmäßig nicht automatisch zum Zeitpunkt des Bootens. Er kann wie folgt von der Kommandozeile aus gestartet werden: 
rhnsd --foreground --interval=240
Der standardmäßige Ort für den rhnsd ist /opt/redhat/rhn/solaris/usr/sbin/rhnsd. Nachfolgend sind die verfügbaren Optionen für den rhnsd unter Solaris aufgeführt:

Tabelle 12.3. rhnsd Optionen

Option Beschreibung
-f, --foreground
Im Vordergrund laufen
-i, --interval=MINS
Alle MINS Minuten mit dem Red Hat Network verbinden
-v, --verbose
Alle Aktionen im Syslog protokollieren
-h, --help
Diese Hilfeliste anbieten
-u, --usage
Diese Hilfeliste anbieten
-V, --version
Programmversion ausgeben

12.4.2.4. Von der Befehlszeile aus aktualisieren

Wie die Website ist auch die Anwendung des Red Hat Update Agent mittels Befehlszeile von den Einschränkungen des UNIX-Paketmanagement betroffen. Die meisten Kernfunktionen können jedoch immer noch mithilfe des up2date-Befehls durchgeführt werden. Der signifikanteste Unterschied ist das Fehlen aller Optionen in Bezug auf Quelldateien. Siehe Tabelle 12.4, »Update Agent Befehlszeilen-Argumente« für eine genaue Liste an Optionen, die für UNIX-Systeme zur Verfügung stehen.
Die Befehlszeilenversion des Red Hat Update Agent akzeptiert folgende Argumente auf UNIX-Systemen:

Tabelle 12.4. Update Agent Befehlszeilen-Argumente

Argument Beschreibung
--version Zeige Information zu Programmversion.
-h, --help Zeige Hilfe-Text und beende.
-v, --verbose Zeige zusätzlichen Output.
-l, --list Liste die neueste Version aller installierten Pakete.
-p, --packages Aktualisiere Pakete in Zusammenhang mit diesem System-Profil.
--hardware Aktualiesiere das Hardware-Profil dieses Systems auf RHN.
--showall Liste alle zum Herunterladen verfügbaren Pakete.
--show-available Liste alle verfügbaren Pakete, die derzeit nicht installiert sind.
--show-orphans Liste alle derzeit installierten Pakete, die sich nicht in Channels befinden, für welche das System derzeit angemeldet ist.
--show-channels Zeige die Channel-Namen gemeinsam mit den Paketnamen.
--installall Installiere alle verfügbaren Pakete. Verwende mit der --channel-Option.
--channel=CHANNEL Geben Sie an, von welchen Channels unter Verwendung von Channel-Labels aktualisiert werden soll.
--get Rufen Sie das festgelegte Paket ab, ohne dabei Abhängigkeiten aufzulösen.