Red Hat Network Satellite 5.4 Client- Konfigurationshandbuch. Red Hat Network Satellite

Transkript

1 Red Hat Network Satellite 5.4 Client- Konfigurationshandbuch Red Hat Network Satellite

2 Client-Konfigurationshandbuch Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch Red Hat Network Satellite Ausgabe 1 Copyright 2010 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. 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 Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners Varsity Drive Raleigh, NC USA Phone: Phone: Fax: Willkommen beim Red Hat Network Satellite Client-Konfigurationshandbuch.

3 1. Einführung 1 2. Client-Applikationen Die neuesten Red Hat Network Client-RPMs einsetzen Client-Applikationen konfigurieren Registrieren mit Aktivierungsschlüsseln Die up2date --configure-option Die Konfigurationsdateien manuell aktualisieren Server-Ausfallsicherung implementieren Das Paket-Updater-Applet Das Red Hat Network Alert Notification Tool für Satellite konfigurieren SSL-Infrastruktur Eine kurze Einführung in SSL Das RHN SSL Maintenance Tool Erklärung zur SSL-Generierung RHN SSL Maintenance Tool-Optionen Das CA SSL-Schlüsselpaar generieren Webserver SSL-Schlüssel-Sets generieren Das öffentliche SSL-Zertifikat der CA auf Clients implementieren Client-Systeme konfigurieren Import angepasster GPG-Schlüssel Verwendung von RHN Bootstrap Vorbereitung Generierung Verwendung des Skripts RHN Bootstrap Optionen Manuelles Erstellen der Konfiguration Implementieren von Kickstart 29 A. Beispiel für ein Bootstrap-Skript 31 B. Versionsgeschichte 35 Stichwortverzeichnis 37 iii

4 iv

5 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 Client- Einstellungen 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. 1

6 2

7 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 Client- Applikationen 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 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- Tools sollten keine Probleme mit der Verbindung zu Ihrer RHN Satellite- oder Proxy-Umgebung haben. Die untenstehende Auseinandersetzung mit diesem Thema beruht auf der Annahme, dass die standardmäßigen Tools 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/html/pub/-verzeichnis mit einer Kopie von yum, pup und rhn_register (oder up2date) RPMs bestückt, die von seinen Client-Systemen 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 RPM-Versionen: 3

8 Kapitel 2. Client-Applikationen rpm -Uvh Beachten Sie dabei, dass die Architektur (in diesem Fall i386) abhängig von den zu versorgenden Systemen eventuell abgeändert werden muss 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 Themen 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 HTTP und 443 für sicheres HTTP (HTTPS) 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. The next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. To see how virtually all reconfiguration can be scripted, see Kapitel 6, Manuelles Erstellen der Konfiguration 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. Zur Registrierung mit einem Aktivierungsschlüssel gehören 4 einfache Schritte: 1. Erstellen Sie einen Aktivierungsschlüssel. 4

9 Die up2date --configure-option 2. Importieren Sie angepasste GPG-Schlüssel. 3. Laden Sie die SSL-Zertifikats-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 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 Alternativ können die meisten der o.g. Schritte in einem Shell-Skript zusammengefasst werden, das die folgenden Zeilen enthält (Beachten Sie, dass dieser Befehl für den Druck und für PDF-Dokumente in mehrere Zeilen umgebrochen, er jedoch am Shell-Prompt in einer einzigen Zeile eingegeben werden muss). wget bash && rhnreg_ks --activation-key my_key --serverurl 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 SSL- Zertifikateinstellungen von rhn_register auf up2date haben. Deshalb muss die Information der SSL-Zertifikate auf diesen Systemen manuell festgelegt werden. Alle anderen Einstellungen, wie beispielsweise die Server-URL, werden einwandfrei übertragen 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 (man 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 Allgemein-Reiter unter Wählen Sie einen Red Hat Network Server aus 5

10 Kapitel 2. Client-Applikationen ersetzen Sie den Standardwert durch dem FQDN des RHN Satellite Servers oder RHN Proxy Servers, wie beispielsweise /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 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. 6

11 Server-Ausfallsicherung implementieren 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. Zum Beispiel: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Warnung Die httpproxy-einstellung in /etc/sysconfig/rhn/up2date bezieht sich nicht auf den RHN Proxy Server. Diese wird dazu verwendet, einen optionalen HTTP-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) Server-Ausfallsicherung implementieren Ab up2date 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/up2date- Konfigurationsdatei hinzu. Fügen Sie ebenso die FQDNs für den Proxy oder Satellite durch ein Semikolon (;) getrennt direkt nach dem primären Server ein. Zum Beispiel: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= 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 Das Paket-Updater-Applet Red Hat Enterprise Linux 5 bietet ein laufendes Programm auf der grafischen Taskleiste, das regelmäßig nach Updates vom RHN oder Satellite Server sucht und Benutzer benachrichtigt, sobald ein neues Update verfügbar ist. 7

