Installationshandbuch 5.1

Transkript

1 RHN Proxy Server Installationshandbuch 5.1 ISBN: Veröffentlicht:

2 RHN Proxy Server 5.1.1

3 RHN Proxy Server 5.1.1: Installationshandbuch Copyright 2008 Red Hat, Inc. Copyright 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries. All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the key is: CA B D6 9D FC 65 F6 EC C CD DB 42 A6 0E 1801 Varsity Drive Raleigh, NC USA Phone: Phone: Fax: PO Box Research

4 RHN Proxy Server 5.1.1

5 1. Einführung Red Hat Network RHN Proxy Server Begriffserklärung Funktionsweise Anforderungen Software-Anforderungen Hardware-Anforderungen Plattenspeicherplatz-Anforderungen Zusätzliche Anforderungen Beispiel-Topologien Einzel-Proxy-Topologie Mehrfach horizontal gereihte Proxy-Topologie Mehrfache, vertikal gereihte Proxy-Topologie Proxies mit RHN Satellite Server Installation Basisinstallation RHN Proxy Server-Installationsprozess RHN Paketmanager Einrichten eines privaten Channels Pakete werden geladen Befehlszeilenoptionen Troubleshooting (Fehlersuche/-behebung) Verwalten des Proxy-Services Log-Dateien Fragen und Antworten Allgemeine Probleme Host nicht gefunden (Host Not Found)/FQDN konnte nicht ermittelt werden (Could Not Determine FQDN) Verbindungsfehler Caching Probleme Proxy-Debugging durch Red Hat...38 A. Beispiel für eine RHN Proxy Server-Konfigurationsdatei...39 Stichwortverzeichnis...41 v

6 vi

7 Einführung 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. 2. RHN Proxy Server Ein RHN Proxy Server ist ein Paket-Caching-Mechanismus der die Bandbreite von RHN reduziert und Custom-Paket-Deployment unterstützt. Proxy-Customers-Cache-RPMs wie z.b. Errata Updates von Red Hat oder Custom-RPMs von anderen Organisationen, auf einen internen, zentralen Server. Client-Systeme empfangen damit ihre Updates besser vom Proxy als individuell eine Internetverbindung aufzubauen. Auch wenn die Pakete nun mit den Proxy bedient werden, sind die Client-Systems-Profile und die Benutzerinformationen sicher und zentral im RHN-Server gespeichert 1, welcher auch die 1

8 Kapitel 1. Einführung RHN-Webseite bedient (rhn.redhat.com). Der Proxy geht zwischen Client-Systems und Red Hat Network (oder ein RHN Satellite Server). Nur die Paketdateien sind auf dem RHN Proxy Server gespeichert. Jede Transaktion ist beglaubigt, und der Red Hat Update-Agent überprüft die GPG Signatur jedes Paketes vom lokalen RHN Proxy Server. Zusätzlich zum Speichern von offiziellen Red Hat-Paketen, kann der RHN Proxy Server auch darauf konfiguriert werden eigene Custom-Pakete von privaten RHN Channels zu liefern, durch die Verwendung von RHN Paketmanager. Zum Beispiel kann eine Organisation ihre eigene Software, in einem RPM eingepackt, entwickeln, es mit einer eigenen GPG-Signatur versehen und den lokalen RHN Proxy Server upgedatet haben. Alles im individuellen System im Netzwerk mit der neusten Version der Custom-Software. 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. Spart Bandbreite Pakete werden nur einmal vom RHN heruntergeladen (via local Proxy-Server-Catching-Mechanismus) anstatt jedes Paket für jedes Client-System herunterzuladen. 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-, betriebseigenenpaketen zu automatisieren. Angepasste Konfiguration (Custom-Konfiguration) Sie können Updates für spezifische Architekturen und OS-Versionen entweder völlig einschränken oder erlauben. Es wird nur eine Internetverbindung benötigt da die Clients sich direkt mit den RHN Proxy Server verbinden und nicht mit den Internet, sie benötigen nur eine Local Area Network Verbindung zum Proxy. Nur der RHN Proxy Server benötigt eine Internetverbindung um die RHN-Server zu kontaktieren, wenn RHN Proxy Server nicht einen RHN Satellite Server benutzt, in diesem Fall benötigt nur der RHN Satellite Server eine Internet Verbindung. 3. Begriffserklärung Bevor Sie sich mit RHN Proxy Server auseinandersetzen, ist es wichtig sich zuerst mit 1 Throughout this document, "RHN" may refer to either RHN's Hosted site ( oder ein RHN Satellite Server. 2

