Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Channel-Managementhandbuch

Red Hat Network Satellite 5.4

Red Hat Network Satellite

Ausgabe 1

Zusammenfassung

Willkommen beim Red Hat Network Satellite Channel-Managementhandbuch.

Kapitel 1. Einführung

Dieses Dokument behandelt den Einsatz und die Verwaltung von maßgeschneiderten Software-Channels für den RHN Proxy Server und den RHN Satellite Server. Es wird nach der Installation und Konfiguration des RHN Satellite Servers oder des RHN Proxy Servers verwendet.
In einigen Fällen verweist dieses Dokument auf Abläufe, die auf den Red Hat Network-Webservern stattfinden. Für Proxy-Kunden sind dies die zentralen Red Hat Network-Server unter https://rhn.redhat.com. Für Satellite-Kunden ist dies der RHN Satellite Server vor Ort.

Kapitel 2. Einführung in RHN-Channels

Ein Red Hat Network-Channel ist eine Sammlung von Software-Paketen. Channels helfen Ihnen beim Aussortieren von Paketen mithilfe von Regeln: ein Channel kann beispielsweise Pakete einer speziellen Red Hat-Distribution enthalten. Außerdem kann ein Channel Pakete für eine Applikation oder eine ganze Applikationsreihe enthalten. Benutzer können Channels auch für ihre eigenen Bedürfnisse anlegen, wobei beispielsweise ein Channel die Pakete für alle Laptops des Unternehmens enthält.

2.1. Basis-Channels und Sub-Channels

Es gibt zwei Arten von Channels: Basis-Channels (Basiskanäle) und Sub-Channels (Unterkanäle). Ein Basis-Channel besteht aus Paketen basierend auf einer spezifischen Architektur und einem Red Hat-Release. Ein Sub-Channel ist ein Channel in Verbindung mit einem Basis-Channel, enthält jedoch zusätzliche Pakete.
Ein System kann nur für einen einzigen Basis-Channel angemeldet sein. Ein System kann bei mehreren Sub-Channels des Basis-Channels angemeldet sein. Ein angemeldetes System kann nur diejenigen Pakete installieren oder aktualisieren, die durch dessen Red Hat Network-Channels erhältlich sind.
Wenn ein System bei Red Hat Network registriert wird, wird dieses bei einem Basis-Channel angemeldet, welcher der jeweiligen Red Hat Enterprise Linux-Version des Systems entspricht. Wenn ein System einmal registriert ist, kann dessen Standard-Basis-Channel auch auf einen privaten Basis-Channel auf der RHN-Website für einzelne Systeme umgeändert werden. Sie können auch Aktivierungsschlüssel anwenden, die in Verbindung mit einem angepassten Channel ("Custom-Channel") gebracht werden, sodass Systeme, die mit diesem Schlüssel registriert sind, automatisch mit dem angepassten Channel in Verbindung gebracht werden.
Auf der Red Hat Network-Website, wird eine Liste von allen Basis-Channels und deren Sub-Channels auf der Channels-Seite (befindet sich unter dem Reiter Channels auf der oberen Navigationsleiste) angezeigt. Indem Sie auf den Namen eines Channels klicken, wird die Seite Channel-Details geöffnet, welche eine Liste aller Pakete in diesem Channel mit Errata und allen damit in Verbindung stehenden Systemen anzeigt.

2.2. Channels abonnieren

Sie können Channels für Systeme auf folgende Arten abonnieren:
  • Anmeldung durch Aktivierungsschlüssel — Aufgrund der einfachen und raschen Handhabung von Aktivierungsschlüsseln sind diese das bevorzugte Verfahren bei der Registrierung von Systemen als Clients des RHN Proxy Servers oder des RHN Satellite Servers. Systeme, die unter Verwendung eines Aktivierungsschlüssels registriert wurden, sind bei allen Channels angemeldet, die mit diesem Aktivierungsschlüssel in Verbindung stehen. Werfen Sie einen Blick in den Red Hat Network Client Configuration Guide und den Red Hat Network Reference Guide für weitere Informationen zu Aktivierungsschlüsseln.
  • Installationsregistrierung — Wenn ein System ursprünglich entweder durch den Red Hat Update Agent oder den Red Hat Network Registration Client angemeldet wird, wird es automatisch dem Basis-Channel zugeordnet, welcher mit der Version von Red Hat Enterprise Linux auf dem System übereinstimmt. Wenn ein System einmal angemeldet ist, kann dessen standardmäßiger Basis-Channel auf der RHN-Website für einzelne Systeme in einen privaten Basis-Channel umgeändert werden. Alternativ dazu können Sie Aktivierungsschlüssel besitzen, die in Verbindung mit einem angepassten Channel gebracht werden, sodass Systeme, die mit diesem Schlüssel registriert werden, automatisch mit dem angepassten Channel in Verbindung gebracht werden. Werfen Sie einen Blick in das entsprechende Kapitel im RHN Referenzhandbuch für weitere Informationen zur Verwendung dieser Applikationen in Bezug auf Ihre Berechtigungsstufe (Management oder Provisioning).
  • Website-Abonnement — Es stehen unterschiedliche, spezielle Sub-Channels abhängig vom Basis-Channel des Systems zur Anmeldung zur Verfügung. Das System kann den Sub-Channel via RHN-Website abonnieren. Wenn Sie Ihre eigenen Basis-Channels erstellt haben, können Sie diesen angepassten Channels auch Systeme via Website neu zuordnen. Werfen Sie einen Blick in das Red Hat Network-Website-Kapitel des RHN Referenzhandbuchs für weitere Informationen über die Online-Anmeldung von Channels.

2.3. Channel-Verfügbarkeit

Es gibt viele Channels in Red Hat Network. Einige sind für alle Benutzer erhältlich, andere nur für Benutzer in einem bestimmten Unternehmen und wiederum andere nur, wenn Sie den Zugang zu diesen Channels erworben haben. Channels werden in folgende Hauptkategorien unterteilt:
  • Kostenpflichtige Service-Channels — Diese Channels sind dann erhältlich, wenn Sie den Zugang dazu direkt oder in Verbindung mit einer speziellen Red Hat-Lösung erworben haben. Red Hat Enterprise Linux ist beispielsweise ein bezahlter Service-Channel.
  • Angepasste Channels — Sie erzeugen diese Channels, um benutzerdefinierte Pakete zu verwalten. Diese Channels sind auch als private Channels bekannt und erscheinen nur bei der Organisation, von der sie erzeugt wurden. Kein anderer kann jemals auf diese Channels zugreifen.
Dieses Dokument konzentriert sich auf das Erstellen und Verwalten von angepassten Channels mit einem RHN Proxy Server oder auf einem RHN Satellite Server.

2.4. Tools, Repositorys und Verfahren

Bevor Sie mit dem Erstellen und Verwalten von Channels beginnen, beachten Sie bitte die Unterschiede zwischen den unterschiedlichen Tools und Repositorys, die Ihnen zur Verfügung stehen. Dies ist besonders wichtig, wenn Sie einen RHN Satellite Server und gleichzeitig einen RHN Proxy Server einsetzen, da dadurch die Dienstprogramme und verfügbaren Speicherplätze erhöht werden. Desweiteren bietet eine Proxy-Satellite-Kombination bestimmte optimale Verfahrensweisen für eine optimale Leistung.
Machen Sie sich zuerst mit diesen Paketmanagement-Tools vertraut:
  • RHN Package Manager - Verwenden Sie den Paketmanager, um angepasste Pakete in angepasste Channels auf Ihrem RHN Proxy Server zu pushen.
  • RHN Push - Verwenden Sie diese Applikation, um angepasste Pakete in angepasste Channels auf Ihrem RHN Satellite Server zu pushen.
  • RHN Satellite Synchronization Tool - Wird zum Importieren von Standard-Paketen von Red Hat Network auf Ihren RHN Satellite Server und zum Synchronisieren mit Red Hat Network verwendet. Dies geschieht über das Internet oder via CD-ROM.
Jedes dieser Tools besitzt ein entsprechendes Paket-Repository. Sowohl RHN Package Manager, als auch RHN Push erfordern das Erstellen eines temporären Arbeitsverzeichnisses, um angepasste Pakete, die auf den Proxy oder Satellite hochgeladen werden, platzieren zu können. Nach Gebrauch müssen Sie diese Arbeitsverzeichnisse löschen.

Anmerkung

Red Hat empfiehlt, dass Sie Ihre angepassten Pakete außerhalb vom Red Hat Network archivieren.
Wenn Sie sowohl einen RHN Proxy Server als auch einen RHN Satellite Server verwenden, dann wenden Sie nur RHN Push und RHN Satellite Synchronization Tool an. Die Proxy-Satellite-Kombination erfordert, dass angepasste Pakete und -Channels nur auf den Satellite hochgeladen werden. Von dort aus bezieht der Proxy die Pakete und verteilt diese an die Client-Systeme.

Kapitel 3. Erstellung von angepassten Paketen

Es gibt viele Dinge, die beim Erstellen von Software-Paketen schiefgehen können. 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 besprochen, warum RPM verwendet werden soll, wie Pakete für RHN erstellt werden sollten und wie Pakete richtig signiert werden können.

3.1. Pakete für Red Hat Network erstellen