12 Kapitel 2. Client-Applikationen Abbildung 2.2. Paket-Updater-Applet Das Paket-Updater-Applet bleibt im Benachrichtigungsfeld der Taskleiste 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 Tool, das runde Symbol in der Taskleiste 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 Tool 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 Tools 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 Tools 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 Tool 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. 8

13 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 Zertifikate generieren. Die manuelle Erstellung und die manuelle Zuordnung von SSL-Schlüsseln und Zertifikaten kann sehr arbeitsaufwändig sein. RHN Proxy Server sowie auch RHN Satellite Server ermöglichen es Ihnen, Ihre eigenen SSL-Schlüssel und Zertifikate basierend auf Ihrer eigenen, privaten Zertifizierungsstelle (Certificate Authority oder im Folgenden kurz CA genannt) während der Installation zu erstellen. Zusätzlich dazu gibt es zu diesem Zweck das separate Befehlszeilendienstprogramm RHN SSL Maintenance Tool. Unabhängig davon müssen diese Schlüssel und Zertifikate auf allen Systemen in Ihrer Infrastruktur eingesetzt werden. In vielen Fällen ist der Einsatz dieser SSL-Schlüssel und Zertifikate bereits für Sie automatisiert. Dieses Kapitel beschreibt effiziente Verfahren zur Durchführung all dieser Aufgaben. Bitte beachten Sie, dass in diesem Kapitel das Thema SSL nicht tiefgreifend behandelt wird. Das RHN SSL Maintenance Tool wurde so entwickelt, dass das Aufsetzen und Verwalten dieser Public- Key-Infrastruktur (PKI) weniger komplex erscheint. Für detailliertere Informationen zu diesem Thema empfehlen wir auf einige der vielen, ausgezeichneten Referenzhandbücher, die in einem Buchhandel in Ihrer Nähe erhältlich sind, zurückzugreifen 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 Zertifikate 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 Zertifikat. Aufgrund dieser Beziehung kann eine vertrauenswürdige Verbindung hergestellt werden. Anmerkung Im Rahmen dieses Dokuments werden private SSL-Schlüssel und öffentliche Zertifikate behandelt. Genau genommen können beide als Keys oder Schlüssel bezeichnet werden (öffentliche und private Schlüssel). Üblicherweise wird jedoch im Zusammenhang mit SSL die öffentliche Hälfte eines SSL-Schlüsselpaares (oder Schlüssel-Sets) als öffentliches Zertifikat bezeichnet. Die SSL-Infrastruktur eines Unternehmens besteht generell aus folgenden SSL-Schlüsseln und Zertifikaten: Privater SSL-Schlüssel und öffentliches Zertifikat Ihrer CA ("Certificate Authority", Zertifizierungsstelle) üblicherweise wird nur ein Set pro Unternehmen generiert. Das öffentliche Zertifikat wird vom privaten Schlüssel digital signiert. Das öffentliche Zertifikat wird an jedes System verteilt. Web Server privater SSL-Schlüssel und öffentliches Zertifikat ein Set pro Applikationsserver. Das öffentliche Zertifikat wird sowohl vom eigenen privaten Schlüssel als auch vom privaten SSL- 9

