Vor einiger Zeit wurde in unserem Bugtracker ein Fehler mit der LVM-verschlüsselten Installation in Kali Linux 1.0.4 gemeldet. Dieser Fehler hatte in unserem TODO hohe Priorität, da verschlüsselte Installationen ein wichtiges Feature in unserer Branche sind, also wollten wir diesen Fehler so schnell wie möglich beseitigen. Dieser Artikel beschreibt den Prozess des Debuggens, Identifizierens und Behebens dieses Fehlers in Kali und letztendlich auch in Debian.
Der Fehler selbst war seltsam; Die Installation von Kali mit der Option „LVM Encrypted“ würde nach Abschluss der Installation zu einem fehlgeschlagenen Start führen:
Die im Fehlerbericht vorgeschlagene Problemumgehung zeigte an, dass die Datei /etc/crypttab Datei war leer. Durch manuelles erneutes Mounten der verschlüsselten Partition, erneutes Auffüllen mit den erforderlichen Parametern und anschließendes Aktualisieren des initramfs würde die Maschine erneut erfolgreich in die verschlüsselte Partition booten. Auf jeden Fall ärgerlich und alles andere als praktisch.
Jetzt, da das Problem gut definiert war, schien die Lösung einfach zu sein. Irgendetwas stimmte wahrscheinlich nicht mit dem Weg /etc/crypttab wird während des Installationsvorgangs aktualisiert. Unser nächster Schritt bestand darin, die Skripte zu untersuchen, die für dieses Update verantwortlich sind, und festzustellen, ob es Fehler im Dateiaktualisierungsprozess gibt. Aber wie würden Sie das genaue Skript finden, das für dieses Update verantwortlich ist, und wie könnten wir herausfinden, in welchem Paket es sich befindet?
Zu unserer Rettung kommt DebianInstaller. Unter Verwendung dieses Satzes von Skripten haben wir den gesamten DebianInstaller-Quellbaum ausgecheckt. Dies würde es uns ermöglichen, nach den Skripten zu suchen, die /etc/crypttab betreffen mit viel größerer Leichtigkeit.
[email protected]:~# svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer
[email protected]:~# cd debian-installer
[email protected]:~/debian-installer# scripts/git-setup
[email protected]:~/debian-installer# mr -p checkout
Nachdem alle Repositorys ausgecheckt waren, konnten wir einfach nach allen Dateien suchen, die auf /etc/crypttab verweisen Datei wie folgt:
[email protected]:~/debian-installer# grep -r '/etc/crypttab' * |grep -v ^manual
...
packages/partman-crypto/finish.d/crypto_config:# dm-crypt: creates /etc/crypttab entries
packages/partman-crypto/finish.d/crypto_config: echo "$target $source $keyfile $opts" >> /target/etc/crypttab
...
[email protected]:~/debian-installer#
Wir sehen oben, dass es die „crypto_config ”-Skript, das in /etc/crypttab schreibt , die sich im partman-crypto befindet Paket.
Idealerweise würden wir dieses Skript gerne debuggen und sehen, wo das Problem liegt, aber wie würden Sie dies in einem Live-Installationsmedium tun? Die Antwort ist relativ einfach – wir mussten während des Installationsvorgangs nur eine Eingabeaufforderung öffnen. Der Trick besteht darin, unsere Debugging-Shell (durch Drücken von STRG+ALT+F2) während der richtigen Phase der Installation aufzurufen – in unserem Fall mussten wir den Installer vor der crypto_config unterbrechen Skript wurde ausgeführt, aber nach dem partman-crypto udeb wurde installiert, daher wäre der Beginn des Partitionierungsprozesses ein guter Punkt. Wir haben die /lib/partman/finish.d/55_crypto_config bearbeitet und fügte „set -x hinzu ” am Anfang des Skripts:
Dann ließen wir den Installer seine Arbeit machen und kurz bevor die Installation abgeschlossen war, haben wir einen Blick auf /var/log/syslog geworfen in einer anderen Schale. Zu unserer Überraschung sahen wir, dass die Datei /etc/crypttab Datei *wurde* entgegen unserer anfänglichen Annahme aktualisiert, wie im Syslog der Installation zu sehen ist. WTH .
Aug 28 21:57:42 main-menu[954]: (process:9810): crypttab_add_entry
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/sda5
Aug 28 21:57:42 main-menu[954]: (process:9810): /var/lib/partman/devices/=dev=sda/256901120-160041009151
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/mapper/sda5_crypt
...
Aug 28 21:57:42 main-menu[954]: (process:9810): echo
Aug 28 21:57:42 main-menu[954]: (process:9810): sda5_crypt UUID=6250dbca-648b-4848-9132-cfa900ab5874 none luks
Hier fingen wir an, uns am Kopf zu kratzen. Wenn das Problem nicht im Schreiben dieser Datei lag (wie wir erwartet hatten), warum gab es dann eine leere /etc/crypttab Datei nach der Installation? Vielleicht lag das Problem nicht in partman-crypto schließlich, aber wie live-build generiert unsere ISOs? Wir haben diese unsere Theorie getestet, indem wir eine Kali-Mini-Installations-ISO (nicht per Live-Build erstellt) verwendet haben und festgestellt haben, dass die LVM-verschlüsselten Installationen bei Verwendung dieses Installationsmediums gut funktionierten.
Wir wissen, dass der Live-Installer tar verwendet um das gesamte Live-Dateisystem in ein gemountetes /target zu kopieren Verzeichnis und es geht davon aus, dass die Dateisysteme leer sind, was meistens zutrifft, da sie gerade von partman erstellt wurden. Dies bedeutet, dass jede bereits vorhandene Datei überschrieben werden kann, wenn sie sich auch im Livebild befindet, was mit /etc/crypttab geschehen ist in diesem Fall.
Weitere Untersuchungen ergaben, dass das Problem im Live-Installer lag , wodurch die generierte /etc/crypttab überschrieben wird . Der Live-Installer hat bereits einige Vorkehrungen getroffen, um /etc/fstab nicht zu überschreiben , es geht also nur darum, diese Regel zu verallgemeinern und /etc/crypttab einzufügen auch Datei:
$ diff --git a/debian/live-installer.postinst b/debian/live-installer.postinst
index 9a39d8d..bc40b84 100644 (file)
--- a/debian/live-installer.postinst
+++ b/debian/live-installer.postinst
@@ -8,6 +8,8 @@ db_capb backup
# Architecture and OS detection
ARCH=`udpkg --print-architecture`
OS=`udpkg --print-os`
+# Files that must not be overwritten by copy of live system
+FILES_TO_PRESERVE="/etc/fstab /etc/crypttab"
NEWLINE="
"
@@ -34,11 +36,12 @@ install_live_system () {
# symlinks there.
rmdir /target/var/lock /target/var/run 2>/dev/null || true
- # Backup pre-existing /etc/fstab as it will be overwritten by the
- # copy of the live system
- if [ -e /target/etc/fstab ] && [ ! -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab /target/etc/fstab.live-installer
- fi
+ # Backup files that should not be overwritten by the copy
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target$f ] && [ ! -e /target/${f}.live-installer ]; then
+ mv /target$f /target${f}.live-installer
+ fi
+ done
for place in $PLACES; do
[ ! -e $place ] && continue
@@ -83,10 +86,12 @@ install_live_system () {
eval ${SUPPORT}_teardown
done
- # Restore the fstab file created by d-i
- if [ -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab.live-installer /target/etc/fstab
- fi
+ # Restore important configuration files
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target${f}.live-installer ]; then
+ mv /target${f}.live-installer /target$f
+ fi
+ done
if [ ${PLACE_FOUND} -eq 0 ]; then
error "Could not find any live images"
Der obige Patch hat das Problem für uns behoben, sodass verschlüsselte LVM-Installationen erfolgreich abgeschlossen und gestartet werden können. Wie bei allen Debian-Fehlern, auf die wir stoßen, senden wir Patches an Debian zurück, um die Distribution, auf der wir aufbauen, zu verbessern. Ein Fix für diesen Installationsfehler wird nächste Woche in unserem nächsten Point-Release (1.0.5) herauskommen. Leute, die ihre eigenen ISO-Images durch Live-Build erzeugen erhält automatisch das feste Paket.