Red Hat Network Satellite 5.5 Handbuch zum Einstieg

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Provisioning und Deployment mit Red Hat Network Satellite Ausgabe 2 Red Hat Dokumentationsteam

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Provisioning und Deployment mit Red Hat Network Satellite Ausgabe 2 Red Hat Do kumentatio nsteam

Rechtlicher Hinweis Copyright 2011 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 Dieses Handbuch enthält Informationen und Anleitungen zum Einsatz der Kickstart-Provisioning- Funktionalität im Red Hat Network Satellite. Weitere Satellite-Grundlagen finden Sie im Satellite Benutzerhandbuch.

Inhaltsverzeichnis Inhaltsverzeichnis. Kapitel....... 1.... Einführung................................................................................. 3........... Kapitel....... 2.... Kickstart................................................................................. 5.......... 2.1. Erforderliche Pakete 5 2.2. Kickstart-Bäume 5 2.3. Kickstart-Profile 7 2.4. Verwenden von Vorlagen 11 2.5. Kickstarten eines Rechners 14 2.5.1. Kickstarten von Bare Metal 14 2.5.2. Reprovisioning 16 2.5.3. Provisioning virtualisierter Gäste 17 2.5.4. Provisioning durch einen RHN Proxy 18. Kapitel....... 3.... Multiple........ Satellites........................................................................ 19........... 3.1. Inter-Satellite-Synchronisation 19 3.2. Organisationssynchronisation 20 3.3. ISS-Anwendungsfälle 21. Kapitel....... 4... Weiterführende................. API-Methoden............... und.... Befehle........................................... 24............ 4.1. Die XML-RPC-Programmierschnittstelle (API) 24 4.2. Cobbler 26 4.3. Koan 30. Kapitel....... 5.... Suche....... und.... Bereinigung............. von..... Fehlern................................................... 32........... 5.1. Weboberfläche 32 5.2. Anaconda 32 5.3. T racebacks 33 5.4. Registrierung 34 5.5. Kickstarts und Snippets 35. Versionsgeschichte.......................................................................................... 37........... 1

2 Red Hat Network Satellite 5.5 Handbuch zum Einstieg

Kapitel 1. Einführung Kapitel 1. Einführung Provisioning bezeichnet die Konfiguration eines physischen oder virtuellen Rechners auf einen vordefinierten, bekannten Z ustand. Red Hat Network (RHN) Satellite nutzt zum Provisioning von Systemen den Kickstart-Prozess. Um die Provisioning-Funktionalität zu nutzen, sind ein oder mehrere Zielrechner erforderlich. Bei den Z ielrechnern kann es sich entweder um physische Bare-Metal-Systeme oder um virtuelle Maschinen handeln. Um RHN Satellite zum Provisioning von virtuellen Maschinen nutzen zu können, müssen die virtuellen Maschinen entweder mit Xen oder KVM erstellt werden. Definitionen Einige Begriffe, die im Laufe dieses Handbuchs verwendet werden: Kickstart Der Vorgang einer automatisierten Installation eines Red Hat Systems, die nur wenig oder keinerlei Eingaben vom Benutzer erfordert. Eigentlich bezieht sich der Begriff Kickstart auf einen Mechanismus im Anaconda-Installationsprogramm, mithilfe dessen Sie dem Installationsprogramm eine detaillierte Beschreibung der gewünschten Inhalte und Konfigurationen eines Rechners zur Verfügung stellen können. Solch eine detaillierte Systemdefinition wird Kickstart-Profil genannt. Kickstart-Profil Die Kickstart-Datei ist eine T extdatei, die alle Optionen spezifiziert, die zum Kickstart eines Rechners nötig sind, u.a. Informationen über Partitionierung, Netzwerkkonfiguration und zu installierende Pakete. In RHN Satellite ist ein Kickstart-Profil eine Obermenge einer herkömmlichen Anaconda-Kickstart-Definition, da die Implementierung von Satellite auf Cobbler's Erweiterungen zum Kickstart aufbaut. Ein Kickstart-Profil setzt das Vorliegen eines Kickstart-Baums voraus. Kickstart-Baum Die zum Kickstart eines Rechners notwendige Software samt unterstützender Dateien; oft auch "Installationsbaum" genannt. Es handelt sich hierbei in der Regel um die Verzeichnisstruktur und Dateien vom Installationsmedium, das für eine bestimmte Release herausgegeben wurde. In Cobbler-Begriffen ist ein Kickstart-Baum T eil einer Distribution. PXE (Preboot execution Environment) Ein Protokoll auf niedriger Ebene, das den Kickstart von Bare-Metal-Rechnern (normalerweise physische, oder reale, Rechner) beim Start ohne Vorkonfiguration des Z ielrechners selbst erlaubt. PXE ist auf einen DHCP-Server angewiesen, um Clients über Bootstrap-Server zu informieren (für dieses Handbuch gehen wir von Satellite 5.5 Installationen oder höher aus). Um PXE einsetzen zu können, muss es in der Firmware des Z ielrechners unterstützt werden. Es ist zwar möglich, die Funktionalitäten des Satellites zur Virtualisierung und Neuinstallation ohne PXE zu nutzen, allerdings ist PXE sehr hilfreich zum Booten von neuen physischen Rechnern oder zur Neuinstallation von Rechnern, die nicht beim Satellite angemeldet sind. Provisioning-Szenarien Die vom RHN Satellite unterstützten Provisioning-Szenarien: Neue Installationen Provisioning eines Systems, auf dem bislang noch keinerlei Betriebssystem installiert war (auch 3

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Bare-Metal-Installation genannt). Virtuelle Installationen Satellite unterstützt KVM, Xen voll virtualisierte Gäste und Xen paravirtualisierte Gäste. Reprovisioning Sowohl auf physischen Systemen als auch auf Gastsystemen kann Reprovisioning durchgeführt werden, vorausgesetzt, diese wurden bei derselben Satellite-Instanz registriert. Siehe Abschnitt 2.5.2, Reprovisioning. 4