Red Hat Network verwendet die RPM Paketmanager (RPM) Technologie, um festzustellen, welche Software-Zusätze 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 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 freigibt, müssen Benutzer nicht erst wieder 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.
Paket-Suchanfrage
RPM bietet Suchanfrage-Optionen, 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 in Verbindung mit einem Paket 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 Designmerkmal von RPM ist die Möglichkeit der Verwendung unverfälschter Software-Quellen, wie Sie von den ursprünglichen Autoren ausgeliefert 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 freigegeben wird, müssen Sie nicht unbedingt wieder ganz von vorne anfangen, um es kompilieren zu lassen. 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 soviel bedeutet, als dass kein manueller Eingriff während der Installation eines Pakets stattfinden kann. Wenn daher RPMs zur Verteilung durch Red Hat Network gebaut 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 des RPM zu besitzen, um Pakete richtig bauen zu können. Für nähere Information verweisen wir für den Anfang auf folgende Ressourcen:
  2. Wenn Sie eine RPM-Datei für einen Sub-Channel bauen, dann erstellen Sie das Paket auf einer 'frischen' Installation von Red Hat Enterprise Linux mit derselben Version, wie der Basis-Channel die 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 ist, 1 das Release ist und i386 die Architektur ist.
  5. Das RPM-Paket sollte vom Maintainer des Pakets signiert werden. Nicht signierte Pakete können zwar durch Red Hat Network verteilt werden, jedoch muss der Red Hat Update Agent (up2date) 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 besprochen.
  6. Wenn die Version in irgendeiner Form verändert wird, inklusive Änderung der Signatur oder ein Neukompilieren, 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, außer es besteht ein zwingender Grund dazu.
  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 auch 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.

3.2. Digitale Signaturen für RHN-Pakete

Alle Pakete, die durch RHN verteilt werden, sollten eine digitale Signatur besitzen. Diese besteht aus einem einzigartigen, privaten Schlüssel und kann mit dem korrespondierenden, öffentlichen Schlüssel verifiziert werden. Nachdem ein Paket erstellt wurde, können die SRPM (Source-RPM) und die RPM-Pakete digital mit einem GnuPG-Schlüssel signiert werden. Bevor das Paket installiert wird, wird mithilfe des öffentlichen Schlüssels festgestellt, ob das Paket von einer vertrauenswürdigen Partei signiert wurde und in der Zwischenzeit auch nicht verändert wurde.

3.2.1. Ein GnuPG-Schlüsselpaar generieren

Ein GnuPG-Schlüsselpaar besteht aus privaten und öffentlichen Schlüsseln. Um ein Schlüsselpaar zu generieren, geben Sie folgenden Befehl als 'root' in einem Shell-Prompt ein: 
gpg --gen-key
Wenn Sie diesen Befehl nicht als Root-Benutzer ausführen, erhalten Sie folgende Mitteilung: 
gpg: Warning: using insecure memory!
Diese Mitteilung erscheint, da Nicht-Root-Benutzer keine Speicherseiten sperren können. Da Sie Ihren privaten GnuPG-Schlüssel oder Zugangscode geheim halten möchten, generieren Sie das Schlüsselpaar als 'root'. Der Root-Benutzer kann Speicherseiten sperren, was bedeutet, dass die Information nie auf Festplatte gespeichert wird.
Nachdem Sie den Befehl zur Generierung des Schlüsselpaares ausgeführt haben, sehen Sie einen Einführungsbildschirm mit Schlüsseloptionen ähnlich der folgenden: 
	gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software
	Foundation, Inc.  This program comes with ABSOLUTELY NO
	WARRANTY. This is free software, and you are welcome to
	redistribute it under certain conditions. See the file COPYING
	for details. Please select what kind of key you want: (1) DSA
	and ElGamal (default) (2) DSA (sign only) (4) RSA (sign only)
	Your selection?
Akzeptieren Sie die Standard-Option: (1) DSA und ElGamal. Diese Option ermöglicht es Ihnen, eine digitale Signatur zu erstellen und die Ver-/Entschlüsselung mit zwei verschiedenen Technologien. Tippen Sie 1 und drücken die Enter-Taste.
Wählen Sie als nächstes die Schlüsselgröße aus, welche die Länge des Schlüssels festlegt. Je länger der Schlüssel, desto sicherer sind Ihre Mitteilungen gegenüber Angriffen. Wir empfehlen hierbei mindestens 1024 Bits.
Im Rahmen der nächsten Option werden Sie nach der Gültigkeitsdauer Ihres Schlüssels gefragt. Wenn Sie sich für ein Ablaufdatum entscheiden, dann müssen Sie auch jeden darüber informieren, der Ihren öffentlichen Schlüssel verwendet und nach Ablauf mit einem neuen Schlüssel versorgen. Es wird empfohlen, dass Sie kein Ablaufdatum eingeben. Wenn Sie kein Ablaufdatum eingeben, dann werden Sie nochmals nach einer Bestätigung gefragt: 
Key does not expire at all Is this correct (y/n)?
Drücken Sie y, um Ihre Entscheidung zu bestätigen.
Als Nächstes müssen Sie eine Benutzer-ID mit Ihrem Namen, Ihrer E-Mail-Adresse und einem optionalen Kommentar eingeben. Diese Informationen werden einzeln abgefragt. Wenn Sie damit fertig sind, erhalten Sie ein Zusammenfassung der von Ihnen zur Verfügung gestellten Information.
Geben Sie ein Passwort ein, nachdem Sie Ihre Auswahl getroffen haben.

Anmerkung

Wie bei Ihren Account-Passwörtern ist eine gutes Passwort essentiell für ein optimales GnuPG-Sicherheitsverfahren. Ihr Passwort sollte aus Groß- und Kleinbuchstaben, Zahlen und/oder Satzzeichen bestehen.
Wenn Sie Ihren Zugangscode einmal eingegeben und überprüft haben, werden Ihre Schlüssel generiert. Es erscheint eine Meldung ähnlich der folgenden: 
We need to generate a lot of random bytes. It is a good idea to perform some
other action (type on the keyboard, move the mouse, utilize the disks) 
during the prime generation; this gives the random number generator a 
better chance to gain enough entropy. 

+++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++ +++.
++++++++++++++++++++++++++++++++++++++..........................++++
Sobald die Aktivität auf dem Bildschirm stoppt, befinden sich Ihre neuen Schlüssel im .gnupg-Verzeichnis im Stammverzeichnis von 'root', da Sie den Befehl als 'root' ausgeführt haben. Um Ihre 'root'-Schlüssel aufzulisten, geben Sie folgenden Befehl ein: 
gpg --list-keys
Sie erhalten etwa folgende Ausgabe: 
/root/.gnupg/pubring.gpg ----------------  pub 1024D/B7085C8A 2002-02-18
 Your Name<you@example.com> 
sub 1024g/E12AF9C4 2002-02-18
Um Ihren öffentlichen Schlüssel abzufragen, verwenden Sie folgenden Befehl: 
gpg --export -a 'Your Name' > public_key.txt
Ihr öffentlicher Schlüssel wird in die Datei public_key.txt geschrieben.
Dieser öffentliche Schlüssel ist sehr wichtig. Es handelt sich nämlich dabei um den Schlüssel, der an alle Client-Systeme verteilt werden muss, die angepasste Software via up2date erhalten. Wie dieser Schlüssel eingesetzt werden kann, wird ausführlich im Red Hat Network-Client-Konfigurationshandbuch behandelt.

3.2.2. Pakete signieren

Bevor Sie Pakete signieren können, müssen Sie Ihre ~/.rpmmacros-Datei konfigurieren, sodass diese Folgendes beinhaltet: 
%_signature gpg 
%_gpg_name B7085C8A
Ersetzen Sie den _gpg_name-Schlüssel-ID-Wert von B7085C8A durch die Schlüssel-ID Ihres GPG-Schlüsselrings, den Sie zum Signieren von Paketen verwenden. Dieser Wert teilt RPM mit, welche Signatur verwendet werden soll.
Um das Paket package-name-1.0-1.noarch.rpm zu signieren, verwenden Sie folgenden Befehl: 
rpm --resign package-name-1.0-1.noarch.rpm
Geben Sie Ihr Passwort ein. Um sicherzugehen, dass das Paket signiert ist, verwenden Sie folgenden Befehl: 
rpm --checksig -v package-name-1.0-1.noarch.rpm
Es sollte daraufhin Good signature from "Ihr Name" ausgegeben werden, wobei Ihr Name durch den Namen ersetzt wird, der mit dem jeweiligen Schlüssel verknüpft ist.

Kapitel 4. Verwaltung von angepassten Channels und Paketen

Angepasste Channels ("Custom-Channels") ermöglichen es Administratoren, die Red Hat Network-Infrastruktur für den Einsatz von Paketen zu verwenden, die von ihren Organisationen gebaut und gepflegt werden. Alle Channel- und Paket-Managementaktivitäten erfolgen im Channel-Reiter der RHN-Website. Die hier angeführten Instruktionen stehen in Zusammenhang mit dem RHN-Website-Kapitel im RHN-Referenzhandbuch.

Anmerkung

Aufgrund der potenziellen Probleme, die aus dem Einsatz ungetesteter Pakete in Ihrer gesamten Produktionsumgebung entstehen können, empfiehlt Red Hat dringend das Erstellen von Beta-Channels, die ausgewählte Systeme abdecken und die zum Staging verwendet werden können.
Wenn Sie beispielsweise eine Systemgruppe von Webservern besitzen, die einen Satz an angepassten Paketen erhält, erstellen Sie temporäre Channels, um die Pakete auf einem nicht-kritischen Teil repräsentativer Systeme vorläufig zu installieren. Dies können Entwicklungs- oder Staging-Server sein, jedoch nicht Live-Produktionssysteme. Diese temporären Channels werden dann mittels der in Abschnitt 4.8, »Software-Channels löschen« beschriebenen Schritte gelöscht.

4.1. Channel-Management-Privilegien

Um Channel-Management-Aufgaben durchzuführen, müssen Benutzer die notwendigen Berechtigungen als Channel-Administrator besitzen. Diese Berechtigungen können auf der Red Hat Network-Website modifiziert werden. Berechtigungen werden an Benutzer durch einen Organization Administrator vergeben, die der höchsten Admin-Stufe angehören. Channel-Administratorprivilegien werden wie folgt vergeben:
  1. Melden Sie sich auf der Red Hat Network-Website als Organization Administrator an.
  2. Auf der oberen Navigationsleiste klicken Sie auf den Benutzer-Reiter und dann auf den Namen des Benutzers, der Channel-Management-Funktionen ausübt.
  3. Auf der Benutzer-Details-Seite verschieben Sie den Fensterinhalt nach oben, bis Sie zum Abschnitt Rollen gelangen und markieren Sie das Auswahlkästchen Channel-Administrator. Klicken Sie dann auf Abschicken am unteren Ende der Seite. Beachten Sie dabei, dass ein Organization Administrator von vornherein Channel-Administrationsprivilegien besitzt.
  4. Der Benutzer sollte sich anschließend auf der Red Hat Network-Website anmelden, auf den Channel-Reiter auf der oberen Navigationsleiste klicken und sicherstellen, dass die Schaltfläche Software-Channel verwalten auf der entsprechenden linken Navigationsleiste erscheint.