9 Funktionsweise folgenden Red Hat Network-Begriffen vertraut zu machen: Channel Ein Channel ist eine Liste von Sofwarepaketen. Es gibt zwei Arten von Channels: Basis-Channel und Child-Channel. Ein Base-channel enthält eine Liste von Paketen die auf der spezifischen Architektur und Red Hat Veröffentlichungen basieren. Ein Child-Channel ist basiert auf einen Basis-Channel und beinhaltet extra Seiten. Organisationsadministrator Ein Organisationsadministrator ist eine Benutzerrolle mit dem höchsten Grad an Kontrolle über einen Red Hat Network-Account eines Unternehmens. Mitglieder dieser Rolle können andere Benutzer hinzufügen, andere Systeme und andere Systemgruppen der zu der Organisation hinzufügen oder löschen. Eine Red Hat Network-Organisation muss mindestens einen Organisationsadministrator haben. 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 Organisationsadministrator mit Hilfe des Benutzer-Reiters der RHN-Website vergeben werden. Red Hat Update-Agent Der Red Hat Update-Agentist die Red Hat Network-Client-Applikation (up2date oder yum), welche es Benutzern ermöglicht, neue oder aktualisierte Pakete für das Client-System, auf dem die Applikation abläuft, abzufragen und zu installieren. Traceback Ein 'Traceback' ist eine detaillierte Beschreibung von "was schiefgelaufen ist" und eignet sich bestens zum Troubleshooting von RHN Proxy Server. 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 versandt. Mehr detaillierte Beispiele zu diesen Thema und anderen finden Sie unterred Hat Network Reference Guide available at und 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. 3

10 Kapitel 1. Einführung 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 RHN-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 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 Paketmanager installiert werden und zum Zusammenstellen und 4

11 Funktionsweise 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 Servers 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 Paketmanager verwendet wird, müssen die Client-Systeme beim privaten RHN-Channel angemeldet sein. 5

12 6

13 Anforderungen 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. 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 Base Für die Installation von Red Hat Enterprise Linux AS 4 oder Red Hat Enterprise Linux AS 3 Update 5 via CD oder ISO-Image, wählen Sie folgende Paketgruppe aus: Minimal Warnung 7

14 Kapitel 2. Anforderungen Security-enhanced Linux (SELinux) muss im Red Hat Enterprise Linux AS 4 deaktiviert sein da RHN Proxy Server vorrangig ist. Dies kann auf verschiedene Arten geschehen: Während der Image-Installation von CD ISO, wählen Sie Disabled wenn die SELinux-Support-Optionen erscheinen. In der Kickstart-Installation verwenden Sie bitte den Befehl selinux --disabled Nachdem die Installation abgeschlossen ist, gehen Sie zur /etc/selinux/config Datei um SELINUX=disabled zu lesen und rebooten Sie das System. Abschießend können Sie den Befehl system-config-securitylevel-tui verwenden und das System rebooten. 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 2, RHN Proxy Server-Installationsprozess für weitere Anleitungen. 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 8

15 Plattenspeicherplatz-Anforderungen 6 GB Speicher pro Distribution/Channel Die Last auf dem Apache-Webserver 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. 3. Plattenspeicherplatz-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. 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 Es wird von RHN strengstens empfohlen den RHN Proxy Server durch eine Firewall vom Internet zu schützen. Jedoch sollten verschiedene TCP-Ports offen bleiben, je nach der Implementation des RHN Proxy Server: Port Richtung Grund 80 Outbound Proxy nutzt diesen Port zur Erreichung von rhn.redhat.com 1, xmlrpc.rhn.redhat.com 2 und satellite.rhn.redhat.com 3 (wenn er nicht in einen Nicht-Verbundenen-Modus für

16 Kapitel 2. Anforderungen Port Richtung Grund einen Satellite läuft) 80 Inbound Client anfragen kommen über http oder https hinein 443 Inbound Client anfragen kommen über http oder https hinein 443 Outbound Um und zu erreichen Outbound Falls ihr Proxy mit einen RHN Satellite Server verbunden ist, verbindet Monitoring sich mit einem aufrhnmd laufenden Client-Systems via diesem TCP.Port, fallsmonitoring deaktiviert ist und sucht es Konfiguration zum registrierten Systemen Inbound Das Öffnen dieses Ports erlaubt osad Client sich mit denjabberd Daemon auf den Proxy zu verbinden, wenn die RHN-Push-Technologie verwendet wird Outbound Falls ihr Proxy einen RHN Satellite Server verbindet, muss dieser Port geöffnet sein, um Server-to-Server Verbindung via jabberd für die RHN-Push-Technologie zu erlauben. Tabelle 2.1. Ports die im Proxy geöffnet werden sollten 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 Zeiteinstellungen 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 Protokoll (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 Account sollte 10

17 Zusätzliche Anforderungen 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 Organisationsadministrator-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 wird. Distributionsspeicherorte Da der Proxy nahezu alle lokalen HTTP-Anfragen an die zentralen RHN-Server weiterleitet, müssen Sie darauf Acht geben, dass Sie alle Dateien, die für die Distribution vorgesehen sind (wie beispielsweise in einem Kickstart-Installationsbaum) in einem Ort auf dem Proxy ablegen, wo nicht weitergeleitet wird: /var/www/html/pub/. Dateien, die in diesem Verzeichnis abgelegt werden, können direkt vom Proxy heruntergeladen werden. Dies kann für das Verteilen von GPG-Schlüsseln oder dem 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. 11

18 12

19 Beispiel-Topologien 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. 1. Einzel-Proxy-Topologie 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. Abbildung 3.1. Einzel-Proxy-Topologie 13

20 Kapitel 3. Beispiel-Topologien 2. Mehrfach horizontal gereihte Proxy-Topologie 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. Abbildung 3.2. Mehrfach horizontal gereihte Proxy-Topologie 3. Mehrfache, vertikal gereihte Proxy-Topologie 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 14

21 Proxies mit RHN Satellite Server 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. Abbildung 3.3. Mehrfache, vertikal gereihte Proxy-Topologie 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. 15

22 16

23 Installation Dieses Kapitel beschreibt die Erstinstallation von RHN Proxy Server. Es setzt die Grundvoraussetzungen, die in Kapitel 2, Anforderungen aufgelistet sind, voraus. Falls Sie jedoch upgraden auf eine neuere Version von RHN Proxy Server, kontaktieren Sie bitte ihren Red Hat Berater für weitere Hilfestellungen. 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 die erforderlichen Pakete von RHN Proxy Server und nur diese Pakete. Anmerkung Sie dürfen nur die Basispakete installieren, alle anderen würden dazu führen, dass die RHN Proxy Server-Installation fehlschlägt. Siehe Abschnitt 1, Software-Anforderungen um zu erfahren, welche Methode welche richtigen Paketgruppen für jede Version von Red Hat Enterprise Linux AS benötigt 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. 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. 17

24 Kapitel 4. Installation 2. RHN Proxy Server-Installationsprozess Die folgenden Anleitungen beschreiben den RHN Proxy Server-Installationsprozess: 1. Registrieren Sie das neu installierte Red Hat Enterprise Linux AS System mit dem Red Hat Network (entweder den zentralen RHN-Server oder Ihr RHN Satellite Server) durch die Verwendung des Unternehmensaccounts, der die RHN Proxy Server Berechtigung beinhaltet, mit den Kommando: rhn_register. 2. Geben Sie den System eine Provisioning Berechtigung. Besuchen Sie die RHN-Webseite (oder den voll qualifizierten Domainnamen des Satellite der den Proxy bedient), loggen Sie sich als Organisationsadministrator ein und gehen Sie zur Your RHN = > Subscription Management Seite. Überprüfen Sie die Box des Systems, in welchen der RHN Proxy Server installiert werden soll, wählen Sie Provisioning aus der Drop-Down-Box aus und klicken Sie auf den Add Entitlement Schalter. 3. Stellen Sie sicher, dass das System subskribiert zum Red Hat Network-Tools-Channel ist, für sein Basisbetriebssystem, durch das Klicken des Namens des Systems und durch das Gehen auf die System = > System Details Seite. Unter der Subscribed Channels Sektion, überprüfen Sie die aufgelisteten Channels für die Tool-Channels. Falls in diesen Channel nicht subskribiert, klicken Sie bitte denalter Channel Subscriptions Link, überprüfen Sie die Box neben den Tool-Channel und klicken Sie den Change Subscriptions Schalter um ihre Auswahl zu bestätigen. 4. Installieren Sie die rhncfg-actions Pakete (welches ebenfalls die rhncfg und rhncfg-client Pakete installiert) beim ersten Navigieren auf das System = > System Details = > Software = > Pakete = > Installieren Subtab. Als nächstes suchen Sie nachrhncfg-actions durch die Verwendung von derfiltern nach Paketnamen Textsuchbox. In der Ergebnisliste, wählen Sie bitte dasrhncfg-actions Paket aus und installieren Sie es. 5. Falls Sie die Secure-Sockets-Layer (SSL) Kodierung auf den Proxy aktivieren wollen und die Verbindung zum zentralen RHN-Server, installieren Sie das rhns-certs-tools Paket vom selben Red Hat Network Tools-Channel und benutzen Sie die Tar-Datei später. Siehe auch das SSL-Zertifikat-Kapitel der RHN Client Configuration Guide für weitere Anweisungen. Wenn Sie SSL-Verschlüsselung auf dem Proxy aktivieren und mit einem RHN Satellite Server oder einem anderen RHN Proxy Server mit SSL verbinden, werden Sie auch das CA-Zertifikat-Passwort für das Parent-System benötigen. 6. Melden Sie sich beim System mittels Terminal als Root an und führen den Befehl rhn_check aus, um die geplante Paketinstallation umgehend einzuleiten. 7. Wenn die Pakete einmal installiert sind, wie Sie aus dem System-Details = >; Events-Reiter ersehen können, bereiten Sie das System darauf vor, Fernbefehle und Konfigurationsmanagement mit dem folgenden Befehl zu akzeptieren: /usr/bin/rhn-actions-control --enable-all 18

25 RHN Proxy Server-Installationsprozess 8. Innerhalb der RHN-Webseite gehen Sie auf den System Details # Details = > Proxy Subtab. Warnung Bitte beachten Sie, dass die RHN Proxy Server Installation vielleicht die squid.conf undhttpd.conf Konfigurationdateien in dem System ersetzen kann, um spätere Updates zu erleichtern. Falls Sie diese Dateien editiert haben und diese erhalten möchten, können diese nach der Installation wieder abgerufen werden, da sie nur verschoben wurden. Abbildung 4.1. System-Details = > Proxy 9. Der System Details = > Details = > Proxy Subtab, des Pulldown-Menüs sollte ihre Fähigkeit zur Aktivierung des Systems als ein RHN Proxy Server anzeigen. Versichern Sie sich, dass die korrekte Version ausgewählt wurde und klicken Sie Activate Proxy. Die Willkommens-Seite der Installation erscheint. 19

26 Kapitel 4. Installation Abbildung 4.2. Willkommen 10.Auf der Willkommens-Seite, finden Sie alle Einstellungen angezeigt, die Sie sonst nicht im System finden. Wenn das System bereit ist, erscheint ein Weiter-Link. Klicken Sie darauf, um auf die Allgemeine Geschäftsbedingungen-Seite zu gelangen. 20

27 RHN Proxy Server-Installationsprozess Abbildung 4.3. Allgemeine Geschäftsbedingungen 11.Auf der Seite Allgemeine Geschäftsbedingungen, klicken Sie auf den Link Allgemeine Geschäftsbedingungen, um die Lizenzbedingungen des RHN Proxy Server zu sehen. Wenn Sie damit einverstanden sind, klicken Sie bitte auf den Zustimmen-Link. Sie müssen zustimmen, um mit der Installation fortzufahren. Für Proxies die in einen Satelitte registriert sind, erscheint als nächstes die Seite Aktivierung des Monitoring. 21

28 Kapitel 4. Installation Abbildung 4.4. Monitoring aktivieren 12.Auf der Seite Aktivierung des Monitoring, müssen Sie sich entscheiden, ob der Proxy dazu benutzt werden soll, um das System zu beobachten. Um dies einzustellen, muss der RHN Proxy Server die Voraussetzungen, wie im Kapitel 2, Anforderungen beschrieben, erfüllen und muss mit den RHN Satellite Server verbunden sein (oder einen anderen Proxy der mit einen Satellite verbunden ist). Um das Monitoring auf einem Proxy zu aktivieren, wählen Sie die Checkbox aus und klicken Sie auf Weiter. Die RHN Proxy Server konfigurieren Seite erscheint. 22

29 RHN Proxy Server-Installationsprozess Abbildung 4.5. RHN Proxy Server konfigurieren 13.Auf der RHN Proxy Server konfigurieren-seite füllen Sie die erforderlichen Felder aus und bestätigen Ihre Eingabe. Die Administrator- -Adresse erhält sämtliche s, die vom Proxy generiert werden, wie manchmal auch u.a. große Mengen an Tracebacks, die mit Fehlern in Zusammenhang stehen. Um diesen Nachrichtenfluss einzudämmen, können Sie Mailfilter einrichten, welche Mitteilungen mit dem Betreff "RHN TRACEBACK from hostname" auffangen. Um mehr als einen Administrator aufzulisten, können Sie eine, durch Kommata getrennte, Liste von -Adressen eingeben. Der RHN-Proxy-Hostname ist der voll qualifizierte Domainname (FQDN) des RHN Proxy Server. Der RHN-Parent-Server ist der Domainname des Servers der Proxy bedient, entweder die Central-RHN-Server, einen anderen RHN Proxy Server oder einen RHN Satellite Server. Um sich mit den Central-RHN-Server zu verbinden, fügen Sie den xmlrpc.rhn.redhat.com Wert hinzu. Um sich mit einem Satellite oder einem anderen Proxy zu verbinden, geben Sie bitte den Parent-System FQDN ein. 23

30 Kapitel 4. Installation Falls der RHN Proxy Server durch einen HTTP-Proxy verbunden wird, konfigurieren Sie dies durch die Verwendung des dazugehörigen Feldes. Beachten Sie, dassprotokolle wie oder nicht im HTTP Proxy Server Feld sein dürfen. Fügen Sie nur den Hostname und den Port in das Format hostname:port ein, wie z.b. your-gateway.example.com:3128. Tip Der Installationsprozess betrifft nur die Proxykonfigurationsdatei: /etc/rhn/rhn.conf. Die Red Hat Update-Agent (up2date) Konfigurationsdatei, /etc/sysconfig/rhn/up2date, muss manuell geupdatet werden, um Updates von anderen Servern wie z.b RHN Satellite Server zu empfangen. Zum Schluss müssen Sie sich entscheiden, ob Sie SSL durch die Checkbox aktivieren wollen. Red Hat empfiehlt ausdrücklich diese Ebene der Kodierung für jeden Datenverkehr vom und zum RHN Proxy Server zu verwenden. Um dies auszuwählen müssen Sie sich jedoch mit den Central-RHN-Servers (welcher standardmäßig SSL aktiviert hat) oder zum RHN Satellite Server oder dem RHN Proxy Server verbinden, welche ebenfalls SSL aktiviert haben. Um eine Verbindung zum Central-RHN-Server herzustellen, müssen Sie sich das bereits erwähnte Tar-Datei-Zertifikat herunterladen. Eine Verbindung zum Sattelite oder einem anderen Proxy setzt ein von SSL verlangtes CA-Zertifikatspasswort voraus, welches bei der Aktivierung von SSL auf den Parent-System verwendet wurde. Anmerkung Siehe "SSL Infrastructure" im Red Hat Network Client-Konfigurationshandbuch für mehr Information über die Konfigurierung einer sicheren RHN Proxy Server-Infrastruktur mit SSL. Sie können sich auch dazu entscheiden SSL nicht während der Installation zu aktivieren. Lassen Sie dazu einfach die Box leer und nehmen Sie Bezug zum SSL-Zertifikats-Kapitel des RHN Client Konfigurationshandbuch um zu lernen wie man diese Ebene der Sicherheit installiert. Wenn dies abgeschlossen ist, klicken Sie auf Weiter. Wenn Sie SSL aktivieren und sich mit den Satellite verbinden, erscheint die Seite Konfiguriere SSL. Falls Sie SSL aktivieren und sich mit einem anderen Proxy oder den zentralen RHN-Server verbinden, erscheint die Upload SSL Seite. Falls Sie SSL nicht aktivieren, dafür aber Monitoring, verwenden Sie bitte die SeiteKonfiguriere Monitoring Seite. Falls Sie weder SSL noch Monitoring aktiviert haben, fahren Sie bitte mit der Seite Installationsprozess fort. 24

31 RHN Proxy Server-Installationsprozess Abbildung 4.6. SSL konfigurieren 14.Die SSL-Konfigurations-Seite, nur aufrufbar mit einer RHN Satellite Server-Proxy-Verbindung;mit aktiviertem SSL, stellt die Informationen bereit die dazu benötigt werden, um das Server-Zertifikat zu erstellen. Dabei ist das CA-Zertifikats-Passwort am wichtigsten, welches übereinstimmen mussmit dem Passwort das während der Aktivierung von SSL auf den Parent-Server verwendet wurde. Die übrigen Felder stimmen vielleicht mit den Werten des Parent-Servers überein, sie können sich aber durch die Rolle des RHN Proxy Servers unterscheiden, z.b. können Sie verschiedene geographische Speicherorte habe. Genauso kann die adresse mit der bereits existierenden des Proxyadministrators übereinstimmen, aber kann auch an den Zertifikatsadministrator geleitet werden. Der Zertifikatsablauf ist einstellbar. Stellen Sie wie immer sicher, dass der Wert der hier geliefert wird auch in den Backups der Informationen existiert, wie in Kapitel 2, Anforderungen beschrieben. Wenn dieser Vorgang beendet wurde, klicken Sie bitte Weitere. 25

32 Kapitel 4. Installation Abbildung 4.7. Monitoring konfigurieren 15.Auf der Monitoring konfigurieren-seite geben Sie den Hostnamen und die IP-Adresse des Parent-Servers an, mit dem Sie durch den RHN Proxy Server verbunden sind. Dies muss entweder ein RHN Satellite Server oder ein anderer Proxy sein, welcher wiederum mit einem Satellite verbunden ist. Monitoring kann nicht durch die zentralen RHN-Server erreicht werden. Wenn Sie damit fertig sind, klicken Sie auf Weiter. Es erscheint die Installationsfortschritt-Seite. Abbildung 4.8. Installationsfortschritt 16.Auf der Installationsfortschritt-Seite können Sie den Verlauf der Installation verfolgen. 26

33 RHN Proxy Server-Installationsprozess Klicken Sie auf den Link des Abschnittes um auf die Action-Details-Seite zu gelangen. Wenn eine Aktion ausgeführt wird, verändert sich der Status von Warteschlange aufaufgenommen und abschließen auf Beendet. Wie in den früheren Paketinstallationen können Sie dies auch durch den rhn_check Befehl im Terminal als Root auslösen. Wenn dieser Vorgang abgeschlossen ist, erscheint die Installationsfortschritt-Seite mit der Mitteilung Die Installation ist komplett. Sie können nun damit beginnen Systeme zu registrieren, die von RHN Proxy Server bedient werden. Siehe RHN-Client-Konfigurationshandbuch. 17.Wenn alles Punkte der Seite Installationsfortschrittbeendet sind, ist der Proxy betriebsbereit. Sie können nun Systeme im RHN über Proxy registrieren. 27

34 28

35 RHN Paketmanager Der RHN Paketmanager ist ein Befehlszeilentool, mit dessen Hilfe es einem Unternehmen möglich ist, lokale Pakete in Zusammenhang mit einem privaten RHN-Channel durch den RHN Proxy Server zu verteilen. Wenn Sie möchten, dass der RHN Proxy Server nur offizielle Red Hat-Pakete aktualisiert, installieren Sie den RHN Paketmanager nicht. Um den RHN Paketmanager zu verwenden, installieren Sie das rhns-proxy-package-manager-paket und alle davon abhängigen Pakete. Es wird nur die Header-Information für Pakete auf die RHN-Server hochgeladen. Die Header werden dazu benötigt, um RHN das Lö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 Paketmanager verwendet die selben Einstellungen wie der Proxy, welche in der /etc/rhn/rhn.conf-konfigurationsdatei festgelegt sind. 1. Einrichten eines privaten Channels Bevor lokale Pakete durch den RHN Proxy Server zur Verfügung gestellt werden können, benötigen Sie einen privaten Channel zur Aufbewahrung. Führen Sie folgende Schritte durch, um einen privaten Channel einzurichten: 1. Melden Sie sich über das RHN-Web-Interface unter an. 2. Klicken Sie auf Channels auf der oberen Navigationsleiste. Wenn die Channels verwalten-option nicht in der linken Navigationsleiste aufscheint, dann versichern Sie sich, dass dieser Benutzer die Berechtigungen zur Channel-Bearbeitung gesetzt hat. Dazu gehen Sie zur Benutzer-Kategorie, die durch die obere Navigationsleiste zugänglich ist. 3. In der linken Navigationsleiste klicken Sie Software Channels verwalten und dann den Neuen Channel einrichten-button ganz rechts oben auf der Seite. 4. Wählen Sie eine Parent-Channel- und Basis-Channel-Architektur aus und geben dann Name, Label, Summary und Beschreibung für den neuen privaten Channel ein. Das Label muss: mindestens sechs Zeichen lang sein, mit einem Buchstaben beginnen und darf nur zwei Kleinbuchstaben, Zahlen, Bindestriche (-) und Punkte besitzen. Geben Sie auch die URL des GPG-Schlüssels des Channels ein. Obwohl dies kein Mussfeld ist, wird es empfohlen, um die Sicherheit zu erhöhen. Siehe das RHN Channel-Managementhandbuch für Anleitungen zur Generierung von GPG-Schlüsseln. 5. Klicken Sie Channel einrichten. 2. Pakete werden geladen 29

36 Kapitel 5. RHN Paketmanager Anmerkung Sie müssen ein Organisationsadministrator sein, um Pakete zu privaten Channel heraufladen zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und nach Ihrem Passwort. Nach dem Einrichten des privaten Channels, können Sie die Paket-Header für Ihre Binär- und Quell-RPMs auf der RHN-Server heraufladen und die Pakete zum RHN Proxy Broker Server kopieren. Um die Paketheader für die Binär-RPMs heraufzuladen geben Sie folgendes in der Befehlszeile ein: rhn_package_manager -c "label_of_private_channel" pkg-list pkg-list ist die Liste der hinaufzuladenden Pakete. Wahlweise können Sie auch die -d-option verwenden, um das lokale Verzeichnis festzulegen, welches die Pakete enthält. Überprüfen Sie, ob das Verzeichnis wirklich nur die benötigten Pakete enthält und keine anderen Dateien. RHN Paketmanager kann die Liste von Paketen auch von Standardeingabe lesen (unter Verwendung von --stdin). Um die Paket-Header für die Quell-RPMs hinaufzuladen: rhn_package_manager -c "label_of_private_channel" --source pkg-list Wenn Sie mehr als einen Channel angegeben haben (unter Verwendung der -c oder --channel Option), werden die hinaufgeladenen Pakete zu allen gelisteten Channels gelinkt. Anmerkung Wenn ein Channelname nicht festgelegt ist, werden die Pakete zu keinem Channel hinzugefügt. Die Pakete können einem Channel unter Verwendung des Red Hat Network-Web-Interface hinzugefügt werden. Die Web-Oberfläche kann auch zur Mofizierung bestehender privater Channels verwendet werden. Nach dem Hinaufladen der Pakete können Sie umgehend das RHN-Web-Interface überprüfen, ob diese gelistet sind. Klicken Sie auf Channels in der oberen Navigationsleiste, auf Software Channels verwalten in der linken Navigationsleiste und dann auf den Namen des Custom-Channels. Klicken Sie dann auf den Pakete-Unterreiter. Jedes RPM-Paket sollte gelistet sein. Sie können auch über die Befehlszeile überprüfen, ob das lokale Verzeichnis mit dem Image der Channels des RHN Servers übereinstimmt: 30

37 Befehlszeilenoptionen rhn_package_manager -s -c "label_of_private_channel" Diese -s-option listet alle fehlenden Pakete (Pakete, die zum RHN-Server hinaufgeladen wurden und sich nicht im Verzeichnis befinden). Sie müssen ein Organisationsadministrator sein, um diesen Befehl verwenden zu können. Das Skript fragt Sie nach Ihrem RHN-Benutzernamen und -Passwort. Siehe Tabelle 5.1, Optionen für rhn_package_manager für zusätzliche Befehlszeilenoptionen. Wenn Sie den RHN Paketmanager dazu verwenden, lokale Pakete hinaufzuladen, müssen Sie dazu auf die RHN-Website gehen, um das System beim privaten Channel anzumelden. 3. Befehlszeilenoptionen Eine Zusammenfassung aller Befehlszeilenoptionen für for RHN Paketmanager rhn_package_manager: Option -v, --verbose -ddir, --dir=dir -cchannel, --channel=channel Beschreibung Verbosität erhöhen. Verarbeite die Pakete des Verzeichnisses DIR. Verwalte diesen Channel kann auch mehrmals vorhanden sein. -nnumber, --count=number Verarbeite diese Anzahl von Headern pro Aufruf Standard ist 32. -l, --list -s, --sync -p, --printconf -XPATTERN, --exclude=pattern --newest --stdin --nosig --username=username --password=password Liste jeden Paketnamen, jede Versionsummer, Releasenummer und Architektur in den festgelegten Channels/im Channel. Überprüfe ob lokales Verzeichnis mit dem Server abgestimmt ist. Drucke die aktuelle Konfiguration und beende. Schließe Dateien aus, die diesem globalen Ausdruck entsprechen kann auch mehrmals vorhanden sein. Pushe nur die Pakete, die neuer sind als die bereits für den festgelegten Channel zum Server gepushten Pakete. Lese die Paketnamen von Standardeingabe. Pushe nicht-signierte Pakete. Standardmäßig versucht der RHN Paketmanager nur signierte Pakete zu pushen. Geben Sie Ihren RHN-Benutzernamen ein. Wenn Sie diese Option nicht verwenden, dann werden Sie in einem Prompt nach Ihrem Benutzernamen gefragt. Geben Sie Ihr RHN-Passwort ein. Wenn Sie diese 31

38 Kapitel 5. RHN Paketmanager Option --source --dontcopy --test --no-ssl Beschreibung Version nicht verwenden, dann werden Sie dazu aufgefordert. Quell-Paketheader hinaufladen. Nach dem Hinaufladen werden die Pakete nicht automatisch in den Paketbaum kopiert. Drucke nur die zu pushenden Pakete. Nicht empfohlen SSL abschalten. -?, --usage Beschreibe kurz die Optionen. --copyonly -h, --help Kopiert die im Argument gelistete Datei in den festgelegten Channel. Nützlich wenn einem Channel auf dem Proxy ein Paket fehlt und Sie nicht alle Pakete nochmals importieren möchten. Beispielsweise: rhn_package_manager-cchannel--copyonly/path/to/missing/file Zeige den Hilfebildschirm mit einer Liste von Optionen an. Tabelle 5.1. Optionen für rhn_package_manager Tip Diese Befehlszeilenoptionen sind auch auf der rhn_package_manager man-seite gelistet: man rhn_package_manager. 32

39 Troubleshooting (Fehlersuche/-behebung) Dieses Kapitel enthält Tipps zur Fehlersuche und Behebung der am häufigsten auftretenden Fehler in Zusammenhang mit RHN Proxy Servern. Sollten Sie zusätzlich dazu Hilfe benötigen, dann kontaktieren Sie bitte den Red Hat Network-Support unter Loggen Sie sich mit Ihrem Proxy-berechtigten Account ein, um die vollständige Liste an Optionen zu erhalten. 1. Verwalten des Proxy-Services Da der RHN Proxy Server aus einer Vielzahl von individuellen Komponenten besteht, stellt Red Hat einen Master-Service zur Verfügung, rhn-proxy, der es Ihnen ermöglicht, die verschiedenen Dienste anzuhalten, zu starten und einen Status der unterschiedlichen Dienste in der entsprechenden Reihenfolge zu erhalten. Dieser Hilfsservice akzeptiert alle der typischen Systems-Befehle: service rhn-proxy startservice rhn-proxy stopservice rhn-proxy restartservice rhn-proxy status Verwenden Sie den rhn-proxy-service, um den gesamten RHN Proxy Server herunter- oder hochzufahren und Statusmitteilungen aller Dienste auf einmal abzufragen. 2. Log-Dateien Es sollte nahezu jeder Troubleshooting-Schritt damit beginnen, sich die damit in Verbindung stehende Log-Datei oder die zugehörigen Log-Dateien genauer anzusehen. Diese Dateien liefern außerordentlich wertvolle Informationen über die Abläufe auf den Geräten oder innerhalb der Applikation und können dazu verwendet werden, das allgemeine Leistungsverhalten zu überwachen und damit eine einwandfreie Konfiguration zu gewährleisten. Siehe Tabelle 6.1, Log-Dateien für die Pfade zu allen relevanten Log-Dateien: Komponente Apache-Webserver Squid RHN Proxy Broker Server RHN SSL Redirect Server Red Hat Update-Agent Log-Datei Speicherort /var/log/httpd/-verzeichnis /var/log/squid/-verzeichnis /var/log/rhn/rhn_proxy_broker.log /var/log/rhn/rhn_proxy_redirect.log /var/log/up2date Tabelle 6.1. Log-Dateien 33