14 Kapitel 3. SSL-Infrastruktur Schlü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-Zertifikats generiert wird. Die 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-Zertifikat 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-Zertifikats 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 Zertifikats 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 Tool 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 Das RHN SSL Maintenance Tool Red Hat Network bietet ein Befehlszeilen-Tool an, um Ihnen das Management Ihrer sicheren Infrastruktur zu erleichtern: das RHN SSL Maintenance Tool ist üblicherweise auch unter dem Befehlsnamen rhn-ssl-tool bekannt. Dieses Tool ist als Teil 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 Tool ermöglicht es Ihnen, Ihr SSL-Schlüsselpaar Ihrer CA sowie auch Webserver SSL- Schlüssel-Sets (manchmal auch als Schlüsselpaare bezeichnet) zu generieren. Es handelt sich hierbei um ein reines Build-Tool. Es generiert alle erforderlichen SSL-Schlüssel und Zertifikate. Die Dateien werden zu einem Paket im RPM-Format zur raschen Verteilung und Installation auf allen Client-Rechnern zusammengefasst. Jedoch werden diese vom Tool 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 Tool notwendig: Wenn Sie Ihr öffentliches Zertifikat Ihrer CA aktualisieren - dies ist äußerst selten der Fall. 10

15 Erklärung zur SSL-Generierung Wenn Sie einen RHN Proxy Server Version 3.6 oder höher installieren, der sich mit den zentralen 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 Zertifikat 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 Tool nicht erforderlich: Während der Installation eines RHN Satellite Server - alle SSL-Einstellungen werden während des Installationsvorgangs vorgenommen. Die SSL-Schlüssel und Zertifikate 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 Top-Level-Service verbunden ist - der RHN Satellite Server beinhaltet sämtliche SSL-Informationen, die dazu benötigt werden, die SSL-Schlüssel und Zertifikate 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-Zertifikat der CA in jedem /pub-verzeichnis eines jeden Servers abgelegt wird. Dieses öffentliche Zertifikat wird von den Client-Systemen dazu verwendet, sich mit den RHN Servern zu verbinden. Siehe Abschnitt 3.3, Das öffentliche SSL-Zertifikat der CA auf Clients implementieren für weitere Informationen. Kurz gesagt, wenn Ihr Unternehmen die aktuellste Version des RHN Satellite Server als Top-Level- Service einsetzt, dann werden Sie höchstwahrscheinlich das Tool nicht benötigen. Ansonsten sollten Sie sich mit dessen Anwendung vertraut machen Erklärung zur SSL-Generierung Der hauptsächliche Nutzen bei der Verwendung des RHN SSL Maintenance Tools liegt in der Sicherheit, Flexibilität und Portabilität. Sicherheit wird durch die Erstellung eindeutiger Webserver SSL-Schlüssel und Zertifikate für jeden RHN Server gewährleistet, wobei alle von einem einzigen SSL-Schlüsselpaar Ihrer CA signiert sind, das von Ihrem Unternehmen erstellt wurde. Flexibilität erhalten Sie durch die Fähigkeit des Tools auf jeder Maschine eingesetzt werden zu können, die das rhns-certs-tools-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 Top-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-Tools Gebrauch, die auf der Website des RHN Satellite Server zur Verfügung gestellt werden. Sie verwenden das RHN SSL Maintenance Tool 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 Zertifikat auf allen Client-Systemen. 11

