Red Hat Network Satellite 5.5 Proxy-Installationshandbuch

Transkript

1 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch Red Hat Network Satellite Ausgabe 3 Red Hat Dokumentationsteam

2 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch Red Hat Network Satellite Ausgabe 3 Red Hat Do kumentatio nsteam

3 Rechtlicher Hinweis Copyright 2010 Red Hat, Inc. T his 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, MetaMatrix, 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. T he 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. Z usammenfassung Willkommen beim RHN Proxy-Installationshandbuch.

4 Inhaltsverzeichnis Inhaltsverzeichnis. Kapitel Einführung Red Hat Netzwerk Häufig verwendete T erminologien RHN Proxy Server Proxy Funktionsweise 6. Kapitel Anforderungen Software-Anforderungen Hardware-Anforderungen Speicherplatzanforderungen Weitere Anforderungen 9. Kapitel Beispieltopologien Einzel-Proxy-T opologie Mehrfach horizontal gestaffelte Proxy-T opologie Mehrfach vertikal gestaffelte Proxy-T opologie Proxys mit RHN Satellite Server 14. Kapitel Installation Basisinstallation RHN Proxy Server Installationsvorgang Die Antwortdatei 19. Kapitel RHN..... Package Manager und.... die.... Lieferung Lokaler Pakete Erstellen eines Privaten Kanals Hochladen von Paketen 22. Kapitel Upgrade Installation Voraussetzungen Upgrade Installationsvorgang 24. Kapitel Suche und.... Bereinigung von..... Fehlern Verwalten des Proxy-Dienstes Protokolldateien Fragen und Antworten Allgemeine Probleme Host nicht gefunden/fqdn konnte nicht ermittelt werden Verbindungsfehler Caching-Probleme Suche und Bereinigung von Proxy-Fehlern durch Red Hat 30. Beispiel für.... eine..... RHN..... Proxy Server Konfigurations-Datei Versionsgeschichte Stichwortverzeichnis A 34 C 34 E 34 F 34 H 34 I 35 K 35 O 35 1

5 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch P R S T V W

6 Inhaltsverzeichnis 3

7 Red Hat Network Satellite 5.5 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 Z uverlä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 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 Z ugang zu den Channel- Managementfähigkeiten. Benutzer in dieser Rolle können Channels erstellen, Pakete 4

8 Kapitel 1. Einführung bestimmten, Channels zuordnen, Channels klonen und Channels löschen. Diese Rolle kann von einem Organisations-Verwalter über den Benutzer T ab 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 'T raceback' ist eine detaillierte Beschreibung dessen, "was schiefgelaufen ist", die sich bestens zur Suche und Bereinigung von Fehlern im RHN Proxy Server eignet. T racebacks 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 versendet. Mehr detaillierte Beispiele zu diesen T hema und anderen finden Sie im Red Hat Network Referenzhandbuch, verfügbar unter sowie auf der Hilfe Seite der Satellite Web-Benutzerschnittstelle 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 Z ugriff 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 Z wischenstation zwischen Client-Systemen und Red Hat Network (oder einem RHN Satellite Server). Nur die Paketdateien sind auf dem RHN Proxy Server gespeichert. Jede T ransaktion wird authentifiziert, und der Red Hat Update Agent überprüft die GPG- Signatur aller Pakete vom lokalen RHN Proxy Server. Z usä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. Z um 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. Z eitersparnis Pakete werden wesentlich schneller über ein lokales Netzwerk geliefert, als über das Internet. Bandbreitenersparnis Pakete werden nur einmal vom RHN heruntergeladen (über den lokalen 5

9 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch 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 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 Z ugang zum Internet. Diese benötigen nur Z ugang 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 HT T P 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-T oken über die Kette von RHN Proxy Servern zurück. Dieser T oken 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 6

10 Kapitel 1. Einführung /var/cache/rhn/ zwischen. Caching reduziert den Overhead in Z usammenhang mit der Authentifizierung mit Red Hat Network und verbessert somit drastisch das Leistungsvermögen des Red Hat Networks. 4. Dieser Session-T oken 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 d ieses Do kuments kann sich " RHN" entwed er auf d ie RHN Ho sted Seite (http ://rhn.red hat.co m) o d er auf einen RHN Satellite Server b eziehen. 7

11 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch 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 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 Base Für die Installation von Red Hat Enterprise Linux von CD oder ISO-Image wählen Sie folgende Paketgruppe aus: Minim al 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). Z ugriff auf den Red Hat Network T ools-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 8

12 Kapitel 2. Anforderungen enthält. Alle auf dem Proxy installierten rhncfg*-pakete (vom RHN-T ools-channel). Entweder das auf dem Proxy installierte rhns-certs-tools Paket (vom RHN-T ools-channel) für RHN Hosted Benutzer, oder das Secure Sockets Layer (SSL) CA-Z ertifikatpasswort, welches für RHN Satellite Server-Benutzer zur Generierung des Parent-Server-Z ertifikats 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 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 Z usammenhang 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 Speicherplatzanforderungen Der vom RHN Proxy Server eingesetzte Caching-Mechanismus ist der Squid HT T P-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 Z uweisung 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/rhnproxy gespeichert sind. Der erforderliche Plattenspeicher für lokale Pakete hängt von der Anzahl der bereitgestellten kundenspezifischen Pakete ab Weitere Anforderungen Die folgenden weiteren Anforderungen müssen erfüllt werden, bevor die RHN Proxy Server-Installation als vollständig angesehen werden kann: Voller Z ugang 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 9

13 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch zu schützen. Jedoch sollten verschiedene T CP-Ports offen bleiben, je nach der Implementation des RHN Proxy Server: T abelle 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) Ausgehend Falls Ihr Proxy mit einen RHN Satellite Server verbunden ist, verbindet sich das Monitoring über diese T CP-Ports mit Client-Systemen, auf denen rhnm d läuft, sofern Monitoring aktiviert ist und nach registrierten Systemen sucht Eingehend Das Öffnen dieses Ports erlaubt dem osad-client, sich mit dem jabberd Dämon auf der Proxy zu verbinden, wenn die RHN-Push-T echnologie verwendet wird 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-T echnologie zu erlauben. Synchronisierte Systemzeiten Die korrekte Z eit spielt eine bedeutende Rolle, wenn mit einem SSL- (Secure Sockets Layer) fähigen Webserver verbunden wird; es ist von entscheidender Bedeutung, dass die Z eiteinstellungen auf den Clients und dem Server sehr nahe beieinander liegen, sodass das SSL-Z ertifikat nicht vor oder während der Verwendung abläuft. Das Network T ime Protokoll (NT P) 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. 10

14 Kapitel 2. Anforderungen 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-Z ertifikat-generierung. Red Hat empfiehlt dringend, dass diese Informationen auf zwei separate Datenträger kopiert wird, ausgedruckt wird, und der Ausdruck in einem sicheren Platz (T resor) aufbewahrt wird. Distributionsspeicherorte Da der Proxy nahezu alle lokalen HT T P-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/htm l/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. Z usä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-Z ugang 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 Z uhilfenahme 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. 11

15 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch 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 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. Abbildung 3.1. Einzel-Proxy-T opologie 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 12

16 Kapitel 3. Beispieltopologien 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. Abbildung 3.2. Mehrfach horizontal gestaffelte Proxy-T opologie 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. 13

17 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch Abbildung 3.3. Mehrfach vertikal gestaffelte Proxy-T opologie 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- T opologien im RHN Satellite Server Installationshandbuch. Das Verknüpfen der SSL Z ertifikate 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. 14

18 Kapitel 4. Installation 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 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. Wichtig 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 T ime Protocol (NT P) auf dem Proxy und wählen die entsprechende Z eitzone aus. Auf allen Client-Systemen sollte bereits der ntpd-daemon laufen und auf die korrekte Z eitzone eingestellt sein. Deaktivieren Sie die ipchains und iptables-dienste nach der Installation 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 T ools-kanal. 4. Installieren Sie den Proxy Installer: 15

19 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch yum install spacewalk-proxy-installer 5. Installation durchführen: configure-proxy.sh Anmerkung Um diesen Schritt erfolgreich durchzuführen ist Root-Z ugriff 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-Z ertifikate. Die folgenden Anleitungen beschreiben den Installationsvorgang: Tipp Wenn Sie bei einem Prompt die Enter T aste 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 []: T raceback em ail ist die -Adresse, an die T raceback-nachrichten bezüglich Fehler gesendet werden, in der Regel ist dies die -Adresse des Proxy-Administrators. Benutzen Sie Kommas, um mehrere -Adressen in diesem Prompt voneinander zu trennen. 7. Die nächste Reihe von Eingabeaufforderungen beziehen sich auf die Detailkonfiguration zum Generieren eines SSL-Z ertifikats, 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 16

20 Kapitel 4. Installation zu konfigurieren. CA Chain [/usr/share/rhn/rhn-org-trusted-ssl-cert]: Drücken Sie im CA Chain Prompt die Eingabe T aste, um den Standardpfad für die Certificate Authority (CA) Chain zu verwenden. Dieser Wert lautet normalerweise /usr/share/rhn/rhn- ORG-T RUST ED-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-Z ertifikate müssen im /usr/share/rhn/ Verzeichnis abgelegt werden. HTTP Proxy []: Falls der RHN Proxy Server über einen HT T P-Proxy verbindet, geben Sie den Proxy-Hostnamen und die Portnummer ein, wie z.b. corporate.proxy.exam ple.com:3128. Geben Sie die erforderlichen Details ein, um ein ordnungsgemäßes SSL-Server-Z ertifikat zu generieren, einschließlich dem Namen der Organization, der Organization Unit (Organisationseinheit, wie z.b. Engineering), Com m on Nam e (der Domain-Name), sowie Angaben zu Ort, Bundesland und Land. Z um Schluss geben Sie noch die -Adresse des Administrators oder des technischen Kontakts ein, der für SSL-Z ertifikate 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 [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. 17