Mit Kickstart-Installationen können wir unbeaufsichtigte oder halb unbeaufsichtigte Installationen von Fedora, Red Hat Enterprise Linux oder CentOS einfach skripten und replizieren. Die für die Installation des Betriebssystems erforderlichen Anweisungen werden mit einer speziellen Syntax in einer Kickstart-Datei angegeben, die an das Anaconda-Installationsprogramm übergeben wird. In diesem Tutorial werden wir sehen, wie man ein bereits existierendes LUKS wiederverwendet (Linux Unified Keys Setup)-Container bei der Durchführung einer Kickstart-Installation:Dies ist etwas, das nicht nur mit Kickstart-Anweisungen erreicht werden kann und einige zusätzliche Schritte erfordert.
In diesem Tutorial lernen Sie:
- Wie man einen vorhandenen LUKS-Container verwendet, wenn man eine Kickstart-Installation von Fedora, RHEL oder CentOS durchführt
- Erstellen und Verwenden einer updates.img-Datei zur Verwendung mit dem Anaconda-Installationsprogramm.
So installieren Sie Fedora/RHEL/CentOS über Kickstart auf einem vorhandenen LUKS-Gerät Softwareanforderungen und verwendete Konventionen
| Kategorie | Anforderungen, Konventionen oder verwendete Softwareversion |
|---|---|
| System | Fedora/Rhel/CentOS |
| Software | Für dieses Tutorial ist keine spezielle Software erforderlich. |
| Andere |
|
| Konventionen | # – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder durch Verwendung von sudo Befehl$ – erfordert, dass bestimmte Linux-Befehle als normaler, nicht privilegierter Benutzer ausgeführt werden |
Einführung
Kickstart ermöglichte es uns, Betriebssysteminstallationen auf eine Weise zu replizieren und anzupassen, die mit dem grafischen Installationsprogramm von Anaconda einfach unmöglich zu erreichen ist. Wir können beispielsweise angeben, 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 im dedizierten %pre angeben und %post Abschnitte der Kickstart-Datei. Wir werden diese letztgenannte Funktion nutzen, um ein bereits vorhandenes LUKS zu verwenden Gerät während des Installationsvorgangs.
Verschlüsselung mit nativer Kickstart-Syntax
Das Erstellen von LUKS-Containern ist recht einfach und kann einfach mit nativen Kickstart-Anweisungen durchgeführt werden. 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 durch Verwendung des part Anweisung erstellen wir ein verschlüsseltes lvm physisches Volume auf /dev/sda Scheibe. Wir spezifizieren das LUKS zu verwendende Version (luks1 in diesem Fall – zumindest in neueren Versionen von Fedora ist luks2 zum Standard geworden), die chiffre , und die Zeit, ausgedrückt in Millisekunden, die für PBKDF aufzuwenden ist (Password-Based Key Derivation Function) Passphrase-Verarbeitung (dies entspricht der Verwendung von --iter-time Option von cryptsetup ).
Auch wenn es keine sichere Angewohnheit ist, haben wir auch die --passphrase verwendet die Verschlüsselungs-Passphrase bereitzustellen:Ohne diese Option würde der Installationsvorgang unterbrochen und wir würden aufgefordert, interaktiv eine Passphrase bereitzustellen.
Wir können deutlich sehen, wie wir mit Kickstart viel mehr Flexibilität im Vergleich zu einer herkömmlichen Installation erhalten; warum müssten wir dann zusätzliche Schritte ausführen? Es gibt immer noch einige Aufgaben, die wir mit der standardmäßigen Kickstart-Syntax nicht bewältigen können. Unter anderem können wir LUKS nicht erstellen Container auf Raw-Geräten (nur auf Partitionen) oder geben Sie den Hash-Algorithmus an, der für LUKS verwendet werden soll key setup, das 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 mithilfe von Tools wie parted innerhalb von %pre Abschnitt der Kickstart-Datei selbst. Möglicherweise haben wir auch nur ein vorhandenes LUKS Setup, 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 geparst wird, wenn die Datei abgerufen wird. Es wird verwendet, um benutzerdefinierte Befehle auszuführen, bevor die Installation beginnt, und muss explizit mit %end geschlossen werden Anleitung.
In %pre , wird standardmäßig der Bash-Shell-Interpreter verwendet, aber andere können über --interpreter angegeben werden Option (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 erforderlich sind Container. Folgendes können wir schreiben:
%pre
iotty="$(tty)"
exec > "${iotty}" 2> "${iotty}"
while true; do
cryptsetup luksOpen /dev/sda1 cryptroot - && break
done
%end
Schauen wir uns den obigen Code an. Zunächst speichern wir das Ergebnis des tty Befehl, der den Dateinamen des mit der Standardeingabe verbundenen Terminals in iotty ausgibt Variable.
Mit dem exec> "${iotty}" 2> "${iotty}" Befehl haben wir Standardausgabe und Standardfehler auf dasselbe Terminal umgeleitet:
Auf diese Weise können wir das Container-Passwort eingeben, wenn crytpsetup luksOpen Der Befehl wird ausgeführt und die Eingabeaufforderung wird auf dem Bildschirm angezeigt. Der Befehl wird in einer Endlosschleife gestartet, die nur unterbrochen wird, wenn LUKS Container wurde erfolgreich geöffnet.
Wenn wir eine vollständig unbeaufsichtigte Installation ausfü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 eine Pipe | an die Standardeingabe des cryptsetup-Befehls übergeben :wir haben das echo verwendet Befehl mit dem -n Option, um zu vermeiden, dass am Ende der Passphrase ein Zeilenumbruchzeichen angehängt wird.
Fedora 31 Anaconda-Installationsprogramm patchen
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 ohne einen für dieses
Gerät spezifizierten Verschlüsselungsschlüssel nicht für die Installation verwendet werden. Bitte scannen Sie den Speicher erneut.
Dies geschieht aufgrund dieses Commit, das in der Fedora 31-Version des Anaconda-Installationsprogramms eingeführt wurde. Der Code überprüft grundsätzlich, ob ein vorhandenes LUKS-Gerät einen registrierten Schlüssel hat, wenn dies nicht der Fall ist, wird die Installation abgebrochen. Das Problem ist, dass blivet , die Python-Bibliothek, die von Anaconda zum Verwalten der Partition verwendet wird, erhält den Schlüssel nur, wenn der Container von ihr geöffnet wird:Dies kann über das grafische Installationsprogramm erfolgen, aber zum Zeitpunkt des Schreibens gibt es keine Kickstart-Anweisung zum Entsperren eines vorhandenen LUKS Container. Ich persönlich habe den Commit kommentiert und die Situation erklärt, und ein Fehler wurde auf Red Hat Bugzilla geöffnet.
Erstellen einer updates.img-Datei
Im Moment besteht die einzige mir bekannte Problemumgehung darin, den Anaconda-Quellcode zu patchen und die Zeile zu kommentieren, die das mit dem oben erwähnten Commit eingeführte Steuerelement ausführt. Die gute Nachricht ist, dass die Bedienung sehr einfach ist.
Als erstes müssen wir das Anaconda-Git-Repository klonen, insbesondere die f31-release Zweig:
$ git clone https://github.com/rhinstaller/anaconda -b f31-release
Sobald das Repo geklont ist, geben wir den anaconda ein Verzeichnis und ändern Sie die pyanaconda/storage/checker.py Datei:Alles, was wir tun müssen, ist die 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 vom Stammverzeichnis des Repositorys aus makeupdates Skript, das in scripts zu finden ist Verzeichnis. Damit das Skript ausgeführt werden kann, müssen wir python2 haben installiert:
$ ./scripts/makeupdates
Das Skript generiert die updates.img Datei, die unsere Änderungen enthalten wird. Um seinen Inhalt zu überprüfen, können wir die lsinitrd verwenden Befehl:
$ 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“.
Anwendung des Patches
Um die in der gerade erstellten Datei enthaltenen Änderungen anzuwenden, müssen wir sie irgendwo platzieren, wo wir leicht darauf zugreifen können, vielleicht über ftp oder http, oder sogar auf einem lokalen Blockgerät, und die inst.updates -Parameter, um ihn aus dem Fedora-Installer-Image zu referenzieren. Aus dem Grub-Menü markieren wir den Menüeintrag „Fedora installieren“:
Fedora 31 Installationsmenü
Sobald die Menüzeile ausgewählt ist, drücken wir die Tabulatortaste:Die mit dem Eintrag verknüpfte Kernel-Befehlszeile wird am unteren Rand des Bildschirms angezeigt:
Die vom „Install Fedora“-Eintrag verwendete Kernel-Kommandozeile Jetzt müssen wir nur noch die
inst.updates anhängen Anweisung und geben Sie den Pfad zur updates.img an Datei, die wir erstellt haben. Angenommen, sowohl Kickstart als auch die Datei updates.img sind über http auf einem lokalen Server mit 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 die Eingabetaste drücken, um zu booten. Mit der obigen Änderung beschwert sich der Installer nicht mehr über
das entsperrte LUKS Gerät, und die Installation wird ohne Probleme fortgesetzt.
Schlussfolgerungen
In diesem Artikel haben wir gesehen, wie man eine Kickstart-Installation optimiert, um ein bereits vorhandenes LUKS wiederzuverwenden Gerät, indem Sie es im %pre entsperren Abschnitt der Kickstart-Datei und wie man eine kleine Problemumgehung auf das Fedora 31 Anaconda-Installationsprogramm anwendet, das andernfalls fehlschlagen würde, wenn eine solche Art von Installation versucht wird. Wenn Sie neugierig auf die Kickstart-Syntax sind, werfen Sie bitte einen Blick in die Online-Dokumentation.