Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch

Transkript

1 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Red Hat Network Satellite Ausgabe 3 Red Hat Documentation Team

2 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Red Hat Network Satellite Ausgabe 3 Red Hat Documentation Team

3 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 Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. 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.

4 Inhaltsverzeichnis Inhaltsverzeichnis. Kapitel Einführung Kapitel Client-Applikationen Implementieren der neuesten Red Hat Network Client-RPMs Konfiguration der Client-Applikationen Registrieren von Clients beim Red Hat Network RHN Satellite Server Registrieren mit Aktivierungsschlüsseln Die up2date --configure-option Manuelle Aktualisierung der Konfigurationsdateien Implementieren von Server-Ausfallsicherung Das Paket-Updater-Applet 8. Kapitel SSL-Infrastruktur Eine kurze Einführung in SSL Das RHN SSL Maintenance Tool Generieren von SSL-Z ertifikaten RHN SSL Maintenance T ool-optionen Generieren des CA-SSL-Schlüsselpaars Generieren des Webserver-SSL-Schlüsselsets Implementieren des öffentlichen CA-SSL-Z ertifikats auf Clients Konfiguration der Client-Systeme 19. Kapitel Import angepasster GPG-Schlüssel Kapitel Verwendung von.... RHN..... Bootstrap Vorbereitung der RHN Bootstrap Installation Erstellen von RHN Bootstrap Skripten Verwenden des RHN Bootstrap Skripts Konfiguration der RHN Bootstrap Optionen 24. Kapitel Manuelles Skripting der.... RHN..... Bootstrap Konfiguration Kapitel Implementieren von..... Kickstart Beispiel für.... ein.... Bootstrap-Skript Revision History Stichwortverzeichnis Symbole 38 A 38 B 39 C 39 G 39 K 39 R 39 S 40 1

5 2 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch

6 Kapitel 1. Einführung Kapitel 1. Einführung Dieser Praxisleitfaden soll Kunden von RHN Satellite Server und RHN Proxy Server bei der Konfiguration ihrer Client-Systeme helfen. Standardmäßig sind alle Red Hat Network Client-Applikationen zur Kommunikation mit zentralen Red Hat Network Servern konfiguriert. Wenn sich Clients stattdessen mit einem RHN Satellite Server oder RHN Proxy Server verbinden, müssen diese Standardeinstellungen geändert werden. Dieses Dokument zeigt Schritte zur Massen-Neukonfiguration, die insbesondere in großen Unternehmensumgebungen mit hunderten oder tausenden von Systemen dabei helfen, diese Standardeinstellungen zu ändern. Aufgrund der Komplexität dieses Unterfangens können Kunden ein vorbereitetes 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 notwendigen Änderungen und der damit verbundenen Implikationen für den Benutzer ä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 aufgefü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

7 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Kapitel 2. Client-Applikationen Um die meisten Red Hat Network Features für den Unternehmensbereich nutzen zu können, wie beispielsweise die Registrierung bei einem RHN Satellite, ist die Konfiguration der neuesten Client- Applikationen erforderlich. Es kann sich jedoch etwas schwierig gestalten, diese Applikationen noch vor der Registrierung des Clients beim Red Hat Network zu erhalten. Dieses Paradox wird speziell dann problematisch, wenn Kunden eine geraume Anzahl von älteren Systemen auf Red Hat Network migrieren. Dieses Kapitel zeigt T echniken, um dieses Dilemma aufzulösen. Wichtig Red Hat empfiehlt dringend, dass mit dem RHN Proxy Server oder RHN Satellite Server verbundene Clients die neuesten Updates von Red Hat Enterprise Linux implementiert haben, um eine bestmögliche Verbindung zu gewährleisten. Falls Client-Firewalls eingerichtet sind, sollten zudem die Ports 80 und 443 geöffnet sein, damit Red Hat Network ordnungsgemäß funktioniert Implementieren der neuesten Red Hat Network Client-RPMs Der Package Updater (pup), yum, das yum-rhn-plugin (yum-rhn-plugin) und der Red Hat Network Registration Client (rhn_register) auf Red Hat Enterprise Linux 5 und 6 sind Voraussetzungen für den Einsatz vieler der Unternehmensfunktionen von Red Hat Network. Es ist wichtig, diese auf den Client-Systemen zu installieren, bevor Sie versuchen, RHN Proxy Server oder RHN Satellite Server in Ihrer Umgebung zu verwenden. Es gibt einige sinnvolle Vorgehensweisen zur Aktualisierung 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, so dass die Pakete mit einem möglichst einfachen Befehl implementiert werden können. In nahezu allen Fällen ist eine manuelle Implementierung von yum, pup und rhn_register nicht notwendig. Diese Client-T ools sollten keine Probleme bei der Verbindung mit der RHN Satellite oder Proxy Umgebung haben. Die folgende Auseinandersetzung mit diesem T hema beruht auf der Annahme, dass die standardmäßigen Tools yum, pup, and rhn_register nicht in den aktuellsten Versionen vorliegen und für Ihre Umgebung nicht funktionieren. Beachten Sie, dass Systeme, auf denen Red Hat Enterprise Linux 5 und 6 läuft, entweder mit firstboot nach der Installation oder mithilfe des rhn_register-befehls bei RHN registriert worden sein müssen. Dieses Handbuch geht davon aus, dass der Kunde mindestens einen RHN Satellite Server und/oder RHN Proxy Server auf seinem Netzwerk installiert hat. Das nachstehende Beispiel veranschaulicht eine einfache Herangehensweise zum erstmaligen Implementieren von yum, pup und rhn_register (oder up2date) durch den Administrator, wenn die Rechner kein funktionsfähiges RHN haben: rpm -Uvh Der Administrator hat das /var/www/htm l/pub/-verzeichnis auf der RHN Satellite oder RHN Proxy Umgebung bereits mit einer Kopie der yum, pup und rhn_register RPMs bestückt, die von den Client-Systemen benötigt werden, so dass durch Ausführen des obigen Befehls die RPMs durch einen einfachen rpm -Uvh-Befehl installiert werden. Wird der rpm -Uvh-Befehl auf einem Client ausgeführt, 4

8 Kapitel 2. Client-Applikationen so werden die RPMs auf diesem Client installiert, vorausgesetzt, der Domainname, Pfad und die RPM- Versionen sind korrekt (Beachten Sie, dass der Befehl zur besseren Lesbarkeit in mehrere Z eilen unterteilt wurde, er am Shell-Prompt jedoch in einer einzigen Z eile angegeben werden sollte): Beachten Sie dabei, dass die Architektur (in diesem Fall i386) und Paketversionen abhängig von den zu versorgenden Systemen eventuell geändert werden muss Konfiguration der Client-Applikationen Z war muss nicht jeder Kunde sicher mit einem RHN Satellite Server oder RHN Proxy Server innerhalb seiner Organisation verbinden; auch muss nicht jeder Kunde einen GPG-Schlüssel für angepasste Pakete erstellen und implementieren, allerdings muss jeder Kunde, der RHN Satellite Server oder RHN Proxy Server verwendet, den Red Hat Update Agent (up2date) und ggf. den Red Hat Network Registration Client (rhn_register) neu konfigurieren, damit dieser statt auf Red Hat Network auf seinen RHN Satellite Server oder RHN Proxy Server verweist. Wichtig Obwohl dies nicht konfigurierbar ist, beachten Sie bitte, dass der von 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 Benutzer sicherstellen, 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. Beachten Sie bitte ebenso, dass für die Verwendung von RHN 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 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.5, Implementieren von Server-Ausfallsicherung für nähere Instruktionen zur Aktivierung dieses Features. Die nächsten Abschnitte beschreiben verschiedene Methoden zur Konfiguration der Client-Systeme zum Zugriff auf den RHN Satellite Server oder RHN Proxy Server. Um zu erfahren, wie fast die gesamte Rekonfiguration unter Einsatz von Skripten durchgeführt werden, werfen Sie einen Blick auf Kapitel 6, Manuelles Skripting der RHN Bootstrap Konfiguration Registrieren von Clients beim Red Hat Network RHN Satellite Server Um ein System bei einem RHN Satellite Server zu registrieren, ist ein voll qualifizierter Domainname (FQDN) und das SSL-Z ertifikat des RHN Satellite Servers erforderlich. Wenn diese Voraussetzungen erfüllt sind, fahren Sie mit den folgenden Schritten fort: 1. Laden Sie das SSL-Z ertifikat auf den Client herunter: cd /usr/share/rhn/ wget 5

9 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch 2. Bearbeiten Sie die /etc/sysconfig/rhn/up2date-datei: serverurl= nosslserverurl= sslcacert=/usr/share/rhn/rhn-org-trusted-ssl-cert 3. Registrieren Sie den Rechner: rhn_register 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 Subskribieren 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. Bei der Registrierung mittels Aktivierungsschlüssel: 1. Erstellen Sie einen Aktivierungsschlüssel. (Siehe Abschnitt "Aktivierungsschlüssel" im RHN Satellite Server Referenzhandbuch) 2. Importieren Sie angepasste GPG-Schlüssel. 3. Laden Sie das SSL-Z ertifikats-rpm vom /pub/-verzeichnis des RHN Proxy Servers oder RHN Satellite Servers herunter und installieren Sie es. Der Befehl für diesen Schritt könnte ungefähr so aussehen: rpm -Uvh 4. Registrieren Sie das System beim RHN Proxy Server oder RHN Satellite Server:: rhnreg_ks --activationkey mykey --serverurl Alternativ können die meisten der oben genannten Schritte in einem Shell-Skript zusammengefasst werden, das die folgenden Z eilen enthält: wget bash && rhnreg_ks --activation-key my_key --serverurl Beachten Sie, dass der Befehl zur besseren Lesbarkeit in mehrere Z eilen unterteilt wurde, er am Shell- Prompt jedoch in einer einzigen Z eile angegeben werden sollte. Das Bootstrap-Skript, das bei der Installation generiert wird und für RHN Satellite Server und RHN Proxy Server zur Verfügung steht, ist ein solches Skript. Das Skript und der RHN Bootstrap, das es generiert, werden genauer in Kapitel 5, Verwendung von RHN Bootstrap behandelt Die up2date --configure-option Der Red Hat Update Agent in Red Hat Enterprise Linux 3 und 4 stellt eine Oberfläche zur Konfiguration verschiedener Einstellungen bereit. Für eine vollständige Liste dieser Einstellungen werfen Sie bitte einen Blick auf die up2date-handbuchseite (m an up2date an der Befehlszeile). 6

10 Kapitel 2. Client-Applikationen 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 den FQDN des RHN Satellite Servers oder RHN Proxy Servers, wie beispielsweise ple.com/xmlrpc. Behalten Sie das /XMLRPC am Ende bei. 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.4, Manuelle Aktualisierung der Konfigurationsdateien für genauere Anweisungen. Warnung Systeme mit Red Hat Enterprise Linux 3 und 4 besitzen Registrierungsfunktionalität, die in den Red Hat Update Agent integriert ist, und installieren daher den Red Hat Network Registration Client nicht. Systeme mit Red Hat Enterprise Linux 5 und 6 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. 7

11 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Manuelle Aktualisierung der Konfigurationsdateien Alternativ zur zuvor erläuterten grafischen Benutzeroberfläche kann der Red Hat Update Agent auch neu konfiguriert werden, indem Benutzer die Konfigurationsdatei der Applikation bearbeiten. 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 durch den FQDN für den RHN Proxy Server oder RHN Satellite Server. Z um 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 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) Implementieren von Server-Ausfallsicherung 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. Um dieses Feature zu verwenden: 1. Vergewissern Sie sich, dass Sie die benötigte Version von up2date sowie Red Hat Enterprise Linux 5 oder 6 ausführen. 2. Fügen Sie manuell als 'root' die sekundären Server zu den serverurl- und nosslserverurl- Einstellungen in der /etc/sysconfig/rhn/up2date-konfigurationsdatei hinzu. 3. Fügen Sie gleich nach dem primären Server die voll qualifizierten Domainnamen (FQDNs) für den Proxy oder Satellite hinzu, getrennt durch ein Semikolon (;). Z um Beispiel: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Die Verbindung mit den Servern wird in der angegebenen Reihenfolge versucht. Fügen Sie so viele Server ein, wie Sie für nötig erachten Das Paket-Updater-Applet 8

12 Kapitel 2. Client-Applikationen 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. 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 es Benutzern zudem, einige Aufgaben zur Paketverwaltung vom Applet aus durchzuführen, indem sie auf das Benachrichtigungs-Icon klicken und eine der folgenden Aufgaben auswählen: Aktualisieren Überprüft RHN oder den Satellite auf neue Updates. Updates anzeigen Startet die Paket-Updater-Applikation, so dass Benutzer 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ßt das Applet. 9

13 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch 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. Sowohl der RHN Proxy Server als auch der RHN Satellite Server ermöglichen es Benutzern, 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 Befehlszeilenprogramm RHN SSL Maintenance T ool. Nichtsdestotrotz müssen diese Schlüssel und Z ertifikate auf allen Systemen in der verwalteten Infrastruktur implementiert werden. In vielen Fällen ist die Implementierung dieser SSL- Schlüssel und Z ertifikate bereits 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-Key- Infrastruktur (PKI) weniger komplex erscheint. Für detailliertere Informationen zu diesem T hema empfehlen wir auf einige der vielen, ausgezeichneten Referenzhandbücher zurückzugreifen, die im Buchhandel erhältlich sind Eine kurze Einführung in SSL SSL oder Secure Sockets Layer ist ein Protokoll, das es Client-Servern ermöglicht, Informationen sicher zu übertragen. 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 können frei zugänglich sein, wohingegen private Schlüssel gesichert aufbewahrt werden müssen. Dieses System basiert auf der mathematischen Beziehung (eine 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 Private SSL-Schlüssel und öffentliche Z ertifikate werden im Laufe dieses Handbuchs immer wieder erwähnt. Beide werden gelegentlich auch als Schlüssel bezeichnet, ein privater und ein öffentlicher Schlüssel. Allerdings ist es im Z usammenhang mit SSL üblich, den öffentlichen T eil eines SSL-Schlüsselpaares (oder Schlüssel-Sets) als öffentliches SSL-Z ertifikat zu bezeichnen. Die SSL-Infrastruktur eines Unternehmens besteht generell aus folgenden SSL-Schlüsseln und Z ertifikaten: Privater SSL-Schlüssel und öffentliches Z ertifikat von der CA üblicherweise wird nur ein Set pro Organisation generiert. Das öffentliche Z ertifikat wird vom privaten Schlüssel digital signiert. Das öffentliche Z ertifikat wird an jedes System verteilt. Privater SSL-Schlüssel und öffentliches Z ertifikat vom Webserver ein Set pro Applikationsserver. Das öffentliche Z ertifikat wird sowohl vom eigenen privaten Schlüssel als auch vom privaten SSL- Schlüssel der CA digital signiert. Wir verweisen des öfteren auf ein Schlüssel-Set eines Webservers, da eine zwischengeschaltete Anfrage des SSL-Z ertifikats generiert wird. Die genauen Details sind in diesem Z usammenhang nicht wichtig. Alle drei werden auf einem RHN Server implementiert. 10

14 Kapitel 3. SSL-Infrastruktur Hier ist ein Beispielszenario: Eine Organisation mit einem RHN Satellite Server und fünf RHN Proxy Servern muss ein CA-SSL-Schlüsselpaar und sechs Webserver SSL-Schlüssel-Sets generieren. Das öffentliche CA-SSL-Z ertifikat 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 CA-SSL-Schlüssel generiert wurde. Dadurch entsteht eine digital verifizierbare Beziehung zwischen dem öffentlichen SSL-Z ertifikat des Webservers und dem CA-SSL-Schlüsselpaar 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 CA-SSL-Schlüsselpaar. 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 dringend empfohlen, dass Sie das SSL-Verzeichnis, das von diesem T ool angelegt wurde, auf einem separaten Medium archivieren. Schreiben Sie ebenfalls 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 Befehlszeilentool an, um die Verwaltung der sicheren Infrastruktur der Organisation zu erleichtern: das RHN SSL T ool, üblicherweise auch unter dem Befehlsnamen rhnssl-tool bekannt. Dieses T ool ist als T eil des rhns-certs-tools-pakets erhältlich. Das Paket befindet sich in den Software-Channels der aktuellen RHN Proxy Server und RHN Satellite Server (sowie auch das RHN Satellite Server ISO). Das RHN SSL T ool ermöglicht es Organisationen, ihr eigenes CA- SSL-Schlüsselpaar sowie Webserver SSL-Schlüssel-Sets (manchmal auch Schlüsselpaare genannt) 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. Allerdings werden diese vom T ool nicht zugeordnet. Dies wird dem Administrator überlassen oder in vielen Fällen mithilfe des RHN Satellite Servers automatisiert. Anmerkung spacewalk-certs-tools, das rhn-ssl-tool beinhaltet, kann auf jedem aktuellen Red Hat Enterprise Linux System mit minimalen Voraussetzungen installiert und eingesetzt werden. Es ist für Administratoren von Vorteil, die ihre SSL-Infrastruktur von ihren Arbeitsplatzrechnern aus oder auch von anderen Systemen statt den RHN Servern aus verwalten möchten. In diesen Fällen ist das Tool notwendig: Beim Aktualisieren des öffentlichen Certificate Authority (CA) Z ertifikats Wenn Sie einen RHN Proxy Server Version 3.6 oder höher installieren, der sich mit den zentralen RHN Servern als dessen T op-level-service verbindet - der gehostete Service kann aus Sicherheitsgründen nicht als Repository für den SSL-Schlüssel der CA und das Z ertifikat dienen, das privat für die Organisation ist. Wenn die RHN-Infrastruktur, die zuvor kein SSL verwendet hat, zur Verwendung von SSL konfiguriert 11

15 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch wird. Wenn mehrere RHN Satellite Server zur RHN-Infrastruktur hinzugefügt werden - 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 Servers - 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 SSL- Schlü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 CA-SSL-Z ertifikat in dem /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, Implementieren des öffentlichen CA-SSL-Z ertifikats auf Clients für weitere Informationen. Mit anderen Worten, wenn die RHN-Infrastruktur der Organisation die neueste Version des RHN Satellite Servers als T op-level-service einsetzt, sollte es kaum Grund zur Verwendung dieses T ools geben Generieren von SSL-Zertifikaten Der größte Vorteil bei der Verwendung des RHN SSL Maintenance T ools ist die Sicherheit, Flexibilität und Portabilität. Sicherheit wird durch die Erstellung eindeutiger Webserver-SSL-Schlüssel und Z ertifikate für jeden RHN Server gewährleistet, die alle von einem einzigen SSL-Schlüsselpaar der CA signiert sind, das von der Organisation erstellt wurde. Flexibilität wird erreicht durch die Fähigkeit des T ools, auf jedem Rechner eingesetzt werden zu können, die das spacewalk-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 der T op-level RHN Server in der Infrastruktur der Organisation der aktuellste RHN Satellite Server ist, dann muss höchstens der ssl-build-baum von einem Archiv in das /root-verzeichnis wiederhergestellt werden und die Konfigurationstools auf der Website des RHN Satellite Servers verwendet werden. Um das RHN SSL Maintenance T ool bestmöglich einzusetzen, führen Sie die folgenden Aufgaben in ungefähr dieser Reihenfolge aus. Für die notwendigen Details verweisen wir auf die verbleibenden Abschnitte: 1. Installieren Sie das spacewalk-certs-tools-paket auf einem System innerhalb der Organisation. Dies kann, muss aber nicht der RHN Satellite Server oder RHN Proxy Server sein. 2. Erstellen Sie ein einzelnes CA-SSL-Schlüsselpaar für die Organisation und installieren Sie das daraus resultierende RPM oder öffentliche Z ertifikat auf allen Client-Systemen. Siehe Abschnitt 3.2.3, Generieren des CA-SSL-Schlüsselpaars für weitere Informationen. 3. Erzeugen Sie ein Webserver-SSL-Schlüssel-Set für jeden der Proxys und Satellites und installieren die daraus resultierenden RPM-Dateien auf den RHN-Servern. 4. Starten Sie den httpd-dienst neu: /sbin/service httpd restart 5. Archivieren Sie den SSL-Build-Baum - bestehend aus dem primären Build-Verzeichnis und allen 12

16 Kapitel 3. SSL-Infrastruktur Unterverzeichnissen und Dateien - auf einem Wechselmedium wie z.b. einer CD oder DVD. (Speicherplatzanforderungen sind vernachlässigbar.) 6. Ü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. 7. Notieren Sie sich das CA-Passwort und bewahren Sie es sicher auf. 8. Löschen Sie den Build-Baum aus Sicherheitsgründen vom Build-System, aber erst dann, wenn die gesamte RHN-Infrastruktur vorhanden und konfiguriert ist. Anmerkung Wenn Sie zusätzliche Webserver-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 RHN SSL Maintenance Tool-Optionen Das RHN SSL Maintenance T ool bietet eine Vielzahl von Befehlszeilenoptionen zur Generierung des CA-SSL-Schlüsselpaares und zur Verwaltung Ihrer Server-SSL-Z ertifikate und -Schlüssel. Das T ool bietet drei Befehlszeilenoptionen zur Anzeige der Hilfe an: rhn-ssl-tool --help (general), rhnssl-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 rhnssl-tool. Die beiden nachfolgenden T abellen unterteilen die Optionen nach Aufgaben, entweder CA- oder Webserver-SSL-Schlüsselset-Generierung. Diesen Optionen muss der --gen-ca-parameter vorangestellt werden: 13

17 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch T abelle 3.1. SSL Certificate Authority (CA) Optionen (rhn-ssl-tool --gen-ca --help) Option --gen-ca -h, --help -f, --force -p=, --password=password -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 Generiert ein Certificate Authority (CA) Schlüsselpaar und ein öffentliches RPM. Diese Option muss zusammen mit einer der verbleibenden Optionen in dieser T abelle benutzt werden. Z eigt den Hilfebildschirm mit einer Liste von Basisoptionen in Z usammenhang mit der CA-Generierung und -Verwaltung an. Erzwingt die Erzeugung eines neuen privaten Schlüssels Ihrer CA und/oder öffentlichen Z ertifikats. Das CA-Passwort. Benutzer 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 Z ertifikate und RPM-Dateien beim Erstellen gespeichert werden. Standard ist./ssl-build. Der Dateiname des privaten Schlüssels Ihrer CA. Standard ist RHN-ORG- PRIVAT E-SSL-KEY. Der Dateiname des öffentlichen Z ertifikats Ihrer CA. Standard ist RHN-ORG- T RUST ED-SSL-CERT. Die Gültigkeit des öffentlichen CA- Z ertifikats. 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- Z ertifikats. Standard ist ''. Die Stadt oder der Ort. Standard ist ''. Das Unternehmen oder die Organisation, wie z.b. Red Hat. Der Standardwert lautet 'Example Corp. Inc.' 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= --rpm-packager=packager Üblicherweise nicht für die CA gesetzt. - Die -Adresse. Die Person, die das generierte RPM paketiert hat, wie z.b. "RHN Admin (rhn- 14

18 Kapitel 3. SSL-Infrastruktur --rpm-vendor=vendor -v, --verbose --ca-cert-rpm =CA_CERT_RPM --key-only --cert-only --rpm-only --no-rpm Der Anbieter des generierten RPMs, wie z.b. "IS/IT Example Corp." Z eigt 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-Z ertifikat beinhaltet (der Basis- Dateiname und nicht dateiname-versionrelease.noarch.rpm). Selten verwendet - Generiert nur einen privaten CA-Schlüssel. Siehe --gen-ca - -key-only --help für weitere Informationen. Selten verwendet - Generiert nur ein öffentliches CA-Zertifikat. Siehe --gen-ca --cert-only --help für weitere Informationen. Selten verwendet - Generiert nur ein RPM zur Implementierung. Siehe --gen-ca -- rpm-only --help für weitere Informationen. Selten verwendet - Führt alle CA-Schritte aus mit Ausnahme der RPM-Generierung. Den folgenden Optionen muss der --gen-server-parameter vorangestellt werden: 15

19 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch T abelle 3.2. SSL-Webwerver-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 --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 Beschreibung Generiert SSL-Schlüssel-Set, RPM und T ar-archiv des Webservers. Diese Option muss zusammen mit einer der verbleibenden Optionen in dieser T abelle benutzt werden. Z eigt den Hilfebildschirm mit einer Liste von Basisoptionen in Z usammenhang mit der Generierung und Verwaltung eines Server- Schlüsselpaares an. Das CA-Passwort. Benutzer 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 Z ertifikate und RPM-Dateien beim Erstellen 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-Z ertifikats des Webservers, das vom Client angefragt wird. Standardmäßig ist dies server.csr. Der Dateiname des SSL-Z ertifikats des Webservers. Standardmäßig ist dies server.crt. 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. Das Ablaufdatum des Server-Z ertifikats. 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. Das Unternehmen oder die Organisation, wie z.b. Red Hat. Der Standardwert lautet 'Example Corp. Inc.' Die Unternehmenseinheit, wie 16

20 Kapitel 3. SSL-Infrastruktur --set-hostnam e=hostname --set-em ail= --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --key-only --cert-req-only --cert-only --rpm-only --no-rpm --server-rpm =SERVER_RPM --server-tar=server_tar 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 Z ertifikats. Der Standardwert lautet 'admin@example.com'. 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." Z eigt 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 --genserver --key-only --help für weitere Informationen. Selten verwendet - Generiert nur eine Anfrage für ein Server-Z ertifikat. Siehe -- gen-server --cert-req-only -- help für weitere Informationen. Selten verwendet - Generiert nur ein Server-Z ertifikat. Siehe --gen-server -- cert-only --help für weitere Informationen. 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 dateiname-versionrelease.noarch.rpm). 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 Basis- Dateiname und nicht dateiname-versionrelease.tar). 17

21 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Generieren des CA-SSL-Schlüsselpaars 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 CA-SSL-Z ertifikat wird auf die Client-Systeme des Satellites oder Proxys 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 weiteren Implementierungen von RHN Servern wiederzuverwenden. Der Build-Prozess erzeugt automatisch das Schlüsselpaar und das ö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 durch die für Ihre Organisation passenden Werten. Dadurch erhalten Sie 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, Implementieren des öffentlichen CA-SSL-Z ertifikats auf Clients Generieren des Webserver-SSL-Schlüsselsets Z u diesem Z eitpunkt sollte bereits ein CA-SSL-Schlüsselpaar generiert worden sein. Allerdings kann es nötig sein, Webserver-SSL-Schlüsselsets häufiger zu erstellen, insbesondere, falls mehr als ein Proxy oder Satellite implementiert ist. Für jeden separaten RHN-Server-Hostnamen müssen separate SSL- Schlüssel und -Z ertifikate generiert werden, beachten Sie also, dass der Wert --set-hostnam e sich für jeden Server unterscheidet. 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 widerspiegeln, wie z.b. /root/ssl-build/machine_name. 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- ="admin@ example.com" \ --set-hostname="rhnbox1.example.com Ersetzen Sie die Beispielwerte durch die für Ihre Organisation passenden Werte. Dadurch erhalten Sie folgende, relevante Dateien in einem rechnerspezifischen Unterverzeichnis des Build-Verzeichnisses: 18

22 Kapitel 3. SSL-Infrastruktur server.key der private SSL Server-Schlüssel des Webservers 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, dass der httpd-dienst nach der Installation neu gestartet werden muss: /sbin/service httpd restart 3.3. Implementieren des öffentlichen CA-SSL-Zertifikats auf Clients Der Installationsprozess des RHN Proxy Servers und des RHN Satellite Servers macht die Implementierung auf Clients relativ einfach, indem ein öffentliches CA-SSL-Z ertifikat und eine RPM-Datei generiert werden. Die Installationsprozesse legen Kopien einer oder beider Dateien ö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 es ansehen: Das öffentliche SSL-Z ertifikat der CA in diesem Verzeichnis kann mithilfe von wget oder curl auf ein Client-System heruntergeladen werden. Z um Beispiel: curl -O wget 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 \ Überprüfen Sie den tatsächlichen Namen des Z ertifikats oder der RPM-Datei, bevor Sie diese Befehle ausführen Konfiguration der Client-Systeme Nachdem die RPM-Datei oder das Rohdaten-Z ertifikat auf einem Client-System implementiert wurde, muss der Administrator dieses Systems die Konfigurationsdateien des Red Hat Update Agents und des Red Hat Network Registraction Clients anpassen, um das neue öffentliche CA-SSL-Z ertifikat zu verwenden und sich mit dem entsprechenden RHN Proxy Server oder RHN Satellite Server verbinden zu können. Der allgemein übliche Speicherort für dieses öffentliche CA-SSL-Zertifikat ist das 19

23 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch /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

24 Kapitel 4. Import angepasster GPG-Schlüssel Kapitel 4. Import angepasster GPG-Schlüssel Allen Kunden, die ihre eigenen RPM-Dateien sicher erstellen und verteilen möchten, wird dringend empfohlen, alle angepassten RPM-Dateien mit GNU Privacy Guard (GPG) zu signieren. Das Generieren von GPG-Schlüsseln und das Erstellen von GPG-signierten Paketen wird im Red Hat Network Channel- Managementhandbuch ausführlicher 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: Z unächst 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 gilt für alle Systeme gleichermaßen und kann unter Verwendung des empfohlenen Website-Verfahrens zur Implementierung von RHN Client-Applikationen abgewickelt werden. (Siehe Abschnitt 2.1, Implementieren der neuesten Red Hat Network Client-RPMs.) 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 durch den Dateinamen Ihres Schlüssels zu ersetzen. Sobald der Schlüssel auf dem Client-Dateisystem vorhanden ist, 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 Nachdem der GPG-Schlüssel 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 wurden. Anmerkung Wenn Sie angepasste RPMs und Channels verwenden, erstellen Sie stets einen angepassten GPG-Schlüssel für diese Pakete. Der Speicherort für den GPG-Schlüssel muss zudem im Kickstart-Profil eingefügt werden. Der angepasste GPG-Schlüssel muss zu den Client-Systemen hinzugefügt werden, andernfalls wird die Installation fehlschlagen. 21

25 Red Hat Network Satellite 5.5 Client-Konfigurationshandbuch Kapitel 5. Verwendung von RHN Bootstrap Red Hat Network bietet ein T ool, das viele Schritte der in vorhergehenden Kapiteln beschriebenen manuellen Konfiguration automatisiert: RHN Bootstrap. RHN Bootstrap 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 Z weck und ist standardmäßig bereits auf RHN Satellite Server und RHN Proxy Server installiert. 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 umleiten Angepasste GPG-Schlüssel importieren SSL-Z ertifikate installieren Das System bei RHN und speziellen Systemgruppen und Channels mithilfe von Aktivierungsschlüsseln anmelden Verschiedene Post-Konfigurationsaufgaben, 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. Sicherheitstools, 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 Verarbeitung von T ransaktionen verwendet werden. Dies eröffnet daher die Möglichkeit, dass sich jemand als Satellite ausgibt und unerwünschte Daten überträgt. Dieses Risiko wird dadurch minimiert, dass beinahe alle Satellite-Server und Client-Systeme hinter Kunden-Firewalls operieren und für externen Datenverkehr nicht 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, Konfiguration der RHN Bootstrap Optionen für eine vollständige Liste der Optionen dieses T ools. Außerdem finden Sie in Anhang A, Beispiel für ein Bootstrap-Skript ein Beispielskript Vorbereitung der RHN Bootstrap Installation 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 aufgerufen werden. Sie können Aktivierungsschlüssel dazu verwenden, um in einem einzigen Vorgang Red Hat Enterprise Linux Systeme zu registrieren, Berechtigungen für einen RHN-Servicelevel an diese Systeme vergeben und bestimmte Channels und Systemgruppen für diese Systeme zu subskribieren. Beachten Sie dabei, dass der Organisationsaccount verfügbare Management-Berechtigungen haben muss, um einen Aktivierungsschlüssel verwenden zu können. Bei der Verwendung mehrerer Aktivierungsschlüssel gleichzeitig sind dagegen Provisioning-Berechtigungen nötig. Generieren Sie 22