Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Proxy-Installationshandbuch

Red Hat Network Satellite 5.5

Red Hat Network Satellite

Ausgabe 3

Red Hat Dokumentationsteam

Zusammenfassung

Willkommen beim RHN Proxy-Installationshandbuch.

Kapitel 1. Einführung

1.1. Red Hat Netzwerk

Das Red Hat Network (RHN) ist die Umgebung für den Support auf Systemebene, die Verwaltung von Red Hat Systemen und Netzwerken von Systemen. Red Hat Network vereint die notwendigen Werkzeuge, Dienste und Informationsquellen, um die Zuverlässigkeit, Sicherheit und Leistung der Systeme zu maximieren. Um RHN verwenden zu können, registrieren Administratoren die Software- und Hardware-Profile ihrer Clients (auch Systemprofile genannt) beim Red Hat Network. Wenn ein Client-System Paket-Updates anfordert, werden lediglich die für den Client zutreffenden Pakete zurückgesendet (basierend auf dem Software-Profil, das auf den RHN Servern gespeichert ist).
Vorteile bei der Verwendung von Red Hat Network:
  • Skalierbarkeit — Mit Red Hat Network kann ein einziger Systemadministrator hunderte oder gar tausende von Red Hat-Systemen einfacher, genauer und schneller erstellen und verwalten, als nur ein einziges System ohne Red Hat Network.
  • Standardprotokolle — Standardprotokolle werden dazu verwendet, Sicherheit aufrecht zu erhalten und das Leistungsvermögen zu erhöhen. So ist Red Hat Network dank XML-RPC zu weitaus mehr in der Lage, als nur Dateien herunterzuladen.
  • Sicherheit — Jegliche Kommunikation zwischen registrierten Systemen und Red Hat Network findet über sichere Internetverbindungen statt.
  • Ansehen von Errata-Meldungen — Sehen Sie sich auf einfachste Weise Errata-Meldungen für alle Ihre Client-Systeme mithilfe einer Website an.
  • Einplanen von Aktionen — Verwenden Sie die Website, um Aktionen einzuplanen, wie u.a. Errata-Updates, Paketinstallationen und Software-Profil-Updates.
  • Vereinfachung — Das Instandhalten von Red Hat-Systemen wird zu einem einfachen, automatisierten Prozess.

1.2. Häufig verwendete Terminologien

Bevor Sie sich mit RHN Proxy Server auseinandersetzen, ist es wichtig, sich zuerst mit folgenden Red Hat Network Begriffen vertraut zu machen:
Kanal (Channel)
Ein Kanal ist eine Liste von Software-Paketen. Es gibt zwei Arten von Kanälen: Basis-Channels (Basiskanäle) und Sub-Channels (Unterkanäle). Ein Basis-Channel besteht aus einer Liste von Paketen basierend auf einer spezifischen Architektur und einer Red Hat Release. Ein Sub-Channel ist ein Kanal in Verbindung mit einem Basis-Channel, enthält jedoch zusätzliche Pakete.
Organisations-Verwalter (Organization Administrator)
Ein Organisationsadministrator ist eine Benutzerrolle mit dem höchsten Grad an Kontrolle über einen Red Hat Network Account einer Organisation. Die Mitglieder dieser Rolle können andere Benutzer, Systeme und Systemgruppen zur Organisation hinzufügen und auch entfernen. Eine Red Hat Network Organisation muss mindestens einen Organisations-Verwalter besitzen.
Kanal-Verwalter (Channel-Administrator)
Ein Kanal-Verwalter ist eine Benutzerrolle mit vollem Zugang zu den Channel-Managementfähigkeiten. Benutzer in dieser Rolle können Channels erstellen, Pakete bestimmten, Channels zuordnen, Channels klonen und Channels löschen. Diese Rolle kann von einem Organisations-Verwalter über den Benutzer Tab auf der RHN-Website vergeben werden.
Red Hat Update Agent
Der Red Hat Update Agent ist die Red Hat Network Client-Applikation (up2date oder yum), mit der Benutzer neue oder aktualisierte Pakete für das Client-System, auf dem die Applikation abläuft, abrufen und installieren können.
Traceback
Ein 'Traceback' ist eine detaillierte Beschreibung dessen, "was schiefgelaufen ist", die sich bestens zur Suche und Bereinigung von Fehlern im RHN Proxy Server eignet. Tracebacks werden automatisch generiert, wenn ein kritischer Fehler auftritt und werden dann an die in der Konfigurations-Datei des RHN Proxy Servers dafür vorgesehenen Personen als E-Mail versendet.
Mehr detaillierte Beispiele zu diesen Thema und anderen finden Sie im Red Hat Network Referenzhandbuch, verfügbar unter http://www.redhat.com/docs/manuals/satellite/, sowie auf der Hilfe Seite der Satellite Web-Benutzerschnittstelle.

1.3. RHN Proxy Server

Ein RHN Proxy Server ist ein Paket-Caching-Mechanismus, der die für RHN erforderliche Bandbreite reduziert und den Einsatz von kundenspezifischen Paketen unterstützt. Proxy-Kunden speichern RPMs, wie z.B. Errata-Updates von Red Hat oder kundenspezifischen RPMs von anderen Organisationen, auf einem internen, zentralen Server zwischen. Client-Systeme empfangen somit ihre Updates vom Proxy, und nicht durch individuellen Zugriff auf das Internet.
Auch wenn die Pakete durch den Proxy bereitgestellt werden, sind die Systemprofile der Clients und die Benutzerinformationen sicher und zentral im RHN-Server gespeichert[1], der auch die RHN-Webseite bedient (rhn.redhat.com). Der Proxy dient als Zwischenstation zwischen Client-Systemen und Red Hat Network (oder einem RHN Satellite Server). Nur die Paketdateien sind auf dem RHN Proxy Server gespeichert. Jede Transaktion wird authentifiziert, und der Red Hat Update Agent überprüft die GPG-Signatur aller Pakete vom lokalen RHN Proxy Server.
Zusätzlich zum Speichern von offiziellen Red Hat Paketen kann der RHN Proxy Server auch darauf konfiguriert werden, eigene kundenspezifische Pakete von privaten RHN Channels mithilfe des RHN Package Managers bereitzustellen. Zum Beispiel kann eine Organisation ihre eigene Software entwickeln, als RPM paketieren, es mit einer eigenen GPG-Signatur versehen und mithilfe des lokalen RHN Proxy Server alle einzelnen Systeme im Netzwerk mit der neuesten Version der kundenspezifischen Software aktualisieren.
Vorteile bei der Verwendung von RHN Proxy Server:
  • Skalierbarkeit — Es kann mehrere lokale RHN Proxy Server innerhalb eines Unternehmens geben.
  • Sicherheit — Es wird für eine durchgehend sichere Verbindung gesorgt: Von den Client-Systemen zum lokalen RHN Proxy Server und zu den Red Hat Network Servern.
  • Zeitersparnis — Pakete werden wesentlich schneller über ein lokales Netzwerk geliefert, als über das Internet.
  • Bandbreitenersparnis — Pakete werden nur einmal vom RHN heruntergeladen (über den lokalen Proxy-Server-Caching-Mechanismus), anstatt jedes Paket für jedes Client-System einzeln herunterzuladen.
  • Kundenspezifische Updates — Ermöglicht ein völlig automatisiertes Paketlieferungssystem für kundenspezifische Software-Pakete sowie auch offizielle Red Hat Pakete, welche für die Client-Systeme benötigt werden. Kundenspezifische, private RHN-Channels ermöglichen es einem Unternehmen, die Lieferung von firmeninternen, betriebseigenen Paketen zu automatisieren.
  • Kundenspezifische Konfiguration — Sie können Updates für spezifische Architekturen und Betriebssystemversionen entweder unterbinden oder erlauben.
  • Nur eine Internetverbindung nötig — Da die Clients sich direkt mit dem RHN Proxy Server verbinden und nicht mit dem Internet, benötigen Sie nur eine LAN-Verbindung zum Proxy. Nur der RHN Proxy Server benötigt eine Internetverbindung, um die RHN Server zu kontaktieren, es sei denn, der RHN Proxy Server benutzt einen RHN Satellite Server, in welchem Fall nur der RHN Satellite Server eine Internetverbindung benötigt.

1.4. Proxy Funktionsweise

Der Red Hat Update Agent oder Paket-Updater auf den Client-Systemen kontaktiert den Red Hat Network Server nicht direkt. Stattdessen verbinden sich die Clients mit einem RHN Proxy Server, der sich wiederum mit den Red Hat Network Servern oder einem RHN Satellite Server verbindet. Demnach benötigen die Client-Systeme keinen direkten Zugang zum Internet. Diese benötigen nur Zugang zum RHN Proxy Server.

Wichtig

Es wird von Red Hat dringend empfohlen, dass Clients, die mit einem RHN Proxy Server verbunden sind, die neueste Version von Red Hat Enterprise Linux besitzen, um eine einwandfreie Verbindungsfähigkeit zu gewährleisten.
Clients, die direkt auf RHN zugreifen, werden standardmäßig von den RHN-Servern authentifiziert. Clients, die auf einen RHN Proxy Server zugreifen, werden auch von RHN authentifiziert, allerdings stellt der Proxy dem RHN in diesem Fall sowohl Authentifizierungs- als auch Routing-Informationen zur Verfügung. Nach einer erfolgreichen Authentifizierung informiert der Red Hat Network den RHN Proxy Server darüber, dass es dem RHN Proxy Server gestattet wurde, eine bestimmte Aktion für einen Client auszuführen. Der RHN Proxy Server lädt anschließend alle aktualisierten Pakete herunter (wenn sich diese noch nicht in seinem Cache befinden) und liefert diese an die Client-Systeme.
Anfragen des Red Hat Update Agents oder Paket-Updaters auf den Client-Systemen werden noch immer serverseitig authentifiziert, wobei jedoch die Paketlieferung wesentlich schneller ist, da die Pakete im HTTP Proxy Caching Server oder dem RHN Proxy Server (für lokale Pakete) zwischengespeichert werden; der RHN Proxy Server und das Client-System sind über das LAN verbunden und werden nur durch die Geschwindigkeit des lokalen Netzwerks eingeschränkt.
Authentifizierung erfolgt in der folgenden Reihenfolge:
  1. Der Client meldet sich zu Beginn einer Client-Sitzung an. Diese Anmeldung durchläuft einen oder mehrere RHN Proxy Server, bis sie einen Red Hat Network erreicht.
  2. Der Red Hat Network versucht, den Client zu authentifizieren. Bei erfolgreicher Authentifizierung sendet der Server einen Session-Token über die Kette von RHN Proxy Servern zurück. Dieser Token hat eine Signatur und ein Verfallsdatum und beinhaltet Benutzerinformationen, wie u.a. subskribierte Channels, Benutzername, usw.
  3. Jeder RHN Proxy Server speichert diesen Token auf seinem lokalen Dateisystem in /var/cache/rhn/ zwischen. Caching reduziert den Overhead in Zusammenhang mit der Authentifizierung mit Red Hat Network und verbessert somit drastisch das Leistungsvermögen des Red Hat Networks.
  4. Dieser Session-Token wird an den Client-Rechner zurückgesendet und wird bei späteren Vorgängen im Red Hat Network verwendet.
Es gibt aus Sicht des Clients keinen Unterschied zwischen einem RHN Proxy Server und einem Red Hat Network Server. Aus Sicht des Red Hat Network Servers ist ein RHN Proxy Server eine spezielle Art von RHN-Client. Folglich hat es auf Clients keinerlei Auswirkungen, welche Route eine Anfrage nimmt, um einen Red Hat Network Server zu erreichen. Die gesamte Logik ist in den RHN Proxy Servern und den Red Hat Network Servern implementiert.
Optional kann der RHN Package Manager installiert und zum Bereitstellen kundenspezifischer Software-Pakete konfiguriert werden. Jegliche Pakete, bei denen es sich nicht um offizielle Red Hat Pakete handelt, einschließlich speziell für ein Unternehmen geschriebene Pakete, können nur von einem privaten Software-Channel (auch kundenspezifischer Software-Channel genannt) bereitgestellt werden. Nachdem ein privater RHN-Channel erstellt wurde, werden die kundenspezifischen RPM-Pakete mit dem privaten Channel verknüpft, indem die Paket-Header auf die RHN-Server hochgeladen werden. Es werden nur die Header hochgeladen, nicht die eigentlichen Paketdateien. Die Header sind erforderlich, da diese äußerst wichtige RPM-Informationen enthalten, wie beispielsweise Software-Abhängigkeiten, die es RHN ermöglichen, die Paketinstallation zu automatisieren. Die eigentlichen, kundenspezifischen RPM-Pakete werden auf dem RHN Proxy Server aufbewahrt und an die Client-Systeme intern über das lokale Netzwerk des Unternehmens versendet.
Die Konfiguration eines Computernetzwerks zur Verwendung von RHN Proxy Servern ist ein recht unkomplizierter Prozess. Die Red Hat Network Applikationen auf den Client-Systemen müssen so konfiguriert werden, dass diese mit dem RHN Proxy Server anstelle der Red Hat Network Server verbinden. Siehe RHN Client-Konfigurationshandbuch für nähere Details. Proxyseitig muss der nächste Proxy in der Kette festgelegt werden (die letztendlich mit einem Red Hat Network Server endet). Wenn der RHN Package Manager verwendet wird, müssen die Client-Systeme den privaten RHN-Channel subskribieren.