4.2. Software-Channel verwalten

Zusätzlich zu den Schaltflächen und Seiten, die den RHN Management-Level-Standardbenutzern zur Verfügung stehen, haben RHN Satellite Server und RHN Proxy Server-Kunden auch Zugang zur Schaltfläche Software-Channels verwalten auf der linken Navigationsleiste. Diese Schaltfläche öffnet die Software-Channel-Management-Oberfläche, auf der das gesamte Management der angepassten Software-Channels stattfindet.

Warnung

Wenn Sie RHN Proxy Server und gleichzeitig auch RHN Satellite Server verwenden, verwalten Sie alle angepassten Channels und Pakete nur auf dem Satellite, da die Proxy-Server die Updates direkt von dort erhalten. Bei der manuellen Verwaltung von Paketen und Channels auf einem Proxy in dieser speziellen Konfiguration riskieren Sie, dass Sie Ihre Server nicht mehr synchron halten können.
Durch das Anklicken der Links innerhalb der Software-Channel-Management-Liste gelangen Sie auf unterschiedliche Reiter der Seite Verwaltete Software-Channel-Details. Durch das Klicken auf einen Channel-Namen wird der Reiter Details geöffnet, wohingegen das Anklicken der Anzahl der Pakete den Auflisten/Entfernen-Unterreiter des Pakete-Reiters öffnet. Werfen Sie einen Blick auf Abschnitt 4.3, »Software-Channel-Details verwalten« für eine detailliertere Beschreibung dieser Bereiche.

4.3. Software-Channel-Details verwalten

Es werden nahezu alle Aufgaben für das Management von angepassten Channels im Rahmen der Seite Verwaltete Software-Channel-Details ausgeführt, indem Sie auf Software-Channels verwalten auf der linken Navigationsleiste klicken und dann den Namen des zu verändernden Channels aussuchen. Diese Seite besteht aus zwei Hauptreitern: Details und Pakete.
  • Details — Dieser Reiter bietet Basisinformationen zum Channel, wie beispielsweise dessen übergeordneten Channel, den Namen, eine Zusammenfassung und eine Beschreibung. Einige dieser Informationen können verändert werden. Zusätzlich dazu sehen Organization Administratoren und Channel-Administratoren ein Auswahlkästchen Global abonnierbar. Dieses kennzeichnet das Standardverhalten eines jeden Channels, der jedem Benutzer erlaubt, Systeme dort anzumelden. Das Deselektieren dieses Kästchens und das Klicken auf Channel aktualisieren führt dazu, dass der Reiter Abonnenten erscheint, welcher dazu benutzt wird, bestimmten Benutzern Berechtigungen für den Channel zu erteilen.
  • Abonnenten — Zeigt eine Liste von Benutzern an, die Abonnement-Berechtigungen für den angepassten Channel besitzen. Dieser Reiter erscheint, wenn zwei Bedingungen erfüllt werden. Erstens muss der eingeloggte Benutzer ein Organization Administrator oder ein Channel-Administrator sein. Zweitens darf das Global abonnierbar-Auswahlkästchen auf dem Details-Reiter nicht markiert sein. Wählen Sie auf diesem Reiter die Auswahlkästchen der Benutzer aus, welche Berechtigungen zur Anmeldung von Systemen bei diesem Channel erhalten sollen und klicken Sie auf Aktualisieren. Beachten Sie bitte, dass Organization Administratoren und Channel-Administratoren automatisch Abonnementzugang zu allen Channels besitzen.
  • Manager — Listet Benutzer mit Management-Berechtigungen für den angepassten Channel auf. Dieser Reiter erscheint für Organization Administratoren und Channel-Administratoren. Wählen Sie die Auswahlkästchen der Benutzer aus, denen eine umfassende Administration dieses Channels ermöglicht werden soll und klicken Sie anschließend auf die Schaltfläche Update. Dieser Status berechtigt den Benutzer jedoch nicht zur Erzeugung eines neuen Channels. Beachten Sie bitte, dass Organization Administratoren und Channel-Administratoren automatisch Abonnementzugang zu allen Channels besitzen.
  • Errata — Zeigt die Errata in Verbindung mit jedem einzelnen Ihrer angepassten Channels an. Genauso wie Red Hat Network Errata-Updates für Red Hat Enterprise Linux-Software produziert und liefert, so liefern Sie Errata-Updates an Ihre angepassten Channels als Teil der Aktualisierung Ihrer Server mit dem neuesten Code. Dieser Reiter beinhaltet Unterreiter, welche es Ihnen ermöglichen, ein Erratum anzusehen, hinzuzufügen, zu entfernen und zu klonen: Auflisten/Entfernen, Hinzufügen und Klonen. Beachten Sie bitte, dass das Klonen von Errata nur via RHN Satellite Server erfolgen kann.
    • Auflisten/Entfernen — Zeigt sämtliche Errata an, die aktuell mit dem angepassten Channel in Verbindung stehen und macht es möglich, diese Verbindung aufzuheben. Um Errata vom Channel zu entfernen, wählen Sie deren Auswahlkästchen aus und klicken Sie auf Errata entfernen ganz unten rechts auf der Seite. Es erscheint eine Bestätigungsseite mit einer Liste der zu entfernenden Errata. Klicken Sie auf Bestätigen, um den Vorgang abzuschließen.
    • Hinzufügen — Ermöglicht das Hinzufügen von Errata zum Channel. Alle Errata, die möglicherweise auf den Channel anwendbar sind, sind aufgelistet. Um Errata zum Channel hinzuzufügen, wählen Sie die entsprechenden Auswahlkästchen aus und klicken Sie auf Errata hinzufügen. Werfen Sie einen Blick auf Kapitel 5, Verwaltung von angepassten Errata zum Thema Errata-Verwaltung.
    • Klonen — Ermöglicht es Satellite-Kunden, Errata und dazugehörige Pakete für einen geklonten Channel zu replizieren. Dieser Unterreiter erscheint sofort als verfügbar für Channels, die entweder mit dem ursprünglichen Status oder mit ausgewählten Errata geklont wurden. Der Klonen-Reiter bekommt auch immer Errata hinzu, wenn diese für den Ziel-Channel (also den ursprünglichen Channel) freigegeben werden. Dadurch ist dieser Reiter auch sehr nützlich für Channels, die mit der 'aktueller Status'-Option geklont wurden. Werfen Sie einen Blick auf Abschnitt 4.7, »Software-Channels klonen« für weitere Informationen über Optionen beim Klonen.
      Um Errata vom Ziel-Channel in den geklonten Channel aufzunehmen, wählen Sie entweder Zusammenführen oder Klonen aus dem Dropdown-Menü eines jeden Advisorys. Die Zusammenführen-Option ist nur dann möglich, wenn das Erratum zuvor geklont wurde. Diese Option sollte zum Zuordnen/Verknüpfen von Errata quer durch alle Channel verwendet, wobei doppelte Einträge vermieden werden können. Verwenden Sie die Klonen-Option, um einen neuen Eintrag zu erstellen.
      Standardmäßig übernehmen geklonte Errata das Label des originalen Red Hat-Advisorys, wobei das vorangestellte "RH" durch "CL" ersetzt wird. Beispielsweise wird RHSA-2003:324 zu CLSA-2003:324. Nachfolgende Klons desselben Advisorys tragen den zweiten Buchstaben in aufsteigender Reihenfolge, wie z.B. "CM" und "CN". Diese Labels können auf der Seite Verwaltete Errata-Details abgeändert werden. Werfen Sie einen Blick auf Abschnitt 5.2, »Verwaltete Errata-Details« für Instruktionen.
      Zusätzlich zur Option Zusammenführen enthalten zuvor geklonte Errata Werte in der Spalte Errata-Bestand. Das Erratum-Label verlinkt zur Details-Seite. Die pub und mod Flags innerhalb der Klammern zeigen an, ob das geklonte Erratum veröffentlicht oder vom ursprünglichen Advisory verändert worden ist. Ein Plus-Zeichen + vor dem Flag bestätigt, dass die geklonten Errata veröffentlicht wurden. Minus - bedeutet das Gegenteil. Beispielsweise bedeutet (-mod), dass ein Paket gelöscht wurde. Um mehr über das Veröffentlichen und Bearbeiten von angepassten Errata zu erfahren, werfen Sie einen Blick auf Abschnitt 5.1, »Errata verwalten«.
      Um Errata vom geklonten Channel auszuschließen, wählen Sie Tue nichts aus dem Dropdown-Menü aus. Wenn Sie mit den Änderungen zufrieden sind, klicken Sie auf Errata klonen. Überprüfen Sie die bevorstehenden Änderungen auf der Bestätigungsseite und wenn Sie damit einverstanden sind, klicken Sie auf Errata aktualisieren.
    • Sync — Zeigt die Errata-Pakete, die nicht im ursprünglichen Channel-Klon enthalten waren, seitdem jedoch aktualisiert wurden. Auf dieser Seite können Sie Ihre geklonten Channel mit aktuellen Errata synchronisieren, indem Sie das gewünschte Auswahlkästchen markieren und auf Errata syncen klicken.
  • Pakete — Enthält die Pakete in Zusammenhang mit jedem Ihrer angepassten Channels. Dieser Reiter enthält Unterreiter, die es Ihnen ermöglichen, Pakete anzusehen, hinzuzufügen und zu entfernen. Auflisten/Entfernen, Hinzufügen und Vergleichen.
    • Auflisten/Entfernen — Zeigt alle Pakete an, die aktuell mit dem angepassten Channel verknüpft sind und lässt Sie diese Verknüpfung auch entfernen. Um Pakete vom Channel zu entfernen, wählen Sie deren Auswahlkästchen aus und klicken Sie auf Pakete entfernen ganz rechts unten auf der Seite. Eine Bestätigungsseite erscheint mit einer Liste der zu entfernenden Pakete. Klicken Sie abschließend auf Bestätigen.

      Wichtig

      Diese Liste unterscheidet sich von der Paketliste, die Sie mittels der Standardseite Software-Channel-Details erhalten, indem alle Versionen eines in der Datenbank verbleibenden Pakets aufgelistet werden und nicht nur die neueste Version. Sie können zu einer vorherigen Version eines Pakets zurückkehren, indem Sie einfach die neueste Version entfernen.
    • Hinzufügen — Ermöglicht das Hinzufügen von Paketen zum Channel. Um verfügbare Pakete anzuzeigen, wählen Sie eine Option des Ansicht-Dropdown-Menüs aus und klicken auf Ansicht. Um Pakete zu dem bearbeiteten Channel hinzuzufügen, wählen Sie die entsprechenden Auswahlkästchen aus und klicken Sie auf Pakete hinzufügen. Werfen Sie einen Blick auf Abschnitt 4.6, »Pakete zu Software-Channels hinzufügen« für eine Erläuterung dieses Vorgangs.
    • Vergleichen — Ermöglicht den Vergleich von Paketlisten auf unterschiedlichen Channeln. Um die Unterschiede sehen zu können, wählen Sie einen anderen Channel aus dem Vergleiche mit:-Dropdown-Menü und klicken Sie auf Vergleichen. Es erscheint eine Liste von Paketen, die nicht auf beiden Channeln gleichzeitig vorkommen. Dabei wird jeweils angegeben, in welchem Channel sich das jeweilige Paket befindet.

4.4. Software-Pakete verwalten

Sie haben zusätzlich zum Hinzufügen und Entfernen von Paketen in Channels ebenso die Möglichkeit, Pakete aus der Datenbank und dem Dateisystem zu löschen. Das Entfernen vom Dateisystem ist um ungefähr eine Stunde verzögert. Dies kann mittels der Software-Paket-Management-Seite geschehen, auf welche Sie durch das Anklicken von Software-Pakete verwalten auf der linken Navigationsleiste gelangen.

Warnung

Obwohl das Löschen von Paketen von der Datenbank wieder rückgängig gemacht werden kann, indem Sie diese wieder hochladen, verlieren diese dabei ihre Verknüpfungen mit jeglichen Errata. Nach dem Hochladen müssen sie manuell wieder mit den Errata verknüpft werden. Werfen Sie einen Blick auf Kapitel 5, Verwaltung von angepassten Errata für nähere Instruktionen.
Um Pakete aus der Datenbank zu entfernen, wählen Sie auf der Seite Software-Paket-Management die entsprechende Option aus dem Ansicht-Dropdown-Menü aus und klicken auf Ansicht. Wählen Sie dann die entsprechenden Auswahlkästchen aus und klicken Sie auf Pakete löschen. Es erscheint eine Bestätigungsseite mit den aufgelisteten Paketen. Klicken Sie auf Bestätigen, um die Pakete vollständig zu löschen.
Da die eigentlichen Pakete auf dem RHN Proxy Server gespeichert werden, können die angepassten Pakete nicht mittels der RHN-Website heruntergeladen werden, auch wenn sie aufgelistet sind. Sie müssen vom Client-System unter Verwendung von up2date abgerufen werden. Da der RHN Satellite Server eine eigene Website besitzt, kann auf dessen angepasste Pakete via HTTP oder dem Red Hat Update Agent zugegriffen werden. Um angepasste Pakete zu erhalten, muss das Client-System bei dem Channel angemeldet sein, welcher die Pakete enthält.

4.5. Software-Channel anlegen

Vor dem Hochladen von Paketen auf den Server kann ein angepasster Channel zur Unterbringung derselben erstellt werden. Werfen Sie einen Blick auf Kapitel 6, Hochladen und Pflege von angepassten Paketen für Instruktionen. Sobald die Pakete hochgeladen wurden, können sie über die Website neu zugeordnet werden, wie in Abschnitt 4.6, »Pakete zu Software-Channels hinzufügen« näher beschrieben.

Anmerkung

Vergewissern Sie sich, dass Sie keine Sub-Channels erstellen, die Pakete enthalten, die mit den abonnierenden Client-Systemen nicht kompatibel sind.
Zudem sollten Ihre Sub-Channel keine Kopien von Inhalten des rhn-tools- oder rhel-virtualization-Channels enthalten, da anhand von bestimmten Paketen in diesen Channels diese Channels identifiziert werden, wenn mithilfe der Web-Oberfläche automatisch Channels für Systeme abonniert werden. Bei diesen Paketen handelt es sich um rhncfg (anhand dessen der rhn-tools-Channel identfiziert wird) und libvirt (anhand dessen der rhel-vt-Channel identifiziert wird).
Channels werden auf der Red Hat Network-Website wie folgt erstellt:
  1. Melden Sie sich auf der Red Hat Network-Website als Channel-Administrator an.
  2. Klicken Sie auf der oberen Navigationsleiste auf den Reiter Channel und danach auf die Schaltfläche Software-Channel verwalten in der linken Navigationsleiste.
  3. Klicken Sie auf der Seite Software-Channel-Management auf Neuen Software-Channel erstellen ganz oben rechts. RHN Satellite Server-Administratoren erhalten die Option Channel klonen. Werfen Sie einen Blick auf Abschnitt 4.7, »Software-Channels klonen« für weitere Informationen.
  4. Legen Sie auf der Seite Neuer Channel die Details für den Channel fest, indem Sie der Anleitung auf der Seite folgen. Für die meisten Channel-Management-Abläufe wird das Channel-Label dazu verwendet, den Channel zu kennzeichnen. Daher empfehlen wir, dass Sie ein Label aussuchen, welches eine bestimmte Bedeutung hat. Dazu sehen Sie sich am besten die Details bereits bestehender Channel an.
    Die GPG Key URL muss der Speicherort des Schlüssels auf dem Server sein, wie während des Konfigurationsprozesses des Clients festgelegt. Werfen Sie einen Blick in das Red Hat Network Client-Konfigurationshandbuch. Die GPG-Schlüssel-ID ist der eindeutige Identifikator, wie beispielsweise "DB42A60E", wohingegen der Fingerabdruck des GPG-Schlüssels so ähnlich aussieht wie "CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E". Beachten Sie dabei, dass die Schlüssel-ID dem letzten Paar von Vierbiteinheiten entspricht.
  5. Wenn Sie damit fertig sind, klicken Sie auf Channel erzeugen ganz unten auf der Seite.

4.6. Pakete zu Software-Channels hinzufügen

Wenn Pakete erstmalig hochgeladen werden, können sie einem angepassten Channel, mehreren angepassten Channels oder überhaupt keinem Channel zugeordnet werden. Werfen Sie einen Blick auf Kapitel 6, Hochladen und Pflege von angepassten Paketen für eine Anleitung diesbezüglich. Sobald die Pakete hochgeladen wurden, können Pakete über angepasste Channels hinweg sowie dem Repository 'Keine Channels' neu zugewiesen werden.
Sie erhalten diese Funktionen, indem Sie auf den Reiter Channel auf der oberen Navigationsleiste und dann auf Software-Channel verwalten auf der linken Navigationsleiste klicken. Auf der Seite Software-Channel-Management klicken Sie auf den Namen des Channels, um die Pakete zu erhalten.
Klicken Sie auf der Seite Verwaltete Software-Channel Details auf Pakete und anschließend auf den Hinzufügen-Unterreiter. Um Pakete dem Channel zuzuordnen, wählen Sie die entsprechende Option (welche nunmehr die Pakete enthält) aus dem Ansicht-Dropdown-Menü aus und klicken auf Ansicht. Pakete, die bereits mit dem Channel in Verbindung stehen, werden nicht mitaufgelistet. Pakete, die keinem spezifischen Channel zugeordnet sind, finden Sie unter dem Menüeintrag Pakete in keinen Channels. Wenn Sie Alle verwalteten Pakete auswählen, erhalten Sie alle verfügbaren Pakete.
Nachdem Sie auf Ansicht geklickt haben, erscheint die Paketliste für die ausgewählte Option. Der Seiten-Header zeigt noch immer den Channel an, der gerade bearbeitet wird. Wählen Sie in der Paketliste die Auswahlkästchen der Pakete aus, die dem zu bearbeitenden Channel zugeordnet werden müssen und klicken Sie dann auf Pakete hinzufügen ganz unten rechts auf der Seite. Es erscheint eine Bestätigungsseite mit den aufgelisteten Paketen. Klicken Sie auf Bestätigen, um die Pakete mit dem Channel in Verbindung zu bringen. Die neuen Pakete werden dann auf dem Auflisten/Entfernen-Unterreiter der Verwaltete Software-Channel Details-Seite aufgelistet.
Wenn Pakete einmal einem Channel zugeordnet sind, wird der Errata-Cache aktualisiert, um diese Änderungen wiederzugeben. Dieses Update ist zeitlich etwas verzögert, sodass Benutzer das Bearbeiten eines Channels beenden können, bevor alle Änderungen bereitgestellt werden. Um Ihre Änderungen manuell im Cache einzuführen, klicken Sie auf den Link Änderungen umgehend übernehmen innerhalb des Texts ganz oben auf dem Auflisten/Entfernen-Unterreiter.

4.7. Software-Channels klonen

RHN Satellite Server Channel-Administratoren können ebenso Software-Channels zur einfachen Paketzuordnung klonen. Durch das Klonen erhalten Sie eine komplette Nachbildung des Channels. Dies ermöglicht Ihnen, die entsprechenden Pakete und Errata umgehend mit einem Software-Channel zu verknüpfen. Diese Funktionalität finden Sie unter Channel auf der oberen Navigationsleiste und Software-Channel verwalten auf der linken Navigationsleiste. Dadurch gelangen Sie auf die Seite Software-Channel-Management. Um mit dem Klonen zu beginnen, klicken Sie auf Channel klonen ganz unten rechts.
Sie erhalten umgehend drei Kloning-Optionen: 'Aktueller Status des Channels', 'Ursprünglicher Status des Channels' oder 'Errata auswählen'. Diese Optionen werden ausführlich auf der Webseite selbst beschrieben, aber wie folgt zusammengefasst:
  • Aktueller Status des Channels — Alle Errata und alle neuesten Pakete, die sich jetzt im Ziel-Channel befinden.
  • Ursprünglicher Status des Channels — Alle originalen Pakete vom Ziel-Channel, aber keine Errata oder damit in Verbindung stehenden Pakete.
  • Errata auswählen — Alle originalen Pakete des Ziel-Channels und die Möglichkeit, bestimmte Errata und damit in Verbindung stehende Update-Pakete auszuschließen.
Wählen Sie die von Ihnen gewünschte Option mithilfe Auswahl-Buttons im Klonen-Feld, legen anschließend den Ziel-Channel fest, indem Sie das Klonen von-Dropdown-Menü auswählen und klicken auf Channel erzeugen.
Füllen Sie auf der Seite Neue Software-Channel die Felder aus, wie in Abschnitt 4.5, »Software-Channel anlegen« beschrieben. Die Standardwerte sind oft ausreichend. Wenn Sie zufrieden sind, klicken Sie auf Channel erstellen. Falls Sie entweder die ursprüngliche oder aktuelle Option ausgewählt haben, werden Sie an den Reiter Details der Seite Verwaltete Software-Channel-Details weitergeleitet, auf der Sie ggf. Einstellungen für den neuen Channel ändern können. Werfen Sie einen Blick auf Abschnitt 4.3, »Software-Channel-Details verwalten« für Instruktionen.
Wenn sie die Option zur Auswahl von Errata verwendet haben, gelangen Sie stattdessen zum Klonen-Unterreiter der Verwaltete Software-Channel Details-Seite, wo Sie individuell Errata und damit verknüpfte Software-Pakete für den neuen Channel auswählen können. Werfen Sie einen Blick auf Abschnitt 4.3, »Software-Channel-Details verwalten« für genauere Instruktionen.

4.8. Software-Channels löschen

RHN Satellite Server- und RHN Proxy Server-Administratoren können darüberhinaus unbenutzte Channels zu entfernen. Diese Aktion wird im Reiter Details der Option Verwaltete Software-Channel-Details einer Channel-Seite durchgeführt. Klicken Sie nach dem Öffnen dieses Reiters (wie detailliert in Abschnitt 4.3, »Software-Channel-Details verwalten« beschrieben) auf Software-Channel löschen in der rechten oberen Ecke der Seite, um den Channel und alle exklusiv damit verknüpfte Pakete komplett zu löschen. Klicken Sie auf der darauffolgenden Seite auf Channel löschen, um die Aktion abzuschließen.
Wenn Sie einen Channel mittels der Website entfernen, löschen Sie gleichzeitig alle Pakete, die mit diesem Channel in Verbindung stehen. Pakete, die aber auch mit anderen Channels in Verbindung stehen, sind nicht davon betroffen. Wenn Sie diesen Channel auf einem Proxy eingerichtet haben, der mit einem Satellite verbunden ist, dann müssen Sie den Channel auf dem RHN Proxy Server löschen.

Kapitel 5. Verwaltung von angepassten Errata

Angepasste Errata (Custom-Errata) ermöglichen es Ihnen, Errata-Meldungen für die Pakete in Ihren eigenen Channels auszugeben. Alle Errata-Management-Aktivitäten finden im Errata-Reiter der RHN-Website statt. Wir verweisen hierbei auch auf das RHN-Website Kapitel im Red Hat Network Reference Guide.

5.1. Errata verwalten

Zusätzlich zu den Schaltflächen und Seiten, die RHN Management-Level-Benutzern zur Verfügung stehen, haben RHN Satellite Server und RHN Proxy Server Kunden auch Zugang zu Errata verwalten in der linken Navigationsleiste. Diese Schaltfläche öffnet die Oberfläche Errata-Management, auf der alle angepassten Errata verwaltet werden.

Warnung

Wenn Sie RHN Proxy Server und auch RHN Satellite Server verwenden, dürfen Sie Errata nur auf dem Satellite verwalten, da die Proxy-Server Updates direkt vom Satellite erhalten. Das Verwalten von Errata auf einem Proxy bringt in dieser kombinierten Konfiguration das Risiko mit sich, dass Ihre Server nicht mehr synchron gehalten werden können.
Das Klicken auf ein Advisory in der Errata-Management-Liste führt Sie zum Details-Reiter der Seite Verwaltete Errata - Details. Werfen Sie einen Blick auf Abschnitt 5.2, »Verwaltete Errata-Details« für eine vollständige Erläuterung dieses Bereichs.

5.1.1. Veröffentlichte Errata

Die Seite Veröffentlichte Errata wird standardmäßig angezeigt, wenn Sie auf Errata verwalten in der linken Navigationsleiste klicken. Sie zeigt die Errata-Meldungen an, die von Ihrem Unternehmen erzeugt und verbreitet wurden.
Um bereits vorhandene veröffentlichte Errata zu bearbeiten, folgen Sie den in Abschnitt 5.3, »Errata erzeugen und bearbeiten« beschriebenen Schritten. Um die Errata zu verteilen, klicken Sie auf Benachrichtigung senden in der oberen rechten Ecke der Seite Errata-Details. Die Errata-Meldung wird an die Administratoren aller betroffenen Systeme versendet.

5.1.2. Unveröffentlichte Errata

Die Seite Unveröffentlichte Errata erscheint wenn Sie auf Unveröffentlicht unter Errata verwalten in der linken Navigationsleiste klicken. Hier werden die Errata-Meldungen angezeigt, die von Ihrem Unternehmen zwar erstellt, jedoch noch nicht versendet wurden.
Um vorhandene, noch nicht veröffentlichte Errata zu bearbeiten, folgen Sie den in Abschnitt 5.3, »Errata erzeugen und bearbeiten« beschriebenen Schritten. Um die Errata zu veröffentlichen, klicken Sie auf Errata veröffentlichen in der oberen rechten Ecke der Seite Errata-Details. Sie müssen dann bestätigen, welche Channels mit den Errata verknüpft werden sollen und auf die Schaltfläche Errata veröffentlichen - jetzt in der unteren rechten Ecke - klicken. Die Errata-Meldung wird auf die Seite Veröffentlicht verlagert und wartet auf die Verteilung.

5.2. Verwaltete Errata-Details

Wenn Sie auf das Advisory einer verwalteten Errata-Meldung auf den Seiten Veröffentlicht oder Unveröffentlicht klicken, erscheint die jeweilige Seite Verwaltete Errata-Details. Diese Seite ist wiederum in drei Reiter unterteilt: Details, Channels und Pakete.
  • Details — Bietet die Hauptinformationen, welche Sie beim Erstellen der angepassten Errata-Meldung eingegeben haben. Diese Informationen sind u.a. Zusammenfassung, Advisory-Name und -Art, zugehöriges Produkt, Bugs, Beschreibung, Lösung, Schlüsselwörter, Referenzen und Anmerkungen. Um irgendeine dieser Informationen zu ändern, führen Sie die Änderungen in den entsprechenden Feldern durch und klicken auf Errata aktualisieren.
  • Channels — Zeigt die Channels in Verbindung mit den ausgewählten Errata an. Um Änderungen an diesen Verknüpfungen durchzuführen, markieren oder entmarkieren Sie die entsprechenden Auswahlkästchen und klicken Sie auf die Schaltfläche Channels aktualisieren.
  • Pakete — Hier können Sie die Pakete in Verbindung mit den ausgewählten Errata verwalten. Dieser Reiter enthält zwei Unterreiter, auf denen Sie Pakete ansehen, hinzufügen und entfernen können: Auflisten/Entfernen und Hinzufügen.
    • Auflisten/Entfernen — Zeigt alle Pakete an, die derzeit mit den angepassten Errata in Verbindung stehen und lässt Sie diese Verknüpfung auch auflösen. Um Pakete von den Errata zu entfernen, wählen Sie deren Auswahlkästchen aus und klicken Sie auf Pakete entfernen ganz unten rechts auf der Seite. Es erscheint eine Bestätigungsseite, welche die zu entfernenden Pakete auflistet. Überprüfen Sie diese und klicken Sie auf Bestätigen.
    • Hinzufügen — Ermöglicht das Hinzufügen von Paketen zum Erratum. Um verfügbare Pakete anzeigen zu lassen, wählen Sie eine Option vom Ansicht-Dropdown-Menü aus und klicken auf Ansicht. Um Pakete zum Erratum hinzuzufügen, welches Sie gerade bearbeiten, wählen Sie die entsprechenden Auswahlkästchen aus und klicken auf Pakete hinzufügen. Werfen Sie einen Blick auf Abschnitt 5.4, »Den Errata Pakete zuweisen« für eine umfassende Beschreibung dieses Prozesses.

5.3. Errata erzeugen und bearbeiten

Wenden Sie dieses Verfahren an, um eine angepasste Errata-Meldung zu erzeugen.
  1. Klicken Sie auf der oberen Navigationsleiste auf Errata und dann auf Errata verwalten auf der linken Navigationsleiste. Auf der Errata-Management-Seite klicken Sie auf Neues Erratum erzeugen.
  2. Geben Sie eine aussagekräftige Bezeichnung für das Erratum in das Advisory-Feld ein. Im Idealfall folgen Sie dabei einer Namenskonvention Ihres Unternehmens. Beachten Sie bitte, dass dieses Label nicht mit den Buchstaben "RH" (Groß- oder Kleinschreibung) beginnen kann, sodass Errata, die von Red Hat herausgegeben worden sind, deutlich von angepassten Errata unterschieden werden können.
  3. Vervollständigen Sie dann alle verbleibenden erforderlichen Felder und klicken auf die Errata erzeugen-Schaltfläche. Sehen Sie sich Red Hat-Standard-Errata-Meldungen an, um ein Beispiel dafür zu erhalten, wie Felder richtig ausgefüllt werden.
RHN Satellite Server-Administratoren können darüberhinaus Errata erzeugen, indem Sie bereits bestehende Errata klonen. Auf diese Weise bleiben Verknüpfungen mit Paketen erhalten, was das Herausgeben der Errata vereinfacht. Werfen Sie einen Blick auf Abschnitt 5.5, »Errata klonen« für weitere Instruktionen.
Um die Details einer bestehenden Errata-Meldung zu bearbeiten, klicken Sie auf das entsprechende Advisory auf der Seite Errata-Management, führen Ihre Änderungen in den entsprechenden Feldern des Reiters Details durch und klicken auf die Schaltfläche Errata aktualisieren. Klicken Sie auf den Channel-Reiter, um die Channel-Verbindung der Errata zu verändern. Klicken Sie auf den Pakete-Reiter, um die dort befindlichen Pakete ansehen und modifizieren zu können.
Um Errata zu löschen, wählen Sie deren Auswahlkästchen auf der Seite Errata-Management aus, klicken auf Errata löschen und danach auf Bestätigen. Bitte beachten Sie dabei, dass das Löschen von veröffentlichten Errata ein paar Minuten dauern kann.

Anmerkung

Wenn Sie eine E-Mail-Benachrichtigung hinsichtlich Errata-Meldungen für Ihr System erhalten möchten, gehen Sie zu Ihr RHN => Ihre Präferenzen auf der RHN-Website und wählen E-Mail-Benachrichtigungen erhalten aus. Dies ist eine sehr nützliche Einrichtung für Administratoren von angemeldeten Systemen in Ihrem Unternehmen.

5.4. Den Errata Pakete zuweisen

Wenden Sie dieses Verfahren an, um Pakete zu Errata zuzuweisen.
  1. Nachdem Sie ein Erratum zur Bearbeitung ausgewählt haben, klicken Sie auf den Reiter Pakete und dann auf den Unterreiter Hinzufügen.
  2. Um Pakete mit diesem Erratum in Verbindung zu bringen, wählen Sie den Channel vom Ansicht-Dropdown-Menü aus, welcher die entsprechenden Pakete enthält und klicken auf Ansicht. Pakete, die bereits mit dem Erratum in Verbindung stehen, werden nicht angezeigt. Wenn Sie Alle verwalteten Pakete auswählen, werden alle verfügbaren Pakete angezeigt.
  3. Wenn Sie auf Ansicht klicken, erscheint die Paketliste für die ausgewählten Optionen. Beachten Sie bitte, dass im Seiten-Header noch immer die Errata aufgelistet sind, welche bearbeitet werden.
  4. Wählen Sie in der Liste die Auswahlkästchen der zuzuordnenden Pakete aus und klicken Sie auf Pakete hinzufügen ganz rechts unten auf der Seite.
  5. Es erscheint eine Bestätigungsseite, auf der die Pakete aufgelistet werden. Klicken Sie auf Bestätigen, um den Prozess abzuschließen. Der Auflisten/Entfernen-Unterreiter der Seite Verwaltete Errata Details erscheint mit den neuen Paketen.
Sobald Pakete einmal einem Erratum zugeordnet sind, wird der Errata-Cache aktualisiert, um diese Änderungen wiederzugeben. Dieses Update wird kurz verzögert, sodass Benutzern genügend Zeit gelassen wird, das Bearbeiten des Erratums abzuschließen. Um Ihre Änderungen manuell im Cache einzuführen, klicken Sie auf den Link Änderungen umgehend übernehmen ganz oben auf der Seite.

5.5. Errata klonen

Als Bestandteil von RHN Satellite Server können Sie Errata zur einfachen Nachbildung klonen. Es können nur Errata geklont werden, die potenziell für einen der Channel anwendbar sind. Ein Erratum kann für einen Channel anwendbar sein, wenn dieser Channel von einem Channel geklont worden ist, auf den das Erratum zutrifft. Diese Funktionalität erhalten Sie unter Errata auf der oberen Navigationsleiste und dann auf Errata klonen auf der linken Navigationsleiste. Dieser Button erscheint nur für RHN Satellite Server-Kunden.
Wählen Sie auf der Seite Errata klonen den Channel mit den Errata vom Ansicht-Dropdown-Menü aus und klicken Sie auf Ansicht. Sobald die Errata-Liste erscheint, wählen Sie das Auswahlkästchen des zu klonenden Erratums aus und klicken auf Errata klonen. Es erscheint eine Bestätigungsseite, auf der die Errata gelistet sind. Bestätigen Sie, um mit dem Klonen abzuschließen.
Die geklonten Errata erscheinen in Ihrer Liste unveröffentlichter Errata. Hier können Sie den Errata-Text und die Pakete in Zusammenhang mit diesen Errata nachprüfen. Wenn Sie einmal damit fertig sind, können Sie die Errata veröffentlichen und somit für alle Benutzer in Ihrem Unternehmen zugänglich machen.

Kapitel 6. Hochladen und Pflege von angepassten Paketen

Abhängig vom verwendeten Red Hat Network-Service gibt es zwei Verfahren zum Hochladen von Paketen auf private Channels.
RHN Proxy Server-Kunden verwenden die RHN Package Manager-Applikation, welche Paket-Header-Informationen an die zentralen Red Hat Network-Servern sendet und das Paket selbst im lokalen Repository des Proxys ablegt, welcher den RHN Package Manager aufgerufen hat.
RHN Satellite Server-Kunden verwenden die RHN Push-Applikation, welche Paket-Header-Informationen an den lokalen RHN Satellite Server sendet und das Paket im lokalen Repository des Satellite ablegt, welcher RHN Push aufgerufen hat.
Dieses Kapitel beschreibt beide Tools im Detail.

Warnung

Wenn Sie sowohl RHN Proxy Server als auch RHN Satellite Server verwenden, verwenden Sie nur RHN Push. Die Proxy-Satellite-Kombination erfordert, dass angepasste Pakete und Channels nur auf den Satellite hochgeladen werden. Von dort holen sich die Proxy-Server die Pakete und verteilen diese an die Client-Systeme.

6.1. Pakete auf den RHN Proxy Server hochladen

RHN Package Manager ermöglicht es einem Unternehmen, angepasste Pakete in Verbindung mit einem privaten RHN-Channel mittels RHN Proxy Server anzubieten. Wenn Sie möchten, dass der RHN Proxy Server nur offizielle Red Hat Enterprise Linux-Pakete anbietet, dann brauchen Sie den RHN Package Manager nicht zu installieren.
Um den RHN Package Manager verwenden zu können, installieren Sie das rhns-proxy-package-manager-RPM-Paket und alle abhängigen Pakete. Dieses Paket ist für registrierte RHN Proxy Server-Systeme erhältlich und wird mittels up2date rhns-proxy-package-manager installiert.

Anmerkung

Es wird nur die Header-Information für die Pakete auf die RHN-Server hochgeladen. Die Header werden für das Auflösen von Paketabhängigkeiten für die Client-Systeme durch RHN benötigt. Die eigentlichen Paketdateien (*.rpm) werden auf dem RHN Proxy Server gespeichert. Aus diesem Grund können angepasste Pakete nicht von der RHN-Website heruntergeladen werden, obwohl diese dort aufgelistet sind. Sie müssen vom Client-System mittels up2date abgerufen werden.

6.1.1. Den RHN Package Manager konfigurieren und verwenden

Bevor Sie den RHN Package Manager dazu verwenden können, Pakete zum RHN hochzuladen, müssen Sie die Pakete zuerst manuell auf den Proxy-Server selbst kopieren. Sie können beispielsweise von einem Entwicklungshost aus scp verwenden: 
scp foo.rpm root@rhnproxy.example.com:/tmp
Wenn Sie den RHN Package Manager dazu verwenden, die Pakete zum Red Hat Network hochzuladen, verweisen Sie auf die Dateien, die Sie zuvor auf den Server kopiert haben.

Anmerkung

Erstellen Sie zumindest einen privaten Channel, um angepasste Pakete vor dem Hochladen zum Red Hat Network zu erhalten, da ein Channel für Systeme notwendig ist, um die Pakete abfragen zu können.
Der folgende Befehl lädt die Paket-Header auf die RHN-Server hoch und kopiert die Pakete in das RHN Proxy Server-Repository: 
rhn_package_manager -c label_of_private_channelpkg-list
label_of_private_channel ist der angepasste Channel, der erstellt wurde, um diese Pakete abzurufen. Bitte achten Sie darauf, dass Sie genau das Channel-Label verwenden, welches bei der Erstellung festgelegt wurde. Wenn Sie einen oder mehrere Channel festgelegt haben (unter Verwendung von -c oder --channel), werden die hochgeladenen Paket-Header mit allen festgelegten Channeln verlinkt. Wenn Sie keinen Channel festlegen, dann werden die Pakete im Keine Channels-Abschnitt der Paket-Management-Seite abgelegt. Werfen Sie einen Blick auf Abschnitt 4.6, »Pakete zu Software-Channels hinzufügen« für Instruktionen, wie die Pakete neu zugeordnet werden können.
Die pkg-list-Referenz stellt die Liste von Paketen dar, die hochgeladen werden sollen. Diese Pakete müssen bereits tatsächlich auf den Proxy-Host kopiert worden sein. Sie können auch die -d-Option verwenden, um das lokale Verzeichnis festzulegen, welches die Pakete enthält, die zum Channel hinzugefügt werden sollen. Der RHN Package Manager kann die Paketliste auch von Standardeingabe lesen (mittels --stdin).
Andere Optionen werden in einer Konfigurationsdatei festgelegt, wie beispielsweise die Red Hat Network Server-URL, der HTTP-Proxy-Benutzername und das Passwort (wenn Ihr HTTP-Proxy Authentifizierung benötigt) und das Top-Verzeichnis, in welchem sich die Pakete befinden. Diese spezielle Konfiguration darf nicht bearbeitet werden und befindet sich in /etc/rhn/default/rhn_proxy_package_manager.conf. Sie können die Auswahl in dieser Standardkonfigurationsdatei entweder durch Einstellungen in der Haupt-Konfigurationsdatei /etc/rhn/rhn.conf außer Kraft setzen oder auch mittels Befehlszeilenoptionen, die Sie an den RHN Package Manager übergeben.
Parameter, die in dieser Datei nicht gesetzt sind, werden von .rhn_package_manager im Stammverzeichnis des aktuell angemeldeten Benutzers gelesen und abschließend von /etc/rhn/rhn_package_manager.conf. Überprüfen Sie, dass alle diese Dateien die entsprechenden Berechtigungen besitzen, sodass nicht jeder diese Dateien lesen kann.
Nachdem Sie die Pakete hochgeladen haben, überprüfen Sie, dass das lokale Verzeichnis mit dem RHN-Server-Image der Channels übereinstimmt: 
rhn_package_manager -s -c name_of_private_channel
Diese -s-Option listet alle fehlenden Pakete auf, die auf den RHN-Server hochgeladen wurden, sich jedoch nicht im lokalen Verzeichnis befinden. Sie müssen ein Organization Administrator sein, um diese Option verwenden zu können. Sie werden nach Ihrem RHN-Benutzernamen und -Passwort gefragt.
Die --copyonly-Option kopiert die im Parameter aufgelistete Datei in den spezifischen Channel, ohne sie auf den Satellite hochzuladen. Dies ist sehr nützlich, wenn einem Channel auf dem RHN Proxy Server ein Paket fehlt und Sie nicht alle Pakete neu importieren möchten. 
rhn_package_manager -c channel-name --copyonly /path/to/missing/file
Sie können den RHN Package Manager auch dazu verwenden, eine Liste von Paketen in einem Channel abzufragen, so wie diese vom RHN-Server gespeichert werden: 
rhn_package_manager -l -c name_of_private_channel
Die -l-Option listet den Paketnamen, die Versionsnummer, die Release-Nummer, die Architektur und den Channel-Namen für jedes Paket in den angegebenen Channels auf. Werfen Sie einen Blick auf Tabelle 6.1, »rhn_package_manager-Optionen« für zusätzliche Optionen.
Tabelle 6.1, »rhn_package_manager-Optionen« ist eine Zusammenfassung aller Befehlszeilenoptionen für den RHN Package Manager (rhn_package_manager):

Tabelle 6.1. rhn_package_manager-Optionen

Option Beschreibung
-v, --verbose Erhöht die Ausführlichkeit von Mitteilungen der Standardausgabe.
-d, --dir DIRECTORY_NAME Verarbeitet Pakete aus diesem Verzeichnis.
-c, --channel CHANNEL_NAME Legt den Channel fest, welcher Pakete erhalten soll. Mehrere Channels können angegeben werden, indem mehrmals die Option -c verwendet wird (z.B.: -c channel_one -c channel_two)
-n, --count NUMBER Verarbeitet diese Anzahl an Headern pro Aufruf — Standard ist 32.
-l, --list Listet die Pakete in den festgelegten Channeln/im festgelegten Channel auf.
-s, --sync Überprüft, ob das lokale Verzeichnis mit dem Server übereinstimmt.
-p, --printconf Druckt die aktuelle Konfiguration und beendet.
--newest Pusht lediglich diejenigen Pakete, die neuer sind als die Pakete auf dem Server. Dabei sollten Sie beachten, dass Source-Pakete dabei eine Ausnahme darstellen, da ihre Versionen niemals miteinander verglichen werden. Ihre 'Neuheit' oder Aktualität hängt jeweils von den zugehörigen Binärpaketen ab. Wenn Sie diese Option mit dem RHN Package Manager und nur einem Source-Paket anwenden, wird das Source-Paket zwar hochgeladen, erscheint aber nicht auf der RHN-Web-Oberfläche, bis das zugehörige Binärpaket hochgeladen wurde. Stellen Sie dies --source gegenüber. Wenn Sie --source --newest gemeinsam verwenden, dann wird das eigenständige Source-Paket mit neueren Paketen aktualisiert und es muss nicht zuerst ein Binärpaket hochgeladen werden.
--source Lädt die angezeigten Source-Pakete hoch. Dadurch werden diese als einfache, alleinstehende Pakete behandelt und nicht als spezielle Source-Pakete, die mit einem anderen, bereits bestehenden Binärpaket in Zusammenhang stehen. Sie können dies beispielsweise dazu verwenden, wenn Sie Applikations-Quellcode unter Entwicklern und Testern außerhalb des regulären Source-Control-Managements verteilen möchten.
--stdin Liest die Paketnamen von der Standardeingabe (stdin).
--nosig Bricht nicht ab, wenn Pakete nicht signiert sind.
--no-ssl Schaltet SSL ab (nicht empfehlenswert).
--stdin Liest die Paketnamen von der Standardeingabe (stdin).
--username USERNAME Gibt den RHN-Benutzernamen an. Wenn dieser nicht angegeben wird, werden Sie nach dem Benutzernamen eines gültigen Channel-Administrators gefragt.
--password PASSWORD Gibt das RHN-Passwort an. Wenn dieses nicht angegeben wird, werden Sie nach dem Passwort eines gültigen Channel-Administrators gefragt.
--dontcopy Kopiert die Pakete nach dem Hochladen nicht an die endgültige Stelle im Paketbaum.
--copyonly Kopiert Pakete lediglich und importiert sie nicht erneut.
--test Zeigt nur eine Liste der zu pushenden Pakete an.
-?, --help Zeigt den Hilfebildschirm mit einer Liste von Optionen an.
--usage Beschreibt kurz die verfügbaren Optionen.
--copyonly Kopiert nur Pakete

Anmerkung

Eine Beschreibung dieser Befehlszeilenoptionen finden Sie auch auf der Handbuchseite von rhn_package_manager: man rhn_package_manager.

6.2. Pakete auf den RHN Satellite Server hochladen

Die RHN Push-Applikation ermöglicht es Ihnen, angepasste Pakete in Verbindung mit einem privaten RHN-Channel durch den RHN Satellite Server anzubieten. Wenn Sie möchten, dass von Ihrem RHN Satellite Server nur offizielle Red Hat Enterprise Linux-Pakete angeboten werden, brauchen Sie RHN Push nicht zu installieren.
Um RHN Push verwenden zu können, müssen Sie das rhnpush-Paket und alle abhängigen Pakete installieren. Dieses Paket ist für alle registrierten RHN Satellite Server-Systeme erhältlich und wird mittels up2date rhnpush installiert.
RHN Push lädt RPM-Header-Information in die RHN Satellite Server-Datenbank und legt das RPM im RHN Satellite Server-Repository ab. Im Gegensatz zum RHN Package Manager des RHN Proxy Server, verteilt RHN Push niemals Paketinformationen, nicht einmal die Header, außerhalb der RHN Satellite Server-Datenbank.

Anmerkung

Wenn Ihre Satellite-Installation Solaris-Betriebssysteme unterstützt, dann können Sie RHN Push von einem Solaris-Client aus verwenden, um Solaris-Paketinhalte an angepasste Solaris-Channels zu verteilen.

6.2.1. RHN Push-Applikation konfigurieren

Wenn RHN Push installiert ist, wird eine zentrale Konfigurationsdatei in /etc/sysconfig/rhn/rhnpushrc installiert. Diese Datei beinhaltet Werte für alle Optionen, die in Tabelle 6.2, »rhnpush-Optionen« aufgeführt sind.
Diese jeweiligen Konfigurationsdateien sind nützlich beim Variieren Ihrer Einstellungen abhängig vom Verzeichnis, von dem aus der rhnpush-Befehl ausgeführt wird. Einstellungen im aktuellen Verzeichnis (./.rhnpushrc) haben Vorrang vor denen im Stammverzeichnis des Benutzers (~/.rhnpushrc), welche wiederum vor den Einstellungen in der zentralen Konfigurationsdatei (/etc/sysconfig/rhn/rhnpushrc) verwendet wird.
Sie können beispielsweise die Konfigurationsdatei des aktuellen Verzeichnisses dazu verwenden, um den Software-Channel zu bestimmen, die Konfigurationsdatei des Stammverzeichnisses, um den Benutzernamen festzulegen, der aufgerufen werden soll und die zentrale Konfigurationsdatei, um den Server zu bestimmen, der die Pakete erhalten soll.
Tabelle 6.2, »rhnpush-Optionen« beinhaltet alle Befehlszeilenoptionen für den rhnpush-Befehl:

Tabelle 6.2. rhnpush-Optionen