16 Kapitel 3. SSL-Infrastruktur 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: /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 Tool wieder her und wiederholen die Schritte 3 bis RHN SSL Maintenance Tool-Optionen Das RHN SSL Maintenance Tool bietet eine Unmenge an Befehlszeilenoptionen zur Generierung Ihres CA SSL-Schlüsselpaares und zur Verwaltung Ihrer Server SSL-Zertifikate und -Schlüssel an. Das Tool bietet grundsätzlich drei Befehlszeilenoptionen für zur Auflistung der Hilfe an: rhn-ssltool --help (allgemein), rhn-ssl-tool --gen-ca --help (Certificate Authority) und rhnssl-tool --gen-server --help (Webserver). Auch die Handbuchseite für 'rhn-ssl-tool' liefert eine detaillierte Beschreibung: man rhn-ssl-tool. Die beiden untenstehenden Tabellen unterteilen die Optionen nach Aufgaben, entweder CA oder Webserver SSL-Schlüssel-Set-Generierung. Diesen Optionen muss der --gen-ca-parameter vorangestellt werden: Tabelle 3.1. SSL Certificate Authority (CA) Optionen (rhn-ssl-tool --gen-ca --help) Option --gen-ca -h, --help -f, --force -p=, --password=password Beschreibung Generiert ein Certificate Authority (CA) Schlüsselpaar und ein öffentliches RPM. Diese Option muss in Zusammenhang mit irgendeiner der verbleibenden Optionen in dieser Tabelle benutzt werden. Zeigt den Hilfebildschirm mit einer Liste von Basisoptionen in Zusammenhang mit der CA-Generierung und -Verwaltung an. Erzwingt die Erzeugung eines neuen privaten Schlüssels Ihrer CA und/oder öffentlichen Zertifikats. Das CA-Passwort. Sie werden zur Eingabe des Passworts aufgefordert, wenn Sie dieses nicht von vornherein angeben. 12

17 RHN SSL Maintenance Tool-Optionen Option -d=, --dir=build_directory --ca-key=filename --ca-cert=filename --cert-expiration=ca_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit Beschreibung Bewahren Sie eine Kopie des Passworts an einem sicheren Ort auf. Für die meisten Befehle erforderlich - Das Verzeichnis, in welches Zertifikate und RPM-Dateien beim Bauen gespeichert werden. Standard ist./ssl-build. Der Dateiname des privaten Schlüssels Ihrer CA. Standard ist RHN-ORG- PRIVATE-SSL-KEY. Der Dateiname des öffentlichen Zertifikats Ihrer CA. Standard ist RHN-ORG- TRUSTED-SSL-CERT. Die Gültigkeit des öffentlichen CA- Zertifikats. Standard ist das Ablaufen der Gültigkeit einen Tag vor dem Epochenwechsel (bzw ). Der zweistellige Ländercode. Standard ist US. Der Staat oder das Bundesland des CA- Zertifikats. Standard ist ''. Die Stadt oder der Ort. Standard ist ''. Die Firma oder das Unternehmen, wie beispielsweise Red Hat. Standard ist Example Corp. Inc. Die Unternehmenseinheit, wie beispielsweise RHN. Standard ist ''. --set-common-name=hostname Üblicherweise nicht für die CA gesetzt. - Der allgemeine Name. --set- = Üblicherweise nicht für die CA gesetzt. - Die -Adresse. --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --ca-cert-rpm=ca_cert_rpm --key-only Die Person, die das generierte RPM paketiert hat, wie z.b. "RHN Admin (rhnadmin@example.com)." Der Anbieter des generierten RPMs, wie z.b. "IS/IT Example Corp." Zeigt ausführliche Mitteilungen an. Akkumulierend - weitere hinzugefügte "v"s resultieren in noch umfangreicheren Details. Selten verändert - Name der RPM-Datei, die das CA Zertifikat beinhaltet (der Basis- Dateiname und nicht filename-versionrelease.noarch.rpm). Selten verwendet - Generiert nur einen privaten CA-Schlüssel. Siehe --gen- 13

18 Kapitel 3. SSL-Infrastruktur Option --cert-only --rpm-only --no-rpm Beschreibung ca --key-only --help für weitere Informationen. Selten verwendet - Generiert nur ein öffentliches CA-Zertifikat. Siehe --genca --cert-only --help für weitere Informationen. Selten verwendet - Generiert nur ein RPM zur Implementierung. Siehe --genca --rpm-only --help für weitere Informationen. Selten verwendet - Führt alle CA-Schritte aus, bis auf die RPM-Generierung. Den folgenden Optionen muss der --gen-server-parameter vorangestellt werden: Tabelle 3.2. SSL Web-Server-Optionen (rhn-ssl-tool --gen-server --help) Option --gen-server -h, --help -p=, --password=password -d=, --dir=build_directory --server-key=filename --server-cert-req=filename --server-cert=filename --startdate=yymmddhhmmssz Beschreibung Generiert SSL-Schlüssel-Set, RPM und Tar-Archiv des Webservers. Diese Option muss in Zusammenhang mit irgendeiner der verbleibenden Optionen in dieser Tabelle benutzt werden. Zeigt den Hilfebildschirm mit einer Liste von Basisoptionen in Zusammenhang mit der Generierung und Verwaltung eines Server-Schlüsselpaares an. 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. Für die meisten Befehle erforderlich - Das Verzeichnis, in welches Zertifikate und RPM-Dateien beim Bauen gespeichert werden. Standard ist./ssl-build. Der Dateiname des privaten SSL- Schlüssels des Webservers. Standardmäßig ist dies server.key. Der Dateiname des SSL-Zertifikats des Webservers, das vom Client angefragt wird. Standardmäßig ist dies server.csr. Der Dateiname des SSL-Zertifikats des Webservers. Standardmäßig ist dies server.crt. Das Startdatum der Gültigkeit für das Server-Zertifikat im Beispielformat: Jahr, Monat, Datum, Stunde, Minute, Sekunde (zwei Zeichen pro Wert). Z ist erforderlich 14

19 RHN SSL Maintenance Tool-Optionen Option --cert-expiration=server_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit --set-hostname=hostname --set- = --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --key-only --cert-req-only --cert-only Beschreibung und steht für Zulu. Standardmäßig wird dieses Datum auf eine Woche vor Generierung gesetzt. Das Ablaufdatum des Server-Zertifikats. Standardmäßig ist dies ein Tag vor dem Epochenwechsel (oder ). Der zweistellige Ländercode. Standard ist US. Der Staat oder die Provinz. Der Standardwert lautet North Carolina. Die Stadt oder der Ort. Der Standardwert lautet Raleigh. Die Firma oder Organisation, wie z.b. Red Hat. Der Standardwert lautet 'Example Corp. Inc.' Die Unternehmenseinheit, wie beispielsweise RHN. Standardmäßig ist dies 'unit'. Der Hostname des RHN Servers, der den Schlüssel erhält. Standardmäßig ist dies der dynamisch gesetzte Hostname des Build-Rechners. Die -Adresse für den Kontakt bezügl. des Zertifikats. Der Standardwert lautet Die Person, die das generierte RPM paketiert hat, wie z.b. "RHN Admin Der Anbieter des generierten RPMs, wie z.b. "IS/IT Example Corp." Zeigt ausführliche Mitteilungen an. Akkumulierend - weitere hinzugefügte "v"s resultieren in noch umfangreicheren Details. Selten verwendet - Generiert nur einen privaten Server-Schlüssel. Siehe -- gen-server --key-only --help für weitere Informationen. Selten verwendet - Generiert nur eine Anfrage für ein Server-Zertifikat. Siehe -- gen-server --cert-req-only -- help für weitere Informationen. Selten verwendet - Generiert nur ein Server-Zertifikat. Siehe --gen-server --cert-only --help für weitere Informationen. 15

20 Kapitel 3. SSL-Infrastruktur Option --rpm-only --no-rpm --server-rpm=server_rpm --server-tar=server_tar Beschreibung Selten verwendet - Generiert nur eine RPM-Datei zur Implementierung. Siehe -- gen-server --rpm-only --help für weitere Informationen. Selten verwendet - Führt alle Serverbezogenen Schritte mit Ausnahme der RPM-Generierung durch. Selten verändert - Name der RPM- Datei, die das SSL-Schlüssel-Set des Webservers beinhaltet (der Basis- Dateiname und nicht filename-versionrelease.noarch.rpm). Selten verändert - Name des.tar Archivs, welches das Webserver SSL-Schlüssel- Set und das öffentliche CA-Zertifikat beinhaltet und ausschließlich von den Installationsroutinen des gehosteten RHN Proxy Servers verwendet wird (der Basis- Dateiname und nicht filename-versionrelease.tar) 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 SSL-Schlüsselpaar generieren. Ein öffentliches SSL-Zertifikat der CA wird auf die Client-Systeme des Satellite oder Proxy verteilt. Das RHN SSL Maintenance Tool 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-PRIVATE-SSL-KEY der private SSL-Schlüssel der CA RHN-ORG-TRUSTED-SSL-CERT das öffentliche SSL-Zertifikat 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-Zertifikat der CA und installiert es in: /usr/share/rhn/rhn-org-trusted-ssl-cert rhn-ca-openssl.cnf die SSL CA Konfigurationsdatei latest.txt listet immer die aktuellsten Versionen der relevanten Dateien auf. 16

21 Webserver SSL-Schlüssel-Sets generieren Nach Abschluss können Sie das RPM auf Client-Systeme verteilen. Werfen Sie dazu einen Blick auf Abschnitt 3.3, Das öffentliche SSL-Zertifikat der CA auf Clients implementieren 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-hostname von Server zu Server verschieden ist. In anderen Worten muss ein eindeutiger Satz an SSL- Schlüsseln und -Zertifikaten für jeden verschiedenen RHN Server-Hostnamen generiert und installiert werden. Der Build-Prozess für das Server-Zertifikat 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-Zertifikate 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- ="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 Build- Verzeichnisses: server.key der private SSL Server-Schlüssel des Web-Servers server.csr die SSL-Zertifikatsanfrage des Webservers server.crt das öffentliche SSL-Zertifikat 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 17

22 Kapitel 3. SSL-Infrastruktur 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-Zertifikat der CA und eine RPM-Datei generiert werden. Diese Installationsprozesse legen eine Kopie bzw. Kopien von beiden öffentlich zugänglich im Verzeichnis /var/www/html/pub/ des RHN Servers ab. Sie können einfach mit einem beliebigen Webbrowser dieses öffentliche Verzeichnis aufrufen und dieses ansehen: Das öffentliche SSL-Zertifikat der CA in diesem Verzeichnis kann auf ein Client-System heruntergeladen werden, indem Sie wget oder curl verwenden. Zum Beispiel: curl -O wget Wenn die RPM-Datei des öffentlichen SSL-Zertifikats der CA sich im /pub/-verzeichnis befindet, kann diese auch direkt auf einem Client-System installiert werden: rpm -Uvh \ Überprüfen Sie den tatsächlichen Namen des Zertifikats oder der RPM-Datei, bevor Sie diese Befehle ausführen Client-Systeme konfigurieren Wenn die RPM-Datei oder das Rohdaten-Zertifikat 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- Zertifikat der CA verwenden und sich mit dem entsprechenden RHN Proxy Server oder RHN Satellite Server verbinden zu können. Der allgemein anerkannte Speicherplatz für dieses öffentliche SSL- Zertifikat 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. 18

23 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 Die -O--Option zeigt die Resultate auf der Standardausgabe an, während die -q-option Wget im Quiet-Modus, also ohne Bildschirmausgabe ablaufen lässt. Vergessen Sie nicht, die YOUR-RPM-GPG- KEY-Variable 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. 19

24 20

25 Verwendung von RHN Bootstrap Red Hat Network liefert ein Tool, das viele Schritte der in vorhergehenden Kapiteln beschriebenen manuellen Konfiguration automatisiert: RHN Bootstrap. Dieses Tool spielt eine wesentliche Rolle für das RHN Satellite Server-Installationsprogramm und ermöglicht das Generieren des Bootstrap- Skripts während der Installation. RHN Proxy Server-Kunden und Kunden mit aktualisierten Satellite-Einstellungen benötigen ein Bootstrap-Tool, das eigenständig verwendet werden kann. RHN Bootstrap, das mit dem Befehl / usr/bin/rhn-bootstrap aufgerufen wird, dient diesem Zweck und wird standardmäßig bereits auf RHN Satellite Server und RHN Proxy Server installiert ausgeliefert. Das Skript, das von diesem Tool 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-Zertifikate 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-Tools, wie beispielsweise ein SSL-Zertifikat, 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 Kunden-Firewalls 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/html/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 Tools. Außderdem finden Sie in Anhang A, Beispiel für ein Bootstrap-Skript ein Beispielskript 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 Zug zur Registrierung von Red Hat Enterprise Linux- Systemen verwenden, Berechtigungen an diese Systeme für einen RHN-Servicelevel vergeben und diese bei speziellen Channels und Systemgruppen anmelden. Beachten Sie dabei, dass Sie 21