Proxy-Installationshandbuch


Red Hat Network Satellite 5.4

Red Hat Network Satellite

Ausgabe 1

Zusammenfassung

Willkommen beim RHN Proxy-Installationshandbuch.

Kapitel 1. Einführung

1.1. Red Hat Network

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 eine einziger Systemadministrator hunderte oder gar tausende von Red Hat Systemen einfacher, genauer und schneller aufsetzen und verwalten, als nur ein einziges System ohne Red Hat Network.
  • Standardprotokolle — Standardprotokolle werden dazu verwendet, die 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.
  • Errata-Meldungen ansehen — sehen Sie sich auf einfachste Weise Errata-Meldungen für alle Ihre Client-Systeme auf einer einzigen Website an.
  • Geplante 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. RHN Proxy Server

Ein RHN Proxy Server ist ein Paket-Caching-Mechanismus, der die für RHN erforderliche Bandbreite reduziert und den Einsatz von angepassten Paketen unterstützt. Proxy-Kunden cachen RPMs wie z.B. Errata-Updates von Red Hat oder angepassten RPMs von anderen Organisationen, auf einem internen, zentralen Server. Client-Systeme empfangen somit ihre Updates vom Proxy, und nicht durch individuellen Zugriff auf das Internet.
Auch wenn die Pakete nun 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 angepasste Pakete von privaten RHN Channels mithilfe des RHN Package Manager bereitzustellen. Zum Beispiel kann eine Organisation ihre eigene Software entwickeln, in einem RPM einpacken, es mit einer eigenen GPG-Signatur versehen und mithilfe des lokalen RHN Proxy Servers alle einzelnen Systeme im Netzwerk mit der neuesten Version der angepassten Software aktualisieren.
Vorteile bei der Verwendung des RHN Proxy Servers sind u.a.:
  • 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.
  • Spart Bandbreite — Pakete werden nur einmal vom RHN heruntergeladen (über lokalem Proxy-Server-Catching-Mechanismus) anstatt jedes Paket für jedes Client-System einzeln herunterzuladen.
  • Angepasste Updates — stellen ein völlig automatisiertes Paketlieferungssystem für angepasste Software-Pakete sowie auch offizielle Red Hat-Pakete dar, welche für die Client-Systeme benötigt werden. Angepasste, private RHN-Channels ermöglichen es einem Unternehmen, die Lieferung von firmeninternen, betriebseigenen Paketen zu automatisieren.
  • Angepasste 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 den 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.3. Begriffserklärung

Bevor Sie sich mit dem RHN Proxy Server auseinandersetzen, ist es wichtig, sich zuerst mit folgenden Red Hat Network Begriffen vertraut zu machen:
Channel
Ein Channel ist eine Liste von Software-Paketen. Es gibt zwei Arten von Channels: Basis-Channels (Basiskanäle) und Sub-Channels (Unterkanäle). Ein Basis-Channel besteht aus einer Liste von 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.
Organisationsadministrator
Ein Organisationsadministrator ist eine Benutzerrolle mit dem höchsten Grad an Kontrolle über einen Red Hat Network Account eines Unternehmens. Die Mitglieder dieser Rolle können andere Benutzer, Systeme und Systemgruppen zum Unternehmen hinzufügen und auch entfernen. Eine Red Hat Network Organisation muss mindestens einen Organisationsadministrator besitzen.
Channel-Administrator
Ein Channel-Administrator 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 Organisationsadministrator über den Benutzer-Reiter 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 läuft, abfragen 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 Konfigurationsdatei des RHN Proxy Servers dafür vorgesehenen Personen gemailt.
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-Benutzeroberfläche.

1.4. 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. Sie 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 RHN Proxy Server dem RHN in diesem Fall sowohl Authentifizierungs- als auch Routing-Informationen zur Verfügung. Nach einer erfolgreichen Authentifizierung informiert der Red Hat Network Server 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 Zwischenspeicher 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 Server erreicht.
  2. Der Red Hat Network Server 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. abonnierte Channels, Benutzername, usw.
  3. Jeder RHN Proxy Server cacht diesen Token auf dem lokalem Dateisystem des Proxys in /var/cache/rhn/. Caching reduziert den Overhead in Zusammenhang mit der Authentifizierung mit Red Hat Network Servern und verbessert somit drastisch das Leistungsvermögen von Red Hat Network.
  4. Dieser Session-Token wird an den Client-Rechner zurückgesandt 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 werden und zum Bereitstellen angepasster 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 angepasster Software-Channel genannt) bereitgestellt werden. Nachdem ein privater RHN-Channel erstellt wurde, werden die angepassten 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, angepassten RPM-Pakete werden auf dem RHN Proxy Server aufbewahrt und an die Client-Systeme intern über das lokale Netzwerk des Unternehmens versandt.
Die Konfiguration eines Computernetzwerks zur Verwendung von RHN Proxy Servern ist ein recht unkomplizierter, überschaubarer 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 man den nächsten Proxy in der Kette festlegen (welche letztendlich mit einem Red Hat Network Server endet). Wenn der RHN Package Manager verwendet wird, müssen die Client-Systeme beim privaten RHN-Channel angemeldet sein.


