Website-Suche

So installieren Sie Fedora/RHEL/CentOS per Kickstart auf einem vorhandenen LUKS-Gerät

Kickstart-Installationen ermöglichen es uns, unbeaufsichtigte oder halbunbeaufsichtigte Installationen von Fedora, Red Hat Enterprise Linux oder CentOS einfach zu skripten und zu replizieren. Die Anweisungen, die zur Installation des Betriebssystems benötigt werden, werden mit einer speziellen Syntax in einer Kickstart-Datei angegeben, die an das Anaconda-Installationsprogramm übergeben wird. In diesem Tutorial werden wir sehen, wie Sie einen bereits vorhandenen LUKS-Container (Linux Unified Keys Setup) bei einer Kickstart-Installation wiederverwenden können: Dies ist etwas, das nicht nur mit Kickstart-Anweisungen erreicht werden kann und einige zusätzliche Schritte erfordert.

In diesem Tutorial lernen Sie:

  • So verwenden Sie einen vorhandenen LUKS-Container bei einer Kickstart-Installation von Fedora, RHEL oder CentOS
  • So erstellen und verwenden Sie eine updates.img-Datei, die mit dem Anaconda-Installationsprogramm verwendet werden soll.

So installieren Sie Fedora/RHEL/CentOS per Kickstart auf einem vorhandenen LUKS-Gerät

Verwendete Softwareanforderungen und Konventionen

Einleitung

Kickstart ermöglicht es uns, Betriebssysteminstallationen auf eine Weise zu replizieren und anzupassen, die mit dem grafischen Anaconda-Installationsprogramm einfach unmöglich zu erreichen ist. Wir können zum Beispiel deklarieren, welche Pakete oder Paketgruppen auf dem System installiert werden sollen und welche stattdessen ausgeschlossen werden sollen.

Wir haben auch die Möglichkeit, benutzerdefinierte Befehle vor oder nach der Installation auszuführen, indem wir sie in den dedizierten Abschnitten %pre und %post der Kickstart-Datei angeben. Wir werden diese letztgenannte Funktion nutzen, um während des Installationsprozesses ein bereits vorhandenes LUKS-Gerät zu verwenden.

Verschlüsselung mit nativer Kickstart-Syntax

Das Erstellen von LUKS-Containern ist recht einfach und kann einfach mit nativen Kickstart-Anweisungen erfolgen. Hier ist ein Beispiel:

part pv.01 --ondisk=sda --encrypted --luks-type=luks1 --cipher=aes-xts-plain64 --pbkdf-time=5000 --passphrase=secretpassphrase

Im obigen Beispiel erstellen wir mit der part-Anweisung ein verschlüsseltes physisches LVM-Volume auf der /dev/sda-Festplatte. Wir geben die zu verwendende LUKS-Version an (in diesem Fall luks1 – zumindest in neueren Versionen von Fedora ist luks2 zum Standard geworden), die Chiffre und die Zeit, ausgedrückt in Millisekunden, die für die PBKDF-Passphrasenverarbeitung (Password-Based Key Derivation Function) aufgewendet werden soll (dies entspricht der Verwendung der Option --iter-time von cryptsetup).

Auch wenn es keine sichere Gewohnheit ist, haben wir auch die --passphrase verwendet, um die Verschlüsselungspassphrase bereitzustellen: Ohne diese Option würde der Installationsprozess unterbrochen und wir würden aufgefordert, eine interaktive Passphrase bereitzustellen.

Wir können deutlich sehen, wie wir mit Kickstart im Vergleich zu einer herkömmlichen Installation viel mehr Flexibilität erhalten. Warum sollten wir dann zusätzliche Schritte durchführen müssen? Es gibt immer noch einige Aufgaben, die wir nicht nur mit der Standard-Kickstart-Syntax erledigen können. Unter anderem können wir keine LUKS-Container auf Rohgeräten erstellen (nur auf Partitionen) oder den Hashing-Algorithmus angeben, der für die Einrichtung des LUKS-Schlüssels verwendet werden soll, der standardmäßig auf sha256 eingestellt ist (daran ist nichts auszusetzen).

Aus diesen Gründen möchten wir vielleicht unser Partitions-Setup erstellen, bevor wir die Installation durchführen, entweder manuell oder mit Tools wie parted in der %pre-Sektion der Kickstart-Datei selbst. Es kann auch sein, dass wir nur ein bestehendes LUKS-Setup haben, das wir nicht zerstören wollen. In all diesen Fällen müssen wir die zusätzlichen Schritte ausführen, die wir gleich sehen werden.

Die Kickstart-Sektion %pre

Der %pre-Abschnitt einer Kickstart-Datei ist der erste, der beim Abrufen der Datei analysiert wird. Es wird verwendet, um benutzerdefinierte Befehle auszuführen, bevor die Installation gestartet wird, und muss explizit mit der %end-Anweisung geschlossen werden.

In %pre wird standardmäßig der Bash-Shell-Interpreter verwendet, aber andere können über die Option --interpreter angegeben werden (um Python zu verwenden, würden wir %pre --interpreter /usr/bin/python schreiben). Wir können diesen Abschnitt verwenden, um die Befehle auszuführen, die zum Öffnen des vorhandenen LUKS-Containers erforderlich sind. Hier ist, was wir schreiben können:

%pre
iotty="$(tty)"
exec > "${iotty}" 2> "${iotty}"

while true; do
  cryptsetup luksOpen /dev/sda1 cryptroot - && break
done
%end

Werfen wir einen Blick auf den obigen Code. Zunächst speichern wir das Ergebnis des Befehls tty, der den Dateinamen des Terminals ausgibt, das mit der Standardeingabe verbunden ist, in die Variable iotty.

Mit dem exec > Befehl "$ {iotty}" 2> "$ {iotty}" haben wir die Standardausgabe und den Standardfehler auf das gleiche Terminal umgeleitet:
crytpsetup luksOpen ausgeführt wird und die Eingabeaufforderung auf dem Bildschirm angezeigt wird. Der Befehl wird in einer Endlosschleife gestartet, die nur unterbrochen wird, wenn der LUKS-Container erfolgreich geöffnet wird.

Wenn wir eine völlig unbeaufsichtigte Installation durchführen möchten, müssen wir die Passphrase direkt an cryptsetup übergeben (auch dies wird nicht empfohlen). Wir würden schreiben:

%pre
echo -n "ourverysecretpassphrase" | cryptsetup luksOpen /dev/sda1 cryptroot -
%end

Im obigen Beispiel haben wir die Passphrase über einen Pipe | an die Standardeingabe des Befehls cryptsetup übergeben: Wir haben den Befehl echo mit der Option -n verwendet, um zu vermeiden, dass am Ende der Passphrase ein Zeilenumbruchzeichen angehängt wird.

Patchen des Fedora 31 Anaconda-Installationsprogramms

Wenn wir versuchen, bei der Installation von Fedora 31 über Kickstart einen entsperrten LUKS-Container zu verwenden, erhalten wir die folgende Meldung
und der Vorgang wird abgebrochen:

Das vorhandene entsperrte LUKS-Gerät kann nicht für die Installation verwendet werden, ohne dass ein Verschlüsselungsschlüssel für dieses Gerät angegeben ist
. Bitte scannen Sie den Speicher erneut.

Dies geschieht aufgrund dieses Commits, der in der Fedora 31-Version des Anaconda-Installationsprogramms eingeführt wurde. Der Code prüft im Grunde, ob ein vorhandenes LUKS-Gerät über einen registrierten Schlüssel verfügt, wenn dies nicht der Fall ist, wird die Installation abgebrochen. Das Problem ist, dass blivet, die Python-Bibliothek, die von Anaconda zur Verwaltung der Partition verwendet wird, den Schlüssel nur erhält, wenn der Container von ihr geöffnet wird: Dies kann über den grafischen Installer erfolgen, aber zum Zeitpunkt des Schreibens gibt es keine Kickstart-Anweisung zum Entsperren eines vorhandenen LUKS-Containers. Ich habe den Commit persönlich kommentiert, um die Situation zu erklären, und es wurde ein Fehler auf Red Hat Bugzilla geöffnet.

Erstellen einer updates.img-Datei

Im Moment besteht der einzige Workaround (den ich kenne) darin, den Anaconda-Quellcode zu patchen und die Zeile zu kommentieren, die das mit dem oben erwähnten Commit eingeführte Control ausführt. Die gute Nachricht ist, dass es sehr einfach zu bedienen ist.

Als erstes müssen wir das Anaconda-Git-Repository klonen, insbesondere den f31-release-Zweig:

git clone https://github.com/rhinstaller/anaconda -b f31-release

Sobald das Repo geklont ist, geben wir das Anaconda-Verzeichnis ein und ändern die Datei pyanaconda/storage/checker.py: Alles, was wir tun müssen, ist, Zeile 619 zu kommentieren:

def set_default_checks(self):
        """Set the default checks."""
        self.checks = list()
        self.add_check(verify_root)
        self.add_check(verify_s390_constraints)
        self.add_check(verify_partition_formatting)
        self.add_check(verify_partition_sizes)
        self.add_check(verify_partition_format_sizes)
        self.add_check(verify_bootloader)
        self.add_check(verify_gpt_biosboot)
        self.add_check(verify_swap)
        self.add_check(verify_swap_uuid)
        self.add_check(verify_mountpoints_on_linuxfs)
        self.add_check(verify_mountpoints_on_root)
       #self.add_check(verify_unlocked_devices_have_key)
        self.add_check(verify_luks_devices_have_key)
        self.add_check(verify_luks2_memory_requirements)
        self.add_check(verify_mounted_partitions)

Wir speichern die Änderung und starten aus dem Stammverzeichnis des Repositorys das makeupdates-Skript, das sich im Skriptverzeichnis befindet. Damit das Skript ausgeführt werden kann, muss python2 installiert sein:

./scripts/makeupdates

Das Skript generiert die Datei updates.img, die unsere Änderungen enthält. Um den Inhalt zu überprüfen, können wir den Befehl lsinitrd verwenden:

lsinitrd updates.img
Image: updates.img: 8.0K
========================================================================
Version:

Arguments:
dracut modules:
========================================================================
drwxr-xr-x   3 egdoc    egdoc           0 Jan 30 09:29 .
drwxr-xr-x   3 egdoc    egdoc           0 Jan 30 09:29 run
drwxr-xr-x   3 egdoc    egdoc           0 Jan 30 09:29 run/install
drwxr-xr-x   3 egdoc    egdoc           0 Jan 30 09:29 run/install/updates
drwxr-xr-x   3 egdoc    egdoc           0 Jan 30 09:29 run/install/updates/pyanaconda
drwxr-xr-x   2 egdoc    egdoc           0 Jan 30 09:29 run/install/updates/pyanaconda/storage
-rw-r--r--   1 egdoc    egdoc       25443 Jan 30 09:29 run/install/updates/pyanaconda/storage/checker.py
========================================================================

Wir werden diese Datei verwenden, um das Installationsprogramm von Fedora 31 zu "patchen".

Anwenden des Patches

Um die in der gerade generierten Datei enthaltenen Änderungen anzuwenden, müssen wir sie an einem Ort platzieren, an dem wir leicht darauf zugreifen können, vielleicht über ftp oder http oder sogar auf einem lokalen Blockgerät, und den Parameter inst.updates verwenden, um sie aus dem Fedora-Installationsimage zu referenzieren. Aus dem Grub-Menü markieren wir den Menüeintrag "Fedora installieren":

Menü des Fedora 31-Installationsprogramms

Sobald die Menüzeile ausgewählt ist, drücken wir die Tab-Taste: Die mit dem Eintrag verknüpfte Kernel-Befehlszeile wird am unteren Rand des Bildschirms angezeigt:

Die Kernel-Befehlszeile, die vom Eintrag "Install Fedora" verwendet wird Alles, was wir jetzt tun müssen, ist, die Anweisung inst.updates anzuhängen und den Pfad zur Datei updates.img anzugeben, die wir erstellt haben. Angenommen, sowohl die Kickstart- als auch die updates.img-Datei sind über http auf einem lokalen Server mit der IP 192.168.0.37 zugänglich, würden wir schreiben:

vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_31-31 quiet
inst.updates=http://192.168.0.37/updates.img inst.ks=http://192.168.0.37/ks.cfg

An dieser Stelle können wir zum Booten die Eingabetaste drücken. Mit der obigen Änderung wird sich der Installer nicht mehr über das entsperrte LUKS-Gerät beschweren
, und die Installation wird ohne Probleme fortgesetzt.

Schlüsse

In diesem Artikel haben wir gesehen, wie man eine Kickstart-Installation so abstimmt, dass man ein bereits vorhandenes LUKS-Gerät wiederverwendet, es im %pre-Abschnitt der Kickstart-Datei entsperrt und wie man einen kleinen Workaround auf das Fedora 31 Anaconda-Installationsprogramm anwendet, das sonst fehlschlagen würde, wenn eine solche Installation versucht wird. Wenn Sie neugierig auf die Kickstart-Syntax sind, werfen Sie bitte einen Blick in die Online-Dokumentation.

Verwandte Artikel: