RHN Proxy Server 4.0. Installationshandbuch

RHN Proxy Server 4.0 Installationshandbuch

RHN Proxy Server 4.0: Installationshandbuch Copyright 2001-2005 von Red Hat, Inc. Red Hat, Inc. 1801Varsity Drive RaleighNC 27606-2072USA Phone: +1 919 7543700 Phone: 888 733 4281Fax: +1 919 7543701 PO Box 13 search Triangle Park NC 27709 USA RHNproxy(DE)-4.0-RHI (2005-04-20T13:40) Copyright 2005 Red Hat, Inc. Das vorliegende Material darf nur unter Einhaltung der in Open Publication License, V1.0 oder neuer dargelegten Geschäftsbedingungenvertrieben werden (die neueste Version ist gegenwärtig unter http://www.opencontent.org/openpub/ verfügbar). Beträchtlich modifizierte Versionen dieses Dokumentes dürfen nur mit ausdrücklichergenehmigung des Copyright-Inhabersvertrieben werden. Der Vertrieb des Werks oder einer Ableitung des Werks in Standardbuchform (Papier) zu kommerziellen Zwecken ist nicht zulässig, sofern dies nicht zuvor durch den Copyright-Inhabergenehmigt wurde. Red Hat und das Red Hat "Shadow Man" Logo sind eingetragene Warenzeichen oder Warenzeichender Red Hat, Inc. in den USA und anderen Ländern. Alle weiteren hier genannten Rechte an Warenzeichen sowie Copyrights liegen bei den jeweiligen Eigentümern. Der GPG-Code des security@redhat.comschlüssels lautet: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Inhaltsverzeichnis 1. Einführung...1 1.1. Red Hat Network...1 1.2. RHN Proxy Server...1 1.3. Begriffserklärung...3 1.4. Funktionsweise...4 2. Anforderungen...7 2.1. Software-Anforderungen...7 2.2. Hardware-Anforderungen...8 2.3. Plattenplatz-Anforderungen...8 2.4. Zusätzliche Anforderungen...9 3. Beispiel-Architekturen...11 3.1. Einzel-Proxy Architektur...11 3.2. Mehrfach horizontal gereihte Proxy Architektur...12 3.3. Mehrfache, vertikal gereihte Proxy Architektur...13 3.4. Proxies mit RHN Satellite Server...14 4. Installation...15 4.1. Basisinstallation...15 4.2. RHN Proxy Server-Installationsprozess...15 5. RHN Paket-Manager...27 5.1. Einrichten eines privaten Channels...27 5.2. Pakete werden geladen...28 5.3. Befehlszeilenoptionen...29 6. Troubleshooting (Fehlersuche/-behebung)...33 6.1. Verwalten des Proxy-Service...33 6.2. Log-Dateien...33 6.3. Fragen und Antworten...34 6.4. Allgemeine Probleme...35 6.5. Host nicht gefunden (Host Not Found)/FQDN konnte nicht ermittelt werden (Could Not Determine FQDN)...35 6.6. Verbindungsfehler...36 6.7. Caching Probleme...37 6.8. Proxy-Debugging durch Red Hat...38 A. Beispiel für eine RHN Proxy Server-Konfigurationsdatei...41 Stichwortverzeichnis...43

Einführung Kapitel 1. 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 Performance der Systeme zu maximieren. Um RHN verwenden zu können, registrieren Administratoren die Software- und Hardwareprofile (auch als Systemprofil bekannt) derer Clients bei Red Hat Network. Wenn ein Client-System Paket-Updates anfordert, werden lediglich die für den Client zutreffenden Pakete zurückgesendet (basierend auf dem Softwareprofil, welches 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 tausende von Red Hat-Systemen einfacher, genauer und schneller aufsetzen und verwalten, als nur ein einziges System ohne Red Hat Network. Standard-Protokolle Standard-Protokolle werden dazu verwendet, Sicherheit aufrecht zu erhalten und das Leistungsvermögen zu erhöhen. Beispielsweise versetzt XML-RPC Red Hat Network in die Lage, weitaus mehr zustande zu bringen, als bloß 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 mit Hilfe einer Website an. Geplante Aktionen verwenden Sie die Website, um Aktionen einzuplanen, wie u.a. Errata-Updates, Paketinstallationen und Softwareprofil-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 lokal im Kundennetzwerk gehosteter Server mit erweiterter Red Hat Network-Funktionalität, wie beispielsweise einem Paket-Caching-Mechanismus

2 Kapitel 1. Einführung für einen reduzierten und somit optimierteren Bandweitenverbrauch und anpassbaren Channeln, die den Einsatz von Custom-Paketen ermöglichen. Dieser Service ermöglicht es einem Betrieb oder einem Unternehmen RPM-Updates auf einem internen, zentralen RHN Proxy Server zu cachen, von dem die Client-Systeme die Updates direkt und nicht über das Internet von einem der RHN-Server herunterladen können 1. Die Systemprofile und Benutzerinformationen der Clients sind auf den sicheren, zentralen RHN-Servern gespeichert, welche auch als Server für die RHN-Website dienen (rhn.redhat.com). Der Proxy dient als Vermittler zwischen Client-Systemen und Red Hat Network (oder einem RHN Satellite Server). Es werden lediglich die Paketdateien auf dem RHN Proxy Server gespeichert. Jeder Vorgang unterliegt einer Authenfizierung und der Red Hat Update Agent überprüft die GPG-Signatur für jedes einzelne Paket, welches vom lokalen RHN Proxy Server abgerufen wird. Der RHN Proxy Server kann nicht nur offizielle Red Hat-Paketen speichern, sondern kann auch unternehmenseigene Custom-Pakete von privaten RHN-Channeln unter Verwendung des RHN Paket-Manager liefern. Beispielsweise könnte ein Unternehmen eine unternehmenseigene Software entwickeln, daraus Quellcode-Pakete mit Quell- und Binärcode erstellen, mit der eigenen GPG-Signatur versehen und alle individuellen Systeme im Netzwerk durch den lokalen RHN Proxy Server mit der neuesten Version der Software aktualisieren lassen. Vorteile bei der Verwendung des RHN Proxy Server 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. Bandweitenersparnis Pakete werden von den RHN-Dateiservern nur einmal heruntergeladen (und nur jeweils einmal im Caching-Mechanismus des lokalen Servers gespeichert). Das Herunterladen von jedem einzelnen Paket für jedes einzelne Client-System entfällt hierbei. Spart Plattenplatz auf individuellen Systemen es wird nur ein großes Platten-Array anstelle von Extra-Plattenplatz auf allen Client-Systemen benötigt. Angepasste Updates (Custom-Updates) stellen ein völlig automatisiertes Paketlieferungssystem für kundeneigene Softwarepakete sowie auch offizielle Red Hat-Pakete dar, welche für die Client-Systeme benötigt werden. Angepasste, private RHN-Channel ermöglichen es einem Unternehmen, die Lieferung von firmeninternen, betriebseigenen Paketen zu automatisieren. 1. Das ganze Dokument hindurch können Sie den Begriff RHN-Server mit RHN Satellite Server ersetzen, falls sich der RHN Proxy Server stattdessen mit einem RHN Satellite Server verbindet.

Kapitel 1. Einführung 3 Angepasste Konfiguration (Custom-Konfiguration) Sie können Updates für spezifische Architekturen und OS-Versionen entweder völlig einschränken oder erlauben. Es ist nur eine Internetverbindung erforderlich die Client-Systeme verbinden sich nur durch den HTTP-fähigen Proxy-Server und benötigen deshalb keine Verbindung zu einem externen Netzwerk (Internet), sondern lediglich Zugang zum LAN, an das der RHN Proxy Server angeschlossen ist. Nur der RHN Proxy Server benötigt eine Internetverbindung, um eine Verbindung mit den RHN-Servern aufbauen zu können, außer der RHN Proxy Server verwendet einen RHN Satellite Server, in welchem Fall nur der RHN Satellite Server eine Internetverbindung benötigt. 1.3. Begriffserklärung Bevor Sie sich mit 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 Channeln: Base-Channel und Child-Channel. Ein Base-Channel besteht aus einer Liste von Paketen basierend auf einer spezifischen Architektur und einem Red Hat-Release. Ein Child-Channel ist ein Channel in Verbindung mit einem Base-Channel, enthält jedoch zusätzliche Pakete. Organization Administrator Ein Organization Administrator 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 sowie auch vom Unternehmen entfernen. Eine Red Hat Network-Organisation muss mindestens einen Organization Administrator besitzen. Channel-Administrator Ein Channel-Administrator ist eine Benutzerrolle mit vollem Zugang zu den Channel-Managementressourcen. Benutzer in dieser Rolle können Channel erstellen, Pakete bestimmten Channeln zuordnen, Channel klonen und Channel löschen. Diese Rolle kann von einem Organization Administrator mit Hilfe des Benutzer- Reiters der RHN-Website vergeben werden. Red Hat Update Agent Der Red Hat Update Agent ist die Red Hat Network-Client- Applikation (up2date), welche es Benutzern ermöglicht, neue oder aktualisierte Pakete für das Client-System, auf dem die Applikation abläuft, abzufragen und zu installieren.

4 Kapitel 1. Einführung Traceback Ein Traceback ist eine detaillierte Beschreibung von "was schiefgelaufen ist" und eignet sich bestens zum Troubleshooting. Tracebacks werden automatisch generiert, wenn ein kritischer Fehler auftritt. Diese werden dann zu den dafür in der Konfigurationsdatei des RHN Proxy Server vorgesehenen Personen per E-Mail versandt. Für detailliertere Erläuterungen dieser und anderer Begriffe verweisen wir auf das Red Hat Network Referenzhandbuch, erhältlich unter http://www.redhat.com/docs/. 1.4. Funktionsweise Der Red Hat Update Agent auf den Client-Systemen kontaktiert den Red Hat Network- Server nicht direkt. Stattdessen verbindet sich der Client (verbinden sich die Clients) mit einem RHN Proxy Server, welcher sich mit den Red Hat Network-Servern oder einem RHN Satellite Server verbindet. Demnach benötigen die Client-Systeme keinen direkten Zugang zum Internet. Diese benötigen nur Zugang zum RHN Proxy Server. Wichtig Es wird von Red Hat strengstens 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. Standardmäßig wird ein Client direkt von Red Hat Network-Servern authentifiziert. Die Verwendung einer RHN Proxy Server-Authentifizierung läuft ähnlich ab, nur dass der RHN Proxy Server auch Route-Informationen zur Verfügung stellt. Nach einer erfolgreichen Authentifizierung informiert der Red Hat Network-Server den RHN Proxy Server darüber, dass ein spezieller, für einen Client durchzuführender Ablauf genehmigt ist. Der RHN Proxy Server ladet sodann alle der aktualisierten Pakete (wenn sich diese noch nicht in seinem Zwischenspeicher befinden) und liefert diese an die Client-Systeme. Anfragen des Red Hat Update Agent auf den Client-Systemen werden noch immer Server-seitig 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 via dem LAN verbunden und werden nur durch die Geschwindigkeit des lokalen Netzwerks eingeschränkt. Authentifizierung erfolgt in der folgenden Reihenfolge: 1. Der Client meldet sich am Beginn einer Clientsitzung an. Dieser Login durchläuft einen oder mehrere RHN Proxy Server, bis dieser bei einem Red Hat Network-Server einlangt. 2. Der Red Hat Network-Server unternimmt die Authentifizierung des Clients. Bei erfolgreicher Authentifizierung sendet der Server einen Sitzungstoken über der Kette

Kapitel 1. Einführung 5 von RHN Proxy Servers zurück. Dieser Token besitzt Signatur und Fälligkeit und beinhaltet Benutzerinformationen, wie u.a. abonnierte Channel, Benutzername, usw.. 3. Jeder RHN Proxy Server cacht diesen Token auf dem lokalem Dateisystem des Proxy 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 Sitzungstoken wird an den Client-Rechner zurückgesandt und wird in späteren Abläufen auf Red Hat Network verwendet. Von der Sicht des Clients aus, gibt es keinen Unterschied zwischen einem RHN Proxy Server und einem Red Hat Network-Server. Von der Sicht des Red Hat Network-Servers aus, ist ein RHN Proxy Server eine spezielle Art von RHN-Client. Clients sind folglich nicht von der Route betroffen, die eine Anfrage einnimmt, 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 Paket-Manager installiert werden und zum Zusammenstellen und Verwalten unternehmenseigener Softwarepakete konfiguriert werden. Hierbei handelt es sich nicht um offizielle Red Hat-Pakete. Nachdem ein privater RHN-Channel erstellt wurde, werden die Custom-RPM-Pakete mit dem privaten Channel in Verbindung gebracht, indem die Paket-Header auf die RHN-Server hinaufgeladen werden. Es werden nur die Header hinaufgeladen und nicht die eigentlichen Paketdateien. Die Header sind erforderlich, da diese äußerst wichtige RPM-Informationen enthalten, wie beispielsweise Softwareabhängigkeiten, die es RHN ermöglichen, die Paketinstallation zu automatisieren. Die eigentlichen Custom-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 umkomplizierter, ü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 das RHN-Client Konfigurationshandbuch für nähere Details. Proxy-seitig muss man den nächsten Proxy in der Kette festlegen (welche letztendlich mit einem Red Hat Network-Server endet). Wenn der RHN Paket-Manager verwendet wird, müssen die Client-Systeme beim privaten RHN-Channel angemeldet sein.

6 Kapitel 1. Einführung

Anforderungen Kapitel 2. Diese Anforderungen müssen vor der Installation erfüllt werden. Um eine RHN Proxy Server-Version 3.6 oder höher vom RHN Satellite Server zu installieren, benötigen Sie die Satellite-Version 3.6 oder höher. 2.1. Software-Anforderungen Um eine Installation durchführen zu können, müssen die folgenden, Software-bezogenen Komponenten vorhanden sein: Basisbetriebssystem RHN Proxy Server wird nur gemeinsam mit Red Hat Enterprise Linux AS 3 Update 5 oder höher oder Red Hat Enterprise Linux AS 4 unterstützt. Das Betriebssystem kann von CD-ROM, via lokalem ISO-Image, Kickstart oder irgendeinem anderen, von Red Hat unterstützten Verfahren installiert werden. Wichtig Wenn Sie Service auf Monitoring-Stufe erhalten möchten, müssen Sie Ihren RHN Proxy Server auf Red Hat Enterprise Linux AS 3 Update 5 oder Red Hat Enterprise Linux AS 4 installieren. Dies sind die einzigen unterstützten Basisbetriebssysteme für Proxies mit Monitoring-berechtigten Systemen. Jede Version von Red Hat Enterprise Linux AS erfordert einen ganz bestimmten Paketsatz, um RHN Proxy Server zu unterstützen. Alles was darüber hinausgeht 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 von entweder Red Hat Enterprise Linux AS 4 oder Red Hat Enterprise Linux AS 3 Update 5, legen Sie die folgende Paketgruppe fest: @ Base Für die Installation von entweder Red Hat Enterprise Linux AS 4 oder Red Hat Enterprise Linux AS 3 Update 5 von CD oder via ISO-Image, wählen Sie folgende Paketgruppe aus: Minimal

8 Kapitel 2. Anforderungen Warnung Security-enhanced Linux (SELinux) muss in Red Hat Enterprise Linux AS 4 vor der RHN Proxy Server-Installation deaktiviert werden. Wählen Sie dabei bei einer CD- oder ISO-Image-Installation Disabled aus, wenn die Optionen für die SELinux-Unterstützung angezeigt werden. Bei einer Kickstart-Installation fügen Sie den Befehl selinux --disabled hinzu oder warten bis die Installation abgeschlossen ist und verändern den Eintrag in der /etc/selinux/config-datei auf SELINUX=disabled und rebooten Sie anschließend das System. Eine verfügbare RHN Proxy Server-Berechtigung innerhalb Ihres Red Hat Network- Accounts. Eine verfügbare Provisioning-Berechtigung innerhalb Ihres Red Hat Network-Accounts (welches Sie im Paket mit Ihrer RHN Proxy Server-Berechtigung erhalten sollten). Zugang zum Red Hat Network-Tools-Channel für die installierte Version von Red Hat Enterprise Linux AS. 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) oder das Secure Sockets Layer (SSL) CA Zertifikatpasswort, welches zur Generierung des Parent-Server-Zertifikats verwendet wird (wie beispielsweise auf einem RHN Satellite Server). Konfiguration auf dem System, um remote Befehle zu akzeptieren und Konfigurationsmanagement durch Red Hat Network. Siehe Abschnitt 4.2 für weitere Anleitungen. 2.2. Hardware-Anforderungen Die folgende Hardwarekonfiguration ist für den RHN Proxy Server erforderlich: Pentium III Prozessor, 1.26GHz, 512K Cache oder äquivalent 512 MB Memory 3 GB Speicher für die Basisinstallation von Red Hat Enterprise Linux AS 6 GB Speicher pro Distribution/Channel Die Last auf dem Apache HTTP-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.

Kapitel 2. Anforderungen 9 2.3. Plattenplatz-Anforderungen 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 Custom-Paketen oder lokalen Paketen konfiguriert ist, dann gehen Sie sicher, dass auf dem /var-mountpunkt auf dem System, welches die lokalen Pakete speichert, ausreichend Plattenplatz vorhanden ist, um sämtliche Custom-Pakete unterzubringen, welche in /var/spool/rhn-proxy gespeichert sind. Der erforderliche Plattenplatz für lokale Pakete hängt von der Anzahl der zu verwaltenden Custom-Pakete ab. 2.4. Zusätzliche Anforderungen Die folgenden zusätzlichen 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 Die RHN Proxy Server-Lösung kann hinter der Firewall gestellt sein, muss aber in der Lage sein, Verbindungen nach außen zum Internet auf den Ports 80 und 443 herzustellen. Wenn zusätzlich dazu der Proxy mit einem RHN Satellite Server verbunden ist, welcher dazu konfiguriert ist, Abläufe zu Client-Systemen und dem Proxy zu pushen, müssen Sie auch eine eingehende Verbindung auf Port 5222 ermöglichen. Synchronisierte Systemzeiten Zeitabhängigkeit spielt eine bedeutende Rolle, wenn mit einem SSL-fähigen Webserver (Secure Sockets Layer) verbunden wird; es ist zwingend notwendig, dass die Zeiteistellungen auf den Clients und dem Server angemessen nahe beieinander liegen, sodass das SSL-Zertifikat nicht vor oder während der Verwendung abläuft. Das Network Time Protocal (NTP) wird zur Synchronisation der Uhren 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 Account mit Red Hat Network. Dieser Ac-

10 Kapitel 2. Anforderungen count sollte zum Kaufzeitpunkt gemeinsam mit dem Verkaufsrepräsentanten 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 Organization Administrator-Account und die SSL-Zertifikat- Generierung. Es wird von Red Hat strengstens empfohlen, dass diese Informationen auf zwei voneinander unabhängige Disketten kopiert wird, ausgedruckt wird und der Ausdruck in einem feuersicheren Tresor aufbewahrt werden. 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 Herstellen von Installationsbäumen für Kickstarts besonders dienlich sein. Zusätzlich dazu, empfiehlt Red Hat, dass das System, welches den Code ablaufen lässt, nicht öffentlich zugänglich ist. Es sollten nur Systemadministratoren Shell-Zugang zu diesen Rechnern besitzen und keine anderen Benutzer. Alle nicht notwendigen Dienste sollten deaktiviert werden. Sie können ntsysv oder chkconfig zur Deaktivierung von Diensten verwenden. Schlussendlich sollten Sie die folgenden technischen Dokumente zur Hand haben, um diese ungefähr in dieser Reihenfolge benutzen zu können: 1. The RHN Proxy Server Installationshandbuch Dieses Handbuch, welches Sie gerade lesen, liefert Ihnen die grundlegenden, notwendigen Schritte, um einen RHN Proxy Server in Gang zu bringen. 2. Das RHN-Client Konfigurationshandbuch Dieses Handbuch erklärt im Detail, wie Sie Systeme konfigurieren können, sodass diese von einem RHN Proxy Server oder RHN Satellite Server Dienste erhalten können. (Sie werden hierbei höchstwahrscheinlich auch auf Das RHN Referenzhanbuch zurückgreifen müssen, welches Schritte zur Registrierung und der Aktualisierung von Systemen enthält.) 3. Das RHN Channel-Managementhandbuch Dieses Handbuch behandelt besonders detailgenau die empfohlenen Methoden zum Bauen von Custom-Paketen, zum Einrichten von Custom-Channels und zur Verwaltung privater Errata. 4. Das RHN Referenzhandbuch Dieses Handbuch beschreibt wie Sie RHN-Accounts erstellen können, wie Sie System registrieren und aktualisieren können und wie Sie das Potenzial der RHN-Website am besten ausschöpfen können. Dieses Handbuch kommt wahrscheinlich während des gesamten Installations- und Konfigurationsprozesses sehr gelegen.

Beispiel-Architekturen Kapitel 3. Der RHN Proxy Server kann auf mehrere Arten konfiguriert werden. Wählen Sie eine Methode abhängig von folgenden Faktoren aus: 1. Die Gesamtanzahl an Client-Systemen für welche 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 kundenspezifischen Paketen und Channels, die vom RHN Proxy Server betreut werden. 4. Die Anzahl an RHN Proxy Servern, die in der Kunden-Umgebung verwendet werden. Der Rest dieses Kapitels beschreibt mögliche Konfigurationen und erläutert deren Vorteile. 3.1. Einzel-Proxy Architektur Die einfachste Konfiguration ist die Verwendung eines Einzel-RHN Proxy Server, der Ihr gesamtes Netzwerk versorgt. Diese Konfiguration ist für eine kleine Gruppe von Clients ausgelegt und für ein Netzwerk angemessen, welches vom Caching von Red Hat RPMs und dem Speichern von Custom-Paketen Vorteile ziehen kann. Der Nachteil bei der Verwendung eines RHN Proxy Server ist die Beeinträchtigung der Performance, wenn die Anzahl der Clients ansteigt, die Pakete abfragen.

12 Kapitel 3. Beispiel-Architekturen Abbildung 3-1. Einzel-Proxy Architektur 3.2. Mehrfach horizontal gereihte Proxy Architektur Für große 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 gereihte Konfiguration, kann die Last der Client-Anfragen besser ausgeglichen 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 Custom- 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 Proxies zu synchronisieren oder es kann ein Network File System (NFS) Share zwischen den Proxies und dem als Repository dienenden Custom-Channel eingerichtet werden. Jede dieser Lösungen ermöglicht es jedem Client von jeglichem RHN Proxy Server alle Custom-Pakete geliefert zu bekommen.

Kapitel 3. Beispiel-Architekturen 13 Abbildung 3-2. Mehrfach horizontal gereihte Proxy Architektur 3.3. Mehrfache, vertikal gereihte Proxy Architektur Ein alternatives Verfahren für den Einsatz von mehreren RHN Proxy Servern ist das Einrichten eines primären Proxy mit dem die anderen verbinden, um RPMs von Red Hat Network zu erhalten sowie auch Custom-Pakete, die lokal erstellt wurden. Im Wesentlichen verhalten sich die sekundären Proxies wie Clients für den primären Proxy. Dadurch ist die Notwendigkeit nicht mehr so hoch, dass eine Synchronisation zwischen den RHN Proxy Servern stattfindet, da diese up2date-funktionalität verwenden. Wie bei der horizontal gereihten Konfiguration, ermöglicht diese vertikale Methode jeglichem Client eines jeglichen RHN Proxy Servers alle Custom-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 gereihte Konfiguration gewährleistet, dass die sekundären Proxies von den primären Proxies für Updates von RHN angewiesen sind sowie auch für Custom-Pakete. Auch dürfen Custom-Channels und Pakete nur auf dem primären Proxy abgelegt werden, um eine Verteilung zu den Child-Proxies sicherzustellen. Schlussendlich müssen die Konfigurationsdateien des sekundären Proxies auf den primären Proxy-Server gerichtet sein, anstatt direkt auf Red Hat Network.

14 Kapitel 3. Beispiel-Architekturen Abbildung 3-3. Mehrfache, vertikal gereihte Proxy Architektur 3.4. Proxies 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 gereihte 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 Linken 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, siehe das RHN Channel-Managementhandbuch.

Installation Kapitel 4. Dieses Kapitel beschreibt die Eingangsinstallation des RHN Proxy Server. Es wird davon ausgegangen, dass die Voraussetzungen, wie in Kapitel 2 beschrieben, erfüllt worden sind. Wenn Sie jedoch auf eine neuere Version von <RHN Proxy Server aufrüsten, kontaktieren Sie den für Sie zuständigen Red Hat-Repräsentanten. 4.1. Basisinstallation Der RHN Proxy Server ist für das Red Hat Enterprise Linux AS-Betriebssystem ausgelegt. Deshalb ist die erste Phase die Installation des Basisbetriebssystems von CD via 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 in Übereinstimmung mit den zuvor erwähnten Hardware-Anforderungen zu speichern. Gechachte Red Hat-Pakete befinden sich standardmäßig in /var/spool/squid, wohingegen sich Custom-Pakete in /var/spool/rhn-proxy befinden. Installieren Sie nur die von RHN Proxy Server benötigten Pakete und nicht mehr. Sie dürfen nur diese Basispakete installieren, da die Installation zusätzlicher Pakete das Fehlschlagen der RHN Proxy Server-Installation zur Folge haben können Siehe Abschnitt 2.1 für das Verfahren, wie Sie die richtige Paketgruppe erhalten können, die für jede Version von Red Hat Enterprise Linux AS benötigt wird. Wichtig Wenn Sie Monitoring-Level-Service erhalten möchten, müssen Sie Ihren RHN Proxy Server auf Red Hat Enterprise Linux AS 3 Update 5 oder Red Hat Enterprise Linux AS 4 installieren. Dies sind die einzigen, unterstützten Basisbetriebssysteme für Proxies, deren Dienste Monitoring-berechtigten Systeme in Anspruch nehmen. 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 ablaufen und auf die korrekte Zeitzone eingestellt sein. Deaktivieren Sie die ipchains und iptables-dienste nach der Installation.