[1] Im Laufe dieses Dokuments kann sich "RHN" entweder auf die RHNs Hosted Site (http://rhn.redhat.com) oder 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.1 installieren möchten, sollte die Satellite-Version 5.1 oder höher sein, darf jedoch nicht 5.0 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 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 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 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 von Paketen kann Fehler bei der Installation hervorrufen. Deshalb empfiehlt Red Hat, die gewünschten Paketsätze auf die folgenden Arten abzufragen:

    Anmerkung

    Für das Kickstarten legen Sie die folgende Paketgruppe fest: @Base
    Für die Installation von Red Hat Enterprise Linux via CD oder ISO-Image wählen Sie folgende Paketgruppe aus: Minimal
  • Eine verfügbare RHN Proxy Server-Berechtigung innerhalb Ihres RHN Satellite Server-Accounts.
  • Eine verfügbare Provisioning-Berechtigung innerhalb Ihres RHN Satellite Server-Accounts (welches Sie im Paket mit Ihrer RHN Proxy Server-Berechtigung erhalten sollten).
  • Zugriff auf den Red Hat Network Tools-Channel für die installierte Version von Red Hat Enterprise Linux. Dieser Channel 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 zur Generierung des Parent-Server-Zertifikats verwendet wird für RHN Satellite Server-Benutzer.
  • Eine Konfiguration auf dem System, die Befehle von Remote aus und Konfigurationsmanagement durch Red Hat Network akzeptiert, falls die veraltete Installationsmethode via Web-Oberfläche angewendet wird. Siehe Abschnitt 4.2, »RHN Proxy Server Installationsprozess« 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 Memory
  • Mindestens 5 GB Speicher für die Basisinstallation von Red Hat Enterprise Linux
  • 25+ GB Speicher pro Distribution/Channel
Die Last auf dem Apache Web server steht in direkter Relation zu 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 festgehalten, reduzieren, dann steigern Sie damit maßgeblich die Last auf dieser Komponente.

Anmerkung

Kickstart-Provisioning auf Multi-Homed Netzwerktopologien wird vom RHN Proxy Server nicht unterstützt. Kickstarts funktionieren nicht ordnungsgemäß auf einem Proxy Server, der mehr als eine Netzwerkschnittstelle besitzt.

2.3. Speicherplatzanforderungen

Der vom RHN Proxy Server eingesetzte Caching-Mechanismus ist der Squid HTTP-Proxy, welcher auf signifikante Weise Bandweite für die Clients einspart. Dieser sollte eine angemessene Menge an Speicherplatz zur Verfügung haben. Die gecachten Pakete werden in /var/spool/squid gespeichert. Die erforderliche Zuweisung an freiem Speicherplatz ist 6 GB Speicher pro Distribution/Channel.
Wenn der RHN Proxy Server zur Distribution von angepassten Paketen ("Custom-Pakete") oder lokalen Paketen konfiguriert ist, dann gehen Sie sicher, dass auf dem /var-Einhängepunkt auf dem System, welches die lokalen Pakete speichert, ausreichend Plattenplatz vorhanden ist, um sämtliche angepassten Pakete unterzubringen, die in /var/spool/rhn-proxy gespeichert sind. Der erforderliche Plattenplatz für lokale Pakete hängt von der Anzahl der bereitgestellten angepassten 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 eine Firewall vom Internet zu schützen. Jedoch sollten verschiedene TCP-Ports offen bleiben, je nach Implementierung des RHN Proxy Servers:
Expand
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 (abhängig davon, ob RHN Proxy 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 Proxy nutzt diesen Port, um rhn.redhat.com, xmlrpc.rhn.redhat.com und Ihre 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 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 den jabberd-Daemon auf den 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-fähigen Webserver (Secure Sockets Layer) 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.
Fully Qualified Domain Name (FQDN)
Das System auf dem der RHN Proxy Server installiert wird, muss in der Lage sein, den eigenen FQDN richtig aufzulösen.
Ein Red Hat Network-Account
Kunden, die sich mit den zentralen Red Hat Network Servern verbinden, um inkrementelle Updates zu erhalten, benötigen einen Red Hat Network Account. Dieser Account 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 Server sind dies u.a. Benutzernamen und Passwörter für den Organisationsadministrator-Account und die SSL-Zertifikat-Generierung. Es wird von Red Hat dringend empfohlen, dass diese Informationen auf zwei separate Datenträger kopiert wird, ausgedruckt wird, und der Ausdruck in einem feuersicheren Tresor aufbewahrt wird.
Distributionsspeicherorte
Da der Proxy nahezu alle lokalen HTTP-Anfragen an die zentralen RHN Server weiterleitet, müssen Sie darauf Acht geben, 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, 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. RHN Proxy Server-Installationshandbuch — Dieses Handbuch, welches Sie gerade lesen, behandelt die wesentlichen Schritte, um einen RHN Proxy Server einsatzbereit zu machen.
  2. RHN Client-Konfigurationshandbuch — 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 Referenzhandbuchs, welches Schritte zur Registrierung und Aktualisierung von Systemen enthält.)
  3. RHN Channel-Managementhandbuch — Dieses Handbuch behandelt detailgenau die empfohlenen Methoden für die Erstellung von angepassten Paketen und Channels sowie auch zur Verwaltung privater Errata.
  4. RHN Referenzhandbuch — Dieses Handbuch beschreibt das Einrichten von RHN-Accounts, 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 an Client-Systemen, für die der RHN Proxy Server als Server dient.
  2. Die maximale Anzahl an Clients, die erwartungsgemäß gleichzeitig mit dem RHN Proxy Server verbinden.
  3. Die Anzahl von angepassten Paketen und Channels, die vom RHN Proxy Server bereitgestellt werden.
  4. Die Anzahl an 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 angepassten 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.

Abbildung 3.1. Einzel-Proxy-Topologie

3.2. Mehrfach horizontal aufgereihte Proxy-Topologie

Für größere Netzwerke könnte eine verteiltere Methode erforderlich sein, wie beispielsweise mehrere RHN Proxy Server, die mit Red Hat Network individuell verbunden sind. Durch diese horizontal aufgereihte 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 ist die Notwendigkeit des Verteilens von angepassten Paketen an die Geschwister-Server, nachdem diese individuell auf einen Proxy hinaufgeladen wurden. Dieser Situation kann auf zwei Arten begegnet werden:
  • Entweder kann das Dateiübertragungsprogramm rsync dazu verwendet werden, Pakete zwischen den Proxys zu synchronisieren oder
  • es kann ein Network File System (NFS) Share zwischen den Proxys und dem als Repository dienenden angepassten Channel eingerichtet werden.
Jede dieser Lösungen ermöglicht es jedem Client von jeglichem RHN Proxy Server, alle angepassten Pakete geliefert zu bekommen.

Abbildung 3.2. Mehrfach horizontal aufgereihte Proxy-Topologie

3.3. Mehrfach vertikal aufgereihte 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 von Red Hat Network zu erhalten sowie auch angepasste 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 aufgereihten Konfiguration ermöglicht diese vertikale Methode jeglichem Client eines jeden RHN Proxy Servers, alle angepassten Pakete geliefert zu bekommen. Der Proxy sieht lediglich im eigenen Repository nach, ob das Paket sich im Dateisystem befindet. Wenn nicht, versucht der Proxy es eine Stufe höher.
Diese vertikal aufgereihte Konfiguration gewährleistet, dass die sekundären Proxys für Updates von RHN sowie auch für angepasste Pakete auf die primären Proxys angewiesen sind. Auch dürfen angepasste Channels und Pakete nur auf dem primären Proxy abgelegt werden, um eine Verteilung zu den untergeordneten Proxys sicherzustellen. Schlussendlich müssen die Konfigurationsdateien des sekundären Proxys auf den primären Proxy Server verweisen, anstatt direkt auf Red Hat Network.

Abbildung 3.3. Mehrfach vertikal aufgereihte 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 aufgereihte 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-Architekturen 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 auf 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 auf eine neuere Version von RHN Proxy Server aktualisieren, 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 der Partition genügend Platz zu, welcher dazu verwendet wird, Pakete gemäß den zuvor erwähnten Hardware-Anforderungen zu speichern. Gecachte Red Hat Pakete befinden sich standardmäßig in /var/spool/squid, während angepasste Pakete sich in /var/spool/rhn-proxy befinden.

    Anmerkung

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

    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 Installationsprozess

Die folgenden Anleitungen beschreiben den RHN Proxy Server Installationsprozess:
  1. 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 Unternehmens-Accounts, der die RHN Proxy Server Berechtigung beinhaltet, mit dem Befehl: rhn_register.
  2. Um eine Installation durchzuführen, geben Sie den folgenden Befehl ein:
    configure-proxy.sh
    
    Copy to Clipboard Toggle word wrap
    Das Befehlszeileninstallationsprogramm führt den 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 Installationsprozess:

    Anmerkung

    Wenn Sie an einem Prompt die Enter-Taste drücken, anstatt eine Eingabe zu tippen, so verwendet das Befehlszeileninstallationsprogramm 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.
  3. Bei der ersten Reihe von Eingabeaufforderungen werden Details abgefragt, spezifisch für den Rechner, auf dem Sie installieren.
    Proxy version to activate [5.3]:
    
    Copy to Clipboard Toggle word wrap
    Proxy version fordert Sie dazu auf, die Version des RHN Proxy Servers zu bestätigen, die Sie installieren möchten.
    RHN Parent [satserver.example.com]:
    
    Copy to Clipboard Toggle word wrap
    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 RHN Satellite Server Server sein.
    Traceback email []:
    
    Copy to Clipboard Toggle word wrap
    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 an diesem Prompt voneinander zu trennen.
  4. Die nächste Reihe von Eingabeaufforderungen bezieht 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
    
    Copy to Clipboard Toggle word wrap
    Tippen Sie am Use SSL-Prompt y, um den RHN Proxy Server für die Unterstützung von SSL zu konfigurieren.
    CA Chain [/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT]:
    
    Copy to Clipboard Toggle word wrap
    Drücken Sie am CA Chain-Prompt die Enter-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.
    HTTP Proxy []:
    
    Copy to Clipboard Toggle word wrap
    Falls der RHN Proxy Server über einen HTTP-Proxy verbindet, geben Sie den Proxy-Hostnamen und Portnummer ein, wie z.B. corporate.proxy.example.com:3128.
    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]:
    
    Copy to Clipboard Toggle word wrap
    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.
  5. Das Befehlszeileninstallationsprogramm fordert Sie auf, Monitoring-Support am RHN Proxy Server zu installieren; es erlaubt Ihnen, einen Konfigurations-Channel für zukünftige RHN Proxy Server-Installationen zu erstellen und zu bestücken, schließt die SSL-Konfiguration ab, und startet jegliche Dienst-Daemons neu, deren Konfiguration aufgrund der Ausführung des RHN Proxy Server-Installationsprogramms modifiziert worden sind.
    You do not have monitoring installed. Do you want to install it?
    Will run 'yum install spacewalk-proxy-monitoring'.  [Y/n]:n
    
    Copy to Clipboard Toggle word wrap
    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
    
    Copy to Clipboard Toggle word wrap
    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
    
    Copy to Clipboard Toggle word wrap
    Das Installationsprogramm fragt anschließend, ob Sie einen Konfigurations-Channel basierend auf den Konfigurationsdateien erstellen möchten, die beim Ausführen von configure-proxy.sh erstellt wurden. Daraufhin erstellt das Installationsprogramm einen RHN Satellite Server Konfigurations-Channel, 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 dem der Konfigurations-Channel für den Proxy Server besteht.
  6. Zuguterletzt startet das Installationsprogramm alle Dienste (bzw. startet sie neu), die mit dem RHN Proxy Server in Zusammenhang stehen; sobald dies abgeschlossen ist, beendet er.
    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.
    
    Copy to Clipboard Toggle word wrap