[1] Im Laufe dieses Dokuments kann sich "RHN" entweder auf die RHN Hosted Seite (http://rhn.redhat.com) oder auf einen RHN Satellite Server beziehen.

Kapitel 2. Anforderungen

Die folgenden Anforderungen müssen vor der Installation erfüllt sein. Der Satellite selbst muss entweder von derselben oder einer höheren Version sein wie der Proxy, den Sie installieren möchten. Wenn Sie beispielsweise den RHN Proxy Server 5.4 installieren möchten, sollte die Satellite-Version 5.4 oder höher sein, darf jedoch nicht 5.3 oder darunter sein.

2.1. Software-Anforderungen

Um eine Installation durchführen zu können, müssen die folgenden Software-Komponenten vorhanden sein:
  • Basisbetriebssystem — RHN Proxy Server wird mit Red Hat Enterprise Linux 5 und 6 unterstützt. Das Betriebssystem kann von CD/DVD, lokalem ISO-Image, Kickstart oder irgendeinem anderen, von Red Hat unterstützten Verfahren installiert werden.
    RHN Proxy Server kann auf Red Hat Enterprise Linux 5 und 6 in einer beliebigen, von Red Hat unterstützten virtualisierten Umgebung installiert werden, dazu gehören Xen, KVM und VMware.
    Beachten Sie, dass wir für den Einsatz in einer Produktionsumgebung empfehlen, den RHN Proxy Server als einzige Applikation auf der zugrunde liegenden physischen Hardware auszuführen, um Konflikte zu vermeiden. Sie sollten sich außerdem darüber im Klaren sein, dass funktionale Unterstützung für virtualisierte Umgebungen nicht immer der Leistung entspricht, die Sie auf physischer Hardware erwarten können. Sie sollten daher Ihre virtualisierte Umgebung mit Bedacht auswählen und nach Möglichkeit die empfohlenen Richtlinien zur Optimierung einhalten.

    Anmerkung

    Jedes erworbene RHN-Proxy-Produkt enthält eine unterstützte Instanz des Red Hat Enterprise Linux Servers. RHN Proxy muss auf einer frischen Installation von Enterprise Linux installiert werden, wobei der RHN Proxy die einzige Applikation und der einzige Dienst sein sollte, die/den dieses Betriebssystem bereitstellt. Die Verwendung des im RHN Proxy enthaltenen Red Hat Enterprise Linux Betriebssystems zur Ausführung anderer Daemonen, Applikationen oder Diensten innerhalb Ihrer Umgebung wird nicht unterstützt.
    Jede Version von Red Hat Enterprise Linux erfordert einen ganz bestimmten Paketsatz, um RHN Proxy Server zu unterstützen. Das Hinzufügen weiterer Pakete kann Fehler bei der Installation hervorrufen. Deshalb empfiehlt Red Hat, die gewünschten Paketsätze auf die folgenden Weisen zu erhalten:

    Anmerkung

    Für das Kickstarten legen Sie die folgende Paketgruppe fest: @Base
    Für die Installation von Red Hat Enterprise Linux von CD oder ISO-Image wählen Sie folgende Paketgruppe aus: Minimal
  • Eine verfügbare RHN Proxy Server Berechtigung innerhalb des RHN Satellite Server Kontos.
  • Eine verfügbare Bereitstellungs-Berechtigung innerhalb des RHN Satellite Server Kontos (welche gebündelt mit der RHN Proxy Server Berechtigung kommen sollte).
  • Zugriff auf den Red Hat Network Tools-Channel für die installierte Version von Red Hat Enterprise Linux. Dieser Kanal beinhaltet das spacewalk-proxy-installer Paket, welches das für die Installation eines RHN Proxy Servers benötigte configure-proxy.sh Installationsprogramm enthält.
  • Alle auf dem Proxy installierten rhncfg*-Pakete (vom RHN-Tools-Channel).
  • Entweder das auf dem Proxy installierte rhns-certs-tools Paket (vom RHN-Tools-Channel) für RHN Hosted Benutzer, oder das Secure Sockets Layer (SSL) CA-Zertifikatpasswort, welches für RHN Satellite Server-Benutzer zur Generierung des Parent-Server-Zertifikats verwendet wird.
  • Eine Konfiguration auf dem System, die Befehle von Remote aus und Konfigurationsmanagement durch das Red Hat Network akzeptiert, falls die veraltete Installationsmethode via Weboberfläche angewendet wird. Siehe Abschnitt 4.2, »RHN Proxy Server Installationsvorgang« für weitere Anweisungen.

2.2. Hardware-Anforderungen

Die folgende Hardware-Konfiguration ist für den RHN Proxy Server erforderlich:
  • Ein Pentium IV Prozessor oder äquivalent
  • 512 MB Arbeitsspeicher
  • Mindestens 5 GB Speicherplatz für die Basisinstallation von Red Hat Enterprise Linux
  • 25+ GB Speicherplatz pro Distribution/Channel
Die Last auf dem Apache Web Server steht in direktem Zusammenhang mit der Häufigkeit, mit der Client-Systeme mit dem Proxy verbinden. Wenn Sie daher das Standardintervall von vier Stunden (oder 240 Minuten), wie in der Konfigurationsdatei /etc/sysconfig/rhn/rhnsd festgelegt, reduzieren, dann steigern Sie damit maßgeblich die Last auf dieser Komponente.

2.3. Speicherplatzanforderungen

Der vom RHN Proxy Server eingesetzte Caching-Mechanismus ist der Squid HTTP-Proxy, der in signifikantem Maß Bandbreite für die Clients einspart. Dieser sollte eine angemessene Menge an Speicherplatz zur Verfügung haben. Die zwischengepeicherten Pakete werden in /var/spool/squid abgelegt. Die erforderliche Zuweisung an freiem Speicherplatz ist 6 GB Speicher pro Distribution/Channel.
Wenn der RHN Proxy Server zur Distribution von kundenspezifischen Paketen (auch "Custom-Pakete" genannt) oder lokalen Paketen konfiguriert ist, dann gehen Sie sicher, dass auf dem /var Einhängepunkt auf dem System, welches die lokalen Pakete speichert, ausreichend Plattenspeicher vorhanden ist, um sämtliche kundenspezifischen Pakete unterzubringen, die in /var/spool/rhn-proxy gespeichert sind. Der erforderliche Plattenspeicher für lokale Pakete hängt von der Anzahl der bereitgestellten kundenspezifischen Pakete ab.

2.4. Weitere Anforderungen

Die folgenden weiteren Anforderungen müssen erfüllt werden, bevor die RHN Proxy Server-Installation als vollständig angesehen werden kann:
Voller Zugang
Client-Systeme benötigen vollen Netzwerkzugang zu den RHN Proxy Server-Diensten und Ports.
Firewall-Regeln
Es wird von RHN dringend empfohlen, den RHN Proxy Server durch einen Firewall vom Internet zu schützen. Jedoch sollten verschiedene TCP-Ports offen bleiben, je nach der Implementation des RHN Proxy Server:

Tabelle 2.1. Ports, die im Proxy geöffnet werden sollten

Port Richtung Grund
80 Ausgehend Proxy nutzt diesen Port um rhn.redhat.com, xmlrpc.rhn.redhat.com und Ihre Satellite URL zu erreichen (je nachdem, ob RHN Proxy entweder mit RHN Hosted oder einem Satellite Server kommuniziert).
80 Eingehend Client-Anfragen gehen über http oder https ein
443 Eingehend Client-Anfragen gehen über http oder https ein
443 Ausgehend Der Proxy nutzt diesen Port, um rhn.redhat.com, xmlrpc.rhn.redhat.com und die Satellite-URL zu erreichen (abhängig davon, ob RHN Proxy mit RHN Hosted oder einem Satellite Server kommuniziert).
4545 Ausgehend Falls Ihr Proxy mit einen RHN Satellite Server verbunden ist, verbindet sich das Monitoring über diese TCP-Ports mit Client-Systemen, auf denen rhnmd läuft, sofern Monitoring aktiviert ist und nach registrierten Systemen sucht.
5222 Eingehend Das Öffnen dieses Ports erlaubt dem osad-Client, sich mit dem jabberd Dämon auf der Proxy zu verbinden, wenn die RHN-Push-Technologie verwendet wird.
5269 Ausgehend Falls Ihr Proxy mit einem RHN Satellite Server verbindet, muss dieser Port geöffnet sein, um zwischen den Servern Verbindungen über jabberd für die RHN-Push-Technologie zu erlauben.
Synchronisierte Systemzeiten
Die korrekte Zeit spielt eine bedeutende Rolle, wenn mit einem SSL- (Secure Sockets Layer) fähigen Webserver verbunden wird; es ist von entscheidender Bedeutung, dass die Zeiteinstellungen auf den Clients und dem Server sehr nahe beieinander liegen, sodass das SSL-Zertifikat nicht vor oder während der Verwendung abläuft. Das Network Time Protokoll (NTP) wird zur Synchronisation der Systemzeiten empfohlen.
Voll qualifizierter Domain-Name (FQDN)
Das System, auf dem der RHN Proxy Server installiert wird, muss in der Lage sein, den eigenen FQDN richtig aufzulösen.
Red Hat Netzwerk Konto
Kunden, die sich mit den zentralen Red Hat Network Servern verbinden, um inkrementelle Updates zu erhalten, benötigen ein Red Hat Network Konto. Dieses Konto sollte zum Kaufzeitpunkt gemeinsam mit dem Vertriebsmitarbeiter eingerichtet werden.
Backups von Login-Informationen
Es ist zwingend notwendig, dass Kunden über alle primären Login-Informationen die Übersicht behalten. Im Falle eines RHN Proxy Servers sind dies u.a. Benutzernamen und Passwörter für das Organisationsadministrator Konto und die SSL-Zertifikat-Generierung. Red Hat empfiehlt dringend, dass diese Informationen auf zwei separate Datenträger kopiert wird, ausgedruckt wird, und der Ausdruck in einem sicheren Platz (Tresor) aufbewahrt wird.
Distributionsspeicherorte
Da der Proxy nahezu alle lokalen HTTP-Anfragen an die zentralen RHN Server weiterleitet, müssen Sie darauf achtgeben, dass Sie alle Dateien, die für die Distribution vorgesehen sind (wie beispielsweise in einem Kickstart-Installationsbaum) in einem Ort auf dem Proxy ablegen, wo nicht weitergeleitet wird: /var/www/html/pub/. Dateien, die in diesem Verzeichnis abgelegt werden, können direkt vom Proxy heruntergeladen werden. Dies kann für das Verteilen von GPG-Schlüsseln oder dem Erstellen von Installationsbäumen für Kickstarts besonders hilfreich sein.
Zusätzlich dazu empfiehlt Red Hat, dass das System, auf dem der Code ausgeführt wird, nicht öffentlich zugänglich ist. Es sollten nur Systemadministratoren Shell-Zugang zu diesen Rechnern besitzen, aber keine anderen Benutzer. Alle nicht notwendigen Dienste sollten deaktiviert werden. Sie können ntsysv oder chkconfig zur Deaktivierung von Diensten verwenden.
Schlussendlich sollten Sie folgende technische Dokumente für den Einsatz griffbereit haben, ungefähr in dieser Reihenfolge:
  1. Das RHN Proxy Server-Installationshandbuch — Dieses Handbuch, welches Sie gerade lesen, behandelt die wesentlichen Schritte, um ein RHN Proxy Server einsatzbereit zu machen.
  2. Das RHN Client Konfigurations-Handbuch — Dieses Handbuch erklärt, wie Systeme konfiguriert werden müssen, um von einem RHN Proxy Server oder RHN Satellite Server bedient zu werden. (Wahrscheinlich erfordert dies auch die Zuhilfenahme des RHN Referenz-Handbuchs, welches Schritte zur Registrierung und Aktualisierung von Systemen enthält.)
  3. Das RHN Channel Management-Handbuch — Dieses Handbuch behandelt detailgenau die empfohlenen Methoden für die Erstellung von kundenspezifischen Paketen und Channels sowie auch zur Verwaltung privater Errata.
  4. Das RHN Referenz-Handbuch — Dieses Handbuch beschreibt das Einrichten von RHN-Konten, die Registrierung und Aktualisierung von Systemen sowie Hinweise dazu, wie Sie das Potenzial der RHN-Website am besten ausschöpfen können. Dieses Handbuch kommt sicherlich während des gesamten Installations- und Konfigurationsprozesses hindurch gelegen.

Kapitel 3. Beispieltopologien

Der RHN Proxy Server kann auf mehrere Arten konfiguriert werden. Wählen Sie abhängig von folgenden Faktoren eine Methode aus:
  1. Die Gesamtanzahl von Client-Systemen, für die der RHN Proxy Server als Server dient.
  2. Die maximale Anzahl von Clients, die erwartungsgemäß gleichzeitig mit dem RHN Proxy Server verbinden.
  3. Die Anzahl von benutzerdefinierten Paketen und Channels, die vom RHN Proxy Server bereitgestellt werden.
  4. Die Anzahl von RHN Proxy Servern, die in der Umgebung des Kunden verwendet werden.
Der Rest dieses Kapitels beschreibt mögliche Konfigurationen und erläutert deren Vorteile.

3.1. Einzel-Proxy-Topologie

Die einfachste Konfiguration ist die Verwendung eines einzelnen RHN Proxy Servers, der Ihr gesamtes Netzwerk versorgt. Diese Konfiguration ist für eine kleine Gruppe von Clients ausgelegt und für ein Netzwerk geeignet, das vom Caching von Red Hat RPMs und dem Speichern von benutzerdefinierten Paketen profitieren kann.
Der Nachteil bei der Verwendung eines einzelnen RHN Proxy Servers ist die Beeinträchtigung der Systemleistung, wenn die Anzahl der Clients ansteigt, die Pakete abrufen.
Einzel-Proxy-Topologie

Abbildung 3.1. Einzel-Proxy-Topologie

3.2. Mehrfach horizontal gestaffelte Proxy-Topologie

Für größere Netzwerke könnte eine weiter verteilte Methode erforderlich sein, wie beispielsweise mehrere RHN Proxy Server, die mit Red Hat Network individuell verbunden sind. Durch diese horizontal gestaffelte Konfiguration kann die Last der Client-Anfragen besser verteilt werden und gleichzeitig ist jeder Proxy in der Lage, simultan mit RHN zu synchronisieren.
Ein Nachteil dieser horizontalen Struktur besteht darin, dass benutzerdefinierte Pakete, die auf einen einzelnen Proxy hochgeladen wurden, anschließend ebenfalls an die Geschwister-Server verteilt werden müssen. Dieser Situation kann auf zwei Arten begegnet werden:
  • Das Dateiübertragungsprogramm rsync wird verwendet um Pakete zwischen den Proxys zu synchronisieren
  • Ein Network File System (NFS) Share kann zwischen den Proxys und dem als Repository dienenden benutzerdefinierten Channel eingerichtet werden.
Beide Lösungen ermöglichen es jedem Client von jedem RHN Proxy Server, alle benutzerdefinierten Pakete geliefert zu bekommen.
Mehrfach horizontal gestaffelte Proxy-Topologie

Abbildung 3.2. Mehrfach horizontal gestaffelte Proxy-Topologie

3.3. Mehrfach vertikal gestaffelte Proxy-Topologie

Ein alternatives Verfahren für den Einsatz von mehreren RHN Proxy Servern ist das Einrichten eines primären Proxys, mit dem die anderen verbinden, um RPMs vom Red Hat Network zu erhalten sowie auch benutzerdefinierte Pakete, die lokal erstellt wurden. Im Wesentlichen verhalten sich die sekundären Proxys wie Clients des primären Proxys. Dadurch ist die Notwendigkeit nicht mehr so hoch, dass eine Synchronisation zwischen den RHN Proxy Servern stattfindet, da diese die im Produkt enthaltene up2date Funktionalität verwenden.
Wie bei der horizontal gestaffelten Konfiguration ermöglicht diese vertikale Methode jedem Client eines jeden RHN Proxy Servers, alle benutzerdefinierten Pakete geliefert zu bekommen. Der Proxy sieht lediglich im eigenen Repository nach, ob sich das Paket im Dateisystem befindet. Wenn nicht, versucht der Proxy es eine Stufe höher.
Diese vertikal gestaffelte Konfiguration gewährleistet, dass die sekundären Proxys für Updates von RHN sowie auch für benutzerdefinierte Pakete auf die primären Proxys angewiesen sind. Auch dürfen benutzerdefinierte Channels und Pakete nur auf dem primären Proxy abgelegt werden, um eine Verteilung zu den untergeordneten Proxys sicherzustellen. Schlussendlich müssen die Konfigurations-Dateien des sekundären Proxys auf den primären Proxy Server verweisen, anstatt direkt auf Red Hat Network.
Mehrfach vertikal gestaffelte Proxy-Topologie

Abbildung 3.3. Mehrfach vertikal gestaffelte Proxy-Topologie

3.4. Proxys mit RHN Satellite Server

Eine alternative Lösung zu den in diesem Kapitel detailliert beschriebenen Methoden ist die Verwendung von RHN Proxy Servern in Verbindung mit einem RHN Satellite Server. Diese Architektur funktioniert ähnlich wie die vertikal gestaffelte Proxy-Konfiguration. Dabei wird jedoch die Kapazität auf signifikante Weise angehoben, da Satellites einer wesentlich größeren Anzahl von Client-Systemen als Server dienen können.
Für eine ausführliche Beschreibung dieser Kombination verweisen wir auf das Kapitel mit den Beispiel-Topologien im RHN Satellite Server Installationshandbuch. Das Verknüpfen der SSL Zertifikate der beiden Produkte wird ausführlich im RHN Client-Konfigurationshandbuch beschrieben. Um herauszufinden, auf welche Art Channels und Pakete von diesen beiden Produkten gemeinsam verwendet werden, werfen Sie einen Blick in das RHN Channel-Managementhandbuch.

Kapitel 4. Installation

Dieses Kapitel beschreibt die Erstinstallation des RHN Proxy Servers. Es setzt die Grundvoraussetzungen, die in Kapitel 2, Anforderungen aufgelistet sind, voraus. Falls Sie dagegen ein Upgrade auf eine neuere Version des RHN Proxy Servers planen, kontaktieren Sie bitte Ihren Red Hat Berater für weitere Hilfestellung.

4.1. Basisinstallation

Der RHN Proxy Server ist für das Red Hat Enterprise Linux Betriebssystem ausgelegt. Deshalb ist die erste Phase die Installation des Basisbetriebssystems von CD/DVD, mittels ISO-Image oder Kickstart. Während und nach der Installation des Betriebssystems sollten Sie folgende Punkte beachten:
  • Weisen Sie derjenigen Partition, auf der die Pakete gespeichert werden, genügend Platz zu, gemäß der zuvor erwähnten Hardware-Anforderungen. Im Cache zwischengespeicherte Red Hat-Pakete befinden sich standardmäßig in /var/spool/squid, während sich kundenspezifische Pakete in /var/spool/rhn-proxy befinden.

    Anmerkung

    Das Installationsprogramm berechnet automatisch den verfügbaren Platz auf der Partition, in der /var/spool/squid bereitgestellt ist, und weist bis zu 60 Prozent des freien Speichers dem RHN Proxy Server zur Verwendung zu.
  • Installieren Sie die Pakete, die für den RHN Proxy Server erforderlich sind.

    Anmerkung

    Sie dürfen nur die Basispakete installieren, alle anderen würden dazu führen, dass die RHN Proxy Server Installation fehlschlägt.
    Werfen Sie einen Blick auf Abschnitt 2.1, »Software-Anforderungen« um zu erfahren, welche Methode die richtigen Paketgruppen für jede Version von Red Hat Enterprise Linux abruft.
  • Aktivieren Sie das Network Time Protocol (NTP) auf dem Proxy und wählen die entsprechende Zeitzone aus. Auf allen Client-Systemen sollte bereits der ntpd-Daemon laufen und auf die korrekte Zeitzone eingestellt sein.
  • Deaktivieren Sie die ipchains und iptables-Dienste nach der Installation.

4.2. RHN Proxy Server Installationsvorgang

Die folgenden Anleitungen beschreiben den RHN Proxy Server Installationsvorgang:
  1. Melden Sie sich als Root-Benutzer auf dem beabsichtigten RHN Proxy Server System an.
  2. Registrieren Sie das neu installierte Red Hat Enterprise Linux System beim Red Hat Network (entweder dem zentralen RHN Server oder Ihrem RHN Satellite Server) unter Verwendung des Organisations-Accounts, der die RHN Proxy Server Berechtigung beinhaltet, mit dem Befehl: rhn_register.
  3. Subskribieren Sie den Client auf den RHN Tools-Kanal.
  4. Installieren Sie den Proxy Installer: 
    yum install spacewalk-proxy-installer
  5. Installation durchführen: 
    configure-proxy.sh

    Anmerkung

    Um diesen Schritt erfolgreich durchzuführen ist Root-Zugriff auf den Satellite Server erforderlich. Alternativ können Sie die --force-own-ca Option zum Befehl hinzufügen.
    Das Befehlszeilen-Installationsprogramm führt Benutzer durch eine Reihe von Eingabeaufforderungen ("Prompts") bezüglich der RHN Proxy Server Installation und Details zur Anfangskonfiguration, wie z.B. Installationsoptionen und Generierung der SSL-Zertifikate. Die folgenden Anleitungen beschreiben den Installationsvorgang:

    Anmerkung

    Wenn Sie bei einem Prompt die Enter Taste drücken, anstatt eine Eingabe zu tippen, so verwendet das Befehlszeilen-Installationsprogramm die in Klammern angezeigte Standardantwort.
    Falls Sie alternativ ohne jegliche Benutzereingabe die Standardantworten übernehmen möchten, verwenden Sie die --non-interactive Option, wodurch sämtliche Standardantworten verwendet werden.
  6. Bei der ersten Reihe von Eingabeaufforderungen werden Details abgefragt, spezifisch für den Rechner, auf dem Sie installieren. 
    Proxy version to activate [5.4]:
    Die Proxy version fordert Sie dazu auf, die Version des RHN Proxy Servers anzugeben, die Sie installieren möchten. 
    RHN Parent [satserver.example.com]:
    RHN Parent ist der Domain-Name oder die Adresse des Systems, das dem Proxy dient, dies können RHN Hosted Server (xmlrpc.rhn.redhat.com) oder ein Satellite Server sein. 
    Traceback email []:
    Traceback email ist die E-Mail-Adresse, an die Traceback-Nachrichten bezüglich Fehler gesendet werden, in der Regel ist dies die E-Mail-Adresse des Proxy-Administrators. Benutzen Sie Kommas, um mehrere E-Mail-Adressen in diesem Prompt voneinander zu trennen.
  7. Die nächste Reihe von Eingabeaufforderungen beziehen sich auf die Detailkonfiguration zum Generieren eines SSL-Zertifikats, was empfohlen wird, um den Datenverkehr zum und vom RHN Proxy Server zu sichern. 
    Use SSL [Y/n]: y
    Geben Sie beim Use SSL Prompt y ein, um den RHN Proxy Server für die Unterstützung von SSL zu konfigurieren. 
    CA Chain [/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT]:
    Drücken Sie im CA Chain Prompt die Eingabe Taste, um den Standardpfad für die Certificate Authority (CA) Chain zu verwenden. Dieser Wert lautet normalerweise /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT, falls der RHN Proxy mit einem RHN Satellite kommuniziert. Falls er dagegen mit RHN Hosted kommuniziert, ist es in der Regel die /usr/share/rhn/RHNS-CA-CERT Datei. Benutzerdefinierte SSL-Zertifikate müssen im /usr/share/rhn/ Verzeichnis abgelegt werden. 
    HTTP Proxy []:
    Falls der RHN Proxy Server über einen HTTP-Proxy verbindet, geben Sie den Proxy-Hostnamen und die Portnummer ein, wie z.B. corporate.proxy.example.com:3128.
    Geben Sie die erforderlichen Details ein, um ein ordnungsgemäßes SSL-Server-Zertifikat zu generieren, einschließlich dem Namen der Organization, der Organization Unit (Organisationseinheit, wie z.B. Engineering), Common Name (der Domain-Name), sowie Angaben zu Ort, Bundesland und Land. Zum Schluss geben Sie noch die E-Mail-Adresse des Administrators oder des technischen Kontakts ein, der für SSL-Zertifikate zuständig ist. 
    Regardless of whether you enabled SSL for the connection to the Proxy Parent
Server, you will be prompted to generate an SSL certificate.
This SSL certificate will allow client systems to connect to this Spacewalk Proxy
securely. Refer to the Spacewalk Proxy Installation Guide for more information.
Organization: Example Company
Organization Unit [proxy1.example.com]:
Common Name: proxy1.example.com
City: New York
State: New York
Country code: US
Email [admin@example.com]:
  8. Als Ergebnis der Ausführung des RHN Proxy Server Installationsprogrammes wird das Befehlszeilen-Installationsprogramm:
    • Die Installation der Überwachungs-Unterstützung für RHN Proxy Server anfordern.
    • Der Organisation ermöglichen einen Konfigurations-Kanal für zukünftige RHN Proxy Server-Installationen zu erstellen und zu füllen.
    • Die SSl Konfiguration abschließen.
    • Alle Service-Dämonen, deren Konfigurationen geändert wurde, neu starten. 
    You do not have monitoring installed. Do you want to install it?
Will run 'yum install spacewalk-proxy-monitoring'.  [Y/n]:n
    Bestätigen Sie, ob Sie Monitoring-Unterstützung auf dem Proxy Server installieren möchten oder nicht. 
    Generating CA key and public certificate:
CA password: 
CA password confirmation: 
Copying CA public certificate to /var/www/html/pub for distribution to clients:
Generating SSL key and public certificate:
CA password: 
Backup made: 'rhn-ca-openssl.cnf' --> 'rhn-ca-openssl.cnf.1'
Rotated: rhn-ca-openssl.cnf --> rhn-ca-openssl.cnf.1
Installing SSL certificate for Apache and Jabberd:
Preparing packages for installation...
rhn-org-httpd-ssl-key-pair-proxy1.example-1.0-1
    Das configure-proxy.sh-Programm konfiguriert dann SSL und fordert Sie dazu auf, ein Passwort für die Certificate Authority zu erstellen und zu bestätigen, bevor schließlich die SSL-Schlüssel und das öffentliche Zertifikat erstellt werden. 
    Create and populate configuration channel rhn_proxy_config_1000010000? [Y]:
Using server name satserver.example.com
Red Hat Network username: admin
Password:
Creating config channel rhn_proxy_config_1000010000
Config channel rhn_proxy_config_1000010000 created
using server name satserver.example.com
Pushing to channel rhn_proxy_config_1000010000:
Local file /etc/httpd/conf.d/ssl.conf -> remote file /etc/httpd/conf.d/ssl.conf
Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf
Local file /etc/rhn/cluster.ini -> remote file /etc/rhn/cluster.ini
Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf
Local file /etc/httpd/conf.d/cobbler-proxy.conf -> remote file /etc/httpd/conf.d/cobbler-proxy.conf
Local file /etc/httpd/conf.d/rhn_proxy.conf -> remote file /etc/httpd/conf.d/rhn_proxy.conf
Local file /etc/httpd/conf.d/rhn_broker.conf -> remote file /etc/httpd/conf.d/rhn_broker.conf
Local file /etc/httpd/conf.d/rhn_redirect.conf -> remote file /etc/httpd/conf.d/rhn_redirect.conf
Local file /etc/jabberd/c2s.xml -> remote file /etc/jabberd/c2s.xml
Local file /etc/jabberd/sm.xml -> remote file /etc/jabberd/sm.xml
    Das Installationsprogramm fragt anschließend, ob Sie einen Konfigurations-Kanal basierend auf den Konfigurations-Dateien erstellen möchten, die beim Ausführen von configure-proxy.sh erstellt wurden. Daraufhin erstellt das Installationsprogramm einen RHN Satellite Server Konfigurations-Kanal, basierend auf dem Namen des Client-Systems, auf dem der RHN Proxy Server installiert ist (im obigen Beispiel lautet die sysID 1000010000), und sammelt die verschiedenen httpd, SSL, squid, und jabberd Server-Dateien, aus denen der Konfigurations-Kanal für den Proxy Server bestehen wird.
  9. Zu guter Letzt startet (bzw. startet neu) das Installationsprogramm alle Dienste, die mit dem RHN Proxy Server in Zusammenhang stehen; sobald dies abgeschlossen ist, beendet es sich selbst. 
    Enabling Satellite Proxy
Shutting down rhn-proxy...
Shutting down Jabber router:                               [  OK  ]
Stopping httpd:                                            [  OK  ]
Stopping squid:                                            [  OK  ]
Done.
Starting rhn-proxy...
init_cache_dir /var/spool/squid... Starting squid: .       [  OK  ]
Starting httpd:                                            [  OK  ]
Starting Jabber services                                   [  OK  ]
Done.

4.2.1. Die Antwortdatei

Falls Sie den Vorgang der RHN Proxy Server Installation auf Ihrem System teilweise automatisieren möchten, ermöglicht das configure-proxy.sh Programm den Administratoren, Antwortdateien zu erstellen, die vordefinierte Antworten auf die Eingabeaufforderungen im Installationsprogramm enthalten.
Im Folgenden sehen Sie ein Beispiel für eine Antwortdatei, die vordefinierte Antworten hinsichtlich der Versionsnummer, des RHN Satellite Servers, der als übergeordneter Server fungiert, SSL, und weiteren Konfigurations-Parametern enthält. Für weitere Informationen über die Erstellung und Verwendung von Antwortdateien werfen Sie bitte einen Blick auf die configure-proxy.sh Handbuchseite durch Eingabe von man configure-proxy.sh in einem Shell-Prompt. 
# Beispiel einer Antwortdatei für configure-proxy.sh
# Für eine vollständige Liste möglicher Optionen siehe
# man configure-proxy.sh

VERSION=5.2
RHN_PARENT=rhn-satellite.example.com
TRACEBACK_EMAIL=jsmith@example.com
USE_SSL=1
SSL_ORG="Red Hat"
SSL_ORGUNIT="Spacewalk"
SSL_CITY=Raleigh
SSL_STATE=NC
SSL_COUNTRY=US
INSTALL_MONITORING=N
ENABLE_SCOUT=N
CA_CHAIN=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
POPULATE_CONFIG_CHANNEL=Y
Um eine Antwortdatei (z.B. namens answers.txt) mit configure-proxy.sh zu verwenden, geben Sie ein: 
configure-proxy.sh --answer-file=answers.txt

Kapitel 5. RHN Package Manager und die Lieferung Lokaler Pakete

Der RHN Package Manager ist ein Befehlszeilen-Tool, durch das eine Organisation lokale Pakete mit einem privaten RHN-Channel durch den RHN Proxy Server betreuen kann. Installieren Sie den RHN Package Manager nicht um nur offizielle Red Hat-Pakete für den RHN Proxy Server zu aktualisieren.
Um den RHN Package Manager zu verwenden, installieren Sie das spacewalk-proxy-package-manager Paket samt aller Abhängigkeiten.
Es wird nur die Header-Information für Pakete auf die RHN Server hochgeladen. Die Header werden dazu benötigt, um RHN das Auflösen von Paketabhängigkeiten für die Client-Systeme zu ermöglichen. Die eigentlichen Paketdateien (*.rpm) befinden sich auf dem RHN Proxy Server.
Der RHN Package Manager verwendet dieselben Einstellungen wie der Proxy, die in der /etc/rhn/rhn.conf Konfigurations-Datei festgelegt sind.
Sehen Sie im Folgenden eine Zusammenfassung aller Befehlszeilen-Optionen für den RHN Package Manager rhn_package_manager:

Tabelle 5.1. Optionen für rhn_package_manager

Option Beschreibung
-v, --verbose Ausführlichkeit der Ausgabe erhöhen.
-dDIR, --dir=DIR Verarbeitet die Pakete des Verzeichnisses DIR.
-cCHANNEL, --channel=CHANNEL Verwaltet diesen Kanal — kann auch mehrmals vorhanden sein.
-nNUMBER, --count=NUMBER Verarbeitet diese Anzahl von Headern pro Aufruf — Standard ist 32.
-l, --list Listet jeden Paketnamen, jede Versionsummer, Release-Nummer und Architektur in den festgelegten Channels/im Channel auf.
-s, --sync Überprüft, ob lokales Verzeichnis mit dem Server abgestimmt (synchron) ist.
-p, --printconf Zeigt die aktuelle Konfiguration an und beendet.
-XPATTERN, --exclude=PATTERN Schließt Dateien aus, die diesem globalen Ausdruck entsprechen — kann auch mehrmals vorhanden sein.
--newest Sende nur die Pakete, die neuer sind als die bereits für den festgelegten Kanal zum Server gesendeten Pakete.
--stdin Liest die Paketnamen von der Standardeingabe.
--nosig Sende nicht-signierte Pakete. Standardmäßig versucht der RHN Package Manager, nur signierte Pakete zu senden.
--username=USERNAME Geben Sie Ihren RHN-Benutzernamen ein. Wenn Sie mit dieser Option keinen Benutzernamen angeben, dann werden Sie dazu aufgefordert.
--password=PASSWORD Geben Sie Ihr RHN-Passwort ein. Wenn Sie mit dieser Option kein Passwort angeben, dann werden Sie dazu aufgefordert.
--source Lädt Quellpaket-Header hoch.
--dontcopy Nach dem Hochladen werden die Pakete nicht automatisch in den Paketbaum kopiert.
--test Zeigt nur die zu sendenden Pakete an.
--no-ssl Nicht empfohlen — SSL abschalten.
-?, --usage Beschreibt kurz die Optionen.
--copyonly Kopiert die als Parameter angegebene Datei in den angegebenen Kanal. Nützlich, wenn einem Kanal auf dem Proxy ein Paket fehlt und Sie nicht alle Pakete im Kanal nochmals importieren möchten. Beispielsweise: rhn_package_manager-cCHANNEL--copyonly/PATH/TO/MISSING/FILE
-h, --help Zeigt den Hilfebildschirm mit einer Liste von Optionen an.

Anmerkung

Diese Befehlszeilenoptionen sind auch auf der rhn_package_manager Handbuchseite aufgeführt: man rhn_package_manager.
Damit RHN Package Manager in der Lage ist die lokalen Pakete zu senden müssen die folgenden Schritte beachtet werden:
  1. Einrichten eines privaten Kanals.
  2. Laden der lokalen Pakete in the Kanal.
Die Schritte werden in den folgenden Abschnitten weiter besprochen.

5.1. Erstellen eines Privaten Kanals

Bevor lokale Pakete durch den RHN Proxy Server bereitgestellt werden können, benötigen Sie einen privaten Kanal zur Aufbewahrung. Führen Sie folgende Schritte durch, um einen privaten Kanal einzurichten:
  1. Melden Sie sich über die RHN-Weboberfläche bei https://rhn.redhat.com an.
  2. Klicken Sie auf Channels auf der oberen Navigationsleiste. Wenn die Channels verwalten Option nicht in der linken Navigationsleiste erscheint, dann versichern Sie sich, dass dieser Benutzer über die Berechtigungen zur Kanal-Bearbeitung verfügt. Gehen Sie dazu zur Benutzer Kategorie, die über die obere Navigationsleiste zugänglich ist.
  3. In der linken Navigationsleiste klicken Sie Software Channels verwalten und dann die Neuen Channel erstellen Schaltfläche ganz rechts oben auf der Seite.
  4. Wählen Sie eine Parent-Channel- und Basis-Channel-Architektur aus und geben dann Name, Label, Zusammenfassung und Beschreibung für den neuen privaten Kanal ein. Das Label muss mindestens sechs Zeichen lang sein, mit einem Buchstaben beginnen und darf nur Kleinbuchstaben, Zahlen, Bindestriche (-) und Punkte enthalten. Geben Sie auch die URL des GPG-Schlüssels des Kanals ein. Obwohl dies kein zwingend erforderliches Feld ist, wird es empfohlen, um die Sicherheit zu erhöhen. Siehe RHN Channel-Managementhandbuch für eine Anleitung zur Herstellung von GPG-Schlüsseln.
  5. Klicken Sie auf Kanal erstellen.

5.2. Hochladen von Paketen

Anmerkung

Sie müssen ein Organisations-Administrator sein, um Pakete auf private RHN-Channels hochladen zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und Passwort.
Nach dem Einrichten des privaten Kanals können Sie die Paket-Header für Ihre Binär- und Quell-RPMs auf den RHN Server hochladen und die Pakete zum RHN Proxy Broker Server kopieren. Um die Paket-Header für die Binär-RPMs hochzuladen, geben Sie folgendes in der Befehlszeile ein: 
 rhn_package_manager -c "label_of_private_channel" pkg-list
Dieser Befehl ladet den Header des Pakets in den angegebenen Kanal, und das Paket selbst in /var/spool/rhn-proxy/rhn.
pkg-list ist die Liste der hochzuladenden Pakete. Wahlweise können Sie auch die -d Option verwenden, um das lokale Verzeichnis festzulegen, welches die zum Kanal hinzuzufügenden Pakete enthält. Vergewissern Sie sich, dass das Verzeichnis nur die benötigten Pakete enthält und keine anderen Dateien. Der RHN Package Manager kann die Liste von Paketen auch von der Standardeingabe lesen (unter Verwendung von --stdin).
Um die Paket-Header für die Quell-RPMs hochzuladen: 
 rhn_package_manager -c "label_of_private_channel" --source pkg-list
Wenn Sie mehr als einen Kanal angegeben haben (unter Verwendung der -c oder --channel Option), werden die hochgeladenen Paket-Header mit allen aufgelisteten Channels verknüpft.

Anmerkung

Wenn kein Kanal-Name angegeben wird, werden die Pakete zu keinem Kanal hinzugefügt. Die Pakete können dann einem Kanal mit Hilfe der Red Hat Network Weboberfläche hinzugefügt werden. Die Schnittstelle kann auch zur Modifizierung bestehender privater Channels verwendet werden.
Nach dem Hochladen der Pakete können Sie umgehend auf der RHN Weboberfläche überprüfen, ob diese aufgelistet sind. Klicken Sie auf Channels in der oberen Navigationsleiste, auf Software-Channels verwalten in der linken Navigationsleiste und dann auf den Namen des benutzerdefinierten Kanals. Klicken Sie dann auf den Pakete Unter-Tab. Jedes RPM-Paket sollte aufgelistet sein.
Sie können auch mit Hilfe der Befehlszeile überprüfen, ob das lokale Verzeichnis mit dem Image der Channels des RHN Servers übereinstimmt: 
 rhn_package_manager -s -c "label_of_private_channel"
Die -s Option listet alle fehlenden Pakete (Hochgeladene Pakete auf dem RHN Server, die nicht im lokalen Verzeichnis vorhanden sind). Sie müssen ein Organization Administrator sein, um diesen Befehl verwenden zu können. Das Skript verlangt Ihren RHN-Benutzernamen und das Passwort.
Wenn Sie den RHN Package Manager dazu verwenden, lokale Pakete hochzuladen, müssen Sie dazu auf die RHN-Website gehen, um das System beim privaten Kanal anzumelden.

Kapitel 6. Upgrade Installation

Dieses Kapitel beschreibt, wie Sie Ihre Installation des RHN Proxy Server aktualisieren können. Es nimmt an, dass Sie einen voll in Betrieb befindlichen RHN Proxy Server sowie die erforderlichen Berechtigungen dafür haben.

6.1. Voraussetzungen

Für die neueste Version des RHN Proxy Servers bedarf es:
  • Red Hat Enterprise Linux 5 (32-bit oder 64-bit) oder Red Hat Enterprise Linux 6 (nur 64-bit).
  • Die Löschung des Systemprofils vom alten Proxy Server von Red Hat Network Classic oder des übergeordneten Satellite Servers (falls zutreffend).

6.2. Upgrade Installationsvorgang

  1. Sichern Sie Ihren Proxy Server. Falls zutreffend, stellen Sie SSL Aufbau-Anweisungen vom Backup in das Verzeichnis /root/ssl-build wieder her.
  2. Registrieren Sie den Proxy Server auf entweder Red Hat Network Classic oder dem übergeordneten Satellite Server (falls zutreffend). Stellen Sie sicher, dass der Proxy-Server sowohl für den Red Hat Enterprise Linux Server Basis-Channel und den Red Hat Network Tools Sub-Channel subskribiert ist.
  3. Installieren Sie das spacewalk-proxy-installer Paket vom Red Hat Network Tools Sub-Channel: 
    # yum install spacewalk-proxy-installer
  4. Installieren Sie die neueste Version von Proxy, wie in Abschnitt 4.2, »RHN Proxy Server Installationsvorgang« dokumentiert.

    Anmerkung

    Wenn der Proxy-Server mit Red Hat Network Classic registriert ist und der Proxy Server zuvor benutzerdefinierte Kanäle verwaltete, müssen Sie das benutzerdefinierte Paket-Repository von der Sicherung vor dem Upgrade wiederherstellen. Die Berechtigungen und Besitzer müssen auch ordnungsgemäß eingerichtet werden. 
    # chmod 0750 /var/spool/rhn-proxy
# chown apache:apache /var/spool/rhn-proxy
# mkdir -m 0750 -p /var/spool/rhn-proxy/list
# chown apache:apache /var/spool/rhn-proxy/list
    Das Standard benutzerdefinierte Paket-Repository ist in der Regel /var/spool/rhn-proxy.
  5. Nach der Installation aktualisieren Sie den Server auf die neuesten Berichtigungs-Updates: 
    # yum update
  6. Neustart der RHN Proxy Server-Dienste und testen Sie die RHN Proxy Server-Funktionalität: 
    # /usr/sbin/rhn-proxy restart

Kapitel 7. Suche und Bereinigung von Fehlern

Dieses Kapitel enthält Tipps zur Suche und Bereinigung der am häufigsten auftretenden Fehler in Zusammenhang mit RHN Proxy Servern. Sollten Sie zusätzliche Hilfe benötigen, dann kontaktieren Sie bitte den Red Hat Network Support unter https://rhn.redhat.com/help/contact.pxt. Melden Sie sich mit Ihrem Proxy-berechtigten Account an, um die vollständige Liste an Optionen zu erhalten.

7.1. Verwalten des Proxy-Dienstes

Da der RHN Proxy Server aus einer Vielzahl individueller Komponenten besteht, stellt Red Hat ein Skript namens rhn-proxy zur Verfügung, das es Administratoren ermöglicht, zu beenden, zu starten, neu zu starten oder einen Status auf dem Proxy zu erhalten.

Tabelle 7.1. rhn-proxy Befehle

Befehl Funktion
/usr/sbin/rhn-proxy start Dieser Befehl startet den RHN Proxy Server, wenn er nicht bereits gestartet ist.
/usr/sbin/rhn-proxy stop Dieser Befehl stoppt den RHN Proxy Server, wenn er nicht bereits angehalten ist.
/usr/sbin/rhn-proxy restart Dieser Befehl stoppt den laufenden RHN Proxy Server und starten ihn neu. Wenn der RHN Proxy Server bereits gestoppt ist, wird er gestartet.
/usr/sbin/rhn-proxy status Dieser Befehl zeigt den aktuellen Status des RHN Proxy Servers an.

7.2. Protokolldateien

Nahezu jede Suche und Bereinigung von Fehlern sollte damit beginnen, sich die damit in Verbindung stehende(n) Protokolldatei(en) genauer anzusehen. Diese Dateien liefern außerordentlich wertvolle Informationen über die Abläufe auf den Einheiten oder innerhalb der Applikation und können dazu verwendet werden, das allgemeine Leistungsverhalten zu überwachen und damit eine einwandfreie Konfiguration zu gewährleisten. Siehe Tabelle 7.2, »Protokolldateien« für die Pfade zu allen relevanten Protokolldateien:

Tabelle 7.2. Protokolldateien

Komponente Speicherort der Protokolldatei
Apache Web server /var/log/httpd/-Verzeichnis
Squid /var/log/squid/-Verzeichnis
RHN Proxy Broker Server /var/log/rhn/rhn_proxy_broker.log
RHN SSL Redirect Server /var/log/rhn/rhn_proxy_redirect.log
Red Hat Update Agent /var/log/yum.log

7.3. Fragen und Antworten

Dieser Abschnitt beinhaltet die Antworten zu den am häufigsten gestellten Fragen hinsichtlich Installation und Konfiguration einer RHN Proxy Server Lösung.
F: Wie kann ich nach der Konfiguration des RHN Package Managers feststellen, ob die lokalen Pakete erfolgreich zum privaten RHN-Channel hinzugefügt wurden?
F: Ich habe die DNS-Namenseinstellung auf meinem Proxy-Server geändert, und nun können meine Client-Systeme sich nicht mehr aktualisieren. Wie kann ich das beheben?
F: Wie kann ich feststellen, ob die Clients mit dem Squid-Server verbunden sind?
F: Der Red Hat Update Agent auf dem Client-System verbindet nicht über den RHN Proxy Server. Wie kann dieser Fehler behoben werden?
F: Meine RHN Proxy Server-Konfiguration funktioniert nicht. Wo fange ich mit der Fehlersuche an?
F:
Wie kann ich nach der Konfiguration des RHN Package Managers feststellen, ob die lokalen Pakete erfolgreich zum privaten RHN-Channel hinzugefügt wurden?
A:
Führen Sie den Befehl rhn_package_manager -l -c "name_of_private_channel" aus, um die den RHN-Servern bekannten Pakete in den privaten Channels aufzulisten. Oder verwenden Sie dazu die RHN Weboberfläche.
Nachdem Sie ein registriertes System bei einem privaten Channel angemeldet haben, können Sie auch den up2date -l --showall Befehl auf den registrierten Systemen anwenden, um im privaten RHN-Channel nach den Paketen zu suchen.
F:
Ich habe die DNS-Namenseinstellung auf meinem Proxy-Server geändert, und nun können meine Client-Systeme sich nicht mehr aktualisieren. Wie kann ich das beheben?
A:
Führen Sie den Befehl up2date -u auf dem Client-System aus, damit die Namensänderung wirksam wird.
F:
Wie kann ich feststellen, ob die Clients mit dem Squid-Server verbunden sind?
A:
Die /var/log/squid/access.log Datei protokolliert alle Verbindungen zum Squid-Server.
F:
Der Red Hat Update Agent auf dem Client-System verbindet nicht über den RHN Proxy Server. Wie kann dieser Fehler behoben werden?
A:
Vergewissern Sie sich, dass die neueste Version des Red Hat Update Agents auf den Client-Systemen installiert ist. Die neuste Version enthält die Features, die zur Verbindung durch einen RHN Proxy Server notwendig sind. Die neueste Version erhalten Sie über das Red Hat Network durch Ausführen des yum update yum Befehls als Root oder von http://www.redhat.com/support/errata/.
Der RHN Proxy Server stellt eine Erweiterung von Apache dar. Siehe Tabelle 7.2, »Protokolldateien« um herauszufinden, wo sich die Protokolldateien befinden.
F:
Meine RHN Proxy Server-Konfiguration funktioniert nicht. Wo fange ich mit der Fehlersuche an?
A:
Überprüfen Sie, ob /etc/sysconfig/rhn/systemid dem Benutzer root.apache gehört und die Berechtigungen 0640 besitzt.
Lesen Sie die Protokolldateien. Eine Liste finden Sie in Tabelle 7.2, »Protokolldateien«.

7.4. Allgemeine Probleme

Um mit der Problembehandlung von allgemeinen Problemen zu beginnen, untersuchen Sie die Protokolldatei(en), die mit der Komponente in Zusammenhang stehen, die das Fehlverhalten aufweist. Führen Sie den Befehl tail für alle Protokolldateien aus und lassen dann up2date --list laufen. Daraufhin sollten Sie alle neuen Protokolleinträge nach möglichen Anhaltspunkten untersuchen.
Ein häufiges Problem ist voller Speicherplatz. Ein nahezu sicheres Zeichen dafür ist das Auftreten von abgebrochenen Aufzeichnungen in den Protokolldateien. Wenn das Protokollieren während des Schreibvorganges abgebrochen wurde, wie beispielsweise mitten im Wort, dann haben Sie höchstwahrscheinlich einen vollen Datenträger. Zur Bestätigung dieser Annahme führen Sie einfach folgenden Befehl aus und überprüfen die Prozentsätze in der Use% Spalte: 
df -h
Zusätzlich zu Protokolldateien können Sie wertvolle Information auch durch die Abfrage des Status Ihrer unterschiedlichen Komponenten erhalten. Dies ist für den Apache Web Server und Squid möglich.
Um den Apache Web Server Status abzufragen, führen Sie den folgenden Befehl aus: 
service httpd status
Um den Squid-Status abzufragen, führen Sie den folgenden Befehl aus: 
service squid status
Wenn der Administrator keine E-Mails vom RHN Proxy Server erhält, dann überprüfen Sie, dass die E-Mail-Adressen für traceback_mail in /etc/rhn/rhn.conf korrekt gesetzt wurden.

7.5. Host nicht gefunden/FQDN konnte nicht ermittelt werden

Da RHN-Konfigurations-Dateien ausschließlich auf voll qualifizierten Domain-Namen (FQDNs) beruhen, ist es unerlässlich, dass Schlüsselapplikationen den Namen des RHN Proxy Server in eine IP-Adresse auflösen können. Red Hat Update Agent, Red Hat Network Registration Client und der Apache Web Server sind für dieses Problem besonders anfällig. Nachdem der Startvorgang scheitert, geben die RHN Applikationen Fehlermeldungen wie "host not found" (Host nicht gefunden) und "Could not determine the server's fully qualified domain name" (FQDN konnte nicht ermittelt werden) aus.
Dieses Problem hat normalerweise seine Ursache in der /etc/hosts Datei. Sie können diese Annahme bestätigen, indem Sie sich /etc/nsswitch.conf genauer ansehen, in welcher das Verfahren und die Reihenfolge festgelegt wird, in der Domainnamen aufgelöst werden. Normalerweise wird die Datei /etc/hosts zuerst überprüft, gefolgt vom Network Information Service (NIS), gefolgt von DNS. Eine dieser Überprüfungen muss erfolgreich sein, damit der Apache Web Server starten kann und die RHN-Client-Applikationen funktionieren können.
Um dieses Problem zu beheben, sehen Sie sich die Inhalte der /etc/hosts Datei genauer an. Diese können ungefähr so aussehen: 
127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost
In einem Text-Editor entfernen Sie die Maschinen Host-Informationen aus der Datei. Es sollte so aussehen: 
127.0.0.1 localhost.localdomain.com localhost
Speichern Sie die Datei und versuchen Sie die RHN-Client-Applikationen oder den Apache Web Server erneut zu starten. Wenn dies immer noch fehlschlägt, dann geben Sie ausdrücklich die IP-Adresse des Proxys in der Datei an, wie z.B.: 
127.0.0.1 localhost.localdomain.com localhost
123.45.67.8 this_machine.example.com this_machine
Ersetzen Sie hier den Wert durch die tatsächliche IP-Adresse des Proxys. Damit sollte das Problem behoben sein. Denken Sie daran dass, falls diese spezielle IP-Adresse auf diese Art festgelegt ist, die Datei immer dann aktualisiert werden muss, wenn die Maschine eine neue Adresse erhält.

7.6. Verbindungsfehler

Wenn Sie Probleme haben, die wahrscheinlich auf eine fehlgeschlagene Verbindung zurückzuführen sind, dann können Sie Folgendes tun:
  • Bestätigen Sie, dass das richtige Paket: 
     rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm
    auf dem RHN Proxy Server installiert ist, und dass das entsprechende rhn-org-trusted-ssl-cert-*.noarch.rpm oder das öffentliche Originale CA SSL-(Client)-Zertifikat auf allen Client-Systemen installiert ist.
  • Überprüfen Sie dass die Client-Systeme konfiguriert sind das entsprechende Zertifikat zu verwenden.
  • Wenn Sie einen oder mehrere RHN Proxy Server verwenden, überprüfen Sie, ob das SSL-Zertifikat eines jeden Proxys richtig vorbereitet ist. Wenn Sie den RHN Proxy Server in Verbindung mit einem RHN Satellite Server verwenden, sollte der Proxy sowohl sein eigenes Server-SSL-Schlüsselpaar als auch das öffentliche SSL-(Client)-Zertifikat Ihrer CA installiert haben. Für detaillierte Informationen verweisen wir dazu auf das Kapitel SSL-Zertifikate im RHN Client-Konfigurationshandbuch.
  • Falls der RHN Proxy Server über einen HTTP-Proxy verbindet, überprüfen Sie, ob die URL gültig ist. Beispielsweise sollte das HTTP-Proxy URL-Feld keine Verweise auf Protokolle enthalten, wie beispielsweise http:// oder https://. Nur der Hostname und Port sollten als hostname:port, wie beispielsweise your-gateway.example.com:8080, angegeben werden.
  • Vergewissern Sie sich, dass Client-Systeme keine eigenen Firewalls verwenden und somit erforderliche Ports blockieren, wie in Abschnitt 2.4, »Weitere Anforderungen« aufgezeigt.

7.7. Caching-Probleme

Falls die Paketlieferung fehlschlägt oder ein Objekt fehlerhaft erscheint und dies nicht auf Verbindungsfehler zurückzuführen ist, sollten Sie in Betracht ziehen, die Caches zu leeren. Der RHN Proxy Server besitzt zwei Caches, mit denen Sie sich befassen sollten: einen für Squid und den anderen zur Authentifizierung.
Der Squid-Cache befindet sich in /var/spool/squid/. Um ihn zu löschen:
  1. Anhalten des Apache Web Servers: service httpd stop
  2. Anhalten des Squid Servers: service squid stop
  3. Löschen Sie den Inhalt des Verzeichnisses: rm -fv /var/cache/rhn/*
  4. Starten Sie beide Dienste neu: 
    	
			service squid start
			service httpd start
Die gleiche Aufgabe kann schneller durch Löschen des Verzeichnisses und Neustart von Squid erreicht werden, aber diese Methode wird höchstwahrscheinlich zu einer Anzahl von RHN Traceback Nachrichten führen.
Der interne Caching-Mechanismus, der durch das Proxy zur Authentifizierung verwendet wird, sollte eventuell ebenfalls entleert werden. Führen Sie dazu den folgenden Befehl aus: 
 rm -fv /var/cache/rhn/*
Auch wenn der RHN Authentication Daemon seit der RHN Proxy Server 3.2.2 Release nicht mehr verwendet wird und durch den zuvor erwähnten internen Authentifizierungs-Mechanismus ersetzt wurde, kann es sein, dass der Daemon immer noch auf Ihrem Proxy läuft. Um diesen abzuschalten, führen Sie folgende individuelle Befehle in dieser Reihenfolge aus: 
 chkconfig --level 2345 rhn_auth_cache off service rhn_auth_cache stop
Um den Cache zu leeren, geben Sie den folgenden Befehl ein: 
 rm /var/up2date/rhn_auth_cache
Wenn Sie jedoch den RHN Authentication Daemon beibehalten müssen, was von Red Hat weder empfohlen noch unterstützt wird, dann kann es sein, dass seine Leistung durch die ausführliche Protokollierung leidet. Aus diesem Grund ist dessen Protokollierung (nach /var/log/rhn/rhn_auth_cache.log) standardmäßig deaktiviert. Wenn Sie den Daemon ausführen und die Protokollierung wünschen, dann können Sie diese wieder einschalten, indem Sie folgende Zeile in der /etc/rhn/rhn.conf Datei des Proxys hinzufügen: 
auth_cache.debug = 2

7.8. Suche und Bereinigung von Proxy-Fehlern durch Red Hat

Wenn alle diese Schritte zur Problembehandlung ausgeschöpft sind oder wenn sie diese an Red Hat Network-Profis abtreten möchten, empfiehlt Red Hat, dass Sie die Vorteile der starken Unterstützung, die mit RHN Proxy Server kommt, nutzen.
Eine Möglichkeit, auf dieses Fachwissen zuzugreifen, ist mittels der Red Hat Wissensdatenbank, die Lösungen für häufig bei Benutzern aufgetretene Probleme bereitstellt, sowie eine robuste Oberfläche zum Stöbern und Suchen bietet, um die richtige Antwort auf Ihr Proxy-Problem zu finden. Sie finden die Red Hat Wissensdatenbank unter http://kbase.redhat.com.
Zusätzlich bietet Red Hat ein Befehlszeilen-Tool namens SoS Report an, weitläufig auch unter dem Befehlsnamen sosreport bekannt. Dieses Tool sammelt die Konfigurationsparameters Ihres Proxys, die Protokolldateien und Datenbankinformationen, und sendet alles direkt an Red Hat.
Um dieses Tool für RHN Satellite Server Informationen zu nutzen, muss das sos Paket installiert sein. Geben Sie als Root sosreport -o rhn auf dem Satellite Server ein, um einen Report zu erzeugen. Zum Beispiel: 
[root@satserver ~]# sosreport -o rhn

sosreport (version 1.7)

This utility will collect some detailed  information about the
hardware and  setup of your  Red Hat Enterprise Linux  system.
The information is collected and an archive is  packaged under
/tmp, which you can send to a support representative.
Red Hat will use this information for diagnostic purposes ONLY
and it will be considered confidential information.

This process may take a while to complete.
No changes will be made to your system.

Press ENTER to continue, or CTRL-C to quit.
Sie werden anschließend nach dem Anfangsbuchstaben Ihres Vornamens und Ihrem Nachnamen gefragt, dann nach einer Support-Ticketnummer (auch Issue-Tracker-Nummer genannt).
Es kann einige Minuten dauern, bis das System den Bericht erzeugt und in einer komprimierten Datei abgespeichert hat. Sobald dieser Vorgang abgeschlossen ist, emailen Sie die neue Datei im /tmp/ Verzeichnis zur umgehenden Diagnose an Ihren Red Hat Vertreter.

Anhang A. Beispiel für eine RHN Proxy Server Konfigurations-Datei

Die /etc/rhn/rhn.conf Konfigurations-Datei für den RHN Proxy Server ermöglicht einem Administrator grundlegende Einstellungen festzulegen. Seien Sie jedoch gewarnt, dass Fehler in dieser Datei Proxy-Ausfälle zur Folge haben können. Machen Sie daher Änderungen an der Konfiguration mit Vorsicht.
Wenn Sie auch einen RHN Satellite Server verwenden, sollten Sie sich speziell mit folgenden Parametern befassen: traceback_mail und proxy.rhn_parent. Sehen Sie das Beispiel und die Kommentare (beginnend mit dem Rauten-Zeichen #) genauer an.

Anmerkung

Sie können die use_ssl Option der rhn.conf Datei nur für Testzwecke hinzufügen. Setzen Sie den Wert auf 0, um SSL zwischen dem Proxy und dem Upstream-Server vorübergehend auszuschalten. Beachten Sie bitte, dass dadurch die Sicherheit extrem gefährdet wird. Setzen Sie die Einstellung wieder auf den Standardwert 1 zurück, um SSL wieder zu aktivieren oder entfernen Sie die Zeile einfach aus der Konfigurations-Datei. 
# Automatically generated RHN Management Proxy Server configuration file.
# -------------------------------------------------------------------------

# SSL CA certificate location
proxy.ca_chain = /usr/share/rhn/RHNS-CA-CERT

# Corporate HTTP proxy, format: corp_gateway.example.com:8080
proxy.http_proxy = 

# Password for that corporate HTTP proxy
proxy.http_proxy_password = 

# Username for that corporate HTTP proxy
proxy.http_proxy_username = 

# Location of locally built, custom packages
proxy.pkg_dir = /var/spool/rhn-proxy

# Hostname of RHN Server or RHN Satellite
proxy.rhn_parent = rhn.redhat.com

# Destination of all tracebacks, etc.
traceback_mail = user0@domain.com, user1@domain.com

Anhang B. Versionsgeschichte

Versionsgeschichte
Version 3-5.2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 3-5.2Mon Apr 22 2013Rainer Gromansperg
Übersetzung und Korrekturgelesen abgeschlossen
Version 3-5.1Thu Mar 21 2013Hedda Peters
Übersetzungsdateien synchronisiert mit XML-Quellen 3-5
Version 3-5Wed Sept 19 2012Dan Macpherson
Endgültige Zusammenstellung für 5.5
Version 3-4 Wed Jul 4 2012Athene Chan
Vorbereitet für 5.5 Release
Änderungen nach technischer Überprüfung implementiert
BZ#491007 Kapitel über Upgrade Installation Hinzugefügt
Version 3-0 Wed Jul 4 2012Athene Chan
Vorbereitet für 5.5 Release
Änderungen nach technischer Überprüfung implementiert
BZ#491007 Kapitel über Upgrade Installation Hinzugefügt
Version 2-5Thu Jan 5 2012Lana Brindley
BZ#682996 - Kapitel Installation - Update Anleitung
BZ#705755 - Kapitel Package Manager - Zusätzliche Information
BZ#722193 - Kapitel Anforderungen - Fehler behoben
BZ#729617 - Kapitel Installation - Fehler behoben
BZ#729663 - Kapitel Installation - Warnung hinzugefügt
Version 2-4Mon Aug 15 2011Lana Brindley
Änderungen der z-Stream Release in y-Stream-Release eingebracht
Version 2-3Wed Jun 22 2011Lana Brindley
BZ#713527 - Hinweise auf RHEL 6 hinzugefügt
Version 2-2Wed Jun 15 2011Lana Brindley
Vorbereitet für Veröffentlichung
Version 2-1Fri May 27 2011Lana Brindley
Änderungen von Übersetzern
Version 2-0Fri May 6 2011Lana Brindley
Vorbereitet für Übersetzung
Version 1-9Wed April 27 2011Lana Brindley
BZ#653844 - QE-Prüfung
Version 1-8Mon Feb 7 2011Lana Brindley
BZ#646176 - Installation

Stichwortverzeichnis

A

Allgemeine Probleme, Allgemeine Probleme
Anforderungen, Anforderungen
Hardware, Hardware-Anforderungen
Software, Software-Anforderungen
Speicherplatz, Speicherplatzanforderungen
weitere, Weitere Anforderungen
Ausgehende Ports
80, 443, Weitere Anforderungen
Authentifizierung, Proxy Funktionsweise
Authentifizierungs-Cache
löschen, Caching-Probleme

C

Caching-Probleme, Caching-Probleme
Channel, Häufig verwendete Terminologien
Channel Adminstrator, Häufig verwendete Terminologien
Client-Konfiguration
Subskribieren eines privaten Kanals, Hochladen von Paketen

E

Eingehende Ports, Satellite
5222, Weitere Anforderungen

F

Fragen und Antworten, Fragen und Antworten

H

Hardware-Anforderungen, Hardware-Anforderungen
Häufig verwendete Terminologien, Häufig verwendete Terminologien
Host nicht gefunden (Host Not Found) Fehler
FQDN konnte nicht ermittelt werden (Could Not Determine FQDN), Host nicht gefunden/FQDN konnte nicht ermittelt werden
HTTP Proxy Caching Server
Speicherplatzanforderungen, Speicherplatzanforderungen

I

Installation
Basis-, Basisinstallation
des RHN Proxy Servers, RHN Proxy Server Installationsvorgang

K

Kanal
Erstellen eines privaten Kanals, Erstellen eines Privaten Kanals

O

Organization Administrator, Häufig verwendete Terminologien

P

Port
443, Weitere Anforderungen
5222, Weitere Anforderungen
80, Weitere Anforderungen
Port 443, Weitere Anforderungen
Port 4545, Weitere Anforderungen
Port 80, Weitere Anforderungen
Privater Kanal, Erstellen eines Privaten Kanals
Protokolldateien, Protokolldateien
Proxy Funktionsweise, Proxy Funktionsweise
Proxy-Ports, Weitere Anforderungen

R

Red Hat Network
Einführung, Red Hat Netzwerk
Red Hat Update Agent, Häufig verwendete Terminologien, Proxy Funktionsweise
RHN Authentication Daemon, deaktivieren
rhn_auth_cache, stoppen, Caching-Probleme
RHN Package Manager, Proxy Funktionsweise, RHN Package Manager und die Lieferung Lokaler Pakete
Befehlszeilen-Optionen, RHN Package Manager und die Lieferung Lokaler Pakete
Channels spezifizieren, Hochladen von Paketen
Erstellen eines privaten Kanals, Erstellen eines Privaten Kanals
Hochladen von Paket-Headern, Hochladen von Paketen
Installation, RHN Package Manager und die Lieferung Lokaler Pakete
Konfiguration, Erstellen eines Privaten Kanals
Konfigurations-Datei, RHN Package Manager und die Lieferung Lokaler Pakete
Verifizieren der lokalen Paketliste, Hochladen von Paketen
rhn-proxy
Dienst, Verwalten des Proxy-Dienstes
rhn.conf
Beispieldatei, Beispiel für eine RHN Proxy Server Konfigurations-Datei
rhn_package_manager , Hochladen von Paketen (Siehe RHN Package Manager)

S

satellite-debug, Suche und Bereinigung von Proxy-Fehlern durch Red Hat
Software-Anforderungen, Software-Anforderungen
Speicherplatzanforderungen, Speicherplatzanforderungen
Squid-Cache, Caching-Probleme
Suche und Bereinigung von Fehlern, Suche und Bereinigung von Fehlern

T

Topologien, Beispieltopologien
einzelner Proxy, Einzel-Proxy-Topologie
mehrere Proxys horizontal gestaffelt, Mehrfach horizontal gestaffelte Proxy-Topologie
mehrfache Proxys, vertikal gestaffelt, Mehrfach vertikal gestaffelte Proxy-Topologie
Proxys mit RHN Satellite Server, Proxys mit RHN Satellite Server
Traceback, Häufig verwendete Terminologien

V

Verbindungsfehler, Verbindungsfehler
Vorteile, RHN Proxy Server

W

Weitere Anforderungen, Weitere Anforderungen

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.