Option Beschreibung
-v --verbose Erhöht die Ausführlichkeit. Diese Option kann mehrmals verwendet werden, d.h. -vv, -vvv und so weiter.
-d, --dir DIRECTORY Verarbeitet Pakete aus diesem Verzeichnis.
-c, --channel CHANNEL_LABEL Legt den Channel fest, der die Pakete erhalten soll. Bitte beachten Sie, dass diese Information im Gegensatz zum Namen des Channels erforderlich ist. Mehrere Channels können angegeben werden, indem die Option -c mehrmals verwendet wird (z.B. -c=CHANNEL_ONE -c=CHANNEL_TWO).
-n, --count N_HEADERS_PER_CALL Verarbeitet diese Anzahl von Headern pro Aufruf. Muss eine Ganzzahl sein. Standardwert ist 25.
-l, --list Listet nur die angegebenen Channels.
-r, --reldirRELATIVE_DIRECTORY Verknüpft dieses relative Verzeichnis mit jeder Datei.
-o, --orgidORGANIZATION_ID Fügt die ID-Nummer Ihrer Organisation ein. Muss eine Ganzzahl sein.
-u , --username USERNAME Fügt den RHN-Benutzernamen des Benutzers mit administrativem Zugang zu den angegebenen Channels ein. Wenn Sie diesen nicht angeben, dann werden Sie von rhnpush zur Eingabe des Benutzernamens eines gültigen Channel-Administrators aufgefordert. Benutzername und Passwort werden in ~/.rhnpushcache für einen begrenzten Zeitraum zwischengespeichert. Fünf Minuten gelten hierbei als Standard. Verwenden Sie --new-cache, um einen neuen Benutzernamen und ein neues Passwort zu erzwingen.
-p , --password PASSWORD Fügt das RHN-Passwort des Benutzers mit administrativem Zugang zum angegebenen Channel ein. Ansonsten werden Sie von rhnpush zur Eingabe des Benutzernamens eines gültigen Channel-Administrators aufgefordert. Benutzername und Passwort werden in ~/.rhnpushcache für einen begrenzten Zeitraum zwischengespeichert. Fünf Minuten gelten hierbei als Standard. Verwenden Sie --new-cache, um einen neuen Benutzernamen und ein neues Passwort zu erzwingen.
-s, --stdin Liest die Paketliste von der Standardeingabe, beispielsweise von einem gepipten ls-Befehl.
-X, --exclude GLOB Schließt Pakete aus, die diesem Glob-Ausdruck entsprechen.
--force Erzwingt das Hochladen eines Pakets, auch wenn dieses Paket sich derzeit bereits im Channel befindet. Ohne diese Option wird beim Hochladen eines bereits bestehenden Pakets eine Fehlermeldung ausgegeben.
--nosig Bricht nicht ab, wenn Pakete nicht signiert sind.
--new-cache Zwingt RHN Push, einen neuen Benutzernamen und ein neues Passwort zu akzeptieren oder danach zu fragen. Dies ist sehr nützlich, wenn Sie beim ersten Mal einen Fehler beim Eintippen gemacht haben.
--newest Pusht nur die Pakete, die neuer sind, als die Pakete auf dem Server. Beachten Sie bitte, dass Source-Pakete dabei eine Ausnahme darstellen, da ihre Versionen niemals miteinander verglichen werden. Ihre Aktualität hängt von den damit in Verbindung stehenden Binärpaketen ab. Wenn Sie diese Version mit RHN Push und nur einem Source-Paket verwenden, wird das Paket hochgeladen, wobei jedoch das Source-Paket solange nicht auf der RHN-Web-Oberfläche erscheint, bis das damit in Zusammenhang stehende Binärpaket hochgeladen wurde. Sie können mit dem Befehl --source das Gegenteil erwirken. Wenn Sie --source --newest gemeinsam verwenden, wird das alleinstehende Source-Paket mit neueren Paketen aktualisiert und es müssen keine Binär-Pakete zuerst hochgeladen werden.
--header Lädt nur die Header hoch.
--source Lädt die angezeigten Source-Pakete hoch. Dadurch werden diese als einfache, alleinstehende Pakete behandelt und nicht als spezielle Source-Pakete, die mit einem anderen, bereits bestehenden Binärpaket in Zusammenhang stehen. Sie können dies beispielsweise dazu verwenden, wenn Sie Applikations-Quellcode unter Entwicklern und Testern außerhalb des regulären Source-Control-Managements verteilen möchten.
--server SERVER Legt den Server fest, auf den Pakete hochgeladen werden sollen. Derzeit ist ein Wert von http://localhost/APP notwendig. Dieser Parameter ist erforderlich.
--test Zeigt lediglich eine Liste der zu pushenden Pakete an, ohne diese tatsächlich zu pushen.
-h, --help Beschreibt kurz die Optionen.
-?, --usage Zeigt eine Zusammenfassung des Verbrauchs an.

Anmerkung

Diese Befehlszeilenoptionen werden auch auf der Handbuchseite von rhnpush beschrieben: man rhnpush.

6.2.2. RHN Push-Applikation verwenden

Anmerkung

Es wird empfohlen, dass Sie zumindest einen privaten Channel erzeugen, um angepasste Pakete noch vor dem Hochladen erhalten zu können. Ein Channel ist für Systeme erforderlich, um Pakete erhalten zu können.
Der folgende Befehl lädt Paket-Header auf den RHN Satellite Server hoch und kopiert die Pakete in das RHN Satellite Server-Paket-Repository: 
rhnpush -c label_of_private_channelpkg-list
Sie können die Einstellungen in Ihren RHN Push-Konfigurationsdateien außer Kraft setzen, indem Sie Optionen und Werte auf der Befehlszeile angeben: 
rhnpush -c label_of_private_channel --server localhost pkg-list
label_of_private_channel ist der angepasste Channel, der erstellt wurde, um diese Pakete abzurufen. Bitte achten Sie darauf, dass Sie genau das Channel-Label verwenden, welches bei der Erstellung festgelegt wurde. Wenn Sie einen oder mehrere Channel festgelegt haben (unter Verwendung von -c oder --channel), werden die hochgeladenen Paket-Header mit allen festgelegten Channeln verlinkt. Wenn Sie keinen Channel festlegen, dann werden die Pakete im Keine Channels-Abschnitt der Paket-Management-Seite abgelegt. Werfen Sie einen Blick auf Abschnitt 4.6, »Pakete zu Software-Channels hinzufügen« für Instruktionen, wie die Pakete neu zugeordnet werden können.
Die --server-Option legt den Server fest, auf welchem die Pakete installiert werden. Diese Angabe ist erforderlich. RHN Push kann auch auf externen Systemen installiert sein, wobei es jedoch empfehlenswert ist, RHN Push lokal auf dem RHN Satellite Server ablaufen zu lassen.
Die pkg-list-Referenz gibt die Liste von Paketen an, die hochgeladen werden sollen. Alternativ dazu können Sie die -d-Option verwenden, um das lokale Verzeichnis festzulegen, welches die Pakete enthält, die zu dem Channel hinzugefügt werden sollen. RHN Push kann die Paketliste auch von Standardeingabe lesen (mittels --stdin).

Anhang A. Versionsgeschichte

Versionsgeschichte
Version 1-3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 1-32012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 1.0-0Fri Feb 27 2009

Stichwortverzeichnis

A

angepasste Pakete, Erstellung von angepassten Paketen
erstellen, Pakete für Red Hat Network erstellen
Richtlinien, RHN RPM-Richtlinien
hochladen auf den RHN Proxy Server, Pakete auf den RHN Proxy Server hochladen
hochladen auf den RHN Satellite Server, Pakete auf den RHN Satellite Server hochladen
signieren, Pakete signieren
Anleitung
zum Abrufen der Channel-Paketliste, Den RHN Package Manager konfigurieren und verwenden
zum Erstellen angepasster Pakete, Pakete für Red Hat Network erstellen
zum Erstellen eines GnuPG-Schlüssels, Ein GnuPG-Schlüsselpaar generieren
zum Hochladen von Paketen auf den RHN Proxy Server, Pakete auf den RHN Proxy Server hochladen
zum Klonen eines Channels, Software-Channels klonen
zum Konfigurieren von RHN Package Manager, Den RHN Package Manager konfigurieren und verwenden
zum Konfigurieren von RHN Push, RHN Push-Applikation konfigurieren
zum Kopieren fehlender Pakete auf den Satellite, Den RHN Package Manager konfigurieren und verwenden
zur Verteilung von nicht-RPM-Paketen, Pakete auf den RHN Satellite Server hochladen

C

Channels
Einführung, Einführung in RHN-Channels
klonen, Software-Channels klonen
löschen, Software-Channels löschen

E

Errata verwalten
Details ansehen, Verwaltete Errata-Details
Errata-Meldungen
erstellen und bearbeiten, Errata erzeugen und bearbeiten
klonen, Errata klonen
nicht veröffentlichte verwalten, Unveröffentlichte Errata
veröffentlichte verwalten, Veröffentlichte Errata
verwalten, Verwaltung von angepassten Errata

G

GnuPG-Schlüssel
erstellen, Ein GnuPG-Schlüsselpaar generieren
Pakete damit signieren, Pakete signieren
GPG-Schlüssel, Ein GnuPG-Schlüsselpaar generieren

P

Pakete
Solaris und UNIX, Pakete auf den RHN Satellite Server hochladen
Pakete hochladen, Hochladen und Pflege von angepassten Paketen

R

RHN Package Manager, Pakete auf den RHN Proxy Server hochladen
Abrufen der Channel-Paketliste, Den RHN Package Manager konfigurieren und verwenden
Channels spezifizieren, Den RHN Package Manager konfigurieren und verwenden
installieren, Pakete auf den RHN Proxy Server hochladen
Konfigurationsdatei, Den RHN Package Manager konfigurieren und verwenden
konfigurieren, Den RHN Package Manager konfigurieren und verwenden
Kopieren fehlender Pakete auf den Satellite, Den RHN Package Manager konfigurieren und verwenden
Paket-Header hochladen, Den RHN Package Manager konfigurieren und verwenden
rhn_package_manager, Den RHN Package Manager konfigurieren und verwenden
Überprüfen der lokalen Paketliste, Den RHN Package Manager konfigurieren und verwenden
RHN Push
Channels spezifizieren, RHN Push-Applikation verwenden
installieren, Pakete auf den RHN Satellite Server hochladen
konfigurieren, RHN Push-Applikation konfigurieren
verwenden, RHN Push-Applikation verwenden
rhn_package_manager, Den RHN Package Manager konfigurieren und verwenden
(Siehe auch RHN Package Manager)
Befehlszeilenoptionen, Den RHN Package Manager konfigurieren und verwenden
rhn_package_manager.conf, Den RHN Package Manager konfigurieren und verwenden
RPM
Vorteile, Vorteile von RPM
RPM-Paketmanager (Siehe RPM)

S

Software
Channel-Verwaltung, Software-Channel-Details verwalten

V

Verwaltete Channel-Details, Software-Channel-Details verwalten
verwaltete Software-Channels
Details, Software-Channel-Details verwalten

W

Was sind
die Vorteile von RPM, Vorteile von RPM
Website
Software-Channels verwalten, Software-Channel-Details verwalten

Rechtlicher Hinweis

Copyright © 2010 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.