Red Hat Network Satellite 5.5

Transkript

1 Red Hat Network Satellite 5.5 Proxy-Installationshandbuch Ausgabe 3 Red Hat Network Satellite Last Updated:

2

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

4 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. Zusammenfassung Willkommen beim RHN Proxy-Installationshandbuch.

5 Inhaltsverzeichnis Inhaltsverzeichnis. KAPITEL EINFÜHRUNG RED HAT NETZWERK HÄUFIG VERWENDETE TERMINOLOGIEN RHN PROXY SERVER PROXY FUNKTIONSWEISE 5. KAPITEL ANFORDERUNGEN SOFTWARE-ANFORDERUNGEN HARDWARE-ANFORDERUNGEN SPEICHERPLATZANFORDERUNGEN WEITERE ANFORDERUNGEN 8. KAPITEL BEISPIELTOPOLOGIEN EINZEL-PROXY-TOPOLOGIE MEHRFACH HORIZONTAL GESTAFFELTE PROXY-TOPOLOGIE MEHRFACH VERTIKAL GESTAFFELTE PROXY-TOPOLOGIE PROXYS MIT RHN SATELLITE SERVER 13. KAPITEL INSTALLATION BASISINSTALLATION RHN PROXY SERVER INSTALLATIONSVORGANG Die Antwortdatei 18. 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. ANHANG A.... BEISPIEL FÜR..... EINE..... RHN..... PROXY SERVER KONFIGURATIONS-DATEI ANHANG B.... VERSIONSGESCHICHTE STICHWORTVERZEICHNIS

6 Proxy-Installationshandbuch 2

7 KAPITEL 1. EINFÜHRUNG KAPITEL 1. EINFÜHRUNG 1.1. RED HAT NETZWERK Das Red Hat Network (RHN) ist die Umgebung für den Support auf Systemebene, die Verwaltung von Red Hat Systemen und Netzwerken von Systemen. Red Hat Network vereint die notwendigen Werkzeuge, Dienste und Informationsquellen, um die Zuverlässigkeit, Sicherheit und Leistung der Systeme zu maximieren. Um RHN verwenden zu können, registrieren Administratoren die Softwareund 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 Zugang zu den Channel- 3

8 Proxy-Installationshandbuch Managementfähigkeiten. Benutzer in dieser Rolle können Channels erstellen, Pakete bestimmten, Channels zuordnen, Channels klonen und Channels löschen. Diese Rolle kann von einem Organisations-Verwalter über den Benutzer Tab auf der RHN-Website vergeben werden. Red Hat Update Agent Der Red Hat Update Agent ist die Red Hat Network Client-Applikation (up2date oder yum), mit der Benutzer neue oder aktualisierte Pakete für das Client-System, auf dem die Applikation abläuft, abrufen und installieren können. Traceback Ein 'Traceback' ist eine detaillierte Beschreibung dessen, "was schiefgelaufen ist", die sich bestens zur Suche und Bereinigung von Fehlern im RHN Proxy Server eignet. Tracebacks werden automatisch generiert, wenn ein kritischer Fehler auftritt und werden dann an die in der Konfigurations-Datei des RHN Proxy Servers dafür vorgesehenen Personen als versendet. Mehr detaillierte Beispiele zu diesen Thema 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 Zugriff auf das Internet. Auch wenn die Pakete durch den Proxy bereitgestellt werden, sind die Systemprofile der Clients und die Benutzerinformationen sicher und zentral im RHN-Server gespeichert [1], der auch die RHN- Webseite bedient (rhn.redhat.com). Der Proxy dient als Zwischenstation zwischen Client-Systemen und Red Hat Network (oder einem RHN Satellite Server). Nur die Paketdateien sind auf dem RHN Proxy Server gespeichert. Jede Transaktion wird authentifiziert, und der Red Hat Update Agent überprüft die GPG-Signatur aller Pakete vom lokalen RHN Proxy Server. Zusätzlich zum Speichern von offiziellen Red Hat Paketen kann der RHN Proxy Server auch darauf konfiguriert werden, eigene kundenspezifische Pakete von privaten RHN Channels mithilfe des RHN Package Managers bereitzustellen. Zum Beispiel kann eine Organisation ihre eigene Software entwickeln, als RPM paketieren, es mit einer eigenen GPG-Signatur versehen und mithilfe des lokalen RHN Proxy Server alle einzelnen Systeme im Netzwerk mit der neuesten Version der kundenspezifischen Software aktualisieren. Vorteile bei der Verwendung von RHN Proxy Server: Skalierbarkeit Es kann mehrere lokale RHN Proxy Server innerhalb eines Unternehmens geben. Sicherheit Es wird für eine durchgehend sichere Verbindung gesorgt: Von den Client- Systemen zum lokalen RHN Proxy Server und zu den Red Hat Network Servern. Zeitersparnis Pakete werden wesentlich schneller über ein lokales Netzwerk geliefert, als über das Internet. 4

9 KAPITEL 1. EINFÜHRUNG Bandbreitenersparnis Pakete werden nur einmal vom RHN heruntergeladen (über den lokalen Proxy-Server-Caching-Mechanismus), anstatt jedes Paket für jedes Client-System einzeln herunterzuladen. Kundenspezifische Updates Ermöglicht ein völlig automatisiertes Paketlieferungssystem für kundenspezifische Software-Pakete sowie auch offizielle Red Hat Pakete, welche für die Client-Systeme benötigt werden. Kundenspezifische, private RHN-Channels ermöglichen es einem Unternehmen, die Lieferung von firmeninternen, betriebseigenen Paketen zu automatisieren. Kundenspezifische Konfiguration Sie können Updates für spezifische Architekturen und Betriebssystemversionen entweder unterbinden oder erlauben. Nur eine Internetverbindung nötig Da die Clients sich direkt mit dem RHN Proxy Server verbinden und nicht mit dem Internet, benötigen Sie nur eine LAN-Verbindung zum Proxy. Nur der RHN Proxy Server benötigt eine Internetverbindung, um die RHN Server zu kontaktieren, es sei denn, der RHN Proxy Server benutzt einen RHN Satellite Server, in welchem Fall nur der RHN Satellite Server eine Internetverbindung benötigt PROXY FUNKTIONSWEISE Der Red Hat Update Agent oder Paket-Updater auf den Client-Systemen kontaktiert den Red Hat Network Server nicht direkt. Stattdessen verbinden sich die Clients mit einem RHN Proxy Server, der sich wiederum mit den Red Hat Network Servern oder einem RHN Satellite Server verbindet. Demnach benötigen die Client-Systeme keinen direkten Zugang zum Internet. Diese benötigen nur Zugang zum RHN Proxy Server. WICHTIG Es wird von Red Hat dringend empfohlen, dass Clients, die mit einem RHN Proxy Server verbunden sind, die neueste Version von Red Hat Enterprise Linux besitzen, um eine einwandfreie Verbindungsfähigkeit zu gewährleisten. Clients, die direkt auf RHN zugreifen, werden standardmäßig von den RHN-Servern authentifiziert. Clients, die auf einen RHN Proxy Server zugreifen, werden auch von RHN authentifiziert, allerdings stellt der Proxy dem RHN in diesem Fall sowohl Authentifizierungs- als auch Routing-Informationen zur Verfügung. Nach einer erfolgreichen Authentifizierung informiert der Red Hat Network den RHN Proxy Server darüber, dass es dem RHN Proxy Server gestattet wurde, eine bestimmte Aktion für einen Client auszuführen. Der RHN Proxy Server lädt anschließend alle aktualisierten Pakete herunter (wenn sich diese noch nicht in seinem Cache befinden) und liefert diese an die Client-Systeme. Anfragen des Red Hat Update Agents oder Paket-Updaters auf den Client-Systemen werden noch immer serverseitig authentifiziert, wobei jedoch die Paketlieferung wesentlich schneller ist, da die Pakete im HTTP Proxy Caching Server oder dem RHN Proxy Server (für lokale Pakete) zwischengespeichert werden; der RHN Proxy Server und das Client-System sind über das LAN verbunden und werden nur durch die Geschwindigkeit des lokalen Netzwerks eingeschränkt. Authentifizierung erfolgt in der folgenden Reihenfolge: 1. Der Client meldet sich zu Beginn einer Client-Sitzung an. Diese Anmeldung durchläuft einen oder mehrere RHN Proxy Server, bis sie einen Red Hat Network erreicht. 2. Der Red Hat Network versucht, den Client zu authentifizieren. Bei erfolgreicher Authentifizierung sendet der Server einen Session-Token über die Kette von RHN Proxy Servern zurück. Dieser Token hat eine Signatur und ein Verfallsdatum und beinhaltet 5

10 Proxy-Installationshandbuch Benutzerinformationen, wie u.a. subskribierte Channels, Benutzername, usw. 3. Jeder RHN Proxy Server speichert diesen Token auf seinem lokalen Dateisystem in /var/cache/rhn/ zwischen. Caching reduziert den Overhead in Zusammenhang mit der Authentifizierung mit Red Hat Network und verbessert somit drastisch das Leistungsvermögen des Red Hat Networks. 4. Dieser Session-Token wird an den Client-Rechner zurückgesendet und wird bei späteren Vorgängen im Red Hat Network verwendet. Es gibt aus Sicht des Clients keinen Unterschied zwischen einem RHN Proxy Server und einem Red Hat Network Server. Aus Sicht des Red Hat Network Servers ist ein RHN Proxy Server eine spezielle Art von RHN-Client. Folglich hat es auf Clients keinerlei Auswirkungen, welche Route eine Anfrage nimmt, um einen Red Hat Network Server zu erreichen. Die gesamte Logik ist in den RHN Proxy Servern und den Red Hat Network Servern implementiert. Optional kann der RHN Package Manager installiert und zum Bereitstellen kundenspezifischer Software-Pakete konfiguriert werden. Jegliche Pakete, bei denen es sich nicht um offizielle Red Hat Pakete handelt, einschließlich speziell für ein Unternehmen geschriebene Pakete, können nur von einem privaten Software-Channel (auch kundenspezifischer Software-Channel genannt) bereitgestellt werden. Nachdem ein privater RHN-Channel erstellt wurde, werden die kundenspezifischen RPM- Pakete mit dem privaten Channel verknüpft, indem die Paket-Header auf die RHN-Server hochgeladen werden. Es werden nur die Header hochgeladen, nicht die eigentlichen Paketdateien. Die Header sind erforderlich, da diese äußerst wichtige RPM-Informationen enthalten, wie beispielsweise Software- Abhängigkeiten, die es RHN ermöglichen, die Paketinstallation zu automatisieren. Die eigentlichen, kundenspezifischen RPM-Pakete werden auf dem RHN Proxy Server aufbewahrt und an die Client- Systeme intern über das lokale Netzwerk des Unternehmens versendet. Die Konfiguration eines Computernetzwerks zur Verwendung von RHN Proxy Servern ist ein recht unkomplizierter Prozess. Die Red Hat Network Applikationen auf den Client-Systemen müssen so konfiguriert werden, dass diese mit dem RHN Proxy Server anstelle der Red Hat Network Server verbinden. Siehe RHN Client-Konfigurationshandbuch für nähere Details. Proxyseitig muss der nächste Proxy in der Kette festgelegt werden (die letztendlich mit einem Red Hat Network Server endet). Wenn der RHN Package Manager verwendet wird, müssen die Client-Systeme den privaten RHN-Channel subskribieren. [1] Im Laufe dieses Dokuments kann sich "RHN" entweder auf die RHN Hosted Seite ( oder auf einen RHN Satellite Server beziehen. 6

11 KAPITEL 2. ANFORDERUNGEN 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 Für die Installation von Red Hat Enterprise Linux von CD oder ISO-Image wählen Sie folgende Paketgruppe aus: Minimal Eine verfügbare RHN Proxy Server Berechtigung innerhalb des RHN Satellite Server Kontos. Eine verfügbare Bereitstellungs-Berechtigung innerhalb des RHN Satellite Server Kontos (welche gebündelt mit der RHN Proxy Server Berechtigung kommen sollte). 7

12 Proxy-Installationshandbuch Zugriff auf den Red Hat Network Tools-Channel für die installierte Version von Red Hat Enterprise Linux. Dieser Kanal beinhaltet das spacewalk-proxy-installer Paket, welches das für die Installation eines RHN Proxy Servers benötigte configure-proxy.sh Installationsprogramm enthält. Alle auf dem Proxy installierten rhncfg*-pakete (vom RHN-Tools-Channel). Entweder das auf dem Proxy installierte rhns-certs-tools Paket (vom RHN-Tools- Channel) für RHN Hosted Benutzer, oder das Secure Sockets Layer (SSL) CA- Zertifikatpasswort, welches für RHN Satellite Server-Benutzer zur Generierung des Parent- Server-Zertifikats verwendet wird. Eine Konfiguration auf dem System, die Befehle von Remote aus und Konfigurationsmanagement durch das Red Hat Network akzeptiert, falls die veraltete Installationsmethode via Weboberfläche angewendet wird. Siehe Abschnitt 4.2,»RHN Proxy Server Installationsvorgang«für weitere Anweisungen HARDWARE-ANFORDERUNGEN Die folgende Hardware-Konfiguration ist für den RHN Proxy Server erforderlich: Ein Pentium IV Prozessor oder äquivalent 512 MB Arbeitsspeicher Mindestens 5 GB Speicherplatz für die Basisinstallation von Red Hat Enterprise Linux 25+ GB Speicherplatz pro Distribution/Channel Die Last auf dem Apache Web Server steht in direktem Zusammenhang mit der Häufigkeit, mit der Client-Systeme mit dem Proxy verbinden. Wenn Sie daher das Standardintervall von vier Stunden (oder 240 Minuten), wie in der Konfigurationsdatei /etc/sysconfig/rhn/rhnsd festgelegt, reduzieren, dann steigern Sie damit maßgeblich die Last auf dieser Komponente SPEICHERPLATZANFORDERUNGEN Der vom RHN Proxy Server eingesetzte Caching-Mechanismus ist der Squid HTTP-Proxy, der in signifikantem Maß Bandbreite für die Clients einspart. Dieser sollte eine angemessene Menge an Speicherplatz zur Verfügung haben. Die zwischengepeicherten Pakete werden in /var/spool/squid abgelegt. Die erforderliche Zuweisung an freiem Speicherplatz ist 6 GB Speicher pro Distribution/Channel. Wenn der RHN Proxy Server zur Distribution von kundenspezifischen Paketen (auch "Custom-Pakete" genannt) oder lokalen Paketen konfiguriert ist, dann gehen Sie sicher, dass auf dem /var Einhängepunkt auf dem System, welches die lokalen Pakete speichert, ausreichend Plattenspeicher vorhanden ist, um sämtliche kundenspezifischen Pakete unterzubringen, die in /var/spool/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 Zugang 8

13 KAPITEL 2. ANFORDERUNGEN Client-Systeme benötigen vollen Netzwerkzugang zu den RHN Proxy Server-Diensten und Ports. Firewall-Regeln Es wird von RHN dringend empfohlen, den RHN Proxy Server durch einen Firewall vom Internet zu schützen. Jedoch sollten verschiedene TCP-Ports offen bleiben, je nach der Implementation des RHN Proxy Server: Tabelle 2.1. Ports, die im Proxy geöffnet werden sollten Port Richtung Grund 80 Ausgehend Proxy nutzt diesen Port um rhn.redhat.com, xmlrpc.rhn.redhat.com und Ihre Satellite URL zu erreichen (je nachdem, ob RHN Proxy entweder mit RHN Hosted oder einem Satellite Server kommuniziert). 80 Eingehend Client-Anfragen gehen über http oder https ein 443 Eingehend Client-Anfragen gehen über http oder https ein 443 Ausgehend Der Proxy nutzt diesen Port, um rhn.redhat.com, xmlrpc.rhn.redhat.com und die Satellite-URL zu erreichen (abhängig davon, ob RHN Proxy mit RHN Hosted oder einem Satellite Server kommuniziert) Ausgehend Falls Ihr Proxy mit einen RHN Satellite Server verbunden ist, verbindet sich das Monitoring über diese TCP-Ports mit Client- Systemen, auf denen rhnmd läuft, sofern Monitoring aktiviert ist und nach registrierten Systemen sucht Eingehend Das Öffnen dieses Ports erlaubt dem osad- Client, sich mit dem jabberd Dämon auf der Proxy zu verbinden, wenn die RHN- Push-Technologie verwendet wird Ausgehend Falls Ihr Proxy mit einem RHN Satellite Server verbindet, muss dieser Port geöffnet sein, um zwischen den Servern Verbindungen über jabberd für die RHN- Push-Technologie zu erlauben. Synchronisierte Systemzeiten Die korrekte Zeit spielt eine bedeutende Rolle, wenn mit einem SSL- (Secure Sockets Layer) fähigen Webserver verbunden wird; es ist von entscheidender Bedeutung, dass die Zeiteinstellungen auf den Clients und dem Server sehr nahe beieinander liegen, sodass das SSL- 9

14 Proxy-Installationshandbuch Zertifikat nicht vor oder während der Verwendung abläuft. Das Network Time Protokoll (NTP) wird zur Synchronisation der Systemzeiten empfohlen. Voll qualifizierter Domain-Name (FQDN) Das System, auf dem der RHN Proxy Server installiert wird, muss in der Lage sein, den eigenen FQDN richtig aufzulösen. Red Hat Netzwerk Konto Kunden, die sich mit den zentralen Red Hat Network Servern verbinden, um inkrementelle Updates zu erhalten, benötigen ein Red Hat Network Konto. Dieses Konto sollte zum Kaufzeitpunkt gemeinsam mit dem Vertriebsmitarbeiter eingerichtet werden. Backups von Login-Informationen Es ist zwingend notwendig, dass Kunden über alle primären Login-Informationen die Übersicht behalten. Im Falle eines RHN Proxy Servers sind dies u.a. Benutzernamen und Passwörter für das Organisationsadministrator Konto und die SSL-Zertifikat-Generierung. Red Hat empfiehlt dringend, dass diese Informationen auf zwei separate Datenträger kopiert wird, ausgedruckt wird, und der Ausdruck in einem sicheren Platz (Tresor) aufbewahrt wird. Distributionsspeicherorte Da der Proxy nahezu alle lokalen HTTP-Anfragen an die zentralen RHN Server weiterleitet, müssen Sie darauf achtgeben, dass Sie alle Dateien, die für die Distribution vorgesehen sind (wie beispielsweise in einem Kickstart-Installationsbaum) in einem Ort auf dem Proxy ablegen, wo nicht weitergeleitet wird: /var/www/html/pub/. Dateien, die in diesem Verzeichnis abgelegt werden, können direkt vom Proxy heruntergeladen werden. Dies kann für das Verteilen von GPG-Schlüsseln oder dem Erstellen von Installationsbäumen für Kickstarts besonders hilfreich sein. Zusätzlich dazu empfiehlt Red Hat, dass das System, auf dem der Code ausgeführt wird, nicht öffentlich zugänglich ist. Es sollten nur Systemadministratoren Shell-Zugang zu diesen Rechnern besitzen, aber keine anderen Benutzer. Alle nicht notwendigen Dienste sollten deaktiviert werden. Sie können ntsysv oder chkconfig zur Deaktivierung von Diensten verwenden. Schlussendlich sollten Sie folgende technische Dokumente für den Einsatz griffbereit haben, ungefähr in dieser Reihenfolge: 1. Das RHN Proxy Server-Installationshandbuch Dieses Handbuch, welches Sie gerade lesen, behandelt die wesentlichen Schritte, um ein RHN Proxy Server einsatzbereit zu machen. 2. Das RHN Client Konfigurations-Handbuch Dieses Handbuch erklärt, wie Systeme konfiguriert werden müssen, um von einem RHN Proxy Server oder RHN Satellite Server bedient zu werden. (Wahrscheinlich erfordert dies auch die Zuhilfenahme des RHN Referenz-Handbuchs, welches Schritte zur Registrierung und Aktualisierung von Systemen enthält.) 3. Das RHN Channel Management-Handbuch Dieses Handbuch behandelt detailgenau die empfohlenen Methoden für die Erstellung von kundenspezifischen Paketen und Channels sowie auch zur Verwaltung privater Errata. 4. Das RHN Referenz-Handbuch Dieses Handbuch beschreibt das Einrichten von RHN-Konten, die Registrierung und Aktualisierung von Systemen sowie Hinweise dazu, wie Sie das Potenzial der RHN-Website am besten ausschöpfen können. Dieses Handbuch kommt sicherlich während des gesamten Installations- und Konfigurationsprozesses hindurch gelegen. 10

15 KAPITEL 3. BEISPIELTOPOLOGIEN 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-Topologie 3.2. MEHRFACH HORIZONTAL GESTAFFELTE PROXY-TOPOLOGIE Für größere Netzwerke könnte eine weiter verteilte Methode erforderlich sein, wie beispielsweise mehrere RHN Proxy Server, die mit Red Hat Network individuell verbunden sind. Durch diese horizontal gestaffelte Konfiguration kann die Last der Client-Anfragen besser verteilt werden und gleichzeitig ist jeder Proxy in der Lage, simultan mit RHN zu synchronisieren. 11

16 Proxy-Installationshandbuch Ein Nachteil dieser horizontalen Struktur besteht darin, dass benutzerdefinierte Pakete, die auf einen einzelnen Proxy hochgeladen wurden, anschließend ebenfalls an die Geschwister-Server verteilt werden müssen. Dieser Situation kann auf zwei Arten begegnet werden: Das Dateiübertragungsprogramm rsync wird verwendet um Pakete zwischen den Proxys zu synchronisieren Ein Network File System (NFS) Share kann zwischen den Proxys und dem als Repository dienenden benutzerdefinierten Channel eingerichtet werden. Beide Lösungen ermöglichen es jedem Client von jedem RHN Proxy Server, alle benutzerdefinierten Pakete geliefert zu bekommen. Abbildung 3.2. Mehrfach horizontal gestaffelte Proxy-Topologie 3.3. MEHRFACH VERTIKAL GESTAFFELTE PROXY-TOPOLOGIE Ein alternatives Verfahren für den Einsatz von mehreren RHN Proxy Servern ist das Einrichten eines primären Proxys, mit dem die anderen verbinden, um RPMs vom Red Hat Network zu erhalten sowie auch benutzerdefinierte Pakete, die lokal erstellt wurden. Im Wesentlichen verhalten sich die sekundären Proxys wie Clients des primären Proxys. Dadurch ist die Notwendigkeit nicht mehr so hoch, dass eine Synchronisation zwischen den RHN Proxy Servern stattfindet, da diese die im Produkt enthaltene up2date Funktionalität verwenden. Wie bei der horizontal gestaffelten Konfiguration ermöglicht diese vertikale Methode jedem Client eines jeden RHN Proxy Servers, alle benutzerdefinierten Pakete geliefert zu bekommen. Der Proxy sieht lediglich im eigenen Repository nach, ob sich das Paket im Dateisystem befindet. Wenn nicht, versucht der Proxy es eine Stufe höher. Diese vertikal gestaffelte Konfiguration gewährleistet, dass die sekundären Proxys für Updates von RHN sowie auch für benutzerdefinierte Pakete auf die primären Proxys angewiesen sind. Auch dürfen benutzerdefinierte Channels und Pakete nur auf dem primären Proxy abgelegt werden, um eine Verteilung zu den untergeordneten Proxys sicherzustellen. Schlussendlich müssen die Konfigurations- Dateien des sekundären Proxys auf den primären Proxy Server verweisen, anstatt direkt auf Red Hat Network. 12

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

18 Proxy-Installationshandbuch 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. 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 RHN PROXY SERVER INSTALLATIONSVORGANG Die folgenden Anleitungen beschreiben den RHN Proxy Server Installationsvorgang: 1. Melden Sie sich als Root-Benutzer auf dem beabsichtigten RHN Proxy Server System an. 2. Registrieren Sie das neu installierte Red Hat Enterprise Linux System beim Red Hat Network (entweder dem zentralen RHN Server oder Ihrem RHN Satellite Server) unter Verwendung des Organisations-Accounts, der die RHN Proxy Server Berechtigung beinhaltet, mit dem Befehl: rhn_register. 3. Subskribieren Sie den Client auf den RHN Tools-Kanal. 14

19 KAPITEL 4. INSTALLATION 4. Installieren Sie den Proxy Installer: yum install spacewalk-proxy-installer 5. Installation durchführen: configure-proxy.sh ANMERKUNG Um diesen Schritt erfolgreich durchzuführen ist Root-Zugriff auf den Satellite Server erforderlich. Alternativ können Sie die --force-own-ca Option zum Befehl hinzufügen. Das Befehlszeilen-Installationsprogramm führt Benutzer durch eine Reihe von Eingabeaufforderungen ("Prompts") bezüglich der RHN Proxy Server Installation und Details zur Anfangskonfiguration, wie z.b. Installationsoptionen und Generierung der SSL-Zertifikate. Die folgenden Anleitungen beschreiben den Installationsvorgang: ANMERKUNG Wenn Sie bei einem Prompt die Enter Taste drücken, anstatt eine Eingabe zu tippen, so verwendet das Befehlszeilen-Installationsprogramm die in Klammern angezeigte Standardantwort. Falls Sie alternativ ohne jegliche Benutzereingabe die Standardantworten übernehmen möchten, verwenden Sie die --non-interactive Option, wodurch sämtliche Standardantworten verwendet werden. 6. Bei der ersten Reihe von Eingabeaufforderungen werden Details abgefragt, spezifisch für den Rechner, auf dem Sie installieren. Proxy version to activate [5.4]: Die Proxy version fordert Sie dazu auf, die Version des RHN Proxy Servers anzugeben, die Sie installieren möchten. RHN Parent [satserver.example.com]: RHN Parent ist der Domain-Name oder die Adresse des Systems, das dem Proxy dient, dies können RHN Hosted Server (xmlrpc.rhn.redhat.com) oder ein Satellite Server sein. Traceback []: Traceback ist die -Adresse, an die Traceback-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-Zertifikats, was empfohlen wird, um den Datenverkehr zum und vom RHN Proxy Server zu sichern. 15

20 Proxy-Installationshandbuch Use SSL [Y/n]: y Geben Sie beim Use SSL Prompt y ein, um den RHN Proxy Server für die Unterstützung von SSL zu konfigurieren. CA Chain [/usr/share/rhn/rhn-org-trusted-ssl-cert]: Drücken Sie im CA Chain Prompt die Eingabe Taste, um den Standardpfad für die Certificate Authority (CA) Chain zu verwenden. Dieser Wert lautet normalerweise /usr/share/rhn/rhn-org-trusted-ssl-cert, falls der RHN Proxy mit einem RHN Satellite kommuniziert. Falls er dagegen mit RHN Hosted kommuniziert, ist es in der Regel die /usr/share/rhn/rhns-ca-cert Datei. Benutzerdefinierte SSL-Zertifikate müssen im /usr/share/rhn/ Verzeichnis abgelegt werden. HTTP Proxy []: Falls der RHN Proxy Server über einen HTTP-Proxy verbindet, geben Sie den Proxy- Hostnamen und die Portnummer ein, wie z.b. corporate.proxy.example.com:3128. Geben Sie die erforderlichen Details ein, um ein ordnungsgemäßes SSL-Server-Zertifikat zu generieren, einschließlich dem Namen der Organization, der Organization Unit (Organisationseinheit, wie z.b. Engineering), Common Name (der Domain-Name), sowie Angaben zu Ort, Bundesland und Land. Zum Schluss geben Sie noch die -Adresse des Administrators oder des technischen Kontakts ein, der für SSL-Zertifikate zuständig ist. Regardless of whether you enabled SSL for the connection to the Proxy Parent Server, you will be prompted to generate an SSL certificate. This SSL certificate will allow client systems to connect to this Spacewalk Proxy securely. Refer to the Spacewalk Proxy Installation Guide for more information. Organization: Example Company Organization Unit [proxy1.example.com]: Common Name: proxy1.example.com City: New York State: New York Country code: US [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 16

21 KAPITEL 4. INSTALLATION 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 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_ ? [Y]: Using server name satserver.example.com Red Hat Network username: admin Password: Creating config channel rhn_proxy_config_ Config channel rhn_proxy_config_ created using server name satserver.example.com Pushing to channel rhn_proxy_config_ : Local file /etc/httpd/conf.d/ssl.conf -> remote file /etc/httpd/conf.d/ssl.conf Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf Local file /etc/rhn/cluster.ini -> remote file /etc/rhn/cluster.ini Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf Local file /etc/httpd/conf.d/cobbler-proxy.conf -> remote file /etc/httpd/conf.d/cobbler-proxy.conf Local file /etc/httpd/conf.d/rhn_proxy.conf -> remote file /etc/httpd/conf.d/rhn_proxy.conf Local file /etc/httpd/conf.d/rhn_broker.conf -> remote file /etc/httpd/conf.d/rhn_broker.conf Local file /etc/httpd/conf.d/rhn_redirect.conf -> remote file /etc/httpd/conf.d/rhn_redirect.conf Local file /etc/jabberd/c2s.xml -> remote file /etc/jabberd/c2s.xml Local file /etc/jabberd/sm.xml -> remote file /etc/jabberd/sm.xml Das Installationsprogramm fragt anschließend, ob Sie einen Konfigurations-Kanal basierend auf den Konfigurations-Dateien erstellen möchten, die beim Ausführen von configureproxy.sh erstellt wurden. Daraufhin erstellt das Installationsprogramm einen RHN Satellite Server Konfigurations-Kanal, basierend auf dem Namen des Client-Systems, auf dem der RHN Proxy Server installiert ist (im obigen Beispiel lautet die sysid ), und sammelt die verschiedenen httpd, SSL, squid, und jabberd Server-Dateien, aus denen der Konfigurations-Kanal für den Proxy Server bestehen wird. 17

22 Proxy-Installationshandbuch 9. Zu guter Letzt startet (bzw. startet neu) das Installationsprogramm alle Dienste, die mit dem RHN Proxy Server in Zusammenhang stehen; sobald dies abgeschlossen ist, beendet es sich selbst. Enabling Satellite Proxy Shutting down rhn-proxy... Shutting down Jabber router: [ OK ] Stopping httpd: [ OK ] Stopping squid: [ OK ] Done. Starting rhn-proxy... init_cache_dir /var/spool/squid... Starting squid:. [ OK ] Starting httpd: [ OK ] Starting Jabber services [ OK ] Done Die Antwortdatei Falls Sie den Vorgang der RHN Proxy Server Installation auf Ihrem System teilweise automatisieren möchten, ermöglicht das configure-proxy.sh Programm den Administratoren, Antwortdateien zu erstellen, die vordefinierte Antworten auf die Eingabeaufforderungen im Installationsprogramm enthalten. Im Folgenden sehen Sie ein Beispiel für eine Antwortdatei, die vordefinierte Antworten hinsichtlich der Versionsnummer, des RHN Satellite Servers, der als übergeordneter Server fungiert, SSL, und weiteren Konfigurations-Parametern enthält. Für weitere Informationen über die Erstellung und Verwendung von Antwortdateien werfen Sie bitte einen Blick auf die configure-proxy.sh Handbuchseite durch Eingabe von man configure-proxy.sh in einem Shell-Prompt. # Beispiel einer Antwortdatei für configure-proxy.sh # Für eine vollständige Liste möglicher Optionen siehe # man configure-proxy.sh VERSION=5.2 RHN_PARENT=rhn-satellite.example.com TRACEBACK_ =jsmith@example.com USE_SSL=1 SSL_ORG="Red Hat" SSL_ORGUNIT="Spacewalk" SSL_CITY=Raleigh SSL_STATE=NC SSL_COUNTRY=US INSTALL_MONITORING=N ENABLE_SCOUT=N CA_CHAIN=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT POPULATE_CONFIG_CHANNEL=Y Um eine Antwortdatei (z.b. namens answers.txt) mit configure-proxy.sh zu verwenden, geben Sie ein: 18

23 KAPITEL 4. INSTALLATION configure-proxy.sh --answer-file=answers.txt 19

24 Proxy-Installationshandbuch KAPITEL 5. RHN PACKAGE MANAGER UND DIE LIEFERUNG LOKALER PAKETE Der RHN Package Manager ist ein Befehlszeilen-Tool, durch das eine Organisation lokale Pakete mit einem privaten RHN-Channel durch den RHN Proxy Server betreuen kann. Installieren Sie den RHN Package Manager nicht um nur offizielle Red Hat-Pakete für den RHN Proxy Server zu aktualisieren. Um den RHN Package Manager zu verwenden, installieren Sie das spacewalk-proxy-packagemanager Paket samt aller Abhängigkeiten. Es wird nur die Header-Information für Pakete auf die RHN Server hochgeladen. Die Header werden dazu benötigt, um RHN das Auflösen von Paketabhängigkeiten für die Client-Systeme zu ermöglichen. Die eigentlichen Paketdateien (*.rpm) befinden sich auf dem RHN Proxy Server. Der RHN Package Manager verwendet dieselben Einstellungen wie der Proxy, die in der /etc/rhn/rhn.conf Konfigurations-Datei festgelegt sind. Sehen Sie im Folgenden eine Zusammenfassung aller Befehlszeilen-Optionen für den RHN Package Manager rhn_package_manager: Tabelle 5.1. Optionen für rhn_package_manager Option Beschreibung -v, --verbose Ausführlichkeit der Ausgabe erhöhen. -ddir, --dir=dir Verarbeitet die Pakete des Verzeichnisses DIR. -cchannel, --channel=channel Verwaltet diesen Kanal kann auch mehrmals vorhanden sein. -nnumber, --count=number Verarbeitet diese Anzahl von Headern pro Aufruf Standard ist 32. -l, --list Listet jeden Paketnamen, jede Versionsummer, Release- Nummer und Architektur in den festgelegten Channels/im Channel auf. -s, --sync Überprüft, ob lokales Verzeichnis mit dem Server abgestimmt (synchron) ist. -p, --printconf Zeigt die aktuelle Konfiguration an und beendet. -XPATTERN, --exclude=pattern Schließt Dateien aus, die diesem globalen Ausdruck entsprechen kann auch mehrmals vorhanden sein. --newest Sende nur die Pakete, die neuer sind als die bereits für den festgelegten Kanal zum Server gesendeten Pakete. --stdin Liest die Paketnamen von der Standardeingabe. 20

25 KAPITEL 5. RHN PACKAGE MANAGER UND DIE LIEFERUNG LOKALER PAKETE Option Beschreibung --nosig Sende nicht-signierte Pakete. Standardmäßig versucht der RHN Package Manager, nur signierte Pakete zu senden. --username=username Geben Sie Ihren RHN-Benutzernamen ein. Wenn Sie mit dieser Option keinen Benutzernamen angeben, dann werden Sie dazu aufgefordert. --password=password Geben Sie Ihr RHN-Passwort ein. Wenn Sie mit dieser Option kein Passwort angeben, dann werden Sie dazu aufgefordert. --source Lädt Quellpaket-Header hoch. --dontcopy Nach dem Hochladen werden die Pakete nicht automatisch in den Paketbaum kopiert. --test Zeigt nur die zu sendenden Pakete an. --no-ssl Nicht empfohlen SSL abschalten. -?, --usage Beschreibt kurz die Optionen. --copyonly Kopiert die als Parameter angegebene Datei in den angegebenen Kanal. Nützlich, wenn einem Kanal auf dem Proxy ein Paket fehlt und Sie nicht alle Pakete im Kanal nochmals importieren möchten. Beispielsweise: rhn_package_manager-cchannel-- copyonly/path/to/missing/file -h, --help Zeigt den Hilfebildschirm mit einer Liste von Optionen an. ANMERKUNG Diese Befehlszeilenoptionen sind auch auf der rhn_package_manager Handbuchseite aufgeführt: man rhn_package_manager. Damit RHN Package Manager in der Lage ist die lokalen Pakete zu senden müssen die folgenden Schritte beachtet werden: 1. Einrichten eines privaten Kanals. 2. Laden der lokalen Pakete in the Kanal. Die Schritte werden in den folgenden Abschnitten weiter besprochen ERSTELLEN EINES PRIVATEN KANALS 21

26 Proxy-Installationshandbuch Bevor lokale Pakete durch den RHN Proxy Server bereitgestellt werden können, benötigen Sie einen privaten Kanal zur Aufbewahrung. Führen Sie folgende Schritte durch, um einen privaten Kanal einzurichten: 1. Melden Sie sich über die RHN-Weboberfläche bei an. 2. Klicken Sie auf Channels auf der oberen Navigationsleiste. Wenn die Channels verwalten Option nicht in der linken Navigationsleiste erscheint, dann versichern Sie sich, dass dieser Benutzer über die Berechtigungen zur Kanal-Bearbeitung verfügt. Gehen Sie dazu zur Benutzer Kategorie, die über die obere Navigationsleiste zugänglich ist. 3. In der linken Navigationsleiste klicken Sie Software Channels verwalten und dann die Neuen Channel erstellen Schaltfläche ganz rechts oben auf der Seite. 4. Wählen Sie eine Parent-Channel- und Basis-Channel-Architektur aus und geben dann Name, Label, Zusammenfassung und Beschreibung für den neuen privaten Kanal ein. Das Label muss mindestens sechs Zeichen lang sein, mit einem Buchstaben beginnen und darf nur Kleinbuchstaben, Zahlen, Bindestriche (-) und Punkte enthalten. Geben Sie auch die URL des GPG-Schlüssels des Kanals ein. Obwohl dies kein zwingend erforderliches Feld ist, wird es empfohlen, um die Sicherheit zu erhöhen. Siehe RHN Channel-Managementhandbuch für eine Anleitung zur Herstellung von GPG-Schlüsseln. 5. Klicken Sie auf Kanal erstellen HOCHLADEN VON PAKETEN ANMERKUNG Sie müssen ein Organisations-Administrator sein, um Pakete auf private RHN-Channels hochladen zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und Passwort. Nach dem Einrichten des privaten Kanals können Sie die Paket-Header für Ihre Binär- und Quell-RPMs auf den RHN Server hochladen und die Pakete zum RHN Proxy Broker Server kopieren. Um die Paket- Header für die Binär-RPMs hochzuladen, geben Sie folgendes in der Befehlszeile ein: rhn_package_manager -c "label_of_private_channel" pkg-list Dieser Befehl ladet den Header des Pakets in den angegebenen Kanal, und das Paket selbst in /var/spool/rhn-proxy/rhn. pkg-list ist die Liste der hochzuladenden Pakete. Wahlweise können Sie auch die -d Option verwenden, um das lokale Verzeichnis festzulegen, welches die zum Kanal hinzuzufügenden Pakete enthält. Vergewissern Sie sich, dass das Verzeichnis nur die benötigten Pakete enthält und keine anderen Dateien. Der RHN Package Manager kann die Liste von Paketen auch von der Standardeingabe lesen (unter Verwendung von --stdin). Um die Paket-Header für die Quell-RPMs hochzuladen: rhn_package_manager -c "label_of_private_channel" --source pkg-list Wenn Sie mehr als einen Kanal angegeben haben (unter Verwendung der -c oder --channel Option), werden die hochgeladenen Paket-Header mit allen aufgelisteten Channels verknüpft. 22

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