Red Hat Network Satellite 5.4 Client

Transcription

Red Hat Network Satellite 5.4
Client-Konfigurationshandbuch
Red Hat Network Satellite
Ausgabe 1
Landmann
Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch
Red Hat Network Satellite
Ausgabe 1
Landmann
rlandmann@redhat.co m
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 Red Hat Network Satellite Client-Konfigurationshandbuch.
Inhaltsverzeichnis
Inhaltsverzeichnis
. . . . . . . . 1.
Kapitel
. . .Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .
.Kapitel
. . . . . . . 2.
. . .Client-Applikationen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .
2.1. Die neuesten Red Hat Network Client-RPMs einsetzen
4
2.2. Client-Applikationen konfigurieren
5
2.2.1. Registrieren mit Aktivierungsschlüsseln
5
2.2.2. Die up2date --configure-Option
6
2.2.3. Die Konfigurationsdateien manuell aktualisieren
7
2.2.4. Server-Ausfallsicherung implementieren
8
2.3. Das Paket-Updater-Applet
8
2.4. Das Red Hat Network Alert Notification T ool für Satellite konfigurieren
9
.Kapitel
. . . . . . . 3.
. . .SSL-Infrastruktur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
............
3.1. Eine kurze Einführung in SSL
10
3.2. Das RHN SSL Maintenance T ool
11
3.2.1. Erklärung zur SSL-Generierung
12
3.2.2. RHN SSL Maintenance T ool-Optionen
13
3.2.3. Das CA SSL-Schlüsselpaar generieren
18
3.2.4. Webserver SSL-Schlüssel-Sets generieren
18
3.3. Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren
19
3.4. Client-Systeme konfigurieren
19
. . . . . . . . 4. .. .Import
Kapitel
. . . . . . .angepasster
. . . . . . . . . . . . . .GPG-Schlüssel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
............
.Kapitel
. . . . . . . 5.
. . .Verwendung
. . . . . . . . . . . . .von
. . . . RHN
. . . . . Bootstrap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
............
5.1. Vorbereitung
22
5.2. Generierung
23
5.3. Verwendung des Skripts
24
5.4. RHN Bootstrap Optionen
24
. . . . . . . . 6.
Kapitel
. . .Manuelles
. . . . . . . . . . .Erstellen
. . . . . . . . . .der
. . . .Konfiguration
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
............
. . . . . . . . 7.
Kapitel
. . .Implementieren
. . . . . . . . . . . . . . . . von
. . . . Kickstart
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
............
. . . . . . . . . für
Beispiel
. . . .ein
. . . Bootstrap-Skript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
...........
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Versionsgeschichte
...........
.Stichwortverzeichnis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
...........
Symbole
38
A
38
B
38
C
38
G
38
K
38
R
39
S
39
1
2
Kapitel 1. Einführung
Kapitel 1. Einführung
Dieses Handbuch mit praktischen Anwendungsbeispielen soll RHN Satellite Server- und RHN Proxy
Server-Kunden dabei helfen, ihre Client-Systeme einfacher konfigurieren zu können.
Standardmäßig kommunizieren alle Red Hat Network Client-Applikationen mit den zentralen Red Hat
Network-Servern. Wenn Clients stattdessen mit einem RHN Satellite Server oder RHN Proxy Server
verbunden werden, müssen viele dieser Einstellungen verändert werden. Das Verändern der ClientEinstellungen für ein oder zwei Systeme ist relativ einfach. Eine Unternehmensumgebung dagegen, die
hunderte oder gar tausende von Systemen umfassen kann, wird höchstwahrscheinlich von den hier
beschriebenen Massenkonfigurationsschritten profitieren.
Aufgrund der Komplexität dieses Unterfangens können Kunden ein bestehendes Skript einsetzen,
welches viele der notwendigen Aufgaben automatisiert, die für eine Verbindung mit einem Proxy oder
Satellite Server notwendig sind. Werfen Sie einen Blick auf Kapitel 5, Verwendung von RHN Bootstrap
für weitere Details. Red Hat ist davon überzeugt, dass das Verständnis der notwendinge Änderungen
und der damit verbundenen Implikationen für den Anwender äußerst hilfreich sein kann und beschreibt
deshalb die manuellen Schritte für die Rekonfiguration in den anfänglichen Kapiteln dieses Handbuchs.
Sie können somit nach eigenem Ermessen die für Ihr Unternehmen ideale Lösung bestimmen.
Obwohl viele der in diesem Handbuch angeführten Befehle genau so angewendet werden können, wie
sie in diesem Handbuch erscheinen, ist es nicht möglich, alle potenziellen Netzwerkkonfigurationen von
Kunden vorauszusagen. Red Hat empfiehlt Ihnen daher, diese Befehle lediglich als Referenzen
anzusehen und die individuellen Einstellungen Ihres Unternehmens zu berücksichtigen.
Anmerkung
Informationen zur Unix Client-Konfiguration finden Sie im RHN Satellite Server Referenzhandbuch
im Unix-Support-Kapitel.
3
Kapitel 2. Client-Applikationen
Um die meisten Red Hat Network-Features im Unternehmensbereich nutzen zu können, wie
beispielsweise die Registrierung für einen RHN Satellite, ist die Konfiguration der neuesten ClientApplikationen erforderlich. Der Erhalt dieser Applikationen noch vor der Registrierung des Clients bei
Red Hat Network kann sich etwas schwierig gestalten. Dieses Paradox wird speziell dann
problematisch, wenn Kunden eine geraume Anzahl von älteren Systemen auf Red Hat Network
migrieren.
Wichtig
Red Hat empfiehlt dringend, dass Clients, die mit einem RHN Proxy Server oder RHN Satellite
Server verbunden sind, das neueste Update von Red Hat Enterprise Linux besitzen, um eine
einwandfreie Verbindungsfähigkeit zu gewährleisten.
Falls zusätzlich Client-Firewalls eingerichtet wurden, sollten die Ports 80 und 443 geöffnet sein,
damit Red Hat Network ordnungsgemäß funktioniert.
2.1. Die neuesten Red Hat Network Client-RPMs einsetzen
Der Paket-Updater (pup), yum , und Red Hat Network Registration Client (rhn_register) auf
Red Hat Enterprise Linux 5 (up2date auf früheren Versionen von Red Hat Enterprise Linux) sind
Voraussetzungen für die Verwendung eines Großteils der Enterprise-Funktionalität von Red Hat
Network. Dabei ist es äußerst wichtig, diese vor dem Versuch, RHN Proxy Server oder RHN Satellite
Server in Ihrer Unternehmensumgebung zu verwenden, auf Client-Systemen zu installieren.
Es gibt hierbei einige sinnvolle Vorgehensweisen für das Update der RHN Client-Software. Eine davon
umfasst das Speichern der RPMs an einem Ort, an dem von allen Client-Systemen auf die RPMs
zugegriffen werden kann und das Implementieren der Pakete mit dem einfachst möglichen Befehl. In
nahezu allen Fällen ist eine manuelle Implementierung von yum , pup und rhn_register (up2date bei
früheren Versionen von Red Hat Enterprise Linux) nicht notwendig. Diese Client-T ools sollten keine
Probleme mit der Verbindung zu Ihrer RHN Satellite- oder Proxy-Umgebung haben. Die untenstehende
Auseinandersetzung mit diesem T hema beruht auf der Annahme, dass die standardmäßigen T ools yum ,
pup, und rhn_register (oder up2date) nicht in den aktuellsten Versionen vorliegen und sich für Ihre
Umgebung nicht eignen.
Bitte vergessen Sie nicht, dass lediglich Systeme mit Red Hat Enterprise Linux 5 sich bei RHN registriert
haben müssen in firstboot nach Installation, oder mittels rhn_register. Systeme mit Red Hat
Enterprise Linux 3 und 4 können die im Red Hat Update Agent eingebaute
Registrierungsfunktionalität verwenden.
In dieser Dokumentation wird davon ausgegangen, dass sich zumindest ein RHN Satellite Server
und/oder RHN Proxy Server im Netzwerk des Kunden befindet. Das untenstehende Beispiel illustriert
eine einfache Vorgehensweise beim erstmaligen Einsatz von yum , pup und rhn_register (oder
up2date) durch einen Administrator. Dabei wird davon ausgegangen, dass die Rechner noch kein
funktionstüchtiges RHN besitzen. Der Administrator hat das /var/www/htm l/pub/-Verzeichnis mit
einer Kopie von yum , pup und rhn_register (oder up2date) RPMs bestückt, die von seinen ClientSystemen benötigt werden und hat diese RPMs mittels dem einfachen rpm -Uvh-Befehl auf seinen
Clients implementiert. Auf einem Client ausgeführt, installiert dieser Befehl die RPM-Dateien auf diesem
Client. Voraussetzung dafür sind der korrekte Domainname, Pfad und die entsprechenden RPMVersionen:
4
rpm -Uvh
http://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/yum-3.2.8-9.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
Beachten Sie dabei, dass die Architektur (in diesem Fall i386) abhängig von den zu versorgenden
Systemen eventuell abgeändert werden muss.
2.2. Client-Applikationen konfigurieren
Es muss nicht jeder Kunde eine sichere Verbindung mit einem RHN Satellite Server oder RHN Proxy
Server innerhalb des eigenen Unternehmens besitzen. Nicht jeder Kunde benötigt einen GPG-Schlüssel
für angepasste Pakete. (Beide dieser T hemen werden später im Detail behandelt.) Jeder Kunde, der
RHN Satellite Server oder RHN Proxy Server verwendet, muss den Red Hat Update Agent (up2date)
neu konfigurieren und möglicherweise auch den Red Hat Network Registration Client
(rhn_register), um diesen von Red Hat Network auf den eigenen RHN Satellite Server oder RHN
Proxy Server umzulenken.
Wichtig
Obwohl dies nicht konfigurierbar ist, beachten Sie bitte, dass der vom up2date verwendete Port
80 für HT T P und 443 für sicheres HT T P (HT T PS) ist. Standardmäßig verwendet yum auf Red
Hat Enterprise Linux 5 nur SSL. Aus diesem Grund sollten sich Benutzer zuerst davon
überzeugen, das ihre Firewalls Verbindungen über den Port 443 zulassen. Um SSL zu umgehen,
müssen Sie das Protokoll für serverURL in /etc/sysconfig/rhn/up2date von https auf
http umändern. Ebenso müssen Sie beachten, dass für die Verwendung von Monitoring und
Probes, die den Red Hat Network Monitoring Daemon benötigen, Client-Systeme Verbindungen
auf dem Port 4545 (oder Port 22, falls stattdessen sshd verwendet wird) zulassen müssen.
Standardmäßig verweisen rhn_register und up2date auf die Haupt-Red Hat Network-Server.
Benutzer müssen daher Client-Systeme neu konfigurieren, sodass diese auf ihren RHN Satellite Server
oder RHN Proxy Server verweisen.
Beachten Sie bitte, dass die neueste Version des Red Hat Update Agent so konfiguriert werden kann,
dass auch mehrere RHN Server verwendet werden können und dieser somit eine Art Ausfallsicherung
darstellt, falls auf den primären Server nicht zugegriffen werden kann. Werfen Sie einen Blick auf
Abschnitt 2.2.4, „Server-Ausfallsicherung implementieren“ für nähere Instruktionen zur Aktivierung
dieses Features.
T he next sections describe different methods of configuring the client systems to access your RHN
Satellite Server or RHN Proxy Server. T o see how virtually all reconfiguration can be scripted, see
Kapitel 6, Manuelles Erstellen der Konfiguration.
2.2.1. Registrieren mit Aktivierungsschlüsseln
Red Hat empfiehlt die Verwendung von Aktivierungsschlüsseln bei der Registrierung und der
Konfiguration von Client-Systemen, die auf RHN Proxy Server oder RHN Satellite Server zugreifen.
Aktivierungsschlüssel können zum Registrieren, Berechtigen und zum Anmelden von Systemen
verwendet werden. Werfen Sie einen Blick auf den Abschnitt "Aktivierungsschlüssel" im RHN Satellite
Server Referenzhandbuch für weitere Informationen über Aktivierungsschlüssel.
Z ur Registrierung mit einem Aktivierungsschlüssel gehören 4 einfache Schritte:
5
1. Erstellen Sie einen Aktivierungsschlüssel.
2. Importieren Sie angepasste GPG-Schlüssel.
3. Laden Sie die SSL-Z ertifikats-RPM vom /pub/-Verzeichnis des RHN Proxy Server oder RHN
Satellite Server herunter und installieren diese. Der Befehl für diesen Schritt könnte ungefähr so
aussehen:
rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.01.noarch.rpm
4. Melden Sie Ihr System bei Ihrem RHN Proxy Server oder RHN Satellite Server an. Der Befehl für
diesen Schritt könnte ungefähr so aussehen:
rhnreg_ks --activationkey mykey --serverUrl https://your-satelliteFQDN/XMLRPC
Alternativ können die meisten der o.g. Schritte in einem Shell-Skript zusammengefasst werden, das die
folgenden Z eilen enthält (Beachten Sie, dass dieser Befehl für den Druck und für PDF-Dokumente in
mehrere Z eilen umgebrochen, er jedoch am Shell-Prompt in einer einzigen Z eile eingegeben werden
muss).
wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://your-satellite-FQDN/XMLRPC
Das Bootstrap-Skript, das bei der Installation generiert wird und für RHN Satellite Server sowie auch
RHN Proxy Server zur Verfügung steht, ist ein solches Skript. Das Skript und der von dem, eRHN
Bootstraps generiert wird, werden genauer in Kapitel 5, Verwendung von RHN Bootstrap besprochen.
Warnung
Systeme mit Red Hat Enterprise Linux 2.1 und Versionen von Red Hat Linux vor 8.0 können
Schwierigkeiten bei der Verwendung von Aktivierungsschlüsseln zur Migration von SSLZ ertifikateinstellungen von rhn_register auf up2date haben. Deshalb muss die Information
der SSL-Z ertifikate auf diesen Systemen manuell festgelegt werden. Alle anderen Einstellungen,
wie beispielsweise die Server-URL, werden einwandfrei übertragen.
2.2.2. Die up2date --configure-Option
Der Red Hat Update Agent in Red Hat Enterprise Linux 3 und 4 stellt eine Oberfläche zur
Konfiguration unterschiedlicher Einstellungen bereit. Für eine vollständige Auflistung dieser
Einstellungen werfen Sie bitte einen Blick auf die up2date-Handbuchseite (m an up2date in der
Befehlszeile).
Um den Red Hat Update Agent neu zu konfigurieren, müssen Sie folgenden Befehl als 'root'
ausführen:
up2date --configure
Es erscheint ein Dialogfenster, welches unterschiedliche Einstellungen anbietet, die neu konfiguriert
werden können. Im Allgem ein-Reiter unter Wählen Sie einen Red Hat Network Server aus
ersetzen Sie den Standardwert durch dem FQDN des RHN Satellite Servers oder RHN Proxy Servers,
6
wie beispielsweise https://your_proxy_or_sat.your_dom ain.com /XMLRPC. /XMLRPC am Ende
sollte beibehalten werden. Klicken Sie anschließend auf OK.
Abbildung 2.1. GUI-Konfiguration des Red Hat Update Agent
Vergewissern Sie sich, dass Sie den Domainnamen Ihres RHN Satellite Server oder RHN Proxy Server
richtig eingeben. Wenn Sie einen falschen Domainnamen eingeben oder das Feld leer lassen, kann es
sein, dass up2date --configure nicht startet. Dieses Problem kann jedoch gelöst werden, indem
Sie den Wert in der up2date-Konfigurationsdatei abändern. Siehe Abschnitt 2.2.3, „Die
Konfigurationsdateien manuell aktualisieren“ für genauere Instruktionen.
Warnung
Systeme mit Red Hat Enterprise Linux 3 oder 4 besitzen Registrierungsfunktionalität, die in den
Red Hat Update Agent eingebaut ist und installieren daher den Red Hat Network
Registration Client nicht. Systeme mit Red Hat Enterprise Linux 5 verwenden up2date nicht,
sie benötigen daher rhn_register, um ihre Systeme bei RHN oder Satellite zu registrieren,
sowie yum und pup, um ihre Pakete zu aktualisieren.
2.2.3. Die Konfigurationsdateien manuell aktualisieren
Alternativ zur zuvor erläuterten grafischen Benutzeroberfläche kann der Red Hat Update Agent auch
neu konfiguriert werden, indem die Konfigurationsdateien der Applikationen bearbeitet werden.
Um Red Hat Update Agent auf den Client-Systemen zu konfigurieren, die mit dem RHN Proxy Server
oder RHN Satellite Server verbinden, bearbeiten Sie die Werte der serverURL- und
noSSLServerURL-Einstellungen in der /etc/sysconfig/rhn/up2date-Konfigurationsdatei als
'root'. Ersetzen Sie die standardmäßige Red Hat Network-URL mit dem FQDN für den RHN Proxy Server
oder RHN Satellite Server. Z um Beispiel:
7
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC
Warnung
Die httpProxy-Einstellung in /etc/sysconfig/rhn/up2date bezieht sich nicht auf den
RHN Proxy Server. Diese wird dazu verwendet, einen optionalen HT T P-Proxy für den Client zu
konfigurieren. Wenn ein RHN Proxy Server vorhanden ist, muss die httpProxy-Einstellung leer
gelassen werden (es darf kein Wert erscheinen).
2.2.4. Server-Ausfallsicherung implementieren
Ab up2date-4 .2.38 kann der Red Hat Update Agent dahingehend konfiguriert werden, nach
Updates von einer Reihe von RHN Servern zu suchen. Dies kann besonders hilfreich sein, wenn Ihr
primärer RHN Proxy Server oder RHN Satellite Server offline ist und Sie trotzdem konstante Updates
erhalten möchten.
Wenn Sie dieses Feature verwenden möchten, müssen Sie zuerst überprüfen, ob Sie die erforderliche
Version von up2date besitzen. Fügen Sie anschließend als 'root' manuell die sekundären Server zu
den serverURL und noSSLServerURL-Einstellungen in der /etc/sysconfig/rhn/up2dateKonfigurationsdatei hinzu. Fügen Sie ebenso die FQDNs für den Proxy oder Satellite durch ein
Semikolon (;) getrennt direkt nach dem primären Server ein. Z um Beispiel:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC;
https://your_secondary.your_domain.com/XMLRPC;
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC;
https://your_secondary.your_domain.com/XMLRPC;
Es wird versucht, die Verbindung zu den Servern in der hier angegebenen Reihenfolge herzustellen. Sie
können ganz nach Wunsch eine beliebige Anzahl an Servern mitaufnehmen. Sie können die zentralen
RHN Server ebenso auflisten. Dies macht jedoch nur dann Sinn, wenn die Client-Server mit dem Internet
verbunden sind.
2.3. Das Paket-Updater-Applet
Red Hat Enterprise Linux 5 bietet ein laufendes Programm auf der grafischen T askleiste, das
regelmäßig nach Updates vom RHN oder Satellite Server sucht und Benutzer benachrichtigt, sobald ein
neues Update verfügbar ist.
8
Abbildung 2.2. Paket-Updater-Applet
Das Paket-Updater-Applet bleibt im Benachrichtigungsfeld der T askleiste und sucht regelmäßig nach
neuen Updates. Das Applet ermöglicht Ihnen auch die Durchführung einiger Aufgaben zur
Paketverwaltung im Applet, durch Klicken auf das Benachrichtigungs-Icon und Auswählen einer der
folgenden Aufgaben:
Aktualisieren — Überprüfe RHN oder den Satellite auf neue Updates
Updates anzeigen — startet die Paket-Updater-Applikation, so dass Sie alle verfügbaren Updates
detaillierter ansehen können und die Updates nach Ihren Spezifikationen konfigurieren können
Updates anwenden — Herunterladen und installieren aller aktualisierten Pakete.
Beenden — Schließen des Applets
2.4. Das Red Hat Network Alert Notification Tool für Satellite
konfigurieren
Das Red Hat Network Alert Notification T ool, das runde Symbol in der T askleiste Ihres Red Hat
Enterprise Linux 3 oder 4 Desktops, kann auf Systemen mit Red Hat Enterprise Linux 3 oder höher
konfiguriert werden, um verfügbare Updates von angepassten Channels auf Ihrem RHN Satellite Server
zu erkennen. Gehen Sie sicher, dass die Konfiguration des RHN Satellite Server dieses Feature
unterstützt. (RHN Proxy Server unterstützt das Applet ohne Modifikation des Clients oder Servers.) Hier
finden Sie die Schritte, um das Red Hat Network Alert Notification T ool zu konfigurieren:
1. Ihr RHN Satellite Server muss Version 3.4 oder höher sein, sodass das rhns-applet-Paket auf
dem Satellite installiert ist. Das Paket finden Sie im RHN Satellite Software-Channel für Versionen
3.4 und höher.
2. Das rhn-applet-actions-Paket kann mit up2date oder mithilfe des Red Hat Network T ools
Software-Channel abgefragt werden. Installieren Sie das Paket auf allen Red Hat Enterprise Linux
3 und neueren Client-Systemen, um über benutzerspezifische Updates mithilfe des Red Hat
Network Alert Notification T ools benachrichtigt zu werden. Die Client-Systeme müssen zur
Management- oder Provisioning-Servicestufe berechtigt sein.
3. Auf der Satellite-Version der RHN-Website gehen Sie zur System -Details-Seite eines jeden
Systems und klicken auf den Link im RHN-Applet-Bereich, um das Red Hat Network Alert
Notification T ool auf den Satellite umzulenken.
Wenn das Applet das nächste Mal gestartet wird, wendet dieses die neue Konfiguration an und
verbindet sich mit dem RHN Satellite Server für Updates.
9
Kapitel 3. SSL-Infrastruktur
Für Red Hat Network-Kunden sind Sicherheitsfragen von höchster Bedeutung. Eine der Stärken von Red
Hat Network ist dessen Fähigkeit, jede einzelne Anfrage über SSL (Secure Sockets Layer) abzuwickeln.
Um diesen Sicherheitslevel beizubehalten, müssen Kunden, die Red Hat Network innerhalb der eigenen
Infrastruktur installieren, benutzerdefinierte SSL-Schlüssel und Z ertifikate generieren.
Die manuelle Erstellung und die manuelle Z uordnung von SSL-Schlüsseln und Z ertifikaten kann sehr
arbeitsaufwändig sein. RHN Proxy Server sowie auch RHN Satellite Server ermöglichen es Ihnen, Ihre
eigenen SSL-Schlüssel und Z ertifikate basierend auf Ihrer eigenen, privaten Z ertifizierungsstelle
(Certificate Authority oder im Folgenden kurz CA genannt) während der Installation zu erstellen.
Z usätzlich dazu gibt es zu diesem Z weck das separate Befehlszeilendienstprogramm RHN SSL
Maintenance T ool. Unabhängig davon müssen diese Schlüssel und Z ertifikate auf allen Systemen in
Ihrer Infrastruktur eingesetzt werden. In vielen Fällen ist der Einsatz dieser SSL-Schlüssel und
Z ertifikate bereits für Sie automatisiert. Dieses Kapitel beschreibt effiziente Verfahren zur Durchführung
all dieser Aufgaben.
Bitte beachten Sie, dass in diesem Kapitel das T hema SSL nicht tiefgreifend behandelt wird. Das RHN
SSL Maintenance T ool wurde so entwickelt, dass das Aufsetzen und Verwalten dieser Public-KeyInfrastruktur (PKI) weniger komplex erscheint. Für detailliertere Informationen zu diesem T hema
empfehlen wir auf einige der vielen, ausgezeichneten Referenzhandbücher, die in einem Buchhandel in
Ihrer Nähe erhältlich sind, zurückzugreifen.
3.1. Eine kurze Einführung in SSL
SSL oder Secure Sockets Layer ist ein Protokoll, das es Client-Servern ermöglicht, Informationen sicher
weiterzugeben. SSL verwendet dabei ein System von öffentlichen und privaten Schlüsselpaaren, um die
Kommunikation zu entschlüsseln, die zwischen den Clients und Servern stattfindet. Auf öffentliche
Z ertifikate oder sog. Public Certificates kann frei zugegriffen werden, wohingegen private Schlüssel oder
Private Keys gesichert aufbewahrt werden müssen. Dieses System basiert auf der mathematischen
Beziehung (digitale Signatur) zwischen einem privaten Schlüssel und dem dazugehörigen öffentlichen
Z ertifikat. Aufgrund dieser Beziehung kann eine vertrauenswürdige Verbindung hergestellt werden.
Anmerkung
Im Rahmen dieses Dokuments werden private SSL-Schlüssel und öffentliche Z ertifikate
behandelt. Genau genommen können beide als Keys oder Schlüssel bezeichnet werden
(öffentliche und private Schlüssel). Üblicherweise wird jedoch im Z usammenhang mit SSL die
öffentliche Hälfte eines SSL-Schlüsselpaares (oder Schlüssel-Sets) als öffentliches Z ertifikat
bezeichnet.
Die SSL-Infrastruktur eines Unternehmens besteht generell aus folgenden SSL-Schlüsseln und
Z ertifikaten:
Privater SSL-Schlüssel und öffentliches Z ertifikat Ihrer CA ("Certificate Authority",
Z ertifizierungsstelle) — üblicherweise wird nur ein Set pro Unternehmen generiert. Das öffentliche
Z ertifikat wird vom privaten Schlüssel digital signiert. Das öffentliche Z ertifikat wird an jedes System
verteilt.
Web Server privater SSL-Schlüssel und öffentliches Z ertifikat — ein Set pro Applikationsserver. Das
öffentliche Z ertifikat wird sowohl vom eigenen privaten Schlüssel als auch vom privaten SSLSchlüssel Ihrer CA digital signiert. Wir verweisen des öfteren auf ein Key-Set oder Schlüssel-Set
eines Webservers, da eine zwischengeschaltete Anfrage des SSL-Z ertifikats generiert wird. Die
10
Verwendung ist in diesem Fall nicht allzu wichtig und wird daher auch nicht weiter im Detail
besprochen. Alle drei werden einem RHN Server zugeordnet.
Hier ist ein Beispielszenario: Sie besitzen einen RHN Satellite Server und fünf RHN Proxy Server. Sie
generieren daher ein SSL-Schlüsselpaar Ihrer CA und sechs Webserver SSL-Schlüssel-Sets. Das
öffentliche SSL-Z ertifikat der CA wird auf alle Systeme verteilt und von allen Clients dazu verwendet,
eine Verbindung mit den jeweiligen Upstream-Servern aufzubauen. Jeder Server besitzt sein eigenes
SSL-Schlüssel-Set, welches speziell an den Hostnamen dieses Servers gebunden ist und unter
Verwendung des eigenen privaten SSL-Schlüssels in Verbindung mit dem privaten SSL-Schlüssel der
CA generiert wurde. Dadurch entsteht eine auf digitaler Basis verifizierbare Beziehung zwischen dem
öffentlichen SSL-Z ertifikats des Webservers und dem SSL-Schlüsselpaar Ihrer CA und dem privaten
Schlüssel des Servers. Das Schlüssel-Set des Webservers kann nicht mit anderen Webservern
gemeinsam verwendet werden.
Wichtig
Das Wichtigste an diesem System ist das SSL-Schlüsselpaar Ihrer CA. Ein Administrator kann
anhand des privaten Schlüssels und öffentlichen Z ertifikats das SSL-Schlüssel-Set eines jeden
Webservers generieren. Dieses CA-SSL-Schlüsselpaar muss sicher aufbewahrt werden. Sobald
die gesamte RHN-Infrastruktur von Servern einmal vollständig aufgesetzt ist, wird strengstens
empfohlen, dass Sie das SSL-Verzeichnis, das von diesem T ool angelegt wurde, auf einem
separaten Medium archivieren. Schreiben Sie ebenso das CA-Passwort auf und bewahren das
externe Speichermedium und das Passwort an einem sicheren Ort auf.
3.2. Das RHN SSL Maintenance Tool
Red Hat Network bietet ein Befehlszeilen-T ool an, um Ihnen das Management Ihrer sicheren
Infrastruktur zu erleichtern: das RHN SSL Maintenance T ool ist üblicherweise auch unter dem
Befehlsnamen rhn-ssl-tool bekannt. Dieses T ool ist als T eil des rhns-certs-tools-Pakets
erhältlich. Dieses Paket kann in den Software-Channels des neuesten RHN Proxy Server und RHN
Satellite Server (sowie auch das RHN Satellite Server ISO) gefunden werden. Das RHN SSL
Maintenance T ool ermöglicht es Ihnen, Ihr SSL-Schlüsselpaar Ihrer CA sowie auch Webserver SSLSchlüssel-Sets (manchmal auch als Schlüsselpaare bezeichnet) zu generieren.
Es handelt sich hierbei um ein reines Build-T ool. Es generiert alle erforderlichen SSL-Schlüssel und
Z ertifikate. Die Dateien werden zu einem Paket im RPM-Format zur raschen Verteilung und Installation
auf allen Client-Rechnern zusammengefasst. Jedoch werden diese vom T ool nicht zugeordnet. Dies
wird dem Administrator überlassen oder via RHN Satellite Server automatisiert.
Anmerkung
rhns-certs-tools, welches rhn-ssl-tool beinhaltet, kann auf jedem aktuellen Red Hat
Enterprise Linux System unter minimalen Voraussetzungen installiert und eingesetzt werden. Es
ist für Administratoren von Vorteil, die deren SSL-Infrastruktur von deren Arbeitsplatzrechnern
aus oder auch von anderen Systemen und nicht den RHN Servern aus verwalten möchten.
In diesen Fällen ist das T ool notwendig:
Wenn Sie Ihr öffentliches Z ertifikat Ihrer CA aktualisieren - dies ist äußerst selten der Fall.
Wenn Sie einen RHN Proxy Server Version 3.6 oder höher installieren, der sich mit den zentralen
11
RHN Servern verbindet - in diesem Fall kann der gehostete Service aus Sicherheitsgründen nicht als
Repository für den SSL-Schlüssel Ihrer CA und für Ihr Z ertifikat dienen.
Wenn Sie Ihre RHN-Infrastruktur neu konfigurieren, die zuvor kein SSL verwendet hat.
Wenn Sie RHN Proxy Server Versionen niedriger als 3.6 in Ihre Infrastruktur aufnehmen.
Wenn Sie mehrere RHN Satellite Server in Ihre RHN-Infrastruktur aufnehmen - konsultieren Sie in
diesem Fall einen Red Hat-Sachverständigen.
In diesen Fällen ist das T ool nicht erforderlich:
Während der Installation eines RHN Satellite Server - alle SSL-Einstellungen werden während des
Installationsvorgangs vorgenommen. Die SSL-Schlüssel und Z ertifikate werden automatisch
generiert und zugeordnet.
Während der Installation eines RHN Proxy Servers der Version 3.6 oder höher, wenn dieser mit
einem RHN Satellite Server Version 3.6 oder höher als dessen T op-Level-Service verbunden ist - der
RHN Satellite Server beinhaltet sämtliche SSL-Informationen, die dazu benötigt werden, die SSLSchlüssel und Z ertifikate des RHN Proxy Servers zu konfigurieren, zu generieren und zuzuordnen.
Beide Installationsvorgänge, der des RHN Satellite Servers und der des RHN Proxy Servers
gewährleisten, dass das öffentliche SSL-Z ertifikat der CA in jedem /pub-Verzeichnis eines jeden
Servers abgelegt wird. Dieses öffentliche Z ertifikat wird von den Client-Systemen dazu verwendet, sich
mit den RHN Servern zu verbinden. Siehe Abschnitt 3.3, „Das öffentliche SSL-Z ertifikat der CA auf
Clients implementieren“ für weitere Informationen.
Kurz gesagt, wenn Ihr Unternehmen die aktuellste Version des RHN Satellite Server als T op-LevelService einsetzt, dann werden Sie höchstwahrscheinlich das T ool nicht benötigen. Ansonsten sollten
Sie sich mit dessen Anwendung vertraut machen.
3.2.1. Erklärung zur SSL-Generierung
Der hauptsächliche Nutzen bei der Verwendung des RHN SSL Maintenance T ools liegt in der
Sicherheit, Flexibilität und Portabilität. Sicherheit wird durch die Erstellung eindeutiger Webserver SSLSchlüssel und Z ertifikate für jeden RHN Server gewährleistet, wobei alle von einem einzigen SSLSchlüsselpaar Ihrer CA signiert sind, das von Ihrem Unternehmen erstellt wurde. Flexibilität erhalten Sie
durch die Fähigkeit des T ools auf jeder Maschine eingesetzt werden zu können, die das rhns-certstools-Paket installiert hat. Portabilität liegt in der Build-Struktur, die überall aufbewahrt und im weiteren
Verlauf bei Bedarf installiert werden kann.
Wenn also in Ihrer Infrastruktur Ihr T op-Level RHN Server der aktuellste RHN Satellite Server ist, dann
ist das Wiederherstellen Ihres ssl-build-Baumes von einem Archiv in das /root-Verzeichnis alles
was Sie tun müssen. Machen Sie von den Konfigurations-T ools Gebrauch, die auf der Website des RHN
Satellite Server zur Verfügung gestellt werden.
Sie verwenden das RHN SSL Maintenance T ool am besten, indem Sie die folgenden Aufgaben in
ungefähr dieser Reihenfolge ausführen. Für die notwendigen Details verweisen wir auf die
verbleibenden Abschnitte:
1. Installieren Sie das rhns-certs-tools-Paket auf einem System in Ihrem Unternehmen. Dies
kann, muss aber nicht der RHN Satellite Server oder RHN Proxy Server sein.
2. Erzeugen Sie ein einzelnes SSL-Schlüsselpaar Ihrer CA für Ihr Unternehmen und installieren die
daraus resultierende RPM-Datei oder das öffentliche Z ertifikat auf allen Client-Systemen.
3. Erzeugen Sie ein Webserver SSL-Schlüssel-Set für jeden der Proxy-Server und Satellite-Server
und installieren die daraus resultierenden RPM-Dateien auf den Servern. Starten Sie
anschließend den httpd-Dienst neu:
12
/sbin/service httpd restart
4. Archivieren Sie den SSL-Build-Baum - bestehend aus dem primären Build-Verzeichnis und allen
Unterverzeichnissen und Dateien - auf externen, transportablen Medien, wie z.B. einer Diskette.
(Speicherplatzanforderungen sind vernachlässigbar.)
5. Überprüfen Sie das Archiv und bewahren es an einem sicheren Ort auf, wie beispielsweise in den
Abschnitten Zusätzliche Anforderungen des Proxy- oder auch Satellite-Installationshandbuchs
beschrieben.
6. Notieren Sie das CA-Passwort und bewahren Sie es für die zukünftige Verwendung auf.
7. Löschen Sie den Build-Baum aus Sicherheitsgründen vom Build-System, aber nur wenn die
gesamte RHN-Infrastruktur vorhanden und konfiguriert ist.
8. Wenn Sie zusätzliche Webser SSL-Schlüssel-Sets benötigen, dann stellen Sie den Build-Baum
auf einem System mit dem RHN SSL Maintenance T ool wieder her und wiederholen die Schritte
3 bis 7.
3.2.2. RHN SSL Maintenance Tool-Optionen
Das RHN SSL Maintenance T ool bietet eine Unmenge an Befehlszeilenoptionen zur Generierung
Ihres CA SSL-Schlüsselpaares und zur Verwaltung Ihrer Server SSL-Z ertifikate und -Schlüssel an. Das
T ool bietet grundsätzlich drei Befehlszeilenoptionen für zur Auflistung der Hilfe an: rhn-ssl-tool -help (allgemein), rhn-ssl-tool --gen-ca --help (Certificate Authority) und rhn-ssl-tool -gen-server --help (Webserver). Auch die Handbuchseite für 'rhn-ssl-tool' liefert eine detaillierte
Beschreibung: m an rhn-ssl-tool.
Die beiden untenstehenden T abellen unterteilen die Optionen nach Aufgaben, entweder CA oder
Webserver SSL-Schlüssel-Set-Generierung.
Diesen Optionen muss der --gen-ca-Parameter vorangestellt werden:
13
T abelle 3.1. SSL Certificate Authority (CA) Optionen (rhn-ssl-tool --gen-ca --help)
Option
Beschreibung
--gen-ca
Generiert ein Certificate Authority (CA)
Schlüsselpaar und ein öffentliches RPM.
Diese Option muss in Z usammenhang mit
irgendeiner der verbleibenden Optionen in
dieser T abelle benutzt werden.
-h, --help
Z eigt den Hilfebildschirm mit einer Liste von
Basisoptionen in Z usammenhang mit der
CA-Generierung und -Verwaltung an.
-f, --force
Erzwingt die Erzeugung eines neuen
privaten Schlüssels Ihrer CA und/oder
öffentlichen Z ertifikats.
-p=, --password=PASSWORD
Das CA-Passwort. Sie werden zur Eingabe
des Passworts aufgefordert, wenn Sie
dieses nicht von vornherein angeben.
Bewahren Sie eine Kopie des Passworts
an einem sicheren Ort auf.
-d=, --dir=BUILD_DIRECTORY
Für die meisten Befehle erforderlich - Das
Verzeichnis, in welches Z ertifikate und
RPM-Dateien beim Bauen gespeichert
werden. Standard ist ./ssl-build.
--ca-key=FILENAME
Der Dateiname des privaten Schlüssels
Ihrer CA. Standard ist RHN-ORGPRIVAT E-SSL-KEY.
--ca-cert=FILENAME
Der Dateiname des öffentlichen Z ertifikats
Ihrer CA. Standard ist RHN-ORGT RUST ED-SSL-CERT .
--cert-expiration=CA_CERT_EXPIRE
Die Gültigkeit des öffentlichen CAZ ertifikats. Standard ist das Ablaufen der
Gültigkeit einen T ag vor dem
Epochenwechsel (bzw. 18.01.2038).
--set-country=COUNTRY_CODE
Der zweistellige Ländercode. Standard ist
US.
--set-state=STATE_OR_PROVINCE
Der Staat oder das Bundesland des CAZ ertifikats. Standard ist ''.
--set-city=CITY_OR_LOCALITY
Die Stadt oder der Ort. Standard ist ''.
--set-org=ORGANIZATION
Die Firma oder das Unternehmen, wie
beispielsweise Red Hat. Standard ist
Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT
Die Unternehmenseinheit, wie
beispielsweise RHN. Standard ist ''.
--set-com m on-nam e=HOSTNAME
Üblicherweise nicht für die CA gesetzt. Der allgemeine Name.
--set-em ail=EMAIL
Üblicherweise nicht für die CA gesetzt. - Die
E-Mail-Adresse.
--rpm -packager=PACKAGER
Die Person, die das generierte RPM
paketiert hat, wie z.B. "RHN Admin (rhn-
14
admin@example.com)."
--rpm -vendor=VENDOR
Der Anbieter des generierten RPMs, wie
z.B. "IS/IT Example Corp."
-v, --verbose
Z eigt ausführliche Mitteilungen an.
Akkumulierend - weitere hinzugefügte "v"s
resultieren in noch umfangreicheren
Details.
--ca-cert-rpm =CA_CERT_RPM
Selten verändert - Name der RPM-Datei,
die das CA Z ertifikat beinhaltet (der BasisDateiname und nicht filename-versionrelease.noarch.rpm).
--key-only
Selten verwendet - Generiert nur einen
privaten CA-Schlüssel. Siehe --gen-ca -key-only --help für weitere
Informationen.
--cert-only
Selten verwendet - Generiert nur ein
öffentliches CA-Z ertifikat. Siehe --gen-ca
--cert-only --help für weitere
Informationen.
--rpm -only
Selten verwendet - Generiert nur ein RPM
zur Implementierung. Siehe --gen-ca -rpm -only --help für weitere
Informationen.
--no-rpm
Selten verwendet - Führt alle CA-Schritte
aus, bis auf die RPM-Generierung.
Den folgenden Optionen muss der --gen-server-Parameter vorangestellt werden:
15
T abelle 3.2. SSL Web-Server-Optionen (rhn-ssl-tool --gen-server --help)
Option
Beschreibung
--gen-server
Generiert SSL-Schlüssel-Set, RPM und
T ar-Archiv des Webservers. Diese Option
muss in Z usammenhang mit irgendeiner
der verbleibenden Optionen in dieser
T abelle benutzt werden.
-h, --help
Z eigt den Hilfebildschirm mit einer Liste von
Basisoptionen in Z usammenhang mit der
Generierung und Verwaltung eines ServerSchlüsselpaares an.
-p=, --password=PASSWORD
Das CA-Passwort. Sie werden zur Eingabe
des Passworts aufgefordert, wenn Sie
dieses nicht von vornherein angeben.
Bewahren Sie eine Kopie des Passworts
an einem sicheren Ort auf.
-d=, --dir=BUILD_DIRECTORY
Für die meisten Befehle erforderlich - Das
Verzeichnis, in welches Z ertifikate und
RPM-Dateien beim Bauen gespeichert
werden. Standard ist ./ssl-build.
--server-key=FILENAME
Der Dateiname des privaten SSLSchlüssels des Webservers.
Standardmäßig ist dies server.key.
--server-cert-req=FILENAME
Der Dateiname des SSL-Z ertifikats des
Webservers, das vom Client angefragt wird.
Standardmäßig ist dies server.csr.
--server-cert=FILENAME
Der Dateiname des SSL-Z ertifikats des
Webservers. Standardmäßig ist dies
server.crt.
--startdate=YYMMDDHHMMSSZ
Das Startdatum der Gültigkeit für das
Server-Z ertifikat im Beispielformat: Jahr,
Monat, Datum, Stunde, Minute, Sekunde
(zwei Z eichen pro Wert). Z ist erforderlich
und steht für Z ulu. Standardmäßig wird
dieses Datum auf eine Woche vor
Generierung gesetzt.
--cert-expiration=SERVER_CERT_EXPIRE
Das Ablaufdatum des Server-Z ertifikats.
Standardmäßig ist dies ein T ag vor dem
Epochenwechsel (oder 18.01.2038).
--set-country=COUNTRY_CODE
Der zweistellige Ländercode. Standard ist
US.
--set-state=STATE_OR_PROVINCE
Der Staat oder die Provinz. Der
Standardwert lautet North Carolina.
--set-city=CITY_OR_LOCALITY
Die Stadt oder der Ort. Der Standardwert
lautet Raleigh.
--set-org=ORGANIZATION
Die Firma oder Organisation, wie z.B. Red
Hat. Der Standardwert lautet 'Example
Corp. Inc.'
--set-org-unit=SET_ORG_UNIT
Die Unternehmenseinheit, wie
16
beispielsweise RHN. Standardmäßig ist
dies 'unit'.
--set-hostnam e=HOSTNAME
Der Hostname des RHN Servers, der den
Schlüssel erhält. Standardmäßig ist dies
der dynamisch gesetzte Hostname des
Build-Rechners.
--set-em ail=EMAIL
Die E-Mail-Adresse für den Kontakt bezügl.
des Z ertifikats. Der Standardwert lautet
'admin@example.com'.
--rpm -packager=PACKAGER
Die Person, die das generierte RPM
paketiert hat, wie z.B. "RHN Admin (rhnadmin@example.com)."
--rpm -vendor=VENDOR
Der Anbieter des generierten RPMs, wie
z.B. "IS/IT Example Corp."
-v, --verbose
Z eigt ausführliche Mitteilungen an.
Akkumulierend - weitere hinzugefügte "v"s
resultieren in noch umfangreicheren
Details.
--key-only
Selten verwendet - Generiert nur einen
privaten Server-Schlüssel. Siehe --genserver --key-only --help für weitere
Informationen.
--cert-req-only
Selten verwendet - Generiert nur eine
Anfrage für ein Server-Z ertifikat. Siehe -gen-server --cert-req-only -help für weitere Informationen.
--cert-only
Selten verwendet - Generiert nur ein
Server-Z ertifikat. Siehe --gen-server -cert-only --help für weitere
Informationen.
--rpm -only
Selten verwendet - Generiert nur eine
RPM-Datei zur Implementierung. Siehe -gen-server --rpm -only --help für
weitere Informationen.
--no-rpm
Selten verwendet - Führt alle Serverbezogenen Schritte mit Ausnahme der
RPM-Generierung durch.
--server-rpm =SERVER_RPM
Selten verändert - Name der RPM-Datei,
die das SSL-Schlüssel-Set des
Webservers beinhaltet (der BasisDateiname und nicht filename-versionrelease.noarch.rpm).
--server-tar=SERVER_TAR
Selten verändert - Name des .tar Archivs,
welches das Webserver SSL-Schlüssel-Set
und das öffentliche CA-Z ertifikat beinhaltet
und ausschließlich von den
Installationsroutinen des gehosteten RHN
Proxy Servers verwendet wird (der BasisDateiname und nicht filename-versionrelease.tar).
17
3.2.3. Das CA SSL-Schlüsselpaar generieren
Bevor Sie das SSL-Schlüssel-Set erzeugen, das vom Webserver benötigt wird, müssen Sie ein CA SSLSchlüsselpaar generieren. Ein öffentliches SSL-Z ertifikat der CA wird auf die Client-Systeme des
Satellite oder Proxy verteilt. Das RHN SSL Maintenance T ool ermöglicht es Ihnen im Bedarfsfall ein
CA SSL Schlüsselpaar zu generieren und dieses für alle nachträglichen Einsätze von RHN Servern
wiederzuverwenden.
Der Build-Prozess erzeugt automatisch das Schlüsselpaar und die öffentliche RPM für die Clients. Alle
CA-Komponenten gelangen in das Build-Verzeichnis, welches in der Befehlszeile angegeben wird und
normalerweise /root/ssl-build ist (oder /etc/sysconfig/rhn/ssl für ältere Satellites und
Proxys). Um ein CA SSL-Schlüsselpaar zu generieren, führen Sie einen Befehl wie diesen aus:
rhn-ssl-tool --gen-ca --password=MY_CA_PASSWORD --dir="/root/ssl-build" \
--set-state="North Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="SSL CA Unit"
Ersetzen Sie die Beispielwerte mit den jeweils für Ihr Unternehmen passenden Werten. Daraus
resultieren folgende, relevante Dateien im festgelegten Build-Verzeichnis:
RHN-ORG-PRIVAT E-SSL-KEY — der private SSL-Schlüssel der CA
RHN-ORG-T RUST ED-SSL-CERT — das öffentliche SSL-Z ertifikat der CA
rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm — die RPM-Datei, die zur Verteilung an die
Client-Systeme bestimmt ist. Diese beinhaltet das öffentliche SSL-Z ertifikat der CA und installiert es
in: /usr/share/rhn/RHN-ORG-T RUST ED-SSL-CERT
rhn-ca-openssl.cnf — die SSL CA Konfigurationsdatei
latest.txt — listet immer die aktuellsten Versionen der relevanten Dateien auf.
Nach Abschluss können Sie das RPM auf Client-Systeme verteilen. Werfen Sie dazu einen Blick auf
Abschnitt 3.3, „Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren“.
3.2.4. Webserver SSL-Schlüssel-Sets generieren
Obwohl Sie bereits ein SSL-Schlüsselpaar der CA besitzen müssen, werden Sie höchstwahrscheinlich
zukünftig des öfteren Webserver SSL-Schlüssel-Sets generieren, insbesondere, wenn mehr als ein
Proxy oder Satellite eingesetzt wird. Beachten Sie dabei bitte, dass der Wert für --set-hostnam e von
Server zu Server verschieden ist. In anderen Worten muss ein eindeutiger Satz an SSL-Schlüsseln und
-Z ertifikaten für jeden verschiedenen RHN Server-Hostnamen generiert und installiert werden.
Der Build-Prozess für das Server-Z ertifikat funktioniert mit einer Ausnahme ähnlich wie die Generierung
des CA SSL-Schlüsselpaars: Alle Server-Komponenten gelangen abschließend in die
Unterverzeichnisse des Build-Verzeichnisses, welche den Rechnernamen des Build-Systems
wiederspiegeln. Um Server-Z ertifikate zu generieren, führen Sie einen Befehl wie diesen aus:
rhn-ssl-tool --gen-server --password=MY_CA_PASSWORD --dir="/root/ssl-build" \
--set-state="North Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="IS/IT" --set-email="admin@example.com" \
--set-hostname="rhnbox1.example.com
Ersetzen Sie die Beispielwerte mit den jeweils für Ihr Unternehmen passenden Werten. Daraus
resultieren folgende, relevante Dateien in einem rechnerspezifischen Unterverzeichnis des BuildVerzeichnisses:
18
server.key — der private SSL Server-Schlüssel des Web-Servers
server.csr — die SSL-Z ertifikatsanfrage des Webservers
server.crt — das öffentliche SSL-Z ertifikat des Webservers
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm — die RPM-Datei, die
zur Verteilung auf den RHN Servern bestimmt ist. Die zugehörige src.rpm Datei wird auch generiert.
Diese RPM-Datei beinhaltet die drei oben genannten Dateien. Diese werden hier gespeichert:
/etc/httpd/conf/ssl.key/server.key
/etc/httpd/conf/ssl.csr/server.csr
/etc/httpd/conf/ssl.crt/server.crt
rhn-server-openssl.cnf — die SSL-Konfigurationsdatei des Webservers
latest.txt — listet immer die aktuellsten Versionen der relevanten Dateien auf.
Wenn Sie damit fertig sind, können Sie die RPM-Datei an den entsprechenden RHN Server verteilen und
installieren. Beachten Sie dabei, dass der httpd-Service nach der Installation neu gestartet werden
muss:
/sbin/service httpd restart
3.3. Das öffentliche SSL-Zertifikat der CA auf Clients
implementieren
Der RHN Proxy Server- sowie auch der RHN Satellite Server-Installationsprozess macht die
Implementierung auf Clients relativ simpel, indem ein öffentliches SSL-Z ertifikat der CA und eine RPMDatei generiert werden. Diese Installationsprozesse legen eine Kopie bzw. Kopien von beiden öffentlich
zugänglich im Verzeichnis /var/www/htm l/pub/ des RHN Servers ab.
Sie können einfach mit einem beliebigen Webbrowser dieses öffentliche Verzeichnis aufrufen und
dieses ansehen: http://proxy-or-sat.example.com/pub/.
Das öffentliche SSL-Z ertifikat der CA in diesem Verzeichnis kann auf ein Client-System heruntergeladen
werden, indem Sie wget oder curl verwenden. Z um Beispiel:
curl -O http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Wenn die RPM-Datei des öffentlichen SSL-Z ertifikats der CA sich im /pub/-Verzeichnis befindet, kann
diese auch direkt auf einem Client-System installiert werden:
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
Überprüfen Sie den tatsächlichen Namen des Z ertifikats oder der RPM-Datei, bevor Sie diese Befehle
ausführen.
3.4. Client-Systeme konfigurieren
Wenn die RPM-Datei oder das Rohdaten-Z ertifikat einmal auf einem Client-System implementiert wurde,
muss der Administrator dieses Systems die Konfigurationsdateien des Red Hat Update Agents und
des Red Hat Network Registration Clients verändern, um das neue öffentliche SSL-Z ertifikat der CA
verwenden und sich mit dem entsprechenden RHN Proxy Server oder RHN Satellite Server verbinden zu
19
können. Der allgemein anerkannte Speicherplatz für dieses öffentliche SSL-Z ertifikat der CA ist das
/usr/share/rhn-Verzeichnis.
RHN Proxy Server und RHN Satellite Server haben beide standardmäßig RHN Bootstrap installiert,
wodurch diese sich wiederholenden Schritte wesentlich reduziert werden können und auch der Prozess
der Registrierung und Konfiguration von Client-Systemen vereinfacht werden kann. Werfen Sie einen
Blick auf Kapitel 5, Verwendung von RHN Bootstrap für weitere Details.
20
Kapitel 4. Import angepasster GPG-Schlüssel
Kapitel 4. Import angepasster GPG-Schlüssel
Allen Kunden, die ihre eigenen RPM-Dateien sicher bauen und verteilen möchten, wird dringend
empfohlen, dass alle angepassten RPM-Dateien unter Verwendung von GNU Privacy Guard (GPG)
signiert sind. Das Generieren von GPG-Schlüsseln und das Bauen von GPG-signierten Paketen wird im
Red Hat Network Channel-Managementhandbuch genauer behandelt.
Wenn die Pakete einmal signiert sind, muss der öffentliche Schlüssel auf allen Systemen, die diese
RPM-Dateien importieren, vorhanden sein. Diese Aufgabe besteht aus zwei Schritten: zuerst muss der
öffentliche Schlüssel für alle Clients zugänglich gemacht werden und im zweiten Schritt muss dann der
Schlüssel dem lokalen GPG-Schlüsselring für jedes System hinzugefügt werden.
Der erste Schritt kommt häufig vor und kann unter Verwendung des empfohlenen Website-Verfahrens
zum Einsatz von RHN Client-Applikationen abgewickelt werden. (Siehe Abschnitt 2.1, „Die neuesten Red
Hat Network Client-RPMs einsetzen“.) Erstellen Sie hierfür ein öffentliches Verzeichnis auf dem
Webserver und legen dort die öffentliche GPG-Signatur ab:
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
Der Schlüssel kann dann von Client-Systemen mittels Wget heruntergeladen werden:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
Die -O--Option zeigt die Resultate auf der Standardausgabe an, während die -q-Option Wget im QuietModus, also ohne Bildschirmausgabe ablaufen lässt. Vergessen Sie nicht, die YOUR-RPM-GPG-KEYVariable mit dem Dateinamen Ihres Schlüssels zu ersetzen.
Wenn der Schlüssel einmal auf dem Client-Dateisystem vorhanden ist, dann importieren Sie ihn in den
lokalen GPG-Schlüsselring. Unterschiedliche Betriebssysteme erfordern dazu unterschiedliche
Verfahren.
Für Red Hat Enterprise Linux 3 oder höher wenden Sie folgenden Befehl an:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Für Red Hat Enterprise Linux 2.1 wenden Sie folgenden Befehl an:
gpg $(up2date --gpg-flags) --import /path/to/YOUR-RPM-GPG-KEY
Wenn der GPG-Schlüssel einmal erfolgreich dem Client hinzugefügt wurde, sollte das System in der
Lage sein, angepasste RPM-Dateien zu validieren, die mit dem dazu passenden Schlüssel signiert sind.
21
Kapitel 5. Verwendung von RHN Bootstrap
Red Hat Network liefert ein T ool, das viele Schritte der in vorhergehenden Kapiteln beschriebenen
manuellen Konfiguration automatisiert: RHN Bootstrap. Dieses T ool spielt eine wesentliche Rolle für
das RHN Satellite Server-Installationsprogramm und ermöglicht das Generieren des BootstrapSkripts während der Installation.
RHN Proxy Server-Kunden und Kunden mit aktualisierten Satellite-Einstellungen benötigen ein
Bootstrap-T ool, das eigenständig verwendet werden kann. RHN Bootstrap, das mit dem Befehl
/usr/bin/rhn-bootstrap aufgerufen wird, dient diesem Z weck und wird standardmäßig bereits auf
RHN Satellite Server und RHN Proxy Server installiert ausgeliefert.
Das Skript, das von diesem T ool generiert wird, kann auf jedem Client ausgeführt werden, um folgende
Aufgaben auszuführen:
Client-Applikationen auf den RHN Proxy oder Satellite umlenken
Angepasste GPG-Schlüssel importieren
SSL-Z ertifikate installieren
Das System bei RHN und speziellen Systemgruppen und Channels mithilfe von
Aktivierungsschlüsseln anmelden
Unterschiedliche Post-Konfigurationsaktivitäten, wie u.a. das Aktualisieren von Paketen, das
Neustarten und das Verändern der RHN-Konfiguration
Kunden sollten dabei jedoch auch die potenziellen Risiken bei der Verwendung eines
Konfigurationsskripts im Auge behalten. Sicherheits-T ools, wie beispielsweise ein SSL-Z ertifikat, werden
vom Skript selbst installiert. Deshalb befinden sich diese noch nicht auf dem System und können
deshalb auch nicht zur Abwicklung von Arbeitsvorgängen verwendet werden. Dies ermöglicht es
allerdings, dass sich jemand als Satellite ausgibt und unerwünschte Daten überträgt. Dieses Risiko wird
dadurch etwas eingedämmt, indem beinahe alle Satellite-Server und Client-Systeme hinter KundenFirewalls operieren und nur für bestimmten Datenverkehr von außen zugänglich sind. Die Anmeldung
wird via SSL durchgeführt und läuft daher geschützt ab.
Das Bootstrap-Skript bootstrap.sh wird automatisch im Verzeichnis
/var/www/htm l/pub/bootstrap/ des RHN Servers abgelegt. Von hier aus kann es
heruntergeladen werden und auf allen Client-Systemen ablaufen. Beachten Sie bitte dabei, dass eine
gewisse Vorbereitung und eine Bearbeitung nach der Installation notwendig ist, wie in den folgenden
Abschnitten beschrieben. Werfen Sie einen Blick auf Abschnitt 5.4, „RHN Bootstrap Optionen“ für eine
vollständige Liste der Optionen dieses T ools. Außderdem finden Sie in Anhang A, Beispiel für ein
Bootstrap-Skript ein Beispielskript.
5.1. Vorbereitung
Da RHN Bootstrap (rhn-bootstrap) von anderen Komponenten der Red Hat Network-Infrastruktur
abhängig ist, um Client-Systeme einwandfrei zu konfigurieren, müssen diese Komponenten noch vor der
Skriptgenerierung vorbereitet werden. Die folgende Liste enthält Vorschläge für erste Maßnahmen:
Generieren Sie Aktivierungsschlüssel, die vom Skript/von den Skripten aufgerufen werden. Sie
können Aktivierungsschlüssel in einem Z ug zur Registrierung von Red Hat Enterprise LinuxSystemen verwenden, Berechtigungen an diese Systeme für einen RHN-Servicelevel vergeben und
diese bei speziellen Channels und Systemgruppen anmelden. Beachten Sie dabei, dass Sie noch
verfügbare Management-Berechtigungen besitzen müssen, um einen Aktivierungsschlüssel
verwenden zu können. Bei der Einbindung von mehreren Aktivierungsschlüsseln gleichzeitig werden
Provisioning-Berechtigungen benötigt. Generieren Sie Aktivierungsschlüssel auf der
22
Aktivierungsschlüssel-Seite innerhalb der System e-Kategorie der RHN-Website (entweder die
zentralen RHN Server für Proxy oder der Fully Qualified Domain Name des Satellite). Siehe die Red
Hat Update Agent- und RHN-Website-Kapitel des RHN Referenzhandbuchs für weitere Instruktionen
zur Erstellung und Anwendung der Schlüssel.
Red Hat empfiehlt, dass Sie Ihre RPMs mit Ihrem eigenen GNU Privacy Guard (GPG) Schlüssel
signieren. Platzieren Sie den Schlüssel so, dass Sie vom Skript aus darauf verweisen können.
Generieren Sie den Schlüssel wie im RHN Channel-Managementhandbuch beschrieben und legen
den Schlüssel im Verzeichnis /var/www/htm l/pub/ des RHN Servers ab, wie in Kapitel 4, Import
angepasster GPG-Schlüssel.
Wenn Sie das Skript zum Einsetzen Ihres öffentlichen CA-SSL-Z ertifikats verwenden möchten, muss
sich das Z ertifikat oder das Paket (RPM), welches das Z ertifikat enthält, auf diesem RHN Server
befinden. Während der Generierung des Skripts können Sie mittels der --ssl-cert-Option das
Z ertifikat mitaufnehmen. Siehe Kapitel 3, SSL-Infrastruktur für nähere Details.
Legen Sie sich die Werte zurecht, um eines oder mehrere Bootstrap-Skripte erstellen, abhängig von
der Vielfalt verschiedener System, die es zu konfigurieren gilt. Da RHN Bootstrap eine Vielzahl an
Konfigurationsoptionen anbietet, kann es dazu verwendet werden, unterschiedliche BootstrapSkripte zu generieren, um jede Art von System zu berücksichtigen. Beispielsweise kann
bootstrap-web-servers.sh dazu verwendet werden, Webserver zu rekonfigurieren,
wohingegen bootstrap-app-servers.sh für die Applikationsserver zuständig ist. Werfen Sie
einen Blick auf Abschnitt 5.4, „RHN Bootstrap Optionen“ für eine vollständige Liste.
5.2. Generierung
Da nunmehr alle notwendigen Komponenten vorhanden sind, können Sie RHN Bootstrap dazu
verwenden, die erforderlichen Skripte zu generieren. Melden Sie sich dazu bei Ihrem RHN Satellite
Server oder RHN Proxy Server als 'root' an und führen den rhn-bootstrap Befehl gefolgt von den
gewünschten Optionen und Werten aus. Wenn keine Optionen angegeben sind, wird standardmäßig
eine bootstrap.sh-Datei erstellt und im bootstrap/-Unterverzeichnis abgelegt. Diese enthält die
wesentlichen und erforderlichen vom Server abgeleiteten Werte, wie beispielsweise das SSL-Z ertifikat,
falls vorhanden, SSL und GPG Einstellungen sowie einen Aufruf für die client-configoverrides.txt-Datei.
Red Hat empfiehlt dringend, dass Sie mindestens Aktivierungsschlüssel, GPG-Schlüssel und erweiterte
Konfigurationsoptionen in Ihre Skripte aufnehmen:
Verwenden Sie die --activation-keys-Option, um Schlüssel unter Berücksichtigung der
erforderlichen Berechtigungen einzubinden, wie in Abschnitt 5.1, „Vorbereitung“ beschrieben.
Verwenden Sie die --gpg-key-Option, um Schlüsselpfad und Dateiname während der
Skriptgenerierung festzulegen. Andernfalls verwenden Sie die --no-gpg-Option, um diese
Verifizierung auf Client-Systemen abzuschalten. Red Hat empfiehl, diese Sicherheitsmaßnahme
beizubehalten.
Fügen Sie die --allow-config-actions-Option ein, um Konfigurationsmanagement von Remote
aus auf allen vom Skript betroffenen Client-Systemen zu ermöglichen. Dieses Feature ist nützlich für
die gleichzeitige Rekonfiguration von mehren Systemen.
Fügen Sie die --allow-rem ote-com m ands-Option ein, um die Skriptanwendung von Remote aus
auf allen Client-Systemen zu ermöglichen. Wie das Konfigurationsmanagement hilft dieses Feature
bei der Rekonfiguration mehrerer Systeme.
Wenn Sie fertig sind, sieht Ihr Befehl in etwa wie folgt aus:
23
rhn-bootstrap --activation-keys KEY1,KEY2 \
--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
--allow-config-actions \
--allow-remote-commands
Fügen Sie die tatsächlichen Schlüsselnamen ein. Siehe Abschnitt 5.4, „RHN Bootstrap Optionen“ für
eine vollständige Liste aller Optionen.
5.3. Verwendung des Skripts
Wenn Sie die Vorbereitung für das Skript abgeschlossen haben, dann können Sie es auch schon
ablaufen lassen. Melden Sie sich dazu beim RHN Satellite Server oder RHN Proxy Server an, gehen zum
/var/www/htm l/pub/bootstrap/-Verzeichnis und führen folgenden Befehl aus, wobei Sie den
Hostnamen und den Namen des Skripts entsprechend dem jeweiligen Systemtyp abändern:
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Eine weniger sichere Alternative ist entweder die Verwendung von wget oder curl, um ein Skript
aufzurufen und von jedem Client-System ablaufen zu lassen. Melden Sie sich bei jeder Client-Maschine
an und geben folgenden Befehl ein, wobei Sie Skript und Hostname dementsprechend abändern:
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Oder mit curl:
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Wenn dieses Skript auf jedem Client-System ausgeführt wurde, sollte alles zur Verwendung des RHN
Servers konfiguriert sein.
5.4. RHN Bootstrap Optionen
Das RHN Bootstrap bietet viele Befehlszeilenoptionen für die Erstellung von Bootstrap-Skripten für
Client-Systeme. Obwohl die Beschreibungen dieser Optionen in der nachfolgenden T abelle aufgeführt
sind, sollten Sie sicher gehen, dass diese auch in der Version des T ools vorhanden sind, welches auf
Ihrem RHN Server installiert ist. Führen Sie dazu einfach den Befehl rhn-bootstrap --help aus
oder vergewissern sich auf der Handbuchseite.
24
T abelle 5.1. RHN Bootstrap Optionen
Option
Beschreibung
-h, --help
Anzeige des Hilfebildschirms mit einer
Liste von Optionen, die spezifisch für
das Bootstrap-Skript sind.
--activation-keys=ACTIVATION_KEYS
Aktivierungsschlüssel, wie auf der
RHN-Website festgelegt (mit
mehrfachen, durch Kommas und
keinem Leerzeichen getrennten
Einträgen)
--overrides=OVERRIDES
Dateiname der KonfigurationsOverrides. Standard ist client-configoverrides.txt.
--script=SCRIPT
Der Dateiname des Bootstrap-Skripts.
Der Standardwert lautet bootstrap.sh.
--hostnam e=HOSTNAME
Der FQDN des Servers (Fully Qualified
Domain Name), mit dem sich der ClientServer verbindet.
--ssl-cert=SSL_CERT
Der Pfad zum öffentlichen SSLZ ertifikats Ihres Unternehmens,
entweder ein Paket oder Rohdaten.
Dieses wird zur --pub-tree-Option
kopiert. Der Wert "" erzwingt eine
Suche von --pub-tree.
--gpg-key=GPG_KEY
Der Pfad zum öffentlichen GPGSchlüssel Ihrer Organisation, falls
verwendet. Dieser wird an die Position
kopiert, die durch die Option --pubtree festgelegt wird.
--http-proxy=HTTP_PROXY
Die HT T P-Proxy-Einstellung für das
Client-System als hostnam e:port.
Der Wert "" deaktiviert diese
Einstellung.
--http-proxy-usernam e=HTTP_PROXY_USERNAME
Wenn Sie einen authentifizierenden
HT T P-Proxy verwenden, geben Sie
einen Benutzernamen an. Der Wert ""
deaktiviert diese Einstellung.
--http-proxy-password=HTTP_PROXY_PASSWORD
Wenn Sie einen authentifizierenden
HT T P-Proxy verwenden, geben Sie ein
Passwort an.
--allow-config-actions
Boolesche Variable. Durch diese
Option kann das System alle
Konfigurationsabläufe via RHN
durchführen. Dies erfordert die
Installation bestimmter rhncfg-*-Pakete,
möglicherweise durch einen
Aktivierungsschlüssel.
--allow-rem ote-com m ands
Boolesche Variable. Durch diese
Option erlaubt das System beliebige
25
Befehle von Remote aus via RHN. Dies
erfordert die Installation bestimmter
rhncfg-*-Pakete, möglicherweise durch
einen Aktivierungsschlüssel.
--no-ssl
Nicht empfohlen - Boolesche Variable.
Diese Option schaltet SSL auf dem
Client-System ab.
--no-gpg
Diese Option schaltet die GPGÜberprüfung auf dem Client-System ab.
--no-up2date
Diese Option veranlasst, dass
up2date nicht mehr abläuft, sobald
Bootstrapping auf dem System
durchgeführt worden ist.
--pub-tree=PUB_TREE
Änderung nicht empfohlen - Der
öffentliche Verzeichnisbaum, in dem
das CA SSL-Z ertifikat und Paket
abgelegt werden; das BootstrapVerzeichnis und Skripte. Standard ist
/var/www/htm l/pub/.
--force
Diese Option erzwingt die Bootstrap
Skript-Generierung trotz Warnungen.
-v, --verbose
Ausführliche Mitteilungen anzeigen.
Akkumulierend (Sammelmeldungen). vvv hat sehr ausführliche Mitteilungen
zur Folge.
26
Kapitel 6. Manuelles Erstellen der Konfiguration
Kapitel 6. Manuelles Erstellen der Konfiguration
Beachten Sie, dass dieses Kapitel eine Alternative zur Verwendung von RHN Bootstrap aufzeigt, um
das Bootstrap-Skript zu generieren. Mit diesen Anweisungen sollten Sie in der Lage sein, Ihr eigenes
Bootstrap-Skript von Grund auf zu erstellen.
Alle der anfänglichen Verfahren hatten eines gemeinsam: die Bereitstellung notwendiger Dateien an
einem zentralen Ort, wo diese mittels einfachen, skriptfähigen Befehlen, die auf jedem Client ausgeführt
werden, abgefragt und installiert werden können. In diesem Kapitel fügen wir alle dieser Einzelteile
zusammen und erstellen ein einziges Skript, welches von jedem System in Ihrem Unternehmen
aufgerufen werden kann.
Wenn wir alle Befehle aus den vorhergehenden Kapiteln in der vernünftigsten Reihenfolge kombinieren,
erhalten wir das folgende Skript. Beachten Sie, dass rhn_register unter Red Hat Enterprise Linux 3
oder 4 nicht existiert:
# First, install the latest client RPMs to the system.
rpm -Uvh \
http://proxy-or-sat.example.com.com/pub/rhn_register-2.8.27-1.7.3.i386.rpm \
http://proxy-or-sat.example.com.com/pub/rhn_register-gnome-2.8.27-1.7.3.i386.rpm
\
http://proxy-or-sat.example.com.com/pub/up2date-3.0.7-1.i386.rpm \
http://proxy-or-sat.example.com.com/pub/up2date-gnome-3.0.7-1.i386.rpm
# Second, reconfigure the clients to talk to the correct server.
perl -p -i -e 's/s/www\.rhns\.redhat\.com/proxy-or-sat\.example\.com/g' \
/etc/sysconfig/rhn/rhn_register \
/etc/sysconfig/rhn/up2date
# Third, install the SSL client certificate for your company's
# RHN Satellite Server or RHN Proxy Server.
rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-*.noarch.rpm
# Fourth, reconfigure the clients to use the new SSL certificate.
perl -p -i -e 's/^sslCA/#sslCA/g;' \
/etc/sysconfig/rhn/up2date /etc/sysconfig/rhn/rhn_register
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
>> /etc/sysconfig/rhn/up2date
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
>> /etc/sysconfig/rhn/rhn_register
# Fifth, download the GPG key needed to validate custom packages.
wget -O - -q http://proxy-or-sat.example.com.com/pub/YOUR-RPM-GPG-KEY
# Sixth, import that GPG key to your GPG keyring.
rpm --import /path/to/YOUR-RPM-GPG-KEY
Beachten Sie, dass der sechste Schritt hier dokumentiert ist, weil er Systeme betrifft, auf denen Red Hat
Linux 3 oder neuer läuft.
Das Skript enthält einen klaren und wiederholbaren Prozess, der jeden potenziellen Red Hat NetworkClient in Vorbereitung auf die Registrierung mit einem RHN Proxy Server oder RHN Satellite Server
komplett konfigurieren sollte. Vergessen Sie dabei nicht, dass die Schlüsselwerte, wie z.B. die URL Ihres
RHN Servers, dessen öffentliches Verzeichnis und Ihr GPG-Schlüssel in die Platzhalter des Skripts
27
eingefügt werden müssen. Abhängig von Ihrer Umgebung kann es auch vorkommen, dass zusätzliche
Modifikationen benötigt werden. Obwohl das Skript exakt in der gezeigten Form funktionieren könnte,
sollte es in der Regel doch nur als Richtlinie angesehen werden.
Wie dessen Komponenten kann auch dieses Skript lokal abgelegt werden. Indem dieses Skript im
/pub/-Verzeichnis des Servers abgelegt wird, darauf wget -O- ausgeführt wird und die Ausgabe in
eine Shell-Session gepipt wird, kann man den gesamten Bootstrap-Prozess mit einem einzigen Befehl
von jedem Client aus ablaufen lassen:
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash
Warnung
Ein Shell-Skript ablaufen zu lassen, dessen Eingabe direkt über eine Internetverbindung gepipt
wurde, bringt natürlich potenzielle Sicherheitsrisiken mit sich. Deshalb ist es dringend notwendig,
in diesem Fall die Sicherheit des Quell-Servers sicherzustellen.
Dieser einzeilige Befehl kann dann auf allen Systemen innerhalb eines Netzwerks aufgerufen werden.
Falls der Administrator SSH-Z ugriff auf alle Systeme besitzt, die in Frage kommen, wäre es eine leichte
Aufgabe, automatisch eine Liste dieser Systeme abzuarbeiten und den Befehl von Remote aus auf allen
auszuführen. Dieses Skript wäre eine perfekte Ergänzung zum %post-Abschnitt eines existierenden
Kickstart-Skripts.
28
Kapitel 7. Implementieren von Kickstart
Offensichtlich ist es am besten, Konfigurationsänderungen auf einem System durchzuführen, wenn
dieses System zum ersten Mal eingerichtet wird. Für Kunden, die Kickstart bereits effektiv einsetzen,
stellt das Bootstrapping-Skript eine ideale Ergänzung zu diesem Prozess dar.
Wenn alle Konfigurationsfragen einmal abgeklärt wurden, kann ein System sich auch bei den lokalen
Red Hat Network-Servern unter Verwendung des rhnreg_ks-Dienstprogramms aus den RPMs
up2date und rhn_register anmelden. Dieses Kapitel behandelt die korrekte Anwendung von
rhnreg_ks, um Systeme zu registrieren.
Das rhnreg_ks-Dienstprogramm verwendet Aktivierungsschlüssel, um Systeme zu registrieren, an
diese Berechtigungen zu vergeben und diese bei bestimmten Channels anzumelden. Um mehr über
Aktivierungsschlüssel zu erfahren, werfen Sie einen Blick auf die Kapitel über den Red Hat Update
Agent und die RHN-Website im Red Hat Network Management Referenzhandbuch.
Die folgende, kommentierte Kickstart-Datei ist eine ideales Beispiel dafür, wie ein System von Anfang bis
Ende unter Verwendung von Red Hat Network konfiguriert werden kann.
29
# Generic 7.2 kickstart for laptops in the Widget Corporation (widgetco)
# Standard kickstart options for a network-based install. For an
# explanation of these options, consult the Red Hat Linux Customization
# Guide.
lang en_US
langsupport --default en_US en_US
keyboard defkeymap
network --bootproto dhcp
install
url --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386
zerombr yes
clearpart --all
part /boot --size 128 --fstype ext3 --ondisk hda
part /
--size 2048 --grow --fstype ext3 --ondisk hda
part /backup --size 1024 --fstype ext3 --ondisk hda
part swap --size 512 --ondisk hda
bootloader --location mbr
timezone America/New_York
rootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.
auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \
--krb5adminserver auth.widgetco.com
mouse --emulthree genericps/2
xconfig --card "S3 Savage/MX" --videoram 8192 --resolution 1024x768 \
--depth 16 --defaultdesktop=GNOME --startxonboot --noprobe \
--hsync 31.5-48.5 --vsync 40-70
reboot
# Define a standard set of packages. Note: Red Hat Network client
# packages are found in Base. This is quite a minimal set of packages;
# your mileage may vary.
%packages
@ Base
@ Utilities
@ GNOME
@ Laptop Support
@ Dialup Support
@ Software Development
@ Graphics and Image Manipulation
@ Games and Entertainment
@ Sound and Multimedia Support
# Now for the interesting part.
%post
( # Note that we run the entire %post section as a subshell for logging.
#
#
#
#
Remember that nifty one-line command for the bootstrap script that we
went through? This is an ideal place for it. And assuming that the
script has been properly configured, it should prepare the system
fully for usage of local Red Hat Network Servers.
wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash
# The following is an example of the usage of rhnreg_ks, the kickstart
# utility for rhn_register. This demonstrates the usage of the
30
#
#
#
#
#
#
#
#
--activationkey flag, which describes an activation key. For example,
this activation key could be set up in the Web interface to join this
system to the "Laptops" group and the local Widgetco "Laptop Software"
channel. Note that this section applies only to Proxy users, as this
step is handled by the Satellite bootstrap script.
For more information about activation keys, consult the Red Hat Network
Management Reference Guide.
/usr/sbin/rhnreg_ks --activationkey=6c933ea74b9b002f3ac7eb99619d3374
# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1
31
Beispiel für ein Bootstrap-Skript
Das vom RHN Satellite Server-Installationsprogramm generierte
/var/www/htm l/pub/bootstrap/bootstrap.sh-Skript bietet die Möglichkeit, Client-Systeme neu
zu konfigurieren, um auf Ihren RHN Server auf einfache Weise zugreifen zu können. Dieses Skript ist für
RHN Satellite Server sowie auch RHN Proxy Server-Kunden durch das RHN Bootstrap-T ool erhältlich.
Nachdem Sie das Skript für Ihre spezielle Verwendung modifiziert haben, kann es auf jedem ClientRechner ablaufen.
Werfen Sie für weitere Details einen Blick auf das Beispielskript und die Kommentare, die mit einem
Rautezeichen (#) beginnen. Folgen Sie den in Kapitel 5, Verwendung von RHN Bootstrap angeführten
Schritten, um das Skript einsatzbereit zu machen.
32
#!/bin/bash
echo "RHN Server Client bootstrap script v3.6"
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
This file was autogenerated. Minor manual editing of this script (and
possibly the client-config-overrides.txt file) may be necessary to complete
the bootstrap setup. Once customized, the bootstrap script can be triggered
in one of two ways (the first is preferred):
(1) centrally, from the RHN Server via ssh (i.e., from the
RHN Server):
cd /var/www/html/pub/bootstrap/
cat bootstrap-<edited_name>.sh | ssh root@<client-hostname> /bin/bash
...or...
(2) in a decentralized manner, executed on each client, via wget or curl:
wget -qOhttps://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
| /bin/bash
...or...
curl -Sks
https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
| /bin/bash
# SECURITY NOTE:
# Use of these scripts via the two methods discussed is the most expedient
# way to register machines to your RHN Server. Since "wget" is used
# throughout the script to download various files, a "Man-in-the-middle"
# attack is theoretically possible.
#
# The actual registration process is performed securely via SSL, so the risk
# is minimized in a sense. This message merely serves as a warning.
# Administrators need to appropriately weigh their concern against the
# relative security of their internal network.
# PROVISIONING/KICKSTART NOTE:
# If provisioning a client, ensure the proper CA SSL public certificate is
# configured properly in the post section of your kickstart profiles (the
# RHN Satellite or hosted web user interface).
# UP2DATE/RHN_REGISTER VERSIONING NOTE:
# This script will not work with very old versions of up2date and
# rhn_register.
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
"MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"
"If this bootstrap script was created during the initial installation"
"of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
"probably *not* be set (see below). If this is the case, please do the"
"following:"
" - copy this file to a name specific to its use."
" (e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
" - on the website create an activation key or keys for the system(s) to"
" be registered."
" - edit the values of the VARIABLES below (in this script) as"
" appropriate:"
33
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
exit
"
"
"
"
- ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
from the website. XKEY or XKEY,YKEY"
- ORG_GPG_KEY needs to be set to the name of the corporate public"
GPG key filename (residing in /var/www/html/pub) if appropriate."
"Verify that the script variable settings are correct:"
" - CLIENT_OVERRIDES should be only set differently if a customized"
"
client-config-overrides-VER.txt file was created with a different"
"
name."
" - ensure the value of HOSTNAME is correct."
" - ensure the value of ORG_CA_CERT is correct."
"Enable this script: comment (with #'s) this block (or, at least just"
"the exit below)"
1
# can be edited, but probably correct (unless created during initial install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=insert_activation_key_here
ORG_GPG_KEY=insert_org_gpg_pub_key_here
# can be edited, but probably correct:
CLIENT_OVERRIDES=client-config-overrides.txt
HOSTNAME=your_rhn_server_host.example.com
ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT
ORG_CA_CERT_IS_RPM_YN=0
USING_SSL=1
USING_GPG=1
REGISTER_THIS_BOX=1
ALLOW_CONFIG_ACTIONS=0
ALLOW_REMOTE_COMMANDS=0
FULLY_UPDATE_THIS_BOX=1
#
# ----------------------------------------------------------------------------# DO NOT EDIT BEYOND THIS POINT ----------------------------------------------# ----------------------------------------------------------------------------#
# an idea from Erich Morisse (of Red Hat).
# use either wget *or* curl
# Also check to see if the version on the
# machine supports the insecure mode and format
# command accordingly.
if [ -x /usr/bin/wget ] ; then
output=`/usr/bin/wget --no-check-certificate 2>&1`
error=`echo $output | grep "unrecognized option"`
if [ -z "$error" ] ; then
FETCH="/usr/bin/wget -q -r -nd --no-check-certificate"
else
FETCH="/usr/bin/wget -q -r -nd"
fi
else
34
if [ -x /usr/bin/curl ] ; then
output=`/usr/bin/curl -k 2>&1`
error=`echo $output | grep "is unknown"`
if [ -z "$error" ] ; then
FETCH="/usr/bin/curl -SksO"
else
FETCH="/usr/bin/curl -SsO"
fi
fi
fi
HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pub
HTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pub
if [ $USING_SSL -eq 0 ] ; then
HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}
fi
echo
echo "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"
echo "-------------------------------------------------"
echo "* downloading necessary files"
echo " client_config_update.py..."
rm -f client_config_update.py
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.py
echo " ${CLIENT_OVERRIDES}..."
rm -f ${CLIENT_OVERRIDES}
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/${CLIENT_OVERRIDES}
if [ !
echo
exit
fi
if [ !
echo
exit
fi
-f "client_config_update.py" ] ; then
"ERROR: client_config_update.py was not downloaded"
1
-f "${CLIENT_OVERRIDES}" ] ; then
"ERROR: ${CLIENT_OVERRIDES} was not downloaded"
1
echo "* running the update scripts"
if [ -f "/etc/sysconfig/rhn/rhn_register" ] ; then
echo " . rhn_register config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/rhn_register \
${CLIENT_OVERRIDES}
fi
echo " . up2date config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/up2date \
${CLIENT_OVERRIDES}
if [ ! -z "$ORG_GPG_KEY" ] ; then
echo
echo "* importing organizational GPG key"
rm -f ${ORG_GPG_KEY}
$FETCH ${HTTPS_PUB_DIRECTORY}/${ORG_GPG_KEY}
# get the major version of up2date
res=$(rpm -q --queryformat '%{version}' up2date | sed -e 's/\..*//g')
if [ $res -eq 2 ] ; then
gpg $(up2date --gpg-flags) --import $ORG_GPG_KEY
else
rpm --import $ORG_GPG_KEY
fi
fi
35
echo
echo "* attempting to install corporate public CA cert"
if [ $USING_SSL -eq 1 ] ; then
if [ $ORG_CA_CERT_IS_RPM_YN -eq 1 ] ; then
rpm -Uvh ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
else
rm -f ${ORG_CA_CERT}
$FETCH ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
mv ${ORG_CA_CERT} /usr/share/rhn/
fi
fi
echo
echo "REGISTRATION"
echo "------------"
# Should have created an activation key or keys on the RHN Server's
# website and edited the value of ACTIVATION_KEYS above.
#
# If you require use of several different activation keys, copy this file and
# change the string as needed.
#
if [ -z "$ACTIVATION_KEYS" ] ; then
echo "*** ERROR: in order to bootstrap RHN clients, an activation key or keys"
echo "
must be created in the RHN web user interface, and the"
echo "
corresponding key or keys string (XKEY,YKEY,...) must be mapped to"
echo "
the ACTIVATION_KEYS variable of this script."
exit 1
fi
if [ $REGISTER_THIS_BOX -eq 1 ] ; then
echo "* registering"
/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
echo
echo "*** this system should now be registered, please verify ***"
echo
else
echo "* explicitely not registering"
fi
echo
echo "OTHER ACTIONS"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
echo "up2date up2date; up2date -p; up2date -uf (conditional)"
else
echo "up2date up2date; up2date -p"
fi
echo "but any post configuration action can be added here. "
echo "------------------------------------------------------"
echo "* completely updating the box"
else
echo "* ensuring up2date itself is updated"
fi
/usr/sbin/up2date up2date
/usr/sbin/up2date -p
/usr/sbin/up2date -uf
fi
echo "-bootstrap complete-"
36
37
Versionsgeschichte
Version 1-3.4 00
Rebuild with publican 4.0.0
2013-10-31
Rüdiger Landmann
Version 1-3
Rebuild for Publican 3.0
2012-07-18
Anthony T owns
Version 1-7
Fri Feb 27 2009
Stichwortverzeichnis
Symbole
--configure
- Verwendung, Die up2date --configure-Option
A
Aktivierungsschlüssel
- Registrieren mit Aktivierungsschlüsseln, Registrieren mit Aktivierungsschlüsseln
B
bootstrap.sh
- Beispieldatei, Beispiel für ein Bootstrap-Skript
- Vorbereitung und Verwendung, Verwendung von RHN Bootstrap
C
Client-Applikationen
- Installation, Die neuesten Red Hat Network Client-RPMs einsetzen
- Konfiguration, Client-Applikationen konfigurieren
Client-Konfiguration
- Red Hat Update Agent , Die up2date --configure-Option
G
GPG-Schlüssel
- importieren, Import angepasster GPG-Schlüssel
K
Kickstart
38
Versionsgeschichte
- Verwendung, Implementieren von Kickstart
Konfiguration
- manuell, Die Konfigurationsdateien manuell aktualisieren
- Server-Ausfallsicherheit, Server-Ausfallsicherung implementieren
- Vollständiges Skripting, Manuelles Erstellen der Konfiguration
R
Red Hat Network Alert Notification T ool
- Konfiguration für Satellite, Das Red Hat Network Alert Notification T ool für Satellite
konfigurieren
Red Hat Update Agent
- Konfiguration zur Verwendung von RHN Proxy Server oder RHN Satellite Server, Die
Konfigurationsdateien manuell aktualisieren
RHN Bootstrap
- Befehlszeilenoptionen, RHN Bootstrap Optionen
- das Skript generieren, Generierung
- das Skript verwenden, Verwendung des Skripts
- verwenden, Verwendung von RHN Bootstrap
- vorbereiten, Vorbereitung
RHN SSL Maintenance T ool
- die CA generieren, Das CA SSL-Schlüsselpaar generieren
- Erklärung zur Generierung, Erklärung zur SSL-Generierung
- Optionen, RHN SSL Maintenance T ool-Optionen
- rhn-ssl-tool , Das RHN SSL Maintenance T ool
- Server-Z ertifikat generieren, Webserver SSL-Schlüssel-Sets generieren
rhn-ssl-tool
- die CA generieren, Das CA SSL-Schlüsselpaar generieren
- Erklärung zur Generierung, Erklärung zur SSL-Generierung
- Optionen, RHN SSL Maintenance T ool-Optionen
- RHN SSL Maintenance T ool , Das RHN SSL Maintenance T ool
- Server-Z ertifikat generieren, Webserver SSL-Schlüssel-Sets generieren
S
SSL (Secure Sockets Layer)
- Einführung, Eine kurze Einführung in SSL
SSL-Z ertifikate
- Generierung, Das RHN SSL Maintenance T ool
- Installation, Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren
39
Installation, Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren
- Konfiguration, Client-Systeme konfigurieren
40

Red Hat Network Satellite 5.4 Client

Transcription

Similar documents

REX 300 Handbuch

Jahresbericht 2015

Red Hat Network Satellite 5.4 Referenzhandbuch

Lizenzvereinbarungen

service center handbuch

Smart-Card-Anwendungen am Fachbereich

Erteilung einer Vollmacht