Kapitel 2. Kickstart Kapitel 2. Kickstart 2.1. Erforderliche Pakete Falls Sie eine angepasste Distribution verwenden, benötigen Sie die folgenden Pakete, die in jedem rhn-tools Red Hat Network Channel erhältlich sind: koan spacewalk-koan Es ist ratsam, einen vorhandenen rhn-tools-channel zu klonen, um von Ihrem angepassten Channel Z ugriff auf diese Pakete zu erhalten. RHN Satellite erwartet die kernel- und initrd-dateien an bestimmten Speicherorten innerhalb des Kickstart-Baums. Allerdings unterscheiden sich diese Speicherorte je nach Architektur. Die nachfolgende T abelle zeigt die verschiedenen Speicherorte: T abelle 2.1. Erforderliche Distributionsdateien nach Architektur Architektur Kernel Initiales RAM-Disk-Image IBM System z TREE_PATH/images/kernel.img TREE_PATH/images/initrd.img PowerPC TREE_PATH/ppc/ppc64/vmlinuz TREE_PATH/images/pxeboot/vmlinux Alle anderen Architekturen TREE_PATH/images/pxeboot/vmlinuz TREE_PATH/images/pxeboot/initrd.img 2.2. Kickstart-Bäume Sie müssen mindestens einen Kickstart-Baum auf Ihrem Satellite installiert haben, um Kickstart- Provisioning nutzen zu können. Kickstart-Bäume können entweder automatisch oder manuell installiert werden. Prozedur 2.1. Automatische Installation von Kickstart-Bäumen Für alle Distributionen, die im RHN einen Basis-Channel haben, können Kickstart-Bäume automatisch installiert werden. Dies erfolgt als T eil der normalen Channel-Synchronisation mittels satellite-sync. 1. Wählen Sie, auf welcher Distribution Ihre Kickstarts basieren sollen und lokalisieren Sie den Basis-Channel dieser Distribution samt zugehörigem RHN T ools Channel. Möchten Sie beispielsweise Red Hat Enterprise 5 für die x86-architektur verwenden, benötigen Sie den rhel-i386-server-5-channel samt zugehörigem RHN-T ools-channel rhn-toolsrhel-i386-server-5. 2. Falls Sie einen verbundenen Satellite verwenden, synchronisieren Sie Ihren Satellite direkt mit den Red Hat Servern mittels satellite-sync. Ist Ihr Satellite nicht verbunden, müssen Sie sich nicht verbundene Channel-Dumps von den Red Hat Servern besorgen und mit diesen synchronisieren. 3. Eine Synchronisation des Channels erzeugt automatisch einen zugehörigen Kickstart-Baum für diese Distribution. Prozedur 2.2. Manuelle Installation von Kickstart-Bäumen Falls Sie eine benutzerdefinierte Distribution, die in der Regel von Red Hat nicht unterstützt wird, oder eine Beta-Version von Red Hat Enterprise Linux kickstarten möchten, müssen Sie manuell einen 5

Red Hat Network Satellite 5.5 Handbuch zum Einstieg entsprechenden Kickstart-Baum erstellen. Sie benötigen ein Installations-ISO der Distribution, die Sie kickstarten möchten. 1. Kopieren Sie das Installations-ISO auf Ihren Satellite-Server und hängen es unter /m nt/iso ein. 2. Kopieren Sie die Inhalte des ISOs an einen benutzerdefinierten Speicherort. Wir empfehlen Ihnen, ein Verzeichnis innerhalb von /var/satellite anzulegen für alle angepassten Distributionen. So könnten Sie beispielsweise die Inhalte einer RHEL-Beta-Distribution nach /var/satellite/custom-distro/rhel-i386-server-5.3-beta/ kopieren. 3. Erstellen Sie einen angepassten Software-Channel über die RHN Satellite Weboberfläche. Navigieren Sie dazu zu Channels Software-Channels verwalten Neuen Channel erstellen und erzeugen einen übergeordneten Channel mit geeignetem Namen und Label. Um beim Beispiel der RHEL-Beta-Version zu bleiben, könnten wir das Label rhel-5.3-beta verwenden. 4. Kopieren Sie mithilfe des rhnpush-befehls die Software-Pakete von ihrem Speicherort im Baum auf den neu erstellten Software-Channel. rhnpush --server=http://localhost/app -c 'rhel-5.3-beta' \ -d /var/satellite/custom-distro/rhel-i386-server-5.3-beta/server/ Das Unterverzeichnis innerhalb des Baums kann sich abhängig von Ihrer Distribution unterscheiden. 5. Nachdem die Software-Pakete auf den Channel kopiert wurden, können Sie mithilfe des rm- Befehls aus dem Baum gelöscht werden. Die Pakete sind weiterhin auf dem Satellite-Server innerhalb des Channels gespeichert und sind nicht länger im Baum erforderlich. rm /var/satellite/custom-distro/rhel-i386-server-5.3-beta/server/*.rpm Anmerkung Falls Sie es vorziehen, können Sie die Software-Pakete auch im Kickstart-Baum belassen. Sie könnten sie somit zu einem späteren Z eitpunkt mithilfe des yum-befehls installieren. 6. Erstellen Sie die Distribution auf der RHN Satellite Weboberfläche. Navigieren Sie zu Systeme Kickstart Distributionen Neue Distribution erstellen, um die Distribution zu erstellen. Wählen Sie ein passendes Label und den vollständigen Baumpfad (wie z.b. /var/satellite/custom-distro/rhel-i386-server-5.3-beta/), sowie den zuvor erstellen Basis-Channel und die richtige Installer-Generation (wie z.b. Red Hat Enterprise Linux 5). Um die Erstellung abzuschließen, wählen Sie Kickstart-Distribution erstellen. 7. Um dieselbe Software über mehrere Umgebungen und Systeme hinweg zu pflegen, kann der RHN T ools Sub-Channel von einem vorhandenen Red Hat Enterprise Linux Basis-Channel als Sub- Channel des neu erstellten Basis-Channels geklont werden. Sie können einen Sub-Channel auf mehrere Arten klonen: a. Klicken Sie auf der Satellite-Weboberfläche auf Channels Software-Channels verwalten Channel klonen b. Wählen Sie den Sub-Channel, den Sie klonen möchten, aus der Drop-Down-Liste Klonen von: und wählen Sie den Klonstatus. c. Klicken Sie auf Channel erstellen. d. Geben Sie die nötigen Informationen ein und wählen Sie den übergeordneten Channel, 6

Kapitel 2. Kickstart unter dem der geklonte untergeordnete Channel angelegt werden soll. e. Klicken Sie auf Channel erstellen. Abbildung 2.1. Kickstart-Distribution erstellen 2.3. Kickstart-Profile Kickstart-Profile spezifizieren die für die Installation zu verwendenden Konfigurationsoptionen. Kickstart-Profile können mithilfe eines Assistenten erstellt werden, der ein Profil erstellt auf Grundlage der Antworten, die Sie auf eine Reihe von Fragen geben. Oder sie können unter Verwendung der Raw- Methode erstellt werden, die Ihnen die vollständige Kontrolle über die Inhalte des Profils erlaubt. Prozedur 2.3. Erstellen eines Kickstart-Profils mit dem Assistenten 1. Klicken Sie auf Systeme Kickstart Neues Kickstart-Profil erstellen 2. Geben Sie ein passendes Label an, und wählen Sie den gewünschten Basis-Channel und den Kickstartbaren Baum 3. Wählen Sie den gewünschten Virtualisierungstyp. Siehe Virtualisierungstypen für weitere Informationen über Virtualisierungstypen. Klicken Sie auf Weiter, um fortzufahren. 4. Wählen Sie den Download-Speicherort für das Kickstart-Profil. Falls Sie eine angepasste Distribution verwenden, geben Sie den Speicherort als URL an (sowohl HTTP als auch FTP 7

Red Hat Network Satellite 5.5 Handbuch zum Einstieg werden unterstützt), andernfalls übernehmen Sie die Standardoption. Klicken Sie auf Weiter, um fortzufahren. 5. Geben Sie das Root-Passwort an und klicken auf Abschließen, um die Profilerstellung abzuschließen. 6. Das vollständige Kickstart-Profil wird nun erstellt. Sie können sich das Profil ansehen, indem Sie auf Kickstart-Datei klicken. Prozedur 2.4. Erstellen eines Kickstart-Profils mit der Raw-Methode 1. Klicken Sie auf Systeme Kickstart Neue Kickstart-Datei hochladen 2. Geben Sie ein passendes Label an, und wählen Sie die gewünschte Distribution. 3. Wählen Sie den gewünschten Virtualisierungstyp. Siehe Virtualisierungstypen für weitere Informationen über Virtualisierungstypen. 4. Wenn Sie bereits eine vorhandene Kickstart-Datei haben, können Sie diese hochladen. Andernfalls schreiben Sie das Kickstart-Profil einfach in das T extfeld Dateiinhalte. Sehen Sie im Folgenden eine beispielhafte Raw-Kickstart-Datei, die Sie als Ausgangspunkt verwenden können: install text network --bootproto dhcp url --url http://$http_server/ks/dist/org/1/ks-rhel-i386-server-5 lang en_us keyboard us zerombr clearpart --all part / --fstype=ext3 --size=200 --grow part /boot --fstype=ext3 --size=200 part swap --size=1000 --maxsize=2000 bootloader --location mbr timezone America/New_York auth --enablemd5 --enableshadow rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0 selinux --permissive reboot firewall --disabled skipx key --skip %packages @ Base %post $SNIPPET('redhat_register') 5. Da der RHN Satellite Server die angegebene Distribution nicht automatisch als url im Kickstart verwendet, müssen Sie selbst die Option url --url in Ihrem Profil angeben. Dies könnte etwa folgendermaßen aussehen: url --url http://satellite.example.com/ks/dist/org/1/my_distro Ersetzen Sie m y_distro durch das Distributions-Label und 1 durch Ihre Organisations-ID. 6. Raw-Kickstart-Profile verwenden $http_server anstelle des Hostnamens des Satellites. Dies wird automatisch ausgefüllt, wenn die Kickstart-Vorlage gerendert wird. 8

Kapitel 2. Kickstart 7. Das redhat_register-snippet wird zur Handhabung der Registrierung verwendet. Abbildung 2.2. Raw Kickstart Virtualisierungstypen Mit allen Kickstart-Profilen ist ein Virtualisierungstyp verknüpft. Die nachstehende T abelle veranschaulicht die verschiedenen Optionen: 9

Red Hat Network Satellite 5.5 Handbuch zum Einstieg T abelle 2.2. Virtualisierungstypen T yp Beschreibung Verwendung Keiner Keine Virtualisierung Verwenden Sie diesen T yp für normales Provisioning, Bare- Metal-Installationen, sowie für virtualisierte Installationen, die nicht auf Xen oder KVM basieren (z.b. VMware oder Virtage) KVM virtualisierter Gast KVM-Gäste Verwenden Sie diesen T yp für das Provisioning von KVM- Gästen Xen voll virtualisierter Gast Xen-Gäste Verwenden Sie diesen T yp für das Provisioning von Xen- Gästen Anmerkung Diese Option erfordert Hardware-Unterstützung auf dem Host, jedoch kein modifiziertes Betriebssystem in dem Gast. Xen paravirtualisierter Gast Xen Virtualisierungs- Host Xen-Gäste Xen-Hosts Verwenden Sie diesen T yp zum Provisioning eines virtuellen Gasts mit Xen- Paravirtualisierung. Paravirtualisierung ist der schnellste Virtualisierungsmodus. Er erfordert ein PAE-Flag auf der System-CPU und ein angepasstes Betriebssystem. Red Hat Enterprise Linux 5 unterstützt Gäste unter Paravirtualisierung. Verwenden Sie diesen T yp zum Provisioning eines virtuellen Hosts mit Xen- Paravirtualisierung. Xen paravirtualisierte Gäste und Hosts werden unterstützt, sofern die Hardware kompatibel ist. Kickstart-Profile für Xen-Hosts müssen das kernel-xen-paket im %packages-abschnitt enthalten. Kickstart-Profile für KVM-Hosts müssen das qem u-paket im %packages-abschnitt enthalten. 10

Kapitel 2. Kickstart Für voll virtualisierte Systeme muss ggf. die Virtualisierungsunterstützung im BIOS des Computers aktiviert werden. Anmerkung Weitere Informationen über Kickstarts finden Sie im Kapitel Kickstart Installationen im Red Hat Enterprise Linux Installationshandbuch. 2.4. Verwenden von Vorlagen Kickstart-Vorlagen (auch Templates genannt) ermöglichen es Ihnen, Variablen, Snippets und Anweisungen zur Flusskontrolle wie z.b. for-schleifen und if-anweisungen in Ihre Kickstart-Dateien einzubeziehen. Ermöglicht wird dies durch das cheetah-t ool. Es gibt eine Vielzahl von Gründen, warum Vorlagen nützlich sein können: Wenn Sie einen bestimmten Abschnitt einer Kickstart-Datei, wie z.b. den Abschnitt zur Festplattenpartitionierung, über mehrere Kickstarts hinweg wiederverwenden möchten. Wenn Sie bestimme Aktionen in %post konsistent über mehrere Kickstarts hinweg durchführen möchten. Wenn Sie ein Snippet über mehrere Server-Rollen (wie z.b. DNS-Server, Proxy-Server, und Webserver) hinweg definieren möchten. Beispielsweise könnte das folgende Snippet für den Webserver definiert sein: httpd mod_ssl mod_python Wenn Sie ein Webserver-Profil erstellen möchten, fügen Sie das Webserver-Snippet im %package- Abschnitt Ihrer Kickstart-Datei ein. Wenn Sie möchten, dass dieses Profil sowohl ein Webserver als auch ein Proxy-Server ist, können Sie beide Snippets im Paketabschnitt einfügen. Möchten Sie später ein weiteres Paket zum Webserver-Snippet hinzufügen, wie z.b. m od_perl, brauchen Sie nur das Snippet selbst zu aktualisieren, und alle Profile, die dieses Snippet enthalten, würden automatisch ebenfalls aktualisiert. Variablen Vorlagen ermöglichen es Ihnen, eine Variable zu definieren, die in der gesamten Kickstart-Datei verwendet wird. Variablen unterliegen einer Art Vererbung, die es ermöglicht, eine Variable auf einer Ebene einzustellen, diese jedoch auf darunterliegenden Ebenen außer Kraft zu setzen. Wird also eine Variable auf Systemebene eingestellt, setzt diese dieselbe Variable auf Profilebene oder Kickstart- Baumebene außer Kraft. Wird eine Variable auf Profilebene eingestellt, setzt diese dieselbe Variable auf Kickstart-Baumebene außer Kraft. Anmerkung Beachten Sie, dass Kickstart-Baumvariablen nicht für automatisch generierte Kickstart-Bäume (wie z.b. jenen, die Sie durch eine Satellite-Synchronisation erhalten) definiert werden können. Snippets 11

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Mithilfe von Snippets werden Stücke von Code über mehrere Kickstart-Vorlagen hinweg wiederverwendet. Snippets können sich über mehrere Z eilen erstrecken und Variablen enthalten. Sie können mithilfe des T exts $SNIPPET('snippet_nam e') in ein Kickstart-Profil eingefügt werden. Sie können ein Snippet für eine Paketliste erstellen, für ein %post-skript, oder für jeden anderen T ext, der normalerweise in einer Kickstart-Datei enthalten ist. Um Snippets zu verwalten, klicken Sie auf Systeme Kickstart Kickstart-Snippets. Die Kickstart-Snippets-Seite zeigt mehrere Standard-Snippets, die nicht verändert werden können, jedoch allen Organisationen zur Verfügung stehen. Standard-Snippets können in Kickstarts verwendet werden, die entweder zum RHN Satellite Server hochgeladen wurden oder dort geschrieben wurden. Standard-Snippets sind im Dateisystem des RHN Satellite Servers unter /var/lib/cobbler/snippets/ gespeichert. Unter /var/lib/rhn/kickstarts/wizard/ finden Sie eine Vorlage für einen Assistenten-Kickstart, die die verschiedenen Standard-Snippets und deren Verwendung erklärt. Das redhat_register Snippet kann dazu verwendet werden, um im Rahmen des Kickstarts Rechner bei einem RHN Satellite Server zu registrieren. Es verwendet eine Variable namens redhat_management_key, um den Rechner beim Server zu registrieren. Setzen Sie die redhat_m anagem ent_key-variable auf System-, Profil- oder Distributionsebene und fügen anschließend $SNIPPET('redhat_register') zum %post-abschnitt Ihrer Kickstart-Datei hinzu. Alle Assistenten-Kickstarts, die vom RHN Satellite Server generiert wurden, verfügen in ihrem %post- Abschnitt bereits über dieses Snippet. Der Reiter Angepasste Snippets ermöglicht Ihnen das Ansehen und Bearbeiten von Snippets, die für Ihre Organisation erstellt wurden. Sie können neue Snippets erstellen, indem Sie auf Neues Snippet erstellen klicken. Angepasste Snippets werden im /var/lib/rhn/kickstarts/snippets/-verzeichnis gespeichert. RHN Satellite speichert Snippets für verschiedene Organisationen in verschiedenen Verzeichnissen; angepasste Snippets werden demnach mit einem Dateinamen ähnlich dem folgenden gespeichert, wobei 1 die Organisations-ID ist: $SNIPPET('spacewalk/1/snippet_name') Um zu bestimmen, welchen T ext Sie in den Kickstart einfügen müssen, um Ihr Snippet zu verwenden, suchen Sie nach der Spalte Snippet Makro in der Snippet-Liste oder auf der Snippet-Detailseite. Anmerkung Snippets existieren auf globaler Ebene und besitzen nicht die gleiche Vererbungsstruktur wie Variablen. Sie können Variablen jedoch innerhalb von Snippets verwenden, um deren Verhaltensweisen zu verändern abhängig von dem System, das den Kickstart anfordert. 12

Kapitel 2. Kickstart Abbildung 2.3. Kickstart-Snippets Fluchtsymbole für Sonderzeichen Die $ und # Z eichen werden bei der Erstellung von Vorlagen zur Spezifizierung von Variablen und der Flusskontrolle verwendet. Falls Sie diese Z eichen in einem Skript für andere Z wecke benötigen, müssen sie mit Fluchtsymbolen versehen werden, damit sie nicht als Variablen gedeutet werden. Sie erreichen dies auf mehrere Arten: Setzen Sie ein Backslash-Z eichen (\) vor jedes $ oder # Z eichen, das in der Vorlage ignoriert werden soll. Schließen Sie das gesamte Skript in #raw... #end raw ein. Alle %pre und %post Skripte, die mithilfe des Kickstart-Assistenten erzeugt werden, sind standardmäßig von #raw...#end raw eingeschlossen. Dies kann geändert werden mittels des T em plate-auswahlkästchens beim Bearbeiten eines %post oder %pre-skripts. Fügen Sie #errorcatcher Echo in der ersten Z eile des Snippets ein. 13

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Beispiel 2.1. Fluchtsymbole für Sonderzeichen in Vorlagen Dieses Beispiel beschreibt, wie Sonderzeichen in Kickstart-Vorlagen mit Fluchtsymbolen versehen werden. Das folgende Bash-Skript soll in einem %post-abschnitt eingefügt werden: %post echo $foo > /tmp/foo.txt Wird das $-Z eichen nicht mit einem Fluchtsymbol versehen, wird die T emplating-engine versuchen, eine Variable namens $foo zu finden und wird schließlich scheitern, da foo nicht als Variable existiert. Der einfachste Weg, das $-Z eichen mit einem Fluchtsymbol zu versehen, ist mithilfe des Backslash- Zeichens (\): %post echo \$foo > /tmp/foo.txt Dadurch wird \$foo als $foo gerendert. Eine zweite Methode ist das Einschließen des gesamten Bash-Skripts in #raw... #end raw, und zwar wie folgt: %post #raw echo $foo > /tmp/foo.txt #end raw Bei der letzten Methode fügen Sie #errorcatcher Echo in der ersten Z eile Ihrer Kickstart-Vorlage ein. Dies weist die T emplating-engine an, jegliche nicht existierenden Variablen zu ignorieren und den T ext wie vorliegend auszugeben. Diese Option ist bereits in den Assistenten-Kickstarts enthalten und kann auch in die manuell erstellten Raw-Kickstarts eingefügt werden. 2.5. Kickstarten eines Rechners 2.5.1. Kickstarten von Bare Metal Wenn ein Rechner kein vorhandenes Betriebssystem oder das falsche Betriebssystem installiert hat, nennt man dies einen Bare-Metal-Rechner. Es gibt zwei Arten von Provisioning für einen Bare-Metal- Rechner: Via standardmäßigem Installationsmedium für das Betriebssystem Via PXE-Boot Prozedur 2.5. Booten vom Installationsmedium 1. Legen Sie das Installationsmedium in Ihren Rechner ein. Das Medium muss dem Kickstart entsprechen, den Sie zu verwenden planen. Wenn Ihr Kickstart beispielsweise zur Verwendung des ks-rhel-i386-server-5-u2 Kickstart-Baums konfiguriert wurde, müssen Sie das Red Hat Enterprise Linux 5.2 i386 Installationsmedium verwenden. 14

Kapitel 2. Kickstart 2. Sobald die Boot-Eingabeaufforderung erscheint, aktivieren Sie den Kickstart durch Eingabe des folgenden Befehls: linux ks=http://satellite.example.com/path/to/kickstart 3. Das System wird booten, den Kickstart herunterladen und automatisch installieren. Prozedur 2.6. PXE-Booting Um einen PXE-Boot durchführen zu können, muss jedes Ihrer Systeme PXE-Boot auf BIOS-Ebene unterstützen. Nahezu sämtliche moderne Hardware sollte dazu in der Lage sein. Z usätzlich müssen Sie über einen DHCP-Server verfügen, selbst wenn Ihre Systeme nach der Installation statisch konfiguriert werden sollen. 1. Wichtig Falls Sie auf einem anderen System im Netzwerk einen DHCP-Server implementiert haben, benötigen Sie administrativen Z ugriff auf den DHCP-Server, um die DHCP- Konfigurationsdatei zu bearbeiten. Falls sich Ihre Rechner auf mehreren Netzwerken befinden, müssen Sie sicherstellen, dass sich all Ihre Rechner mit dem DHCP-Server verbinden können. Sie erreichen dies durch das Multi- Homing Ihres DHCP-Servers (entweder echtes oder sog. "trunked" VLAN) und der Konfiguration Ihrer Router oder Switches zur Weiterleitung des DHCP-Protokolls über Netzwerkgrenzen hinweg. Konfigurieren Sie Ihren DHCP Server derart, dass dieser auf den PXE-Server verweist, indem Sie die next-server-adresse für Systeme einstellen, die Sie vom RHN Satellite verwalten lassen möchten. Um bei der Installation Hostnamen zu verwenden, konfigurieren Sie den DHCP-Server, um auf die Domain und IP-Adressen zu verweisen, gefolgt von den folgenden Z eilen: option domain-name DOMAIN_NAME; option domain-name-servers IP_ADDRESS1, IP_ADDRESS2; 2. Wechseln Sie auf dem DHCP-Server zum Root-Benutzer und öffnen Sie die /etc/dhcpd.conf- Datei. Fügen Sie eine neue Klasse hinzu mit Optionen zum Durchführen einer PXE-Boot- Installation: allow booting; allow bootp; class "PXE" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; next-server 192.168.2.1; filename "pxelinux.0"; } Diese Klasse wird die folgenden Aktionen durchführen: a. Aktivieren des Netzwerk-Boots mit dem bootp-protokoll b. Erstellen einer Klasse namens PXE. Falls ein System PXE als erste Boot-Priorität konfiguriert hat, wird es als PXEClient identifiziert. c. Der DHCP-Server verweist das System an den Cobbler-Server unter der IP-Adresse 192.168.2.1 15

Red Hat Network Satellite 5.5 Handbuch zum Einstieg d. Der DHCP-Server verweist auf die Boot-Image-Datei unter /var/lib/tftpboot/pxelinux.0 3. Konfigurieren Sie Xinetd. Xinetd ist ein Daemon, der eine Reihe von Diensten verwaltet, einschließlich T FT P, der FT P-Server, der zur Übertragung des Boot-Image an einen PXE Client verwendet wird. Aktivieren Sie Xinetd mithilfe des chkconfig-befehls: chkconfig xinetd on Wechseln Sie alternativ zum Root-Benutzer und öffnen die /etc/xinetd.d/tftp-datei. Suchen Sie die Z eile disable = yes und ändern diese auf disable = no. 4. Starten Sie den Xinetd-Dienst, damit T FT P ab sofort das pxelinux.0-boot-image bereitstellen kann. chkconfig --level 345 xinetd on /sbin/service xinetd start Der chkconfig-befehl aktiviert den xinetd-dienst für alle Benutzer-Runlevel, während der /sbin/service-befehl den xinetd-dienst sofort aktiviert. 2.5.2. Reprovisioning Die Neuinstallation eines vorhandenen Systems wird als Reprovisioning bezeichnet. Reprovisioning kann über die RHN Satellite Weboberfläche durchgeführt werden, und das System wird dasselbe Systemprofil verwenden, das es bereits vor dem Reprovisioning verwendete. Dadurch wird ein großer T eil der Informationen und Einstellungen des Systems bewahrt. Sie können das Reprovisioning auf dem Provisioning-Reiter einplanen, wenn Sie ein System ansehen. Falls Sie zusätzliche Optionen konfigurieren möchten, klicken Sie auf die Seite Erweiterte Konfiguration. Auf dieser Seite können Sie Details wie z.b. Kernel-Optionen, Netzwerkinformationen und Paketprofil-Synchronisation konfigurieren. Der Kernel-Optionen-Abschnitt bezieht sich auf Kernel-Optionen während des Kickstarts. Post-Kernel-Optionen sind die Kernel-Optionen, die nach Abschluss des Kickstarts verwendet werden, wenn das System zum ersten Mal hochfährt. Beispiel 2.2. Konfiguration von Kernel-Optionen und Post-Kernel-Optionen Dieses Beispiel beschreibt den Unterschied zwischen Kernel-Optionen und Post-Kernel-Optionen im Reprovisioning-Konfigurationsprozess. Wenn Sie eine VNC-Verbindung herstellen möchten, um den Kickstart von Remote aus überwachen zu können, fügen Sie vnc vncpassword=password in der Kernel Options-Z eile ein Wenn Sie möchten, dass der Kernel des neuen Systems mit der noapic-kernel-option bootet, fügen Sie noapic zur Post Kernel Options-Z eile hinzu. Prozedur 2.7. Dateierhaltung Mithilfe des Dateierhaltungs-Features kann verhindert werden, dass Dateien während des Reprovisionings verloren gehen. Dieses Feature speichert Dateien während des Kickstarts vorübergehend und stellt sie wieder her, nachdem das Reprovisioning abgeschlossen wurde. 16

Kapitel 2. Kickstart Anmerkung Dateierhaltungslisten sind nur verfügbar für Assistenten-Kickstarts und können nur während des Reprovisionings verwendet werden. 1. Klicken Sie auf Systeme Kickstart Dateierhaltung Neue Dateierhaltungsliste erstellen und erstellen Sie eine Liste der zu erhaltenden Dateien. 2. Klicken Sie auf Systeme Kickstart Profile und verknüpfen Sie die Dateierhaltungsliste mit einem Kickstart, indem Sie das gewünschte Profil auswählen. 3. Klicken Sie auf System-Details Dateierhaltung und wählen Sie die Dateierhaltungsliste. 2.5.3. Provisioning virtualisierter Gäste Provisioning virtualisierter Gäste wird im RHN Satellite 5.5 unterstützt unter Verwendung der folgenden Virtualisierungstechnologien: KVM virtualisierter Gast Xen voll virtualisierter Gast Xen paravirtualisierter Gast Prozedur 2.8. Provisioning eines virtualisierten Gasts 1. Vergewissern Sie sich, dass das Host-System über eine Virtualisierungs- oder Virtualisierungsplattform-Systemberechtigung verfügt. 2. Wählen Sie auf der System e-seite den richtigen virtuellen Host und klicken Sie anschließend auf Virtualisierung Provisioning. Wählen Sie das entsprechende Kickstart-Profil und geben Sie einen Gastnamen ein. 3. Um zusätzliche Parameter wie z.b. Gastspeicher und CPU-Verbrauch zu konfigurieren, klicken Sie auf die Schaltfläche Erweiterte Konfiguration. Dort haben Sie die Möglichkeit, folgende Optionen zu konfigurieren: Netzwerk: statisch oder DHCP Kernel-Optionen Paketprofil-Synchronisation: Wenn der Kickstart abgeschlossen ist, synchronisiert das System sein Paketprofil mit dem eines anderen Systems oder einem gespeicherten Profil Speicherzuweisung: RAM, standardmäßig 512 MB Virtuelle Plattengröße Virtuelle CPUs (standardmäßig 1) Virtuelle Bridge: Die Netzwerk-Bridge, die zur Installation genutzt wird. Standardmäßig xenbr0 für Xen-Provisioning und virbr0 für KVM. Anmerkung Die virbr0 Netzwerk-Bridge erlaubt keinen externen Netzwerkverkehr. Falls Sie externen Netzwerkzugriff benötigen, konfigurieren Sie den Host stattdessen zur Erstellung einer echten Bridge. xenbr0 ist eine echte Bridge, weshalb empfohlen wird, diese nach Möglichkeit zu verwenden. Virtueller Speicherpfad: Pfad zu entweder einer Datei, einem logischen LVM-Datenträger, einem Verzeichnis oder Blockgerät, in dem die Festplattendaten des Gasts gespeichert 17

Red Hat Network Satellite 5.5 Handbuch zum Einstieg werden sollen, z.b. /dev/sdb, /dev/logvol00/mydisk, VolGroup00 oder /var/lib/xen/im ages/m ydisk. 4. Klicken Sie auf Kickstart einplanen und fertigstellen. 2.5.4. Provisioning durch einen RHN Proxy Provisioning kann auch unter Verwendung eines RHN Proxys erfolgen, der installiert und beim RHN Satellite registriert wurde. 1. Wählen Sie beim Provisioning eines virtuellen Gasts oder beim Reprovisioning eines Systems den gewünschten Proxy aus dem Satellite Proxy wählen Drop-Down-Menü. 2. Ersetzen Sie für eine Bare-Metal-Installation den vollqualifizierten Domainnamen (FQDN) des RHN Satellites durch den FQDN des Proxys. Falls die URL zur Kickstart-Datei beispielsweise folgendermaßen lautet: http://satellite.example.com/ks/cfg/org/1/label/myprofile Dann verwenden Sie zum Kickstart des Proxys: http://proxy.example.com/ks/cfg/org/1/label/myprofile 18

Kapitel 3. Multiple Satellites Kapitel 3. Multiple Satellites Die Inter-Satellite Synchronisation (ISS) ermöglicht es Ihnen, Inhalte zwischen mehreren Satellites zu koordinieren. Dieses Feature kann auf verschiedene Arten eingesetzt werden, je nach Anforderungen Ihrer Organisation. Dieses Kapitel enthält einen Abschnitt über Anwendungsfälle und erläutert, wie ISS für die Ansprüche Ihrer Organisation am besten eingerichtet werden kann. ISS-Voraussetzungen Folgende Bedingungen müssen für den Einsatz von ISS erfüllt sein: Zwei oder mehr RHN Satellite Server Mindestens ein RHN Satellite, der mit mindestens einem Channel bestückt ist Für sichere Verbindungen benötigt jeder Slave RHN Satellite zudem ein SSL-Z ertifikat vom Master RHN Satellite 3.1. Inter-Satellite-Synchronisation Prozedur 3.1. Konfiguration des Master-Servers Auf dem Master-Server wird bestimmt, welche Dateien auf die anderen Satellites synchronisiert werden. 1. Aktivieren Sie das Inter-Satellite Synchronisation (ISS) Feature. Öffnen Sie dazu die /etc/rhn/rhn.conf-datei und ändern die folgende Z eile bzw. fügen diese ein: disable_iss=0 2. Suchen Sie in der /etc/rhn/rhn.conf-datei nach der Z eile allowed_iss_slaves=. Standardmäßig sind keine zu synchronisierenden Slave-Satellites angegeben. Geben Sie also die Hostnamen aller Slave-Satellite-Server an, durch Kommas voneinander getrennt: allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org 3. Speichern Sie die Konfigurationsdatei ab und starten den httpd-dienst neu: service httpd restart Prozedur 3.2. Konfiguration der Slave-Server Slave-Satellite-Server sind diejenigen Rechner, deren Inhalte mit dem Master-Server synchronisiert werden. 1. Um Inhalte sicher auf die Slave-Server zu übertragen, benötigen Sie das ORG-SSL-Z ertifikat von Ihrem Master-Server. Sie können das Z ertifikat über HT T P vom /pub/-verzeichnis eines beliebigen Satellites heruntergeladen. Die Datei heißt RHN-ORG-T RUST ED-SSL-CERT, kann jedoch umbenannt und an einem beliebigen Speicherort auf dem Slave-Satellite abgelegt werden, wie z.b. im /usr/share/rhn/-verzeichnis. 2. Sehen Sie sich die Liste der Channels, die zur Synchronisation vom Master-Server zur Verfügung stehen, mithilfe des folgenden Befehls an. Dies zeigt sowohl offizielle Red Hat Channels als auch jegliche verfügbaren angepassten Channels: satellite-sync --iss-parent=master.satellite.example.com --cacert=/usr/share/rhn/rhn-org-trusted-ssl-cert --list-channels 19

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Ersetzen Sie dabei master.satellite.example.com durch den Hostnamen des Master- Servers. Prozedur 3.3. Durchführen einer Inter-Satellite-Synchronisation Nachdem die Master- und Slave-Server konfiguriert wurden, können Sie nun eine Synchronisation zwischen den beiden durchführen. 1. Öffnen Sie auf den Slave-Servern die /etc/rhn/rhn.conf-datei in einem T exteditor und fügen Sie den Hostnamen und den Pfad der SSL-Z ertifikatsdatei des Master-Servers ein: iss_parent iss_ca_chain = master.satellite.example.com = /usr/share/rhn/rhn-org-trusted-ssl-cert 2. Beginnen Sie die Synchronisation durch Ausführen des Befehls satellite-sync: satellite-sync -c your-channel Anmerkung Befehlszeilenoptionen, die Sie beim satellite-sync-befehl mit angeben, setzen die Standardeinstellungen oder angepasste Einstellungen der /etc/rhn/rhn.conf-datei außer Kraft. 3.2. Organisationssynchronisation ISS kann auch dazu verwendet werden, um Inhalte in eine bestimmte Organisation zu importieren. Dies kann entweder lokal erfolgen oder durch Synchronisation von Remote aus. Diese Funktion ist hilfreich für einen nicht verbundenen Satellite mit mehreren Organisationen, wo Inhalte über Channel-Dumps oder durch Export von verbundenen Satellites und anschließenden Import zum nicht verbundenen Satellite bezogen werden. Organisationssynchronisation kann verwendet werden, um angepasste Channels von verbundenen Satellites zu exportieren. Es kann auch effektiv dazu genutzt werden, um Inhalte zwischen Organisationen zu verschieben. Organisationssynchronisation folgt einer Reihe von klaren Regeln, um die Integrität der Quellorganisation zu wahren. Falls die Quellinhalte zur NULL-Organisation gehören (also jegliche Red Hat Inhalte), wird standardmäßig die NULL-Organisation gewählt, selbst wenn eine Z ielorganisation angegeben wurde. Dies gewährleistet, dass sich der angegebene Inhalt immer in der privilegierten NULL-Organisation befindet. Wird auf der Befehlszeile eine Organisation angegeben, werden Inhalte von dieser Organisation importiert. Wird keine Organisation angegeben, wird standardmäßig Organisation 1 gewählt. Im Folgenden sehen Sie drei Beispielszenarien, in denen Organisations-IDs (orgid) zur Synchronisation zwischen Satellites verwendet werden: 20

Kapitel 3. Multiple Satellites Beispiel 3.1. Inhalte vom Master- zum Slave-Satellite importieren In diesem Beispiel werden Inhalte vom Master- zum Slave-Satellite importiert: satellite-sync --parent-sat=master.satellite.example.com -c channel-name -- orgid=2 Beispiel 3.2. Inhalte von einem exportierten Dump einer Organisation importieren In diesem Beispiel werden Inhalte von einem exportierten Dump einer bestimmten Organisation importiert: $ satellite-sync -m /dump -c channel-name --orgid=2 Beispiel 3.3. Inhalte von Red Hat Network Hosted importieren In diesem Beispiel werden Inhalte von Red Hat Network Hosted importiert (vorausgesetzt, das System ist registriert und aktiviert): $ satellite-sync -c channel-name 3.3. ISS-Anwendungsfälle ISS kann auf verschiedene Arten eingesetzt werden, abhängig von den Anforderungen Ihrer Organisation. Dieser Abschnitt liefert Beispiele für mögliche Anwendungsfälle von ISS sowie die Methoden zum Einrichten und Durchführen dieser Fälle. 21

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Beispiel 3.4. Staging-Satellite In diesem Beispiel wird ein Satellite als Staging-Satellite zur Vorbereitung von Inhalten und zur Durchführung von Aufgaben zur Qualitätssicherung eingesetzt, um so sicherzustellen, dass Pakete bereit für den Einsatz in einer Produktionsumgebung sind. Nachdem Inhalte für die Produktion freigegeben wurden, kann der Produktions-Satellite die Inhalte vom Staging-Satellite synchronisieren. 1. Führen Sie den satellite-sync-befehl aus, um Daten mit dem rhn_parent (in der Regel Red Hat Network Hosted) zu synchronisieren: satellite-sync -c your-channel 2. Führen Sie folgenden Befehl aus, um Daten vom Staging-Server zu synchronisieren: satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel Beispiel 3.5. Synchronisierte Slaves In diesem Beispiel liefert der Master-Satellite Daten direkt an seine Slaves und Änderungen werden regelmäßig synchronisiert. 22

Kapitel 3. Multiple Satellites Beispiel 3.6. Angepasste Inhalte auf den Slaves In diesem Beispiel wird der Master-Satellite als Entwicklungs-Channel genutzt, von dem Inhalte auf alle Produktions-Slave-Satellites synchronisiert werden. Einige der Slave-Satellites verfügen über zusätzliche Inhalte, die nicht auf den Channels des Master-Satellites vorliegen. Diese Pakete werden bewahrt, alle anderen Änderungen vom Master-Satellite jedoch werden auf den Slaves synchronisiert. Beispiel 3.7. Bi-direktionale Synchronisation In dieser Umgebung fungieren zwei RHN Satellite Server als Master des jeweils anderen und können Inhalte gegenseitig synchronisieren. 1. Stellen Sie sicher, dass beide Satellites SSL-Z ertifikate austauschen können. 2. Öffnen Sie auf dem ersten Satellite die /etc/rhn/rhn.conf-datei und verweisen Sie mit der iss_parent-option auf den Hostnamen des zweiten Satellites. 3. Öffnen Sie auf dem zweiten Satellite die /etc/rhn/rhn.conf-datei und verweisen Sie mit der iss_parent-option auf den Hostnamen des ersten Satellites. 23

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Kapitel 4. Weiterführende API-Methoden und Befehle 4.1. Die XML-RPC-Programmierschnittstelle (API) RHN Satellite 5.5 unterstützt das Provisioning mithilfe der XML-RPC-Programmierschnittstelle. Die folgenden API-Methoden ermöglichen die Pflege von Kickstart-Profilen und -Bäumen: 24

Kapitel 4. Weiterführende API-Methoden und Befehle T abelle 4.1. XML-RPC-Methoden XML-RPC-Namensraum kickstart kickstart.tree kickstart.filepreservation kickstart.keys Verwendung Erstellen, Importieren und Löschen von Kickstart- Profilen. Auch zum Auflisten der verfügbaren Kickstart-Bäume und -Profile. Erstellen, Umbenennen, Aktualisieren und Löschen von Kickstart-Bäumen. Auflisten, Erstellen und Löschen von Dateierhaltungslisten, die mit einem Kickstart- Profil verknüpft werden können. Nachdem eine Dateierhaltungsliste erstellt wurde, kann sie durch Aufruf der kickstart.profile.system.add_file_pr eservations API-Methode mit einem Kickstart- Profil verknüpft werden. Auflisten, Erstellen und Entfernen von kryptografischen Schlüsseln (GPG/SSL), die mit verschiedenen Kickstart-Profilen verknüpft werden können. Anmerkung Nachdem ein kryptographischer Schlüssel erstellt wurde, kann er durch Aufruf der kickstart.profile.system.add_ke ys API-Methode mit einem Kickstart-Profil verknüpft werden. kickstart.profile kickstart.profile.keys kickstart.profile.software kickstart.profile.system Ändern von IP-Bereichen, des Kickstart-Baums und der Sub-Channels, Herunterladen der einem Profil zugehörigen Kickstart-Datei, Ändern erweiterter und angepasster Optionen, und Hinzufügen der einem Kickstart-Profil zugehörigen Pre-/Post-Skripts. Auflisten, Hinzufügen (Verknüpfung erstellen) und Entfernen (Verknüpfung lösen) der einem Kickstart-Profil zugehörigen Aktivierungsschlüssel. Ändern der mit einem Kickstart verknüpften Liste von Paketen. Verwalten der Dateierhaltung, Verwalten kryptographischer Schlüssel, Aktivieren/Deaktivieren von Konfigurationsverwaltung und Remote-Befehlen, Einrichten von Partitionierungsschemata, und Einrichten der einem Kickstart-Profil zugehörigen Gebietsschema-Informationen. Die folgenden API-Methoden können zum Re-Provisioning eines Host und zum Einplanen von 25

Red Hat Network Satellite 5.5 Handbuch zum Einstieg Gastinstallationen verwendet werden. system.provision_system system.provision_virtual_guest Weitere Informationen über API-Aufrufe finden Sie in der API-Dokumentation unter https://satellite.exam ple.com/rpc/api. 4.2. Cobbler RHN Satellite nutzt Cobbler, um Provisioning zu ermöglichen. Wenn die Kickstart-Profile, -Bäume (Distributionen) und Systeme zum Provisioning im RHN Satellite aktualisiert werden, werden sie auf der Cobbler-Instanz auf dem RHN Satellite Host synchronisiert. Dies bedeutet, dass Sie Cobbler falls gewünscht direkt zur Verwaltung des Provisionings einsetzen können. Die nachstehende T abelle beschreibt die Cobbler-Befehle: 26

Kapitel 4. Weiterführende API-Methoden und Befehle T abelle 4.2. Cobbler-Befehle Befehl cobbler profile list cobbler distro list cobbler system list cobbler profile report -- name=profile-name or cobbler system report --nam e=system-nam e cobbler profile edit -- nam e=profile-nam e --virt-ram =1024 cobbler system edit --nam e=systemnam e --netboot-enabled=1 cobbler system edit --nam e=systemnam e --profile=new-profile-nam e -- netboot-enabled=1 cobbler system find -- profile=profile-nam e cobbler system find --profile="abc" xargs -n1 --replace cobbler system edit \ --name={} --profile="def" -- netboot-enabled=1 cobbler profile edit -- nam e=profilenam e -- kopts="variablenam e=3" --in-place cobbler system edit -- nam e=system nam e -- kopts="selinux=disabled asdf=jkl" cobbler profile find -- nam e="* webserver*" xargs -n1 -- replace cobbler profile edit -- nam e={} --profile="rhel5-i386" Verwendung Führen Sie diesen Befehl auf dem RHN Satellite Host aus, um eine Liste mit Profilen anzuzeigen Z eigt eine Liste von Kickstart-Bäumen, Kernels, RAM-Disks und anderen Optionen an Z eigt eine Liste von Systemaufzeichnungen, die beim Einplanen eines Kickstarts erzeugt werden Z eigt eine ausführlichere Ausgabe für ein bestimmtes Objekt Bearbeitet verschiedene Parameter. Dieses Beispiel weist jeder virtualisierten Installation eines gegebenen Profils 1 GB RAM zu. Z wingt das System beim nächsten Neustart zur Neuinstallation Weist einem System ein neues Profil zur Neuinstallation zu Listet alle mit einem Profil verknüpften Systeme auf Weist allen Systemen, denen derzeit das abc- Profil zugewiesen ist, das def-profil zu und installiert diese beim nächsten Neustart neu Setzt eine zusätzliche Vorlagenvariable auf einem Profil, ohne die anderen Variablen zu verändern Weist einer Systemaufzeichnung verschiedene Variablen zu, ungeachtet alter Variablen, die ggf. bereits gesetzt waren Richtet alle neuen Installationen beliebiger Profile, die den String webserver enthalten, zur Verwendung eines Profils namens RHEL5-i386 ein Weitere Cobbler-Einstellungen Es gibt nur wenige Cobbler-Einstellungen, die direkt in der /etc/cobbler/settings-datei verändert werden sollten. Dazu gehört die pxe_just_once-option (beschrieben in Prozedur 4.3, Konfiguration von Cobbler zur Verwendung von PXE ). Auch die server-option kann geändert werden, um der Adresse oder dem Hostnamen des RHN Satellite Servers zu entsprechen. Führen Sie nach einer Änderung in der /etc/cobbler/settings-datei die folgenden Befehle aus, damit die Änderungen wirksam werden: 27

Red Hat Network Satellite 5.5 Handbuch zum Einstieg /sbin/service cobblerd restart cobbler sync Wichtig Ändern Sie keine der anderen Einstellungen in /etc/cobbler/settings. RHN Satellite erfordert, dass diese Datei in einer bestimmten Konfiguration vorliegt, festgelegt vom RHN Satellite Installationsprogramm. Ebenso sollte auch die /etc/cobbler/m odules.conf-datei, die Authentifizierungsquellen verwaltet, in dem vom RHN Satellite Installationsprogramm angelegten Zustand verbleiben. Insbesondere muss das Authentifizierungsmodul authn_spacewalk ausgewählt bleiben und kann nicht verändert werden. Prozedur 4.1. Konfiguration von SELinux zur Verwendung mit Cobbler Red Hat Enterprise Linux wird standardmäßig mit SELinux-Unterstützung und einer sicheren Firewall installiert. Um einen Red Hat Enterprise Linux Server ordnungsgemäß zur Verwendung von Cobbler zu konfigurieren, müssen Sie SELinux konfigurieren, um Verbindungen vom und zum Cobbler-Server zu erlauben. 1. Um SELinux für Cobbler-Unterstützung einzurichten, müssen Sie mittels einer Boolschen Variable die HT T PD Webservice-Komponenten erlauben. Führen Sie dazu den folgenden Befehl aus: setsebool -P httpd_can_network_connect true Der -P-Schalter ist dabei sehr wichtig, da er die HT T PD-Verbindungen persistent über Neustarts hinweg erlaubt. 2. Setzen Sie die SELinux-Dateikontextregeln für T FT P, um die Boot-Imagedatei bereitzustellen, indem Sie auf dem Cobbler-Server den folgenden Befehl ausführen: semanage fcontext -a -t public_content_t "var/lib/tftpboot/.*" 3. Anschließend muss IPT ables konfiguriert werden, um eingehenden und ausgehenden Netzwerkverkehr auf dem Cobbler-Server zu erlauben. Falls Sie bereits ein vorhandenes Firewall-Regelset mit iptables haben, fügen Sie die folgenden Regeln hinzu, um die für Cobbler notwendigen Ports zu öffnen: Für TFTP: /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT Für HTTPD: /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT Für Cobbler: 28

Kapitel 4. Weiterführende API-Methoden und Befehle /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j ACCEPT Für Koan: /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j ACCEPT 4. Speichern Sie abschließend die Firewall-Konfiguration: /sbin/iptables-save 5. Vergewissern Sie sich, dass die Konfigurationsdateien alle synchronisiert sind, indem Sie den folgenden Befehl ausführen: cobbler sync 6. Starten Sie den Satellite Server: /usr/sbin/rhn-satellite start Warnung Starten oder stoppen Sie den cobblerd-dienst nicht unabhängig vom Satellite-Dienst, da dies Fehler und andere Probleme verursachen könnte. Verwenden Sie immer /usr/sbin/rhn-satellite, um den RHN Satellite zu starten und zu stoppen. Prozedur 4.2. Konfiguration der Cobbler-Systemaufzeichnungen Cobbler-Systemaufzeichnungen sind Objekte in Cobbler, die den Überblick über ein System und dessen zugehörige Kickstarts bewahren. Um PXE-Kickstarts durchzuführen, muss ein Satellite-Kickstart-Profil mit den Cobbler-Systemaufzeichnungen derjenigen Rechner, für die Sie PXE-Kickstarts durchführen möchten, verknüpft werden. 1. Gehen Sie zu System-Details Provisioning für jedes System und wählen Sie das zu verknüpfende Kickstart-Profil. 2. Klicken Sie auf die Schaltfläche Cobbler-System aufzeichnung erstellen, um die Verknüpfung herzustellen. 3. Nachdem diese Verknüpfung einmal hergestellt wurde, bleibt sie für immer bestehen, es sei denn, Sie haben in Cobbler pxe_just_once auf "true" für den fraglichen Rechner eingestellt. In diesem Fall würde diese Verknüpfung nach erfolgreichem Kickstart gelöst werden. Siehe Prozedur 4.3, Konfiguration von Cobbler zur Verwendung von PXE für weitere Informationen über diese Einstellung. Prozedur 4.3. Konfiguration von Cobbler zur Verwendung von PXE Cobbler ist standardmäßig zur Generierung von PXE-Konfigurationen eingerichtet. Um den bestmöglichen PXE-Ablauf im BIOS zu erhalten, kann jedoch die pxe_just_once-konfigurationsoption angepasst werden. 1. Oft legt die BIOS-Reihenfolge fest, das zuerst ein PXE-Boot erfolgen soll. Das bedeutet, dass das 29