Red Hat Network Satellite 5.5 Proxy

Transcription

Red Hat Network Satellite 5.5
Proxy-Installationshandbuch
Red Hat Network Satellite
Ausgabe 3
Red Hat Dokumentationsteam
Red Hat Network Satellite 5.5 Proxy-Installationshandbuch
Red Hat Network Satellite
Ausgabe 3
Red Hat Do kumentatio nsteam
Rechtlicher Hinweis
Copyright © 2010 Red Hat, Inc.
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus T orvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Z usammenfassung
Willkommen beim RHN Proxy-Installationshandbuch.
Inhaltsverzeichnis
Inhaltsverzeichnis
.Kapitel
. . . . . . . 1.
. . .Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .
1.1. Red Hat Netzwerk
4
1.2. Häufig verwendete T erminologien
4
1.3. RHN Proxy Server
5
1.4. Proxy Funktionsweise
6
.Kapitel
. . . . . . . 2.
. . .Anforderungen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . .
2.1. Software-Anforderungen
8
2.2. Hardware-Anforderungen
9
2.3. Speicherplatzanforderungen
9
2.4. Weitere Anforderungen
9
.Kapitel
. . . . . . . 3.
. . .Beispieltopologien
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
............
3.1. Einzel-Proxy-T opologie
12
3.2. Mehrfach horizontal gestaffelte Proxy-T opologie
12
3.3. Mehrfach vertikal gestaffelte Proxy-T opologie
13
3.4. Proxys mit RHN Satellite Server
14
.Kapitel
. . . . . . . 4. .. .Installation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
............
4.1. Basisinstallation
15
4.2. RHN Proxy Server Installationsvorgang
15
4.2.1. Die Antwortdatei
19
.Kapitel
. . . . . . . 5.
. . .RHN
. . . . .Package
. . . . . . . . .Manager
. . . . . . . . . .und
. . . .die
. . . .Lieferung
. . . . . . . . . . Lokaler
. . . . . . . . Pakete
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
............
5.1. Erstellen eines Privaten Kanals
22
5.2. Hochladen von Paketen
22
.Kapitel
. . . . . . . 6.
. . .Upgrade
. . . . . . . . .Installation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
............
6.1. Voraussetzungen
24
6.2. Upgrade Installationsvorgang
24
.Kapitel
. . . . . . . 7.
. . .Suche
. . . . . . .und
. . . . Bereinigung
. . . . . . . . . . . . . von
. . . . .Fehlern
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
............
7.1. Verwalten des Proxy-Dienstes
26
7.2. Protokolldateien
26
7.3. Fragen und Antworten
26
7.4. Allgemeine Probleme
27
7.5. Host nicht gefunden/FQDN konnte nicht ermittelt werden
28
7.6. Verbindungsfehler
29
7.7. Caching-Probleme
29
7.8. Suche und Bereinigung von Proxy-Fehlern durch Red Hat
30
. . . . . . . . . für
Beispiel
. . . .eine
. . . . .RHN
. . . . .Proxy
. . . . . .Server
. . . . . . . Konfigurations-Datei
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
...........
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Versionsgeschichte
...........
.Stichwortverzeichnis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
............
A
34
C
34
E
34
F
34
H
34
I
35
K
35
O
35
1
P
R
S
T
V
W
2
35
35
36
36
36
36
Inhaltsverzeichnis
3
Kapitel 1. Einführung
1.1. Red Hat Netzwerk
Das Red Hat Network (RHN) ist die Umgebung für den Support auf Systemebene, die Verwaltung von
Red Hat Systemen und Netzwerken von Systemen. Red Hat Network vereint die notwendigen
Werkzeuge, Dienste und Informationsquellen, um die Z uverlässigkeit, Sicherheit und Leistung der
Systeme zu maximieren. Um RHN verwenden zu können, registrieren Administratoren die Software- und
Hardware-Profile ihrer Clients (auch Systemprofile genannt) beim Red Hat Network. Wenn ein ClientSystem 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. ErrataUpdates, Paketinstallationen und Software-Profil-Updates.
Vereinfachung — Das Instandhalten von Red Hat-Systemen wird zu einem einfachen,
automatisierten Prozess.
1.2. 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 SubChannel ist ein Kanal in Verbindung mit einem Basis-Channel, enthält jedoch zusätzliche
Pakete.
Organisations-Verwalter (Organization Administrator)
Ein Organisationsadministrator ist eine Benutzerrolle mit dem höchsten Grad an Kontrolle über
einen Red Hat Network Account einer Organisation. Die Mitglieder dieser Rolle können andere
Benutzer, Systeme und Systemgruppen zur Organisation hinzufügen und auch entfernen. Eine
Red Hat Network Organisation muss mindestens einen Organisations-Verwalter besitzen.
Kanal-Verwalter (Channel-Administrator)
Ein Kanal-Verwalter ist eine Benutzerrolle mit vollem Z ugang zu den ChannelManagementfähigkeiten. Benutzer in dieser Rolle können Channels erstellen, Pakete
4
bestimmten, Channels zuordnen, Channels klonen und Channels löschen. Diese Rolle kann
von einem Organisations-Verwalter über den Benutzer T ab auf der RHN-Website vergeben
werden.
Red Hat Update Agent
Der Red Hat Update Agent ist die Red Hat Network Client-Applikation (up2date oder yum ), mit
der Benutzer neue oder aktualisierte Pakete für das Client-System, auf dem die Applikation
abläuft, abrufen und installieren können.
T raceback
Ein 'T raceback' ist eine detaillierte Beschreibung dessen, "was schiefgelaufen ist", die sich
bestens zur Suche und Bereinigung von Fehlern im RHN Proxy Server eignet. T racebacks
werden automatisch generiert, wenn ein kritischer Fehler auftritt und werden dann an die in der
Konfigurations-Datei des RHN Proxy Servers dafür vorgesehenen Personen als E-Mail
versendet.
Mehr detaillierte Beispiele zu diesen T hema und anderen finden Sie im Red Hat Network
Referenzhandbuch, verfügbar unter http://www.redhat.com/docs/manuals/satellite/, sowie auf der Hilfe
Seite der Satellite Web-Benutzerschnittstelle.
1.3. RHN Proxy Server
Ein RHN Proxy Server ist ein Paket-Caching-Mechanismus, der die für RHN erforderliche Bandbreite
reduziert und den Einsatz von kundenspezifischen Paketen unterstützt. Proxy-Kunden speichern RPMs,
wie z.B. Errata-Updates von Red Hat oder kundenspezifischen RPMs von anderen Organisationen, auf
einem internen, zentralen Server zwischen. Client-Systeme empfangen somit ihre Updates vom Proxy,
und nicht durch individuellen Z ugriff auf das Internet.
Auch wenn die Pakete durch den Proxy bereitgestellt werden, sind die Systemprofile der Clients und die
Benutzerinformationen sicher und zentral im RHN-Server gespeichert [1] , der auch die RHN-Webseite
bedient (rhn.redhat.com). Der Proxy dient als Z wischenstation zwischen Client-Systemen und Red Hat
Network (oder einem RHN Satellite Server). Nur die Paketdateien sind auf dem RHN Proxy Server
gespeichert. Jede T ransaktion wird authentifiziert, und der Red Hat Update Agent überprüft die GPGSignatur aller Pakete vom lokalen RHN Proxy Server.
Z usätzlich zum Speichern von offiziellen Red Hat Paketen kann der RHN Proxy Server auch darauf
konfiguriert werden, eigene kundenspezifische Pakete von privaten RHN Channels mithilfe des RHN
Package Managers bereitzustellen. Z um Beispiel kann eine Organisation ihre eigene Software
entwickeln, als RPM paketieren, es mit einer eigenen GPG-Signatur versehen und mithilfe des lokalen
RHN Proxy Server alle einzelnen Systeme im Netzwerk mit der neuesten Version der
kundenspezifischen Software aktualisieren.
Vorteile bei der Verwendung von RHN Proxy Server:
Skalierbarkeit — Es kann mehrere lokale RHN Proxy Server innerhalb eines Unternehmens geben.
Sicherheit — Es wird für eine durchgehend sichere Verbindung gesorgt: Von den Client-Systemen
zum lokalen RHN Proxy Server und zu den Red Hat Network Servern.
Z eitersparnis — Pakete werden wesentlich schneller über ein lokales Netzwerk geliefert, als über
das Internet.
Bandbreitenersparnis — Pakete werden nur einmal vom RHN heruntergeladen (über den lokalen
5
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 ClientSysteme 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.
1.4. Proxy Funktionsweise
Der Red Hat Update Agent oder Paket-Updater auf den Client-Systemen kontaktiert den Red Hat
Network Server nicht direkt. Stattdessen verbinden sich die Clients mit einem RHN Proxy Server, der
sich wiederum mit den Red Hat Network Servern oder einem RHN Satellite Server verbindet. Demnach
benötigen die Client-Systeme keinen direkten Z ugang zum Internet. Diese benötigen nur Z ugang zum
RHN Proxy Server.
Wichtig
Es wird von Red Hat dringend empfohlen, dass Clients, die mit einem RHN Proxy Server
verbunden sind, die neueste Version von Red Hat Enterprise Linux besitzen, um eine
einwandfreie Verbindungsfähigkeit zu gewährleisten.
Clients, die direkt auf RHN zugreifen, werden standardmäßig von den RHN-Servern authentifiziert.
Clients, die auf einen RHN Proxy Server zugreifen, werden auch von RHN authentifiziert, allerdings stellt
der Proxy dem RHN in diesem Fall sowohl Authentifizierungs- als auch Routing-Informationen zur
Verfügung. Nach einer erfolgreichen Authentifizierung informiert der Red Hat Network den RHN Proxy
Server darüber, dass es dem RHN Proxy Server gestattet wurde, eine bestimmte Aktion für einen Client
auszuführen. Der RHN Proxy Server lädt anschließend alle aktualisierten Pakete herunter (wenn sich
diese noch nicht in seinem Cache befinden) und liefert diese an die Client-Systeme.
Anfragen des Red Hat Update Agents oder Paket-Updaters auf den Client-Systemen werden noch
immer serverseitig authentifiziert, wobei jedoch die Paketlieferung wesentlich schneller ist, da die Pakete
im HT T P Proxy Caching Server oder dem RHN Proxy Server (für lokale Pakete) zwischengespeichert
werden; der RHN Proxy Server und das Client-System sind über das LAN verbunden und werden nur
durch die Geschwindigkeit des lokalen Netzwerks eingeschränkt.
Authentifizierung erfolgt in der folgenden Reihenfolge:
1. Der Client meldet sich zu Beginn einer Client-Sitzung an. Diese Anmeldung durchläuft einen oder
mehrere RHN Proxy Server, bis sie einen Red Hat Network erreicht.
2. Der Red Hat Network versucht, den Client zu authentifizieren. Bei erfolgreicher Authentifizierung
sendet der Server einen Session-T oken über die Kette von RHN Proxy Servern zurück. Dieser
T oken hat eine Signatur und ein Verfallsdatum und beinhaltet Benutzerinformationen, wie u.a.
subskribierte Channels, Benutzername, usw.
3. Jeder RHN Proxy Server speichert diesen T oken auf seinem lokalen Dateisystem in
6
/var/cache/rhn/ zwischen. Caching reduziert den Overhead in Z usammenhang mit der
Authentifizierung mit Red Hat Network und verbessert somit drastisch das Leistungsvermögen
des Red Hat Networks.
4. Dieser Session-T oken wird an den Client-Rechner zurückgesendet und wird bei späteren
Vorgängen im Red Hat Network verwendet.
Es gibt aus Sicht des Clients keinen Unterschied zwischen einem RHN Proxy Server und einem Red Hat
Network Server. Aus Sicht des Red Hat Network Servers ist ein RHN Proxy Server eine spezielle Art von
RHN-Client. Folglich hat es auf Clients keinerlei Auswirkungen, welche Route eine Anfrage nimmt, um
einen Red Hat Network Server zu erreichen. Die gesamte Logik ist in den RHN Proxy Servern und den
Red Hat Network Servern implementiert.
Optional kann der RHN Package Manager installiert und zum Bereitstellen kundenspezifischer SoftwarePakete konfiguriert werden. Jegliche Pakete, bei denen es sich nicht um offizielle Red Hat Pakete
handelt, einschließlich speziell für ein Unternehmen geschriebene Pakete, können nur von einem
privaten Software-Channel (auch kundenspezifischer Software-Channel genannt) bereitgestellt werden.
Nachdem ein privater RHN-Channel erstellt wurde, werden die kundenspezifischen RPM-Pakete mit dem
privaten Channel verknüpft, indem die Paket-Header auf die RHN-Server hochgeladen werden. Es
werden nur die Header hochgeladen, nicht die eigentlichen Paketdateien. Die Header sind erforderlich,
da diese äußerst wichtige RPM-Informationen enthalten, wie beispielsweise Software-Abhängigkeiten,
die es RHN ermöglichen, die Paketinstallation zu automatisieren. Die eigentlichen, kundenspezifischen
RPM-Pakete werden auf dem RHN Proxy Server aufbewahrt und an die Client-Systeme intern über das
lokale Netzwerk des Unternehmens versendet.
Die Konfiguration eines Computernetzwerks zur Verwendung von RHN Proxy Servern ist ein recht
unkomplizierter Prozess. Die Red Hat Network Applikationen auf den Client-Systemen müssen so
konfiguriert werden, dass diese mit dem RHN Proxy Server anstelle der Red Hat Network Server
verbinden. Siehe RHN Client-Konfigurationshandbuch für nähere Details. Proxyseitig muss der nächste
Proxy in der Kette festgelegt werden (die letztendlich mit einem Red Hat Network Server endet). Wenn
der RHN Package Manager verwendet wird, müssen die Client-Systeme den privaten RHN-Channel
subskribieren.
[1] Im Laufe d ies es Do kuments kann s ic h " RHN" entwed er auf d ie RHN Ho s ted Seite (http ://rhn.red hat.c o m) o d er auf einen RHN
Satellite Server b ez iehen.
7
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.
2.1. Software-Anforderungen
Um eine Installation durchführen zu können, müssen die folgenden Software-Komponenten vorhanden
sein:
Basisbetriebssystem — RHN Proxy Server wird mit Red Hat Enterprise Linux 5 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 fest: @ Base
Für die Installation von Red Hat Enterprise Linux von CD oder ISO-Image wählen Sie folgende
Paketgruppe aus: Minim al
Eine verfügbare RHN Proxy Server Berechtigung innerhalb des RHN Satellite Server Kontos.
Eine verfügbare Bereitstellungs-Berechtigung innerhalb des RHN Satellite Server Kontos (welche
gebündelt mit der RHN Proxy Server Berechtigung kommen sollte).
Z ugriff auf den Red Hat Network T ools-Channel für die installierte Version von Red Hat Enterprise
Linux. Dieser Kanal beinhaltet das spacewalk-proxy-installer Paket, welches das für die
Installation eines RHN Proxy Servers benötigte configure-proxy.sh Installationsprogramm
8
enthält.
Alle auf dem Proxy installierten rhncfg* -Pakete (vom RHN-T ools-Channel).
Entweder das auf dem Proxy installierte rhns-certs-tools Paket (vom RHN-T ools-Channel) für
RHN Hosted Benutzer, oder das Secure Sockets Layer (SSL) CA-Z ertifikatpasswort, welches für
RHN Satellite Server-Benutzer zur Generierung des Parent-Server-Z ertifikats verwendet wird.
Eine Konfiguration auf dem System, die Befehle von Remote aus und Konfigurationsmanagement
durch das Red Hat Network akzeptiert, falls die veraltete Installationsmethode via Weboberfläche
angewendet wird. Siehe Abschnitt 4.2, „RHN Proxy Server Installationsvorgang“ für weitere
Anweisungen.
2.2. Hardware-Anforderungen
Die folgende Hardware-Konfiguration ist für den RHN Proxy Server erforderlich:
Ein Pentium IV Prozessor oder äquivalent
512 MB Arbeitsspeicher
Mindestens 5 GB Speicherplatz für die Basisinstallation von Red Hat Enterprise Linux
25+ GB Speicherplatz pro Distribution/Channel
Die Last auf dem Apache Web Server steht in direktem Z usammenhang mit der Häufigkeit, mit der ClientSysteme 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.
2.3. Speicherplatzanforderungen
Der vom RHN Proxy Server eingesetzte Caching-Mechanismus ist der Squid HT T P-Proxy, der in
signifikantem Maß Bandbreite für die Clients einspart. Dieser sollte eine angemessene Menge an
Speicherplatz zur Verfügung haben. Die zwischengepeicherten Pakete werden in /var/spool/squid
abgelegt. Die erforderliche Z uweisung an freiem Speicherplatz ist 6 GB Speicher pro
Distribution/Channel.
Wenn der RHN Proxy Server zur Distribution von kundenspezifischen Paketen (auch "Custom-Pakete"
genannt) oder lokalen Paketen konfiguriert ist, dann gehen Sie sicher, dass auf dem /var
Einhängepunkt auf dem System, welches die lokalen Pakete speichert, ausreichend Plattenspeicher
vorhanden ist, um sämtliche kundenspezifischen Pakete unterzubringen, die in /var/spool/rhnproxy gespeichert sind. Der erforderliche Plattenspeicher für lokale Pakete hängt von der Anzahl der
bereitgestellten kundenspezifischen Pakete ab.
2.4. Weitere Anforderungen
Die folgenden weiteren Anforderungen müssen erfüllt werden, bevor die RHN Proxy Server-Installation
als vollständig angesehen werden kann:
Voller Z ugang
Client-Systeme benötigen vollen Netzwerkzugang zu den RHN Proxy Server-Diensten und
Ports.
Firewall-Regeln
Es wird von RHN dringend empfohlen, den RHN Proxy Server durch einen Firewall vom Internet
9
zu schützen. Jedoch sollten verschiedene T CP-Ports offen bleiben, je nach der Implementation
des RHN Proxy Server:
T abelle 2.1. Ports, die im Proxy geöffnet werden sollten
Port
Richtung
Grund
80
Ausgehend
Proxy nutzt diesen Port um
rhn.redhat.com, xmlrpc.rhn.redhat.com
und Ihre Satellite URL zu erreichen (je
nachdem, ob RHN Proxy entweder mit
RHN Hosted oder einem Satellite Server
kommuniziert).
80
Eingehend
Client-Anfragen gehen über http oder
https ein
443
Eingehend
Client-Anfragen gehen über http oder
https ein
443
Ausgehend
Der Proxy nutzt diesen Port, um
rhn.redhat.com, xmlrpc.rhn.redhat.com
und die Satellite-URL zu erreichen
(abhängig davon, ob RHN Proxy mit
RHN Hosted oder einem Satellite Server
kommuniziert).
4545
Ausgehend
Falls Ihr Proxy mit einen RHN Satellite
Server verbunden ist, verbindet sich
das Monitoring über diese T CP-Ports
mit Client-Systemen, auf denen rhnm d
läuft, sofern Monitoring aktiviert ist und
nach registrierten Systemen sucht.
5222
Eingehend
Das Öffnen dieses Ports erlaubt dem
osad-Client, sich mit dem jabberd
Dämon auf der Proxy zu verbinden,
wenn die RHN-Push-T echnologie
verwendet wird.
5269
Ausgehend
Falls Ihr Proxy mit einem RHN Satellite
Server verbindet, muss dieser Port
geöffnet sein, um zwischen den Servern
Verbindungen über jabberd für die
RHN-Push-T echnologie zu erlauben.
Synchronisierte Systemzeiten
Die korrekte Z eit spielt eine bedeutende Rolle, wenn mit einem SSL- (Secure Sockets Layer)
fähigen Webserver verbunden wird; es ist von entscheidender Bedeutung, dass die
Z eiteinstellungen auf den Clients und dem Server sehr nahe beieinander liegen, sodass das
SSL-Z ertifikat nicht vor oder während der Verwendung abläuft. Das Network T ime Protokoll
(NT P) wird zur Synchronisation der Systemzeiten empfohlen.
Voll qualifizierter Domain-Name (FQDN)
Das System, auf dem der RHN Proxy Server installiert wird, muss in der Lage sein, den eigenen
FQDN richtig aufzulösen.
10
Red Hat Netzwerk Konto
Kunden, die sich mit den zentralen Red Hat Network Servern verbinden, um inkrementelle
Updates zu erhalten, benötigen ein Red Hat Network Konto. Dieses Konto sollte zum
Kaufzeitpunkt gemeinsam mit dem Vertriebsmitarbeiter eingerichtet werden.
Backups von Login-Informationen
Es ist zwingend notwendig, dass Kunden über alle primären Login-Informationen die Übersicht
behalten. Im Falle eines RHN Proxy Servers sind dies u.a. Benutzernamen und Passwörter für
das Organisationsadministrator Konto und die SSL-Z ertifikat-Generierung. Red Hat empfiehlt
dringend, dass diese Informationen auf zwei separate Datenträger kopiert wird, ausgedruckt
wird, und der Ausdruck in einem sicheren Platz (T resor) aufbewahrt wird.
Distributionsspeicherorte
Da der Proxy nahezu alle lokalen HT T P-Anfragen an die zentralen RHN Server weiterleitet,
müssen Sie darauf achtgeben, dass Sie alle Dateien, die für die Distribution vorgesehen sind
(wie beispielsweise in einem Kickstart-Installationsbaum) in einem Ort auf dem Proxy ablegen,
wo nicht weitergeleitet wird: /var/www/htm l/pub/. Dateien, die in diesem Verzeichnis
abgelegt werden, können direkt vom Proxy heruntergeladen werden. Dies kann für das
Verteilen von GPG-Schlüsseln oder dem Erstellen von Installationsbäumen für Kickstarts
besonders hilfreich sein.
Z usätzlich dazu empfiehlt Red Hat, dass das System, auf dem der Code ausgeführt wird, nicht öffentlich
zugänglich ist. Es sollten nur Systemadministratoren Shell-Z ugang zu diesen Rechnern besitzen, aber
keine anderen Benutzer. Alle nicht notwendigen Dienste sollten deaktiviert werden. Sie können ntsysv
oder chkconfig zur Deaktivierung von Diensten verwenden.
Schlussendlich sollten Sie folgende technische Dokumente für den Einsatz griffbereit haben, ungefähr in
dieser Reihenfolge:
1. Das RHN Proxy Server-Installationshandbuch — Dieses Handbuch, welches Sie gerade lesen,
behandelt die wesentlichen Schritte, um ein RHN Proxy Server einsatzbereit zu machen.
2. Das RHN Client Konfigurations-Handbuch — Dieses Handbuch erklärt, wie Systeme konfiguriert
werden müssen, um von einem RHN Proxy Server oder RHN Satellite Server bedient zu werden.
(Wahrscheinlich erfordert dies auch die Z uhilfenahme des RHN Referenz-Handbuchs, welches
Schritte zur Registrierung und Aktualisierung von Systemen enthält.)
3. Das RHN Channel Management-Handbuch — Dieses Handbuch behandelt detailgenau die
empfohlenen Methoden für die Erstellung von kundenspezifischen Paketen und Channels sowie
auch zur Verwaltung privater Errata.
4. Das RHN Referenz-Handbuch — Dieses Handbuch beschreibt das Einrichten von RHN-Konten,
die Registrierung und Aktualisierung von Systemen sowie Hinweise dazu, wie Sie das Potenzial
der RHN-Website am besten ausschöpfen können. Dieses Handbuch kommt sicherlich während
des gesamten Installations- und Konfigurationsprozesses hindurch gelegen.
11
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.
3.1. Einzel-Proxy-Topologie
Die einfachste Konfiguration ist die Verwendung eines einzelnen RHN Proxy Servers, der Ihr gesamtes
Netzwerk versorgt. Diese Konfiguration ist für eine kleine Gruppe von Clients ausgelegt und für ein
Netzwerk geeignet, das vom Caching von Red Hat RPMs und dem Speichern von benutzerdefinierten
Paketen profitieren kann.
Der Nachteil bei der Verwendung eines einzelnen RHN Proxy Servers ist die Beeinträchtigung der
Systemleistung, wenn die Anzahl der Clients ansteigt, die Pakete abrufen.
Abbildung 3.1. Einzel-Proxy-T opologie
3.2. Mehrfach horizontal gestaffelte Proxy-Topologie
Für größere Netzwerke könnte eine weiter verteilte Methode erforderlich sein, wie beispielsweise
mehrere RHN Proxy Server, die mit Red Hat Network individuell verbunden sind. Durch diese horizontal
gestaffelte Konfiguration kann die Last der Client-Anfragen besser verteilt werden und gleichzeitig ist
jeder Proxy in der Lage, simultan mit RHN zu synchronisieren.
Ein Nachteil dieser horizontalen Struktur besteht darin, dass benutzerdefinierte Pakete, die auf einen
12
Kapitel 3. Beispieltopologien
einzelnen Proxy hochgeladen wurden, anschließend ebenfalls an die Geschwister-Server verteilt
werden müssen. Dieser Situation kann auf zwei Arten begegnet werden:
Das Dateiübertragungsprogramm rsync wird verwendet um Pakete zwischen den Proxys zu
synchronisieren
Ein Network File System (NFS) Share kann zwischen den Proxys und dem als Repository dienenden
benutzerdefinierten Channel eingerichtet werden.
Beide Lösungen ermöglichen es jedem Client von jedem RHN Proxy Server, alle benutzerdefinierten
Pakete geliefert zu bekommen.
Abbildung 3.2. Mehrfach horizontal gestaffelte Proxy-T opologie
3.3. Mehrfach vertikal gestaffelte Proxy-Topologie
Ein alternatives Verfahren für den Einsatz von mehreren RHN Proxy Servern ist das Einrichten eines
primären Proxys, mit dem die anderen verbinden, um RPMs vom Red Hat Network zu erhalten sowie
auch benutzerdefinierte Pakete, die lokal erstellt wurden. Im Wesentlichen verhalten sich die sekundären
Proxys wie Clients des primären Proxys. Dadurch ist die Notwendigkeit nicht mehr so hoch, dass eine
Synchronisation zwischen den RHN Proxy Servern stattfindet, da diese die im Produkt enthaltene
up2date Funktionalität verwenden.
Wie bei der horizontal gestaffelten Konfiguration ermöglicht diese vertikale Methode jedem Client eines
jeden RHN Proxy Servers, alle benutzerdefinierten Pakete geliefert zu bekommen. Der Proxy sieht
lediglich im eigenen Repository nach, ob sich das Paket im Dateisystem befindet. Wenn nicht, versucht
der Proxy es eine Stufe höher.
Diese vertikal gestaffelte Konfiguration gewährleistet, dass die sekundären Proxys für Updates von RHN
sowie auch für benutzerdefinierte Pakete auf die primären Proxys angewiesen sind. Auch dürfen
benutzerdefinierte Channels und Pakete nur auf dem primären Proxy abgelegt werden, um eine
Verteilung zu den untergeordneten Proxys sicherzustellen. Schlussendlich müssen die KonfigurationsDateien des sekundären Proxys auf den primären Proxy Server verweisen, anstatt direkt auf Red Hat
Network.
13
Abbildung 3.3. Mehrfach vertikal gestaffelte Proxy-T opologie
3.4. Proxys mit RHN Satellite Server
Eine alternative Lösung zu den in diesem Kapitel detailliert beschriebenen Methoden ist die Verwendung
von RHN Proxy Servern in Verbindung mit einem RHN Satellite Server. Diese Architektur funktioniert
ähnlich wie die vertikal gestaffelte Proxy-Konfiguration. Dabei wird jedoch die Kapazität auf signifikante
Weise angehoben, da Satellites einer wesentlich größeren Anzahl von Client-Systemen als Server
dienen können.
Für eine ausführliche Beschreibung dieser Kombination verweisen wir auf das Kapitel mit den BeispielT opologien im RHN Satellite Server Installationshandbuch. Das Verknüpfen der SSL Z ertifikate der
beiden Produkte wird ausführlich im RHN Client-Konfigurationshandbuch beschrieben. Um
herauszufinden, auf welche Art Channels und Pakete von diesen beiden Produkten gemeinsam
verwendet werden, werfen Sie einen Blick in das RHN Channel-Managementhandbuch.
14
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.
4.1. Basisinstallation
Der RHN Proxy Server ist für das Red Hat Enterprise Linux Betriebssystem ausgelegt. Deshalb ist die
erste Phase die Installation des Basisbetriebssystems von CD/DVD, mittels ISO-Image oder Kickstart.
Während und nach der Installation des Betriebssystems sollten Sie folgende Punkte beachten:
Weisen Sie derjenigen Partition, auf der die Pakete gespeichert werden, genügend Platz zu, gemäß
der zuvor erwähnten Hardware-Anforderungen. Im Cache zwischengespeicherte Red Hat-Pakete
befinden sich standardmäßig in /var/spool/squid, während sich kundenspezifische Pakete in
/var/spool/rhn-proxy befinden.
Anmerkung
Das Installationsprogramm berechnet automatisch den verfügbaren Platz auf der Partition, in
der /var/spool/squid bereitgestellt ist, und weist bis zu 60 Prozent des freien Speichers
dem RHN Proxy Server zur Verwendung zu.
Installieren Sie die Pakete, die für den RHN Proxy Server erforderlich sind.
Wichtig
Sie dürfen nur die Basispakete installieren, alle anderen würden dazu führen, dass die RHN
Proxy Server Installation fehlschlägt.
Werfen Sie einen Blick auf Abschnitt 2.1, „Software-Anforderungen“ um zu erfahren, welche Methode
die richtigen Paketgruppen für jede Version von Red Hat Enterprise Linux abruft.
Aktivieren Sie das Network T ime Protocol (NT P) auf dem Proxy und wählen die entsprechende
Z eitzone aus. Auf allen Client-Systemen sollte bereits der ntpd-Daemon laufen und auf die korrekte
Z eitzone eingestellt sein.
Deaktivieren Sie die ipchains und iptables-Dienste nach der Installation.
4.2. RHN Proxy Server Installationsvorgang
Die folgenden Anleitungen beschreiben den RHN Proxy Server Installationsvorgang:
1. Melden Sie sich als Root-Benutzer auf dem beabsichtigten RHN Proxy Server System an.
2. Registrieren Sie das neu installierte Red Hat Enterprise Linux System beim Red Hat Network
(entweder dem zentralen RHN Server oder Ihrem RHN Satellite Server) unter Verwendung des
Organisations-Accounts, der die RHN Proxy Server Berechtigung beinhaltet, mit dem Befehl:
rhn_register.
3. Subskribieren Sie den Client auf den RHN T ools-Kanal.
4. Installieren Sie den Proxy Installer:
15
yum install spacewalk-proxy-installer
5. Installation durchführen:
configure-proxy.sh
Anmerkung
Um diesen Schritt erfolgreich durchzuführen ist Root-Z ugriff auf den Satellite Server
erforderlich. Alternativ können Sie die --force-own-ca Option zum Befehl hinzufügen.
Das Befehlszeilen-Installationsprogramm führt Benutzer durch eine Reihe von
Eingabeaufforderungen ("Prompts") bezüglich der RHN Proxy Server Installation und Details zur
Anfangskonfiguration, wie z.B. Installationsoptionen und Generierung der SSL-Z ertifikate. Die
folgenden Anleitungen beschreiben den Installationsvorgang:
Tipp
Wenn Sie bei einem Prompt die Enter T aste drücken, anstatt eine Eingabe zu tippen, so
verwendet das Befehlszeilen-Installationsprogramm die in Klammern angezeigte
Standardantwort.
Falls Sie alternativ ohne jegliche Benutzereingabe die Standardantworten übernehmen
möchten, verwenden Sie die --non-interactive Option, wodurch sämtliche
Standardantworten verwendet werden.
6. Bei der ersten Reihe von Eingabeaufforderungen werden Details abgefragt, spezifisch für den
Rechner, auf dem Sie installieren.
Proxy version to activate [5.4]:
Die Proxy version fordert Sie dazu auf, die Version des RHN Proxy Servers anzugeben, die
Sie installieren möchten.
RHN Parent [satserver.example.com]:
RHN Parent ist der Domain-Name oder die Adresse des Systems, das dem Proxy dient, dies
können RHN Hosted Server (xmlrpc.rhn.redhat.com) oder ein Satellite Server sein.
Traceback email []:
T raceback em ail ist die E-Mail-Adresse, an die T raceback-Nachrichten bezüglich Fehler
gesendet werden, in der Regel ist dies die E-Mail-Adresse des Proxy-Administrators. Benutzen
Sie Kommas, um mehrere E-Mail-Adressen in diesem Prompt voneinander zu trennen.
7. Die nächste Reihe von Eingabeaufforderungen beziehen sich auf die Detailkonfiguration zum
Generieren eines SSL-Z ertifikats, was empfohlen wird, um den Datenverkehr zum und vom RHN
Proxy Server zu sichern.
Use SSL [Y/n]: y
Geben Sie beim Use SSL Prompt y ein, um den RHN Proxy Server für die Unterstützung von SSL
16
zu konfigurieren.
CA Chain [/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT]:
Drücken Sie im CA Chain Prompt die Eingabe T aste, um den Standardpfad für die Certificate
Authority (CA) Chain zu verwenden. Dieser Wert lautet normalerweise /usr/share/rhn/RHNORG-T RUST ED-SSL-CERT , falls der RHN Proxy mit einem RHN Satellite kommuniziert. Falls er
dagegen mit RHN Hosted kommuniziert, ist es in der Regel die /usr/share/rhn/RHNS-CACERT Datei. Benutzerdefinierte SSL-Z ertifikate müssen im /usr/share/rhn/ Verzeichnis
abgelegt werden.
HTTP Proxy []:
Falls der RHN Proxy Server über einen HT T P-Proxy verbindet, geben Sie den Proxy-Hostnamen
und die Portnummer ein, wie z.B. corporate.proxy.exam ple.com :3128.
Geben Sie die erforderlichen Details ein, um ein ordnungsgemäßes SSL-Server-Z ertifikat zu
generieren, einschließlich dem Namen der Organization, der Organization Unit
(Organisationseinheit, wie z.B. Engineering), Com m on Nam e (der Domain-Name), sowie
Angaben zu Ort, Bundesland und Land. Z um Schluss geben Sie noch die E-Mail-Adresse des
Administrators oder des technischen Kontakts ein, der für SSL-Z ertifikate zuständig ist.
Regardless of whether you enabled SSL for the connection to the Proxy Parent
Server, you will be prompted to generate an SSL certificate.
This SSL certificate will allow client systems to connect to this Spacewalk
Proxy
securely. Refer to the Spacewalk Proxy Installation Guide for more
information.
Organization: Example Company
Organization Unit [proxy1.example.com]:
Common Name: proxy1.example.com
City: New York
State: New York
Country code: US
Email [[email protected]]:
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 ServerInstallationen zu erstellen und zu füllen.
Die SSl Konfiguration abschließen.
Alle Service-Dämonen, deren Konfigurationen geändert wurde, neu starten.
You do not have monitoring installed. Do you want to install it?
Will run 'yum install spacewalk-proxy-monitoring'. [Y/n]:n
Bestätigen Sie, ob Sie Monitoring-Unterstützung auf dem Proxy Server installieren möchten oder
nicht.
17
Generating CA key and public certificate:
CA password:
CA password confirmation:
Copying CA public certificate to /var/www/html/pub for distribution to
clients:
Generating SSL key and public certificate:
CA password:
Backup made: 'rhn-ca-openssl.cnf' --> 'rhn-ca-openssl.cnf.1'
Rotated: rhn-ca-openssl.cnf --> rhn-ca-openssl.cnf.1
Installing SSL certificate for Apache and Jabberd:
Preparing packages for installation...
rhn-org-httpd-ssl-key-pair-proxy1.example-1.0-1
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 SSLSchlüssel und das öffentliche Z ertifikat erstellt werden.
Create and populate configuration channel rhn_proxy_config_1000010000? [Y]:
Using server name satserver.example.com
Red Hat Network username: admin
Password:
Creating config channel rhn_proxy_config_1000010000
Config channel rhn_proxy_config_1000010000 created
using server name satserver.example.com
Pushing to channel rhn_proxy_config_1000010000:
Local file /etc/httpd/conf.d/ssl.conf -> remote file
/etc/httpd/conf.d/ssl.conf
Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf
Local file /etc/rhn/cluster.ini -> remote file /etc/rhn/cluster.ini
Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf
Local file /etc/httpd/conf.d/cobbler-proxy.conf -> remote file
/etc/httpd/conf.d/cobbler-proxy.conf
Local file /etc/httpd/conf.d/rhn_proxy.conf -> remote file
/etc/httpd/conf.d/rhn_proxy.conf
Local file /etc/httpd/conf.d/rhn_broker.conf -> remote file
/etc/httpd/conf.d/rhn_broker.conf
Local file /etc/httpd/conf.d/rhn_redirect.conf -> remote file
/etc/httpd/conf.d/rhn_redirect.conf
Local file /etc/jabberd/c2s.xml -> remote file /etc/jabberd/c2s.xml
Local file /etc/jabberd/sm.xml -> remote file /etc/jabberd/sm.xml
Das Installationsprogramm fragt anschließend, ob Sie einen Konfigurations-Kanal basierend auf
den Konfigurations-Dateien erstellen möchten, die beim Ausführen von configure-proxy.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 1000010000), und sammelt die
verschiedenen httpd, SSL, squid, und jabberd Server-Dateien, aus denen der KonfigurationsKanal für den Proxy Server bestehen wird.
9. Z u guter Letzt startet (bzw. startet neu) das Installationsprogramm alle Dienste, die mit dem RHN
Proxy Server in Z usammenhang stehen; sobald dies abgeschlossen ist, beendet es sich selbst.
18
Enabling Satellite Proxy
Shutting down rhn-proxy...
Shutting down Jabber router:
Stopping httpd:
Stopping squid:
Done.
Starting rhn-proxy...
init_cache_dir /var/spool/squid... Starting squid: .
Starting httpd:
Starting Jabber services
Done.
[ OK ]
[ OK ]
[ OK ]
[
[
[
OK ]
OK ]
OK ]
4.2.1. 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 m an 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
[email protected]
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:
configure-proxy.sh --answer-file=answers.txt
19
Kapitel 5. RHN Package Manager und die Lieferung Lokaler
Pakete
Der RHN Package Manager ist ein Befehlszeilen-T ool, 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-packagem anager 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 Z usammenfassung aller Befehlszeilen-Optionen für den RHN Package
Manager rhn_package_m anager:
20
Kapitel 5. RHN Package Manager und die Lieferung Lokaler Pakete
T abelle 5.1. Optionen für rhn_package_m anager
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, ReleaseNummer und Architektur in den festgelegten Channels/im
Channel auf.
-s, --sync
Überprüft, ob lokales Verzeichnis mit dem Server
abgestimmt (synchron) ist.
-p, --printconf
Z eigt 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.
--nosig
Sende nicht-signierte Pakete. Standardmäßig versucht der
RHN Package Manager, nur signierte Pakete zu senden.
--usernam e=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
Z eigt 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_m anager-cCHANNEL-copyonly/PATH/TO/MISSING/FILE
-h, --help
Z eigt den Hilfebildschirm mit einer Liste von Optionen an.
Tipp
Diese Befehlszeilenoptionen sind auch auf der rhn_package_m anager Handbuchseite
aufgeführt: m an rhn_package_m anager.
21
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.
5.1. Erstellen eines Privaten Kanals
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 https://rhn.redhat.com an.
2. Klicken Sie auf Channels auf der oberen Navigationsleiste. Wenn die Channels verwalten
Option nicht in der linken Navigationsleiste erscheint, dann versichern Sie sich, dass dieser
Benutzer über die Berechtigungen zur 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, Z usammenfassung und Beschreibung für den neuen privaten Kanal ein. Das Label muss
mindestens sechs Z eichen lang sein, mit einem Buchstaben beginnen und darf nur
Kleinbuchstaben, Z ahlen, 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.
5.2. 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 PaketHeader 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
22
Kapitel 5. RHN Package Manager und die Lieferung Lokaler Pakete
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.
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 SoftwareChannels verwalten in der linken Navigationsleiste und dann auf den Namen des
benutzerdefinierten Kanals. Klicken Sie dann auf den Pakete Unter-T ab. 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
Kapitel 6. Upgrade Installation
Dieses Kapitel beschreibt, wie Sie Ihre Installation des RHN Proxy Server aktualisieren können. Es nimmt
an, dass Sie einen voll in Betrieb befindlichen RHN Proxy Server sowie die erforderlichen
Berechtigungen dafür haben.
6.1. Voraussetzungen
Für die neueste Version des RHN Proxy Servers bedarf es:
Red Hat Enterprise Linux 5 (32-bit oder 64-bit) oder Red Hat Enterprise Linux 6 (nur 64-bit).
Die Löschung des Systemprofils vom alten Proxy Server von Red Hat Network Classic oder des
übergeordneten Satellite Servers (falls zutreffend).
6.2. Upgrade Installationsvorgang
1. Sichern Sie Ihren Proxy Server. Falls zutreffend, stellen Sie SSL Aufbau-Anweisungen vom Backup
in das Verzeichnis /root/ssl-build wieder her.
2. Registrieren Sie den Proxy Server auf entweder Red Hat Network Classic oder dem
übergeordneten Satellite Server (falls zutreffend). Stellen Sie sicher, dass der Proxy-Server
sowohl für den Red Hat Enterprise Linux Server Basis-Channel und den Red Hat Network T ools
Sub-Channel subskribiert ist.
3. Installieren Sie das spacewalk-proxy-installer Paket vom Red Hat Network T ools SubChannel:
# yum install spacewalk-proxy-installer
4. Installieren Sie die neueste Version von Proxy, wie in Abschnitt 4.2, „RHN Proxy Server
Installationsvorgang“ dokumentiert.
Anmerkung
Wenn der Proxy-Server mit Red Hat Network Classic registriert ist und der Proxy Server
zuvor benutzerdefinierte Kanäle verwaltete, müssen Sie das benutzerdefinierte PaketRepository von der Sicherung vor dem Upgrade wiederherstellen. Die Berechtigungen und
Besitzer müssen auch ordnungsgemäß eingerichtet werden.
#
#
#
#
chmod
chown
mkdir
chown
0750 /var/spool/rhn-proxy
apache:apache /var/spool/rhn-proxy
-m 0750 -p /var/spool/rhn-proxy/list
apache:apache /var/spool/rhn-proxy/list
Das Standard benutzerdefinierte Paket-Repository ist in der Regel /var/spool/rhnproxy.
5. Nach der Installation aktualisieren Sie den Server auf die neuesten Berichtigungs-Updates:
# yum update
6. Neustart der RHN Proxy Server-Dienste und testen Sie die RHN Proxy Server-Funktionalität:
24
Kapitel 6. Upgrade Installation
# /usr/sbin/rhn-proxy restart
25
Kapitel 7. Suche und Bereinigung von Fehlern
Dieses Kapitel enthält T ipps zur Suche und Bereinigung der am häufigsten auftretenden Fehler in
Z usammenhang mit RHN Proxy Servern. Sollten Sie zusätzliche Hilfe benötigen, dann kontaktieren Sie
bitte den Red Hat Network Support unter https://rhn.redhat.com/help/contact.pxt. Melden Sie sich mit
Ihrem Proxy-berechtigten Account an, um die vollständige Liste an Optionen zu erhalten.
7.1. Verwalten des Proxy-Dienstes
Da der RHN Proxy Server aus einer Vielzahl individueller Komponenten besteht, stellt Red Hat ein Skript
namens rhn-proxy zur Verfügung, das es Administratoren ermöglicht, zu beenden, zu starten, neu zu
starten oder einen Status auf dem Proxy zu erhalten.
T abelle 7.1. rhn-proxy Befehle
Befehl
Funktion
/usr/sbin/rhn-proxy
start
Dieser Befehl startet den RHN Proxy Server, wenn er nicht bereits
gestartet ist.
/usr/sbin/rhn-proxy stop
Dieser Befehl stoppt den RHN Proxy Server, wenn er nicht bereits
angehalten ist.
/usr/sbin/rhn-proxy
restart
Dieser Befehl stoppt den laufenden RHN Proxy Server und starten
ihn neu. Wenn der RHN Proxy Server bereits gestoppt ist, wird er
gestartet.
/usr/sbin/rhn-proxy
status
Dieser Befehl zeigt den aktuellen Status des RHN Proxy Servers
an.
7.2. Protokolldateien
Nahezu jede Suche und Bereinigung von Fehlern sollte damit beginnen, sich die damit in Verbindung
stehende(n) Protokolldatei(en) genauer anzusehen. Diese Dateien liefern außerordentlich wertvolle
Informationen über die Abläufe auf den Einheiten oder innerhalb der Applikation und können dazu
verwendet werden, das allgemeine Leistungsverhalten zu überwachen und damit eine einwandfreie
Konfiguration zu gewährleisten. Siehe T abelle 7.2, „Protokolldateien“ für die Pfade zu allen relevanten
Protokolldateien:
T abelle 7.2. Protokolldateien
Komponente
Speicherort der Protokolldatei
Apache Web server
/var/log/httpd/-Verzeichnis
Squid
/var/log/squid/-Verzeichnis
RHN Proxy Broker Server
/var/log/rhn/rhn_proxy_broker.log
RHN SSL Redirect Server
/var/log/rhn/rhn_proxy_redirect.log
Red Hat Update Agent
/var/log/yum .log
7.3. Fragen und Antworten
Dieser Abschnitt beinhaltet die Antworten zu den am häufigsten gestellten Fragen hinsichtlich
Installation und Konfiguration einer RHN Proxy Server Lösung.
26
F:
Wie kann ich nach der Konfiguration des RHN Package Managers feststellen, ob die
lokalen Pakete erfolgreich zum privaten RHN-Channel hinzugefügt wurden?
A:
Führen Sie den Befehl rhn_package_m anager -l -c "nam e_of_private_channel" aus,
um die den RHN-Servern bekannten Pakete in den privaten Channels aufzulisten. Oder verwenden
Sie dazu die RHN Weboberfläche.
Nachdem Sie ein registriertes System bei einem privaten Channel angemeldet haben, können Sie
auch den up2date -l --showall Befehl auf den registrierten Systemen anwenden, um im
privaten RHN-Channel nach den Paketen zu suchen.
F:
Ich habe die DNS-Namenseinstellung auf meinem Proxy-Server geändert, und nun
können meine Client-Systeme sich nicht mehr aktualisieren. Wie kann ich das
beheben?
A:
Führen Sie den Befehl up2date -u auf dem Client-System aus, damit die Namensänderung
wirksam wird.
F:
Wie kann ich feststellen, ob die Clients mit dem Squid-Server verbunden sind?
A:
Die /var/log/squid/access.log Datei protokolliert alle Verbindungen zum Squid-Server.
F:
Der Red Hat Update Agent auf dem Client-System verbindet nicht über den RHN Proxy
Server. Wie kann dieser Fehler behoben werden?
A:
Vergewissern Sie sich, dass die neueste Version des Red Hat Update Agents auf den ClientSystemen installiert ist. Die neuste Version enthält die Features, die zur Verbindung durch einen
RHN Proxy Server notwendig sind. Die neueste Version erhalten Sie über das Red Hat Network
durch Ausführen des yum update yum Befehls als Root oder von
http://www.redhat.com/support/errata/.
Der RHN Proxy Server stellt eine Erweiterung von Apache dar. Siehe T abelle 7.2,
„Protokolldateien“ um herauszufinden, wo sich die Protokolldateien befinden.
F:
Meine RHN Proxy Server-Konfiguration funktioniert nicht. Wo fange ich mit der
Fehlersuche an?
A:
Überprüfen Sie, ob /etc/sysconfig/rhn/system id dem Benutzer root.apache gehört und die
Berechtigungen 0640 besitzt.
Lesen Sie die Protokolldateien. Eine Liste finden Sie in T abelle 7.2, „Protokolldateien“.
7.4. Allgemeine Probleme
Um mit der Problembehandlung von allgemeinen Problemen zu beginnen, untersuchen Sie die
Protokolldatei(en), die mit der Komponente in Z usammenhang stehen, die das Fehlverhalten aufweist.
Führen Sie den Befehl tail für alle Protokolldateien aus und lassen dann up2date --list laufen.
Daraufhin sollten Sie alle neuen Protokolleinträge nach möglichen Anhaltspunkten untersuchen.
Ein häufiges Problem ist voller Speicherplatz. Ein nahezu sicheres Z eichen dafür ist das Auftreten von
abgebrochenen Aufzeichnungen in den Protokolldateien. Wenn das Protokollieren während des
27
Schreibvorganges abgebrochen wurde, wie beispielsweise mitten im Wort, dann haben Sie
höchstwahrscheinlich einen vollen Datenträger. Z ur Bestätigung dieser Annahme führen Sie einfach
folgenden Befehl aus und überprüfen die Prozentsätze in der Use% Spalte:
df -h
Z usätzlich zu Protokolldateien können Sie wertvolle Information auch durch die Abfrage des Status Ihrer
unterschiedlichen Komponenten erhalten. Dies ist für den Apache Web Server und Squid möglich.
Um den Apache Web Server Status abzufragen, führen Sie den folgenden Befehl aus:
service httpd status
Um den Squid-Status abzufragen, führen Sie den folgenden Befehl aus:
service squid status
Wenn der Administrator keine E-Mails vom RHN Proxy Server erhält, dann überprüfen Sie, dass die EMail-Adressen für traceback_m ail in /etc/rhn/rhn.conf korrekt gesetzt wurden.
7.5. Host nicht gefunden/FQDN konnte nicht ermittelt werden
Da RHN-Konfigurations-Dateien ausschließlich auf voll qualifizierten Domain-Namen (FQDNs) beruhen,
ist es unerlässlich, dass Schlüsselapplikationen den Namen des RHN Proxy Server in eine IP-Adresse
auflösen können. Red Hat Update Agent, Red Hat Network Registration Client und der Apache Web
Server sind für dieses Problem besonders anfällig. Nachdem der Startvorgang scheitert, geben die RHN
Applikationen Fehlermeldungen wie "host not found" (Host nicht gefunden) und "Could not determine the
server's fully qualified domain name" (FQDN konnte nicht ermittelt werden) aus.
Dieses Problem hat normalerweise seine Ursache in der /etc/hosts Datei. Sie können diese
Annahme bestätigen, indem Sie sich /etc/nsswitch.conf genauer ansehen, in welcher das
Verfahren und die Reihenfolge festgelegt wird, in der Domainnamen aufgelöst werden. Normalerweise
wird die Datei /etc/hosts zuerst überprüft, gefolgt vom Network Information Service (NIS), gefolgt von
DNS. Eine dieser Überprüfungen muss erfolgreich sein, damit der Apache Web Server starten kann und
die RHN-Client-Applikationen funktionieren können.
Um dieses Problem zu beheben, sehen Sie sich die Inhalte der /etc/hosts Datei genauer an. Diese
können ungefähr so aussehen:
127.0.0.1 this_machine.example.com this_machine localhost.localdomain \
localhost
In einem T ext-Editor entfernen Sie die Maschinen Host-Informationen aus der Datei. Es sollte so
aussehen:
127.0.0.1 localhost.localdomain.com localhost
Speichern Sie die Datei und versuchen Sie die RHN-Client-Applikationen oder den Apache Web Server
erneut zu starten. Wenn dies immer noch fehlschlägt, dann geben Sie ausdrücklich die IP-Adresse des
Proxys in der Datei an, wie z.B.:
28
127.0.0.1 localhost.localdomain.com localhost
123.45.67.8 this_machine.example.com this_machine
Ersetzen Sie hier den Wert durch die tatsächliche IP-Adresse des Proxys. Damit sollte das Problem
behoben sein. Denken Sie daran dass, falls diese spezielle IP-Adresse auf diese Art festgelegt ist, die
Datei immer dann aktualisiert werden muss, wenn die Maschine eine neue Adresse erhält.
7.6. Verbindungsfehler
Wenn Sie Probleme haben, die wahrscheinlich auf eine fehlgeschlagene Verbindung zurückzuführen
sind, dann können Sie Folgendes tun:
Bestätigen Sie, dass das richtige Paket:
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm
auf dem RHN Proxy Server installiert ist, und dass das entsprechende rhn-org-trusted-sslcert-* .noarch.rpm oder das öffentliche Originale CA SSL-(Client)-Z ertifikat auf allen ClientSystemen installiert ist.
Überprüfen Sie dass die Client-Systeme konfiguriert sind das entsprechende Z ertifikat zu
verwenden.
Wenn Sie einen oder mehrere RHN Proxy Server verwenden, überprüfen Sie, ob das SSL-Z ertifikat
eines jeden Proxys richtig vorbereitet ist. Wenn Sie den RHN Proxy Server in Verbindung mit einem
RHN Satellite Server verwenden, sollte der Proxy sowohl sein eigenes Server-SSL-Schlüsselpaar als
auch das öffentliche SSL-(Client)-Z ertifikat Ihrer CA installiert haben. Für detaillierte Informationen
verweisen wir dazu auf das Kapitel SSL-Z ertifikate im RHN Client-Konfigurationshandbuch.
Falls der RHN Proxy Server über einen HT T P-Proxy verbindet, überprüfen Sie, ob die URL gültig ist.
Beispielsweise sollte das HT T P-Proxy URL-Feld keine Verweise auf Protokolle enthalten, wie
beispielsweise http:// oder https://. Nur der Hostname und Port sollten als hostname:port, wie
beispielsweise your-gateway.exam ple.com :8080, angegeben werden.
Vergewissern Sie sich, dass Client-Systeme keine eigenen Firewalls verwenden und somit
erforderliche Ports blockieren, wie in Abschnitt 2.4, „Weitere Anforderungen“ aufgezeigt.
7.7. Caching-Probleme
Falls die Paketlieferung fehlschlägt oder ein Objekt fehlerhaft erscheint und dies nicht auf
Verbindungsfehler zurückzuführen ist, sollten Sie in Betracht ziehen, die Caches zu leeren. Der RHN
Proxy Server besitzt zwei Caches, mit denen Sie sich befassen sollten: einen für Squid und den anderen
zur Authentifizierung.
Der Squid-Cache befindet sich in /var/spool/squid/. Um ihn zu löschen:
1. Anhalten des Apache Web Servers: service httpd stop
2. Anhalten des Squid Servers: service squid stop
3. Löschen Sie den Inhalt des Verzeichnisses: rm -fv /var/cache/rhn/*
4. Starten Sie beide Dienste neu:
service squid start
service httpd start
29
Die gleiche Aufgabe kann schneller durch Löschen des Verzeichnisses und Neustart von Squid erreicht
werden, aber diese Methode wird höchstwahrscheinlich zu einer Anzahl von RHN T raceback
Nachrichten führen.
Der interne Caching-Mechanismus, der durch das Proxy zur Authentifizierung verwendet wird, sollte
eventuell ebenfalls entleert werden. Führen Sie dazu den folgenden Befehl aus:
rm -fv /var/cache/rhn/*
Auch wenn der RHN Authentication Daemon seit der RHN Proxy Server 3.2.2 Release nicht mehr
verwendet wird und durch den zuvor erwähnten internen Authentifizierungs-Mechanismus ersetzt
wurde, kann es sein, dass der Daemon immer noch auf Ihrem Proxy läuft. Um diesen abzuschalten,
führen Sie folgende individuelle Befehle in dieser Reihenfolge aus:
chkconfig --level 2345 rhn_auth_cache off service rhn_auth_cache stop
Um den Cache zu leeren, geben Sie den folgenden Befehl ein:
rm /var/up2date/rhn_auth_cache
Wenn Sie jedoch den RHN Authentication Daemon beibehalten müssen, was von Red Hat weder
empfohlen noch unterstützt wird, dann kann es sein, dass seine Leistung durch die ausführliche
Protokollierung leidet. Aus diesem Grund ist dessen Protokollierung (nach
/var/log/rhn/rhn_auth_cache.log) standardmäßig deaktiviert. Wenn Sie den Daemon
ausführen und die Protokollierung wünschen, dann können Sie diese wieder einschalten, indem Sie
folgende Z eile in der /etc/rhn/rhn.conf Datei des Proxys hinzufügen:
auth_cache.debug = 2
7.8. Suche und Bereinigung von Proxy-Fehlern durch Red Hat
Wenn alle diese Schritte zur Problembehandlung ausgeschöpft sind oder wenn sie diese an Red Hat
Network-Profis abtreten möchten, empfiehlt Red Hat, dass Sie die Vorteile der starken Unterstützung,
die mit RHN Proxy Server kommt, nutzen.
Eine Möglichkeit, auf dieses Fachwissen zuzugreifen, ist mittels der Red Hat Wissensdatenbank, die
Lösungen für häufig bei Benutzern aufgetretene Probleme bereitstellt, sowie eine robuste Oberfläche
zum Stöbern und Suchen bietet, um die richtige Antwort auf Ihr Proxy-Problem zu finden. Sie finden die
Red Hat Wissensdatenbank unter http://kbase.redhat.com.
Z usätzlich bietet Red Hat ein Befehlszeilen-T ool namens SoS Report an, weitläufig auch unter dem
Befehlsnamen sosreport bekannt. Dieses T ool sammelt die Konfigurationsparameters Ihres Proxys,
die Protokolldateien und Datenbankinformationen, und sendet alles direkt an Red Hat.
Um dieses T ool für RHN Satellite Server Informationen zu nutzen, muss das sos Paket installiert sein.
Geben Sie als Root sosreport -o rhn auf dem Satellite Server ein, um einen Report zu erzeugen.
Z um Beispiel:
30
[root@satserver ~]# sosreport -o rhn
sosreport (version 1.7)
This utility will collect some detailed information about the
hardware and setup of your Red Hat Enterprise Linux system.
The information is collected and an archive is packaged under
/tmp, which you can send to a support representative.
Red Hat will use this information for diagnostic purposes ONLY
and it will be considered confidential information.
This process may take a while to complete.
No changes will be made to your system.
Press ENTER to continue, or CTRL-C to quit.
Sie werden anschließend nach dem Anfangsbuchstaben Ihres Vornamens und Ihrem Nachnamen
gefragt, dann nach einer Support-T icketnummer (auch Issue-T racker-Nummer genannt).
Es kann einige Minuten dauern, bis das System den Bericht erzeugt und in einer komprimierten Datei
abgespeichert hat. Sobald dieser Vorgang abgeschlossen ist, emailen Sie die neue Datei im /tm p/
Verzeichnis zur umgehenden Diagnose an Ihren Red Hat Vertreter.
31
Beispiel für eine RHN Proxy Server Konfigurations-Datei
Die /etc/rhn/rhn.conf Konfigurations-Datei für den RHN Proxy Server ermöglicht einem
Administrator grundlegende Einstellungen festzulegen. Seien Sie jedoch gewarnt, dass Fehler in dieser
Datei Proxy-Ausfälle zur Folge haben können. Machen Sie daher Änderungen an der Konfiguration mit
Vorsicht.
Wenn Sie auch einen RHN Satellite Server verwenden, sollten Sie sich speziell mit folgenden
Parametern befassen: traceback_mail und proxy.rhn_parent. Sehen Sie das Beispiel und die
Kommentare (beginnend mit dem Rauten-Z eichen #) genauer an.
Anmerkung
Sie können die use_ssl Option der rhn.conf Datei nur für T estzwecke hinzufügen. Setzen Sie
den Wert auf 0, um SSL zwischen dem Proxy und dem Upstream-Server vorübergehend
auszuschalten. Beachten Sie bitte, dass dadurch die Sicherheit extrem gefährdet wird. Setzen Sie
die Einstellung wieder auf den Standardwert 1 zurück, um SSL wieder zu aktivieren oder
entfernen Sie die Z eile einfach aus der Konfigurations-Datei.
# Automatically generated RHN Management Proxy Server configuration file.
# ------------------------------------------------------------------------# SSL CA certificate location
proxy.ca_chain = /usr/share/rhn/RHNS-CA-CERT
# Corporate HTTP proxy, format: corp_gateway.example.com:8080
proxy.http_proxy =
# Password for that corporate HTTP proxy
proxy.http_proxy_password =
# Username for that corporate HTTP proxy
proxy.http_proxy_username =
# Location of locally built, custom packages
proxy.pkg_dir = /var/spool/rhn-proxy
# Hostname of RHN Server or RHN Satellite
proxy.rhn_parent = rhn.redhat.com
# Destination of all tracebacks, etc.
traceback_mail = [email protected], [email protected]
32
Versionsgeschichte
Versionsgeschichte
Version 3-5.2.4 00
Rebuild with publican 4.0.0
2013-10-31
Rüdiger Landmann
Version 3-5.2
Mon Apr 22 2013
Übersetzung und Korrekturgelesen abgeschlossen
Rainer Gromansperg
Version 3-5.1
T hu Mar 21 2013
Übersetzungsdateien synchronisiert mit XML-Quellen 3-5
Hedda Peters
Version 3-5
Wed Sept 19 2012
Endgültige Z usammenstellung für 5.5
Dan Macpherson
Version 3-4
Wed Jul 4 2012
Vorbereitet für 5.5 Release
Änderungen nach technischer Überprüfung implementiert
BZ #491007 Kapitel über Upgrade Installation Hinzugefügt
Athene Chan
Version 3-0
Wed Jul 4 2012
Vorbereitet für 5.5 Release
Änderungen nach technischer Überprüfung implementiert
BZ #491007 Kapitel über Upgrade Installation Hinzugefügt
Athene Chan
Version 2-5
T hu Jan 5 2012
BZ #682996 - Kapitel Installation - Update Anleitung
BZ #705755 - Kapitel Package Manager - Z usätzliche Information
BZ #722193 - Kapitel Anforderungen - Fehler behoben
BZ #729617 - Kapitel Installation - Fehler behoben
BZ #729663 - Kapitel Installation - Warnung hinzugefügt
Lana Brindley
Version 2-4
Mon Aug 15 2011
Lana Brindley
Änderungen der z-Stream Release in y-Stream-Release eingebracht
Version 2-3
Wed Jun 22 2011
BZ #713527 - Hinweise auf RHEL 6 hinzugefügt
Lana Brindley
Version 2-2
Wed Jun 15 2011
Vorbereitet für Veröffentlichung
Lana Brindley
Version 2-1
Änderungen von Übersetzern
Fri May 27 2011
Lana Brindley
Version 2-0
Vorbereitet für Übersetzung
Fri May 6 2011
Lana Brindley
Version 1-9
BZ #653844 - QE-Prüfung
Wed April 27 2011
Lana Brindley
33
Version 1-8
BZ #646176 - Installation
Mon Feb 7 2011
Lana Brindley
Stichwortverzeichnis
A
Allgemeine Probleme, Allgemeine Probleme
Anforderungen, Anforderungen
- Hardware, Hardware-Anforderungen
- Software, Software-Anforderungen
- Speicherplatz, Speicherplatzanforderungen
- weitere, Weitere Anforderungen
Ausgehende Ports
- 80, 443, Weitere Anforderungen
Authentifizierung, Proxy Funktionsweise
Authentifizierungs-Cache
- löschen, Caching-Probleme
C
Caching-Probleme, Caching-Probleme
Channel, Häufig verwendete T erminologien
Channel Adminstrator, Häufig verwendete T erminologien
Client-Konfiguration
- Subskribieren eines privaten Kanals, Hochladen von Paketen
E
Eingehende Ports, Satellite
- 5222, Weitere Anforderungen
F
Fragen und Antworten, Fragen und Antworten
H
Hardware-Anforderungen, Hardware-Anforderungen
Häufig verwendete T erminologien, Häufig verwendete T erminologien
Host nicht gefunden (Host Not Found) Fehler
- FQDN konnte nicht ermittelt werden (Could Not Determine FQDN), Host nicht
gefunden/FQDN konnte nicht ermittelt werden
34
Stichwortverzeichnis
HT T P Proxy Caching Server
- Speicherplatzanforderungen, Speicherplatzanforderungen
I
Installation
- Basis-, Basisinstallation
- des RHN Proxy Servers, RHN Proxy Server Installationsvorgang
K
Kanal
- Erstellen eines privaten Kanals, Erstellen eines Privaten Kanals
O
Organization Administrator, Häufig verwendete T erminologien
P
Port
Port 4 4 3, Weitere Anforderungen
Port 4 54 5, Weitere Anforderungen
Port 80, Weitere Anforderungen
Privater Kanal, Erstellen eines Privaten Kanals
Protokolldateien, Protokolldateien
Proxy Funktionsweise, Proxy Funktionsweise
Proxy-Ports, Weitere Anforderungen
R
Red Hat Network
- Einführung, Red Hat Netzwerk
Red Hat Update Agent, Häufig verwendete T erminologien, Proxy Funktionsweise
RHN Authentication Daemon, deaktivieren
- rhn_auth_cache, stoppen, Caching-Probleme
RHN Package Manager, Proxy Funktionsweise, RHN Package Manager und die Lieferung
Lokaler Pakete
35
-
Befehlszeilen-Optionen, RHN Package Manager und die Lieferung Lokaler Pakete
Channels spezifizieren, Hochladen von Paketen
Erstellen eines privaten Kanals, Erstellen eines Privaten Kanals
Hochladen von Paket-Headern, Hochladen von Paketen
Installation, RHN Package Manager und die Lieferung Lokaler Pakete
Konfiguration, Erstellen eines Privaten Kanals
Konfigurations-Datei, RHN Package Manager und die Lieferung Lokaler Pakete
Verifizieren der lokalen Paketliste, Hochladen von Paketen
rhn-proxy
- Dienst, Verwalten des Proxy-Dienstes
rhn.conf
- Beispieldatei, Beispiel für eine RHN Proxy Server Konfigurations-Datei
rhn_package_manager , Hochladen von Paketen (Siehe RHN Package Manager)
S
satellite-debug, Suche und Bereinigung von Proxy-Fehlern durch Red Hat
Software-Anforderungen, Software-Anforderungen
Speicherplatzanforderungen, Speicherplatzanforderungen
Squid-Cache, Caching-Probleme
Suche und Bereinigung von Fehlern, Suche und Bereinigung von Fehlern
T
T opologien, Beispieltopologien
- einzelner Proxy, Einzel-Proxy-T opologie
- mehrere Proxys horizontal gestaffelt, Mehrfach horizontal gestaffelte Proxy-T opologie
- mehrfache Proxys, vertikal gestaffelt, Mehrfach vertikal gestaffelte Proxy-T opologie
- Proxys mit RHN Satellite Server, Proxys mit RHN Satellite Server
T raceback, Häufig verwendete T erminologien
V
Verbindungsfehler, Verbindungsfehler
Vorteile, RHN Proxy Server
W
Weitere Anforderungen, Weitere Anforderungen
36

Red Hat Network Satellite 5.5 Proxy

Transcription

Documents pareils

Anleitung zur Einrichtung des Proxy

Proxy-Server mit Cache

Proxyserver aktivieren und deaktiveren. IE benutzen! Einstellungen

PDF

Artikel als PDF anzeigen

SQL-Server Administrator (m/w)