So führen Sie unbeaufsichtigte Linux-Installationen mit Kickstart durch

Kickstart ist eine automatische Installationsmethode, die nativ auf den Distributionen verfügbar ist, die das Anaconda-Installationsprogramm verwenden: Red Hat Enterprise Linux (und seine Klone) und Fedora. Es kann tatsächlich auch verwendet werden, um Ubuntu zu installieren, aber in diesem Zusammenhang fungiert es als Kompatibilitätsschicht zur debian-nativen Preseeding-Methode. Mit Kickstart können wir unbeaufsichtigte, anpassbare und reproduzierbare Installationen durchführen.

In diesem Tutorial lernen wir die Grundlagen von Kickstart kennen und sehen, wie man eine unbeaufsichtigte Installation eines Fedora Workstation-Systems durchführt.

In diesem Tutorial lernen Sie:

So führen Sie unbeaufsichtigte Installationen mit Kickstart durch
Wie schreibe ich eine Kickstart-Datei?
So übergeben Sie eine Kickstart-Datei an das Anaconda-Installationsprogramm

Einleitung

Wenn wir eine Kickstart-Installation durchführen, geben wir, anstatt interaktiv auf die Fragen des Systeminstallateurs zu den verschiedenen Aspekten des Installationsprozesses zu antworten, eine Reihe von Befehlen/Anweisungen in der sogenannten Kickstart-Datei weiter. Darin definieren wir, welches Partitionslayout wir verwenden möchten, welches Gebietsschema und welche Zeitzone für das neue System verwendet werden sollen, welche Pakete installiert werden sollen usw.

Der beste Weg, um zu lernen, wie man eine Kickstart-Datei schreibt, besteht darin, von einem Beispiel aus der Praxis auszugehen und die verschiedenen Abschnitte und Befehle zu analysieren, die darin verwendet werden. Für dieses Tutorial werfen wir einen Blick auf eine Kickstart-Datei, die zur Installation eines Fedora Workstation-Systems verwendet werden kann. Hier ist es in seiner Gesamtheit:

url --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
repo --name=rpmfusion-free --mirrorlist=https://mirrors.rpmfusion.org/metalink?repo=free-fedora-$releasever&arch=$basearch
rootpw --lock
user --groups=wheel --name=tux --password=$6$fz9G6LVJIRHXk39j$IKgBBqkj9RQBWz8MylDWwViuREVTCIBwuxLEAeY0A6yniK2FIWBZDr9lH5YbUBidmBtqKR5CLA0h9AigOucCT/ --iscrypted --gecos="tux"

lang en_US.UTF-8
keyboard --vckeymap=us --xlayouts=us
timezone Europe/Rome --utc

network --hostname=linuxconfig --device=eth0 --bootproto=dhcp --noipv6 --activate --onboot=yes
xconfig --startxonboot

ignoredisk --only-use=/dev/vda
clearpart --all --initlabel --drives=vda
part /boot/efi --fstype=efi  --ondisk=/dev/vda --size=550 --fsoptions="umask=0077,shortname=winnt"
part /boot     --fstype=ext2 --ondisk=/dev/vda --size=1024
part pv.0 --fstype=lvmpv --ondisk=/dev/vda --grow
volgroup linuxconfig_vg pv.0
logvol /     --fstype=ext4 --vgname=linuxconfig_vg --name=root_lv --size=15360
logvol /home --fstype=ext4 --vgname=linuxconfig_vg --name=home_lv --percent=95
bootloader --location=mbr --boot-drive=/dev/vda

%packages
@workstation-product-environment
-gnome-boxes
%end

Festlegen der Installationsquelle

In der obigen Kickstart-Datei haben wir als erstes die Installationsquelle definiert. Die Installationsquelle kann entweder "lokal" (z. B. eine CD-ROM) oder remote (ein Installationsbaum) sein, auf die über eines der unterstützten Protokolle wie ftp oder http zugegriffen wird. Letzteres ist genau das, was wir im Beispiel verwendet haben:

url --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch

Mit dem von uns angegebenen url-Befehl möchten wir eine Remote-Installationsquelle verwenden. Wir haben die URL der Datei, die die Liste der verfügbaren Spiegel enthält, als Argument an die Option --mirrorlist übergeben. Die Variablen $releasever und $basearch in der URL werden jeweils auf die Fedora-Version (z. B. 37) und die Systemarchitektur erweitert. Als Alternative könnten wir einen bestimmten Spiegel direkt verwenden, indem wir seine URL als Argument an die Option --url übergeben.

Verwendung zusätzlicher Repositories während der Installation

Die zweite Zeile in der Kickstart-Datei, die wir im Beispiel verwendet haben, lautet wie folgt:

repo --name=rpmfusion-free --mirrorlist=https://mirrors.rpmfusion.org/metalink?repo=free-fedora-$releasever&arch=$basearch

Der Befehl repo ist optional: Er wird verwendet, um zusätzliche Repositories anzugeben, die während der Installation verwendet werden sollen. In diesem Beispiel haben wir das RPMFusion-Repository als Softwarequelle hinzugefügt. Es enthält Pakete, die aus dem einen oder anderen Grund nicht in den offiziellen Fedora-Repositories wie z.B. VLC verfügbar sind. Wir haben die obligatorische Option --name verwendet, um die Repository-ID anzugeben, und --mirrorlist, um die URL der Datei anzugeben, die eine Liste der Repository-Spiegelserver enthält.

Ein Repository, das so definiert ist, wie wir es im Beispiel getan haben, wäre nur während der Installation verfügbar: Um es auch auf dem installierten System zu aktivieren, müssen wir die Option --install hinzufügen.

Eine weitere interessante Option, die wir bei der Angabe eines zusätzlichen Repositorys verwenden möchten, ist --cost. Die Option nimmt eine ganze Zahl als Wert an und wird verwendet, um die Installationspriorität zu definieren. Dies ist nützlich, wenn ein Paket von mehr als einer Softwarequelle verfügbar ist: Niedrigere Kosten bedeuten eine höhere Priorität.

Verwalten von Systembenutzern

Im obigen Beispiel haben wir zwei Befehle verwendet, um Benutzer im neu installierten System zu verwalten:

Root-Passwort
Benutzer

Der erste Befehl. rootpw ist obligatorisch: Es wird verwendet, um das Passwort des root-Benutzers einzurichten. In diesem Fall haben wir die Option --lock an den Befehl übergeben, der, wie Sie sich vorstellen können, zum Sperren des Passworts verwendet wird, um die direkte Root-Anmeldung zu deaktivieren:

rootpw --lock

Als nächstes haben wir dem System über den Benutzerbefehl einen nicht privilegierten Benutzer hinzugefügt, indem wir die Optionen --groups, --name, --password, --iscrypted und --gecos verwendet haben:

user --groups=wheel --name=tux --password=$6$fz9G6LVJIRHXk39j$IKgBBqkj9RQBWz8MylDWwViuREVTCIBwuxLEAeY0A6yniK2FIWBZDr9lH5YbUBidmBtqKR5CLA0h9AigOucCT/ --iscrypted --gecos="tux"

Die Option --name wird verwendet, um den Benutzernamen des Kontos anzugeben, und ist erforderlich. Die Option --groups akzeptiert stattdessen eine durch Kommas getrennte Liste der Gruppen, in denen der Benutzer Mitglied sein soll. In diesem Fall haben wir den Benutzer zu einem Teil der Radgruppe gemacht, um ihn in die Lage zu versetzen, Berechtigungen mit sudo zu eskalieren.

Die Optionen --password und --iscrypted sind miteinander verknüpft. Ersteres wird verwendet, um das Benutzerpasswort bereitzustellen, letzteres zur Angabe sollte davon ausgegangen werden, dass es bereits verschlüsselt ist (das Gegenteil dieser Option ist --plaintext). Die Verwendung eines bereits verschlüsselten Passworts ist nützlich, falls wir die Kickstart-Datei irgendwie freigeben oder unter Versionskontrolle stellen müssen. Es gibt verschiedene Methoden, mit denen wir ein Passwort verschlüsseln und die Zeichenfolge abrufen können, um sie in die Datei zu setzen. Eine Möglichkeit ist die Verwendung des Dienstprogramms pwkickstart. Es nimmt ein Passwort als Argument und gibt seine MD5-, SHA256- und SHA512-verschlüsselten Versionen zurück (letztere ist diejenige, die wir wollen):

pwkickstart mypassword
$1$shCWoE7t$eY546wqr/rrsaUugnvBbs0
$5$pmMb0I1fhyddIHJV$y9lmRW02wpSTxNzAoEh4qljlPBD1jCXulLDgTyvq1v9
$6$77bw2sxFQAU3Ejtw$DBj5IKCU3pw3sAH.XdGCalwqdIH/Nss7NVMnc6a9CbJyevo8BVPU3DFquqQvSzloQVjgfo0Z0YUSDDaZ.z.Tl1

Die letzte Option, die wir verwendet haben, ist --gecos: Sie wird benötigt, um zusätzliche Benutzerinformationen wie seinen echten Namen anzugeben. Diese Informationen werden im fünften Feld jeder Zeile in der Datei /etc/passwd gespeichert:

tux:x:1000:1000:tux:/home/tux:/bin/bash

Einstellungen für Gebietsschema, Tastatur und Zeitzone

Ein weiterer, sehr wichtiger Teil der Systemkonfiguration/-installation ist die Lokalisierung. Im Beispiel haben wir drei Direktiven verwendet, um die Systemsprache, das Tastaturlayout und die Systemzeitzone einzurichten. Sie sind jeweils: lang, keyboard und timezone.

Die lang-Direktive legt sowohl die Sprache fest, die während der Installation verwendet werden soll, als auch die Systemsprache. Es nimmt die Sprach-ID als Argument:

lang en_US.UTF-8

Die Tastaturdirektive wird verwendet, um das Tastaturlayout des Systems festzulegen. Sie können sehen, dass wir zwei Optionen verwendet haben: --vckeymap und --xlayouts, wobei wir "us" als Argument an beide übergeben haben:

Tastatur –vckeymap=us –xlayouts=uns

Ersteres wird verwendet, um die Tastenbelegung der Konsole festzulegen, letzteres zum Festlegen des Tastaturlayouts für den grafischen Server. Schließlich legen wir mit der timezone-Direktive die Systemzeitzone fest:

timezone Europe/Rome --utc

Mit der Option --utc haben wir angegeben, dass die Systemuhr auf UTC eingestellt ist.

Festplattenpartitionierung und Bootloader-Installation

Die Festplattenpartitionierung ist wahrscheinlich der wichtigste Aspekt einer Systeminstallation. Die Verwendung der Kickstart-Datei im Beispiel führt zur Erstellung von zwei Standardpartitionen (der EFI-Partition und einer dedizierten "Boot"-Partition) und zur Installation des restlichen Systems auf einem LVM-Layout (Logical Volume Manager). Als erstes haben wir den Befehl ignoredisk verwendet:

ignoredisk --only-use=/dev/vda

Dieser Befehl wird als Sicherheitsmaßnahme verwendet, um festzulegen, auf welche Festplatten das Anaconda-Installationsprogramm Zugriff hat. Wir können hier zwei Strategien implementieren: Entweder übergeben wir die durch Kommas getrennte Liste der ausgeschlossenen Laufwerke als Argument an die Option --drives oder wir machen das Gegenteil und übergeben die Liste der zugänglichen Festplatten als Argument an die Option --only-use.

Was wir in diesem Beispiel gemacht haben, war, dem Installer im Grunde nur den Zugriff auf die /dev/vda-Festplatte zu ermöglichen. In diesem Fall haben wir die Festplatte mit dem Namen identifiziert, der dem Kernel zugewiesen wurde, da es sich um die einzige verfügbare Festplatte handelt. In einem realen Szenario ist es vorzuziehen, stattdessen eindeutige Bezeichner wie UUID oder PATH zu verwenden, da sie vorhersagbar sind (der Kernel weist Gerätenamen in der Reihenfolge der Erkennung zu).

Löschen vorhandener Partitionen

Der nächste Befehl, den wir verwendet haben, ist clearpart:

clearpart --all --initlabel --drives=vda

Dieser Befehl wird verwendet, um alle vorhandenen Partitionen von den angegebenen Festplatten zu löschen, bevor die neuen Partitionen erstellt werden. Mit den von uns angegebenen Optionen --all möchten wir alle vorhandenen Partitionen löschen (mit --linux hätten wir stattdessen den Installer angewiesen, nur "linux" -Partitionen zu entfernen).

Die Option --initlabel wird verwendet, um die Festplatte mit einer MBR- oder GPT-Partitionsbezeichnung zu initialisieren, abhängig von der Architektur und der Art und Weise, wie wir das Installationsprogramm gestartet haben (UEFI oder BIOS). Schließlich wird --drives verwendet, um anzugeben, auf welchen Laufwerken die Partitionen gelöscht werden sollen.

Erstellen von Partitionen und das LVM-Setup

In einem nächsten Schritt haben wir die eigentlichen Partitionen und logischen Volumes definiert. Da wir das System im UEFI-Modus mit einem GPT-Partitionsschema installieren möchten, müssen wir eine EFI-Partition erstellen. Der Befehl, der zum Erstellen einer Standardpartition verwendet wird, besteht aus:

part /boot/efi --fstype=efi  --ondisk=/dev/vda --size=550 --fsoptions="umask=0077,shortname=winnt"

Das erste Argument, das an den Befehl übergeben wird, ist der Einhängepunkt der Partition, die erstellt wird. Dabei kann es sich entweder um einen tatsächlichen Dateisystempfad handeln oder um einen "speziellen" Wert wie "swap" (wird für Swap-Partitionen verwendet) oder pv.<id> für physische LVM-Volumes.

Die Option --fstype wird verwendet, um das Dateisystem anzugeben, das auf der Partition erstellt werden soll. In diesem Fall ist "efi " nicht der Dateisystemtyp an sich, sondern teilt dem System mit, dass wir eine EFI-Partition erstellen möchten.

Die Option --ondisk wird verwendet, um anzugeben, auf welcher Festplatte die Partition erstellt werden soll. Hier haben wir /dev/vda verwendet (um eine vorhandene Partition wiederzuverwenden, wird stattdessen --onpart verwendet).

Die Option --size wird verwendet, um die minimale Partitionsgröße in MiB anzugeben. Schließlich nimmt --fsoptions eine durch Kommas getrennte Liste von Einhängeoptionen an, die in die Datei /etc/fstab kopiert wird.

Die zweite Partition, die wir erstellt haben, ist die Boot-Partition:

part /boot --fstype=ext2 --ondisk=/dev/vda --size=1024

Die Verwendung einer separaten Boot-Partition und des ext2-Dateisystems darauf ist wirklich nicht notwendig, da GRUB sowohl LVM als auch ext4 unterstützt, es ist nur die Macht der Gewohnheit. Als nächstes haben wir die Partition definiert, die als physisches LVM-Volume verwendet werden soll. Hier können Sie feststellen, dass wir lvmpv als Dateisystemtyp verwendet haben, und die Option --grow: Damit legen wir fest, dass die Partition den gesamten verfügbaren Speicherplatz einnehmen soll:

part pv.0 --fstype=lvmpv --ondisk=/dev/vda --grow

Mit dem Befehl volgroup haben wir eine LVM-Volume-Gruppe erstellt. Diese Direktive verwendet den Namen der Volume-Gruppe als erstes Argument und die physischen Volumes, die hinzugefügt werden sollen, als zweites:

volgroup linuxconfig_vg pv.0

Nach der Volume-Gruppe haben wir die logischen Volumes mit dem Befehl logvol erstellt. Dieser Befehl funktioniert ähnlich wie part, akzeptiert aber einige zusätzliche Optionen, wie zum Beispiel --vgname, das benötigt wird, um die Volume-Gruppe anzugeben, zu der das logische Volume gehört, und --percent, das verwendet werden kann, um die Größe des logischen Volumes als Prozentsatz des verfügbaren Speicherplatzes anzugeben.

Installation des Bootloaders

Schließlich haben wir den Bootloader-Befehl verwendet, der benötigt wird, um zu konfigurieren, wie und wo der Bootloader installiert wird:

bootloader --location=mbr --boot-drive=/dev/vda

Hier haben wir die Optionen --location und --boot-drive verwendet, um anzugeben, dass der Bootloader im mbr (tatsächlich in der EFI-Partition auf UEFI-installierten Systemen) des Laufwerks /dev/vda installiert werden soll.

Festlegen der Paketliste

Mit Hilfe von Kickstart können wir im Detail festlegen, welche Pakete im neuen System installiert werden sollen und welche ausgeschlossen werden sollen. Wir listen Pakete im %packages-Abschnitt auf, eines pro Zeile. Der Abschnitt muss mit dem Tag %end geschlossen werden:

%packages
@workstation-product-environment
-gnome-boxes
%end

In diesem Beispiel können Sie sehen, dass wir die Paketgruppe @workstation-product-environment explizit eingeschlossen haben (eine Gruppe wird durch ein @ vor dem Namen gekennzeichnet), und wir haben das Paket gnome-boxes ausgeschlossen, indem wir das Zeichen - vor seinen Namen gesetzt haben.

Die Abschnitte %pre und %post

Lassen Sie uns über zwei Abschnitte sprechen, die wir in unserem Beispiel nicht verwendet haben: %pre und %post: Diese Abschnitte in einer Kickstart-Datei können sehr nützlich sein, da wir in ihnen benutzerdefinierte Aktionen mit einer der verfügbaren Skriptsprachen auf dem System ausführen können (Bash ist die Standardeinstellung). Beide Abschnitte müssen mit einem %end-Tag geschlossen werden, werden aber in unterschiedlichen Phasen der Installation ausgeführt. Die %pre-Sektion wird ausgeführt, bevor die Installation beginnt, unmittelbar nachdem die Kickstart-Datei analysiert wurde. Der Abschnitt %post wird stattdessen ausgeführt, nachdem die Installation abgeschlossen ist. Die Befehle, die wir darin ausführen, laufen im installierten System, in chroot.

Übergeben der Kickstart-Datei an das Installationsprogramm

Sobald unsere Kickstart-Datei fertig ist, müssen wir dem Installer mitteilen, wo sie zu finden ist. Wir tun dies über die Boot-Option inst.ks. Wir können zum Beispiel die Kickstart-Datei online verfügbar machen, dann den Installer darauf verweisen, wie wir es unten getan haben (wir haben die Datei als test.ks gespeichert):

Schlüsse

In diesem Tutorial haben wir die Grundlagen von Kickstart kennengelernt. Wir haben gesehen, wie man die entsprechenden Befehle verwendet, um die Installationsquelle festzulegen, zusätzliche Repositories hinzuzufügen, das Gebietsschema des Systems festzulegen und ein Partitionslayout zu definieren. Wir haben auch gesehen, wie man festlegt, welche Pakete installiert werden sollen, und über die Abschnitte %pre und %post gesprochen, die verwendet werden können, um benutzerdefinierte Aktionen zu skripten, die vor dem Start der Installation bzw. nach deren Abschluss ausgeführt werden. Schließlich sahen wir ein Beispiel dafür, wie die Kickstart-Datei an das Anaconda-Installationsprogramm übergeben werden kann. Die vollständige Liste der Kickstart-Befehle finden Sie in der offiziellen Dokumentation.