4.2.1. Die Antwortdatei

Falls Sie den Prozess der RHN Proxy Server Installation auf Ihrem System teilweise automatisieren möchten, ermöglicht das configure-proxy.sh-Programm es 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 enthält hinsichtlich der Versionsnummer, des RHN Satellite Servers der als übergeordneter Server fungiert, SSL, und weiteren Konfigurationsparametern. 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 an einem Shell-Prompt.
# example of answer file for configure-proxy.sh
# for full list of possible option see
# 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
Copy to Clipboard Toggle word wrap
Um eine Antwortdatei (z.B. namens answers.txt) mit configure-proxy.sh zu verwenden, geben Sie ein:
configure-proxy.sh --answer-file=answers.txt
Copy to Clipboard Toggle word wrap

Kapitel 5. RHN Package Manager

Der RHN Package Manager ist ein Befehlszeilen-Tool, mit dessen Hilfe es einem Unternehmen möglich ist, lokale Pakete in Zusammenhang mit einem privaten RHN-Channel durch den RHN Proxy Server zu verteilen. Wenn Sie möchten, dass der RHN Proxy Server nur offizielle Red Hat Pakete aktualisiert, installieren Sie den RHN Package Manager nicht.
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-Konfigurationsdatei festgelegt sind.

5.1. Erstellen eines privaten Channels

Bevor lokale Pakete durch den RHN Proxy Server zur Verfügung gestellt werden können, benötigen Sie einen privaten Channel zur Aufbewahrung. Führen Sie folgende Schritte durch, um einen privaten Channel einzurichten:
  1. Melden Sie sich über die RHN-Web-Oberfläche unter 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 Channel-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 einrichten-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 Channel ein. Das Label muss mindestens sechs Zeichen lang sein, mit einem Buchstaben beginnen und darf nur zwei Kleinbuchstaben, Zahlen, Bindestriche (-) und Punkte enthalten. Geben Sie auch die URL des GPG-Schlüssels des Channels 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 Generierung von GPG-Schlüsseln.
  5. Klicken Sie auf Channel einrichten.

5.2. Hochladen von Paketen

Anmerkung

Sie müssen ein Organisationsadministrator sein, um Pakete auf private RHN-Channels hochladen zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und nach Ihrem Passwort.
Nach dem Einrichten des privaten Channels 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
Copy to Clipboard Toggle word wrap
pkg-list ist die Liste der hochzuladenden Pakete. Wahlweise können Sie auch die -d-Option verwenden, um das lokale Verzeichnis festzulegen, welches die Pakete enthält. Vergewissern Sie sich, dass das Verzeichnis wirklich nur die benötigten Pakete enthält und keine anderen Dateien. 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
Copy to Clipboard Toggle word wrap
Wenn Sie mehr als einen Channel angegeben haben (unter Verwendung der -c oder --channel Option), werden die hochgeladenen Pakete mit allen aufgelisteten Channels verknüpft.

Anmerkung

Wenn kein Channel-Name angegeben wird, werden die Pakete zu keinem Channel hinzugefügt. Die Pakete können einem Channel mit Hilfe der Red Hat Network-Web-Oberfläche hinzugefügt werden. Die Web-Oberfläche kann auch zur Modifizierung bestehender privater Channels verwendet werden.
Nach dem Hochladen der Pakete können Sie umgehend auf der RHN-Web-Oberflä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 angepassten Channels. Klicken Sie dann auf den Pakete-Unterreiter. Jedes RPM-Paket sollte aufgelistet sein.
Sie können auch mithilfe 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" 
Copy to Clipboard Toggle word wrap
Diese -s-Option listet alle fehlenden Pakete auf (Pakete, die zum RHN Server hochgeladen wurden und sich nicht im lokalen Verzeichnis befinden). Sie müssen ein Organisationsadministrator sein, um diesen Befehl verwenden zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und -Passwort. Siehe Tabelle 5.1, »rhn_package_manager-Optionen« für zusätzliche Befehlszeilenoptionen.
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 Channel anzumelden.

5.3. Befehlszeilenoptionen

Eine Zusammenfassung aller Befehlszeilenoptionen für RHN Package Manager rhn_package_manager:
Expand
Tabelle 5.1. rhn_package_manager-Optionen
Option Beschreibung
-v, --verbose Ausführlichkeit erhöhen.
-dDIR, --dir=DIR Verarbeitet die Pakete des Verzeichnisses DIR.
-cCHANNEL, --channel=CHANNEL Verwaltet diesen Channel — 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.
-s, --sync Überprüft, ob lokales Verzeichnis mit dem Server abgestimmt ist.
-p, --printconf Zeigt die aktuelle Konfiguration an und beendet.
-XPATTERN, --exclude=PATTERN Schließt Dateien aus, die diesem Glob-Ausdruck entsprechen — kann auch mehrmals vorhanden sein.
--newest Pusht nur die Pakete, die neuer sind als die bereits für den festgelegten Channel zum Server gepushten Pakete.
--stdin Liest die Paketnamen von der Standardeingabe.
--nosig Pusht nicht-signierte Pakete. Standardmäßig versucht der RHN Package Manager, nur signierte Pakete zu pushen.
--username=USERNAME Geben Sie Ihren RHN-Benutzernamen ein. Wenn Sie mit dieser Option keinen Benutzernamen angeben, dann werden Sie in einem Prompt dazu aufgefordert.
--password=PASSWORD Geben Sie Ihr RHN-Passwort ein. Wenn Sie mit dieser Option kein Passwort angeben, dann werden Sie in einem Prompt 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 pushenden Pakete an.
--no-ssl Nicht empfohlen — SSL abschalten.
-?, --usage Beschreibt kurz die Optionen.
--copyonly Kopiert die als Parameter angegebene Datei in den angegebenen Channel. Nützlich, wenn einem Channel auf dem Proxy ein Paket fehlt und Sie nicht alle Pakete 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.

Kapitel 6. 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.

6.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 Ihnen ermöglicht, zu beenden, zu starten, oder einen Status auf dem Proxy zu erhalten.
/usr/sbin/rhn-proxy start
/usr/sbin/rhn-proxy stop
/usr/sbin/rhn-proxy restart
/usr/sbin/rhn-proxy status
Copy to Clipboard Toggle word wrap
Verwenden Sie den rhn-proxy-Befehl, um den gesamten RHN Proxy Server herunter- oder hochzufahren und Statusmitteilungen aller Dienste auf einmal abzufragen.

6.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 Geräten 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 6.1, »Protokolldateien« für die Pfade zu allen relevanten Protokolldateien:
Expand
Tabelle 6.1. 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

6.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 sich 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 Web-Oberflä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 sich nicht über den RHN Proxy Server. Wie kann dieser Fehler behoben werden?
A:
Vergewissern Sie sich, dass die neueste Version des Red Hat Update Agent 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 6.1, »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 6.1, »Protokolldateien«.

6.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 ablaufen. Daraufhin sollten Sie alle neuen Protokolleinträge nach potenziellen Anhaltspunkten untersuchen.
Ein häufiges Problem ist mangelnder 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 keinen freien Speicherplatz mehr. Zur Bestätigung dieser Annahme führen Sie einfach folgenden Befehl aus und überprüfen die Prozentsätze in der Use%-Spalte:
df -h
Copy to Clipboard Toggle word wrap
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 folgenden Befehl aus:
service httpd status
Copy to Clipboard Toggle word wrap
Um den Squid-Status abzufragen, führen Sie folgenden Befehl aus:
service squid status
Copy to Clipboard Toggle word wrap
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.

6.5. Host nicht gefunden/FQDN konnte nicht ermittelt werden

Da RHN-Konfigurationsdateien ausschließlich auf FQDNs beruhen, ist es unerlässlich, dass die wichtigsten Applikationen den Namen des RHN Proxy Servers 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 mit den RHN-Applikationen besonders anfällig. Es erscheinen Fehlermeldungen wie "Host nicht gefunden" ("host not found") und "FQN des Servers konnte nicht ermittelt werden" ("Could not determine the server's fully qualified domain name"), nachdem der Startvorgang gescheitert ist.
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 Apache Web server starten kann und die RHN-Client-Applikationen funktionieren können.
Um diese 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
Copy to Clipboard Toggle word wrap
Entfernen Sie zunächst in einem Texteditor die problematische Rechnerinformation, z.B.:
127.0.0.1 localhost.localdomain.com localhost
Copy to Clipboard Toggle word wrap
Speichern Sie daraufhin 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
Copy to Clipboard Toggle word wrap
Ersetzen Sie hier den Wert durch die tatsächliche IP-Adresse des Proxys. Damit sollte das Problem behoben sein. Denken Sie daran, falls diese spezielle IP-Adresse auf diese Art festgelegt ist, muss die Datei immer dann aktualisiert werden, wenn die Maschine eine neue Adresse erhält.

6.6. Verbindungsfehler

Wenn Sie Probleme haben, die wahrscheinlich auf eine fehlgeschlagenen Verbindung zurückzuführen sind, dann können Sie Folgendes tun:
  • Überprüfen Sie, dass das richtige Paket:
     rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm 
    Copy to Clipboard Toggle word wrap
    auf dem RHN Proxy Server installiert ist, und dass das entsprechende rhn-org-trusted-ssl-cert-*.noarch.rpm oder das öffentliche SSL-(Client)-Zeritifikat der CA in Rohform auf allen Client-Systemen installiert ist.
  • Vergewissern Sie sich, dass die Client-Systeme die passenden Zertifikate 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 detailliertere Informationen verweisen wir dazu auf das Kapitel SSL-Zertifikate im RHN Client-Konfigurationshandbuch.
  • Falls sich 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.

6.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 diesen zu leeren, stoppen Sie Apache Web server und Squid und löschen Sie die Inhalte dieses Verzeichnisses und starten beide Dienste neu. Führen Sie diese Befehle in der angegebenen Reihenfolge aus:
service httpd stop
service squid stop
rm -fv /var/spool/squid/*
service squid start
service httpd start
Copy to Clipboard Toggle word wrap
Sie können dieselbe Aufgabe schneller ausführen, indem Sie nur die Verzeichnisinhalte löschen und Squid neustarten. Dadurch erhalten Sie jedoch wahrscheinlich eine Reihe von RHN-Traceback-Mitteilungen.
Der Cache des internen Caching-Mechanismus, der zur Authentifizierung vom Proxy verwendet wird, sollte eventuell ebenfalls entleert werden. Führen Sie dazu folgenden Befehl aus:
 rm -fv /var/cache/rhn/* 
Copy to Clipboard Toggle word wrap
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 Authentifizierungsmechanismus ersetzt wurde, kann es sein, dass der Daemon immer noch auf Ihrem Proxy ablä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 
Copy to Clipboard Toggle word wrap
Um den Cache zu leeren, geben Sie folgenden Befehl ein:
 rm /var/up2date/rhn_auth_cache 
Copy to Clipboard Toggle word wrap
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 die Leistung unter der ausführlichen 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
Copy to Clipboard Toggle word wrap

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

Falls Sie alle diese Schritte zur Suche und Bereinigung von Fehlern ausgeschöpft haben oder dabei den Red Hat Network Experten den Vortritt lassen möchten, dann empfiehlt Ihnen Red Hat, dass Sie auf den ausgezeichneten Support, der zum RHN Proxy Server gehört, zurückgreifen.
Eine Möglichkeit, auf dieses Fachwissen zuzugreifen, ist mittels der Red Hat Wissensdatenbank, die Lösungen anbietet für häufig bei Benutzern aufgetretene Probleme, sowie eine robuste Oberfläche bietet zum Stöbern und Suchen, 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 all dies 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.
Copy to Clipboard Toggle word wrap
Sie werden anschließend nach dem Anfangsbuchstaben Ihres Vornamens und Ihrem Nachnamen gefragt, dann nach einer Support-Fallnummer (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 Ihre Red Hat Vertretung.

Anhang A. RHN Proxy Server Installation über die Satellite-Website

Neben der in Abschnitt 4.2, »RHN Proxy Server Installationsprozess« dargestellten Installationsmethode können Sie den RHN Proxy Server auch über die RHN Satellite Server Website installieren.

Warnung

Diese Installationsmethode ist veraltet und wird evtl. aus zukünftigen RHN Satellite Server Versionen entfernt. Die empfohlene Installationsmethode ist in Abschnitt 4.2, »RHN Proxy Server Installationsprozess« dokumentiert.
  1. Registrieren Sie das neu installierte Red Hat Enterprise Linux AS System beim Red Hat Network (entweder dem zentralen RHN Server oder Ihrem RHN Satellite Server) unter Verwendung des Unternehmens-Accounts, der die RHN Proxy Server Berechtigung beinhaltet, mit dem Befehl: rhn_register.
  2. Erteilen Sie dem System eine Provisioning-Berechtigung. Besuchen Sie dazu die RHN-Website (oder den "Fully Qualified Domain Name", FQDN, des Satellites, der dem Proxy dient), melden sich an als Organization Administrator, und gehen zur Ihr RHN => Abonnement-Management-Seite. Aktivieren Sie das Kästchen des Systems, auf dem der RHN Proxy Server installiert werden soll, wählen Provisioning aus dem Dropdown-Menü aus, und klicken die Berechtigung hinzufügen-Schaltfläche.
  3. Vergewissern Sie sich, dass das System für sein Basisbetriebssystem den Red Hat Network Tools-Channel abonniert hat, indem Sie den Systemnamen anklicken und zur System => System-Details-Seite gehen. Suchen Sie unter Abonnierte Channels in den aufgelisteten Channels nach dem Tools-Channel. Falls dieser Channel nicht abonniert ist, klicken Sie den Channel-Abonnements ändern-Link, aktivieren das Kästchen neben dem Tools-Channel, und klicken anschließend die Abonnement ändern-Schaltfläche, um Ihre Auswahl zu bestätigen.
  4. Installieren Sie das rhncfg-actions-Paket (welches ebenfalls die rhncfg und rhncfg-client als Abhängigkeiten installiert), indem Sie zunächst einmal zum System => System-Details => Software => Pakete => Installieren-Unterreiter gehen. Suchen Sie als Nächstes mithilfe des Filtern nach Paketname-Textsuchfelds nach rhncfg-actions. Wählen Sie das rhncfg-actions-Paket aus der Ergebnisliste aus, und installieren Sie es.
  5. Falls Sie Secure Sockets Layer (SSL)-Verschlüsselung auf dem Proxy aktivieren und mit den zentralen RHN Servern verbinden werden, installieren Sie das rhns-certs-tools-Paket von demselben Red Hat Network Tools-Channel und benutzen das RHN SSL Maintenance Tool, um die später benötigte tar-Datei zu generieren. Für Anleitungen hierzu verweisen wir auf das Kapitel über SSL-Zertifikate des RHN Client-Konfigurationshandbuch.
    Falls Sie SSL-Verschlüsselung auf dem Proxy aktivieren und mit einem RHN Satellite Server oder einem anderen RHN Proxy Server mit SSL verbinden wollen, werden Sie zudem das für das Parent-System verwendete CA-Zertifikatpasswort benötigen.
  6. Melden Sie sich an einem Terminal als Root im System an und führen den rhn_check-Befehl aus, um die geplante Paketinstallation sofort einzuleiten.
  7. Sobald die Pakete installiert wurden, wie unter dem System-Details => Ereignisse-Reiter bestätigt wird, bereiten Sie das System darauf vor, von Remote aus Befehle und Konfigurationsverwaltung zu akzeptieren mithilfe des folgenden Befehls:
     /usr/bin/rhn-actions-control --enable-all 
    Copy to Clipboard Toggle word wrap
  8. Gehen Sie auf der RHN-Website zum Unterreiter System-Details => Details => Proxy.

    Warnung

    Um den Proxy-Reiter nach der Registrierung eines Systems zu sehen, muss es beim standardmäßigen RHEL Basis-Channel angemeldet sein; der Proxy-Reiter ist dagegen nicht sichtbar, wenn das System bei einem angepassten oder geklonten Channel angemeldet ist.
    Beachten Sie, dass die RHN Proxy Server Installation ggf. die squid.conf und httpd.conf-Konfigurationsdateien auf dem System ersetzt, um spätere Upgrades zu erleichtern. Falls Sie diese Dateien bearbeitet hatten und sie deshalb behalten möchten: Die Dateien haben lediglich ihren Speicherort gewechselt und können nach Abschluss der Installation abgerufen werden.

    Abbildung A.1. System-Details => Proxy

  9. Im System-Details => Details => Proxy-Unterreiter sollte das Pulldown-Menü anzeigen, dass Sie Ihr System als RHN Proxy Server aktivieren können. Vergewissern Sie sich, dass die korrekte Version ausgewählt ist, und klicken die Proxy aktivieren Schaltfläche. Die Willkommen-Seite der Installation erscheint.

    Abbildung A.2. Willkommen

  10. Auf der Willkommen-Seite finden Sie Meldungen hinsichtlich etwaiger Anforderungen, die vom System nicht erfüllt werden. Wenn das System bereit ist, erscheint ein Weiter-Link. Klicken Sie den, um zur Seite Lizenzvereinbarung zu gelangen.

    Abbildung A.3. Lizenzvereinbarung

  11. Klicken Sie auf der Seite Lizenzvereinbarung auf den gleichnamigen Link, um die Lizenzvereinbarung des RHN Proxy Servers einzusehen. Wenn Sie damit einverstanden sind, klicken Sie auf den Ich stimme zu-Link. Sie müssen zustimmen, um mit der Installation fortzufahren. Für Proxys, die sich bei einem Satellite registrieren und Monitoring aktiviert haben, erscheint als Nächstes die Seite Monitoring aktivieren.

    Abbildung A.4. Monitoring aktivieren

  12. Auf der Monitoring aktivieren-Seite müssen Sie entscheiden, ob der Proxy dazu verwendet wird Systeme zu überwachen, die von ihm versorgt werden. Dazu muss der RHN Proxy Server die in Kapitel 2, Anforderungen definierten Anforderungen erfüllen und mit einem RHN Satellite Server verbunden sein (oder mit einem anderen Proxy, welcher mit einem Satellite verbunden ist). Um Monitoring auf dem Proxy einzuschalten, aktivieren Sie das Auswahlkästchen und klicken Weiter. Die RHN Proxy Server konfigurieren-Seite erscheint.

    Abbildung A.5. RHN Proxy Server konfigurieren

  13. Auf der RHN Proxy Server konfigurieren-Seite machen Sie Einträge für alle erforderlichen Felder bzw. bestätigen diese. Die E-Mail-Adresse des Administrators wird sämtliche E-Mails empfangen, die vom Proxy generiert werden, einschließlich einer großen Menge an Tracebacks bezüglich Fehler. Um diese Flut einzudämmen, sollten Sie das Einrichten von Mail-Filtern in Betracht ziehen, die Nachrichten mit dem Betreff "RHN TRACEBACK von Hostname" abfangen. Um mehr als einen Administrator einzutragen, geben Sie eine kommagetrennte Liste mit E-Mail-Adressen ein.
    Beim RHN-Proxy-Hostnamen handelt es sich um den FQDN ("Fully Qualified Domain Name") des RHN Proxy Servers. Der RHN Parent Server ist der Domain-Name des Servers, der dem Proxy dient — entweder die zentralen RHN Server, ein anderer RHN Proxy Server oder ein RHN Satellite Server. Um mit den zentralen RHN Servern zu verbinden, fügen Sie den Wert xmlrpc.rhn.redhat.com ein. Um mit einem Satellite oder einem anderen Proxy zu verbinden, geben Sie den FQDN des Parent-Systems ein.
    Falls der RHN Proxy Server über einen HTTP-Proxy verbinden wird, konfigurieren Sie ihn mittels der entsprechenden Felder. Beachten Sie, dass Angaben zum Protokoll, wie z.B. http:// oder https:// nicht im HTTP Proxy Server-Feld eingegeben werden sollten. Tragen Sie ausschließlich den Hostnamen und Port im Format hostname:port ein, also z.B. your-gateway.example.com:3128.

    Anmerkung

    Der Installationsprozess wirkt sich auschließlich auf die Proxy-Konfigurationsdatei aus: /etc/rhn/rhn.conf. Die Red Hat Update Agent (up2date) Konfigurationsdatei /etc/sysconfig/rhn/up2date muss manuell aktualisiert werden, um Updates von einem anderen Server, wie z.B. einem RHN Satellite Server, zu beziehen.
    Zum Schluss müssen Sie noch mittels des Auswahlkästchens unten entscheiden, ob SSL aktiviert werden soll. Red Hat empfiehlt dringend, diese Verschlüsselungsebene für jeglichen Datenverkehr zum/vom RHN Proxy Server anzuwenden. Um es jedoch zu aktivieren, müssen Sie sich mit den zentralen RHN Servern verbinden (die SSL standardmäßig aktiviert haben), oder mit einem RHN Satellite Server oder RHN Proxy Server, der SSL aktiviert hat. Das Verbinden mit den zentralen RHN Servern erfordert das Hochladen der oben erwähnten Zertifikats-tar-Datei. Das Verbinden mit einem Satellite oder Proxy per SSL erfordert das CA-Zertifikatpasswort, dass beim Aktivieren von SSL auf dem Parent-System verwendet wurde.

    Anmerkung

    Werfen Sie einen Blick auf das Kapitel "SSL Infrastruktur" im RHN Client-Konfigurationshandbuch für weitere Informationen über das Einrichten einer sicheren RHN Proxy Server-Infrastruktur unter Verwendung von SSL.
    Falls Sie SSL während der Installation nicht aktivieren möchten, wählen Sie dieses Kästchen nicht aus, und lesen Sie bitte die Kapitel über SSL-Zertifikate im RHN Client-Konfigurationshandbuch für Informationen darüber, wie Sie dieses Sicherheitslevel nach der Installation noch einstellen können. Wenn Sie fertig sind, klicken Sie Weiter. Falls Sie SSL aktiviert haben und mit einem Satellite verbinden, erscheint nun die SSL konfigurieren-Seite. Falls Sie SSL aktiviert haben und mit einem anderen Proxy oder den zentralen RHN Servern verbinden, erscheint die SSL hochladen-Seite. Falls Sie zwar nicht SSL, aber Monitoring aktiviert haben, gehen Sie weiter zur Beschreibung der Monitoring konfigurieren-Seite. Falls Sie weder SSL noch Monitoring aktiviert haben, überspringen Sie beides und gehen weiter zur Beschreibung der Installationsfortschritt-Seite.

    Abbildung A.6. SSL konfigurieren

  14. Auf der SSL konfigurieren-Seite, die nur zutrifft auf einen Proxy, der mit einem RHN Satellite Server verbindet mit aktiviertem SSL, geben Sie bitte die benötigten Informationen zur Generierung des Server-Zertifikats ein. Das wichtigste Element ist das CA-Zertifikatpasswort, das übereinstimmen muss mit dem Passwort, das zum Aktivieren von SSL auf dem Parent-Server verwendet wurde. Die übrigen Felder können zwar mit den Werten des Parent-Servers übereinstimmen, können sich aber auch unterscheiden je nach Aufgabe des RHN Proxy Servers, z.B. um eine andere geografische Lage wiederzuspiegeln. Ebenso kann auch die E-Mail-Adresse dieselbe sein, die vorher für den Proxy-Administrator angegeben wurde, kann jedoch stattdessen auch die eines speziellen Zertifikats-Administrators sein. Der Ablauf des Zertifikats ist konfigurierbar. Vergewissern Sie sich wie immer, dass die hier angegebenen Werte in den Daten-Backups vorliegen, die in Kapitel 2, Anforderungen beschrieben sind. Wenn Sie damit fertig sind, klicken Sie Weiter.

    Abbildung A.7. Monitoring konfigurieren

  15. Auf der Monitoring konfigurieren-Seite machen Sie Angaben (bzw. bestätigen diese) zum Hostnamen und zur IP-Adresse des Parent-Servers, mit dem der RHN Proxy Server verbunden ist. Dies muss entweder ein RHN Satellite Server sein, oder anderer Proxy, der seinerseits mit einem Satellite verbunden ist. Sie können kein Monitoring ausführen durch die zentralen RHN Server. Wenn Sie damit fertig sind, klicken Sie Weiter. Die Seite Installationsfortschritt erscheint als Nächstes.

    Abbildung A.8. Installationsfortschritt

  16. Auf der Seite Installationsfortschritt können Sie die einzelnen Schritte der Installation während ihrer Ausführung überwachen. Klicken Sie auf den Link zu einem Schritt, um zu dessen Aktions-Details-Seite zu gelangen. Wenn eine Aktion beginnt, ändert sich ihr Status von Queued (in der Warteschlange) zu Picked Up (aufgenommen) und schließlich zu Completed (abgeschlossen). Wie auch die früheren Paketinstallationen können Sie diese Schritte sofort einleiten, indem Sie als Root den rhn_check-Befehl in einem Terminal am System ausführen. Sobald abgeschlossen, wird die Seite Installationsfortschritt die Meldung The installation is complete. ausgeben. Sie können jetzt mit dem Registrieren von Systemen beginnen, die vom RHN Proxy Server versorgt werden sollen. Siehe RHN Client-Konfigurationshandbuch.
  17. Wenn alle Posten auf der Installationsfortschritt-Seite Completed (abgeschlossen) sind, ist der Proxy einsatzbereit. Sie können nun Systeme über den Proxy bei RHN registrieren.

Anhang B. Beispiel für eine RHN Proxy Server-Konfigurationsdatei

Die /etc/rhn/rhn.conf-Konfigurationsdatei für den RHN Proxy Server ermöglicht es Ihnen, grundlegende Einstellungen festzulegen. Seien Sie jedoch gewarnt, dass Fehler in dieser Datei Satellite-Ausfälle zur Folge haben können. Führen Sie daher Änderungen an der Konfiguration mit höchster Vorsicht durch.
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 Raute-Zeichen #) genauer an.

Anmerkung

Sie können die use_ssl-Einstellung der rhn.conf-Datei 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 Konfigurationsdatei.
# 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
Copy to Clipboard Toggle word wrap

Anhang C. 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 Jul 23 2010

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, Funktionsweise
Authentifizierungs-Cache
löschen, Caching-Probleme

B

Begriffserklärung, Begriffserklärung

C

Caching-Probleme, Caching-Probleme
Channel, Begriffserklärung
privaten Channel erstellen, Erstellen eines privaten Channels
Channel-Adminstrator, Begriffserklärung
Client-Konfiguration
bei privatem Channel anmelden, Hochladen von Paketen

E

Eingehende Ports, Satellite
5222, Weitere Anforderungen

F

Fragen und Antworten, Fragen und Antworten
Funktionsweise, Funktionsweise

H

Hardware-Anforderungen, Hardware-Anforderungen
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

O

Organisationsadministrator, Begriffserklärung

R

Red Hat Network
Einführung, Red Hat Network
Red Hat Update Agent, Begriffserklärung, Funktionsweise
RHN Authentication Daemon, deaktivieren
rhn_auth_cache, stoppen, Caching-Probleme
RHN Package Manager, Funktionsweise, RHN Package Manager
Befehlszeilenoptionen, Befehlszeilenoptionen
Channels spezifizieren, Hochladen von Paketen
Installation, RHN Package Manager
Konfiguration, Erstellen eines privaten Channels
Konfigurationsdatei, RHN Package Manager
Paket-Header hochladen, Hochladen von Paketen
privaten Channel erstellen, Erstellen eines privaten Channels
Verifizieren der lokalen Paketliste, Hochladen von Paketen
rhn-proxy
Dienst, Verwalten des Proxy-Dienstes
rhn.conf
Beispieldatei, Beispiel für eine RHN Proxy Server-Konfigurationsdatei
rhn_package_manager , Hochladen von Paketen (Siehe RHN Package Manager)

S

Satellite-Debugging, 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
mehrfache Proxys, horizontal aufgereiht, Mehrfach horizontal aufgereihte Proxy-Topologie
mehrfache Proxys, vertikal aufgereiht, Mehrfach vertikal aufgereihte Proxy-Topologie
Proxys mit RHN Satellite Server, Proxys mit RHN Satellite Server
Traceback, Begriffserklärung

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.
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat