Ich versuche seit Wochen unter Jessie/Stretch während des Bootens 2 oder mehr luks-Container automatisch entschlüsseln zu lassen, wie es bis Wheezy einwandfrei ging. Die Container sind unabhängig voneinander verschlüsselt. Jeder Container hat eine eigene Zeile in der crypttab und ein eigenes Keyscript zum Entschlüsseln.
Der erste Container ist in der Regel /root und swap in einem LVM, der zweite ist ein auf eine zweite Platte verlegtes /home. Das muss sofort mit eingebunden werden.
Bis Wheezy hat das einwandfrei funktioniert. War egal ob nach der ursprünglichen Methode von Janssen/Weijn mit einem Keyfile auf einem USB-Stick, oder später frei nach der Methode die in https://wiki.ubuntuusers.de/System_vers ... C3%BCssel/ beschrieben wird.
Ich verwende nicht die Skripte aus dem Artikel, sondern habe das Conf-File und die notwendigen Aktionen in einem Skript zusammengefasst.
Mit Jessie und Stretch klappt das auch mit dem ersten Eintrag in der crypttab, für weitere wird aber immer ein Key auf der Konsole abgefragt. Ich habe an der Ecke ewig rumgebastelt und kriege es nicht zum Laufen. Gibt es für dieses Problem eine Lösung?
Sogern ich meinen Hauptrechner auf Stretch upgraden würde, ohne das Feature mehrerer Container automatisch zu öffnen mache ich das nicht.
Schönen Restfeiertag, Rolf
Mehrere luks-Container automatisch öffnen
Re: Mehrere luks-Container automatisch öffnen
Seit jessie werden fstab und crypttab von systemd (systemd-mount) und nicht mehr von mount und cryptsetup abgearbeitet.
Aber mit systemd sind keine Keyscripts mehr möglich. Und systemd hält das auch für ein Feature, weil man keine Scripte mehr im Bootvorgang sehen will. Da wird sich also nichts ändern.
Du hast folgende Möglichkeiten:
a) Umstieg auf System V-init
b) Umstieg auf Keyfiles statt Keyscripten.
c) Das öffnen/schlißen und mounten/unmounten der Platten als eigenen Dienst nach local-fs.target einbauen und auf fstab und crypttab zu verzichten.
b) Dürfte die einfachste Variante sein. Und die beste Wahl wenn das möglich ist. c) die universellste, die auch in recht unkonventionellen Installationen noch funktioniert. a) ist zumindest unter debian defakto nicht mehr möglich.
Willst du Hilfe zu einem der Punkte brauchst melde dich einfach nochmal.
Aber mit systemd sind keine Keyscripts mehr möglich. Und systemd hält das auch für ein Feature, weil man keine Scripte mehr im Bootvorgang sehen will. Da wird sich also nichts ändern.
Du hast folgende Möglichkeiten:
a) Umstieg auf System V-init
b) Umstieg auf Keyfiles statt Keyscripten.
c) Das öffnen/schlißen und mounten/unmounten der Platten als eigenen Dienst nach local-fs.target einbauen und auf fstab und crypttab zu verzichten.
b) Dürfte die einfachste Variante sein. Und die beste Wahl wenn das möglich ist. c) die universellste, die auch in recht unkonventionellen Installationen noch funktioniert. a) ist zumindest unter debian defakto nicht mehr möglich.
Willst du Hilfe zu einem der Punkte brauchst melde dich einfach nochmal.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Mehrere luks-Container automatisch öffnen
@wanne: Danke für den Denkanstoss, ich bin jetzt einen grossen Schritt weiter, der Container meiner Datenplatte wird automatisch laut Option b) mit einem Keyfile geöffnet.
Ich habe wohl 2 Fehler gemacht:
1.) Keyfile war bei mir immer gleichbedeutend mit dem Öffnen und Ausgeben des Keyfiles per cat nach Janssen/Weijn.
2.) Ich habe dann auch nicht den kompletten Pfad für den Keyfile verwendet, sondern nur den Namen. Nachdem ich das korrigiert hatte, läuft die Entschlüsselung.
Habe da noch mal einige Threads zur Schlüsselableitung gelesen und endlich ein für mich näherungsweise passendes Beispiel gefunden das den Kronleuchter angeworfen hat.
Stand:
- Die OS-SSD wird nach der Ubuntu-Methode per Keyscript über diese Debian-spezifische Sonderlocke geöffnet.
- Der Keyfile liegt im entschlüsselten root in einem Directory versteckt.
- Die Datenplatte wird beim Boot soweit ich das bis jetzt beurteilen kann zuverlässig entschlüsselt und in /dev/mapper gelistet.
Aber ab da hängt es jetzt wieder:
- Das LVM auf der Datenplatte wird nicht erkannt/eingebunden. Es müsste da automatisch ein vgscan/vgchange angeschmissen werden.
- Dann möchte ich eigentlich automatisch ein fs-check vor dem Mounten laufen haben.
Wie kriege das möglichst einfach gebacken?
Danke, Rolf
Ich habe wohl 2 Fehler gemacht:
1.) Keyfile war bei mir immer gleichbedeutend mit dem Öffnen und Ausgeben des Keyfiles per cat nach Janssen/Weijn.
2.) Ich habe dann auch nicht den kompletten Pfad für den Keyfile verwendet, sondern nur den Namen. Nachdem ich das korrigiert hatte, läuft die Entschlüsselung.
Habe da noch mal einige Threads zur Schlüsselableitung gelesen und endlich ein für mich näherungsweise passendes Beispiel gefunden das den Kronleuchter angeworfen hat.
Stand:
- Die OS-SSD wird nach der Ubuntu-Methode per Keyscript über diese Debian-spezifische Sonderlocke geöffnet.
- Der Keyfile liegt im entschlüsselten root in einem Directory versteckt.
- Die Datenplatte wird beim Boot soweit ich das bis jetzt beurteilen kann zuverlässig entschlüsselt und in /dev/mapper gelistet.
Aber ab da hängt es jetzt wieder:
- Das LVM auf der Datenplatte wird nicht erkannt/eingebunden. Es müsste da automatisch ein vgscan/vgchange angeschmissen werden.
- Dann möchte ich eigentlich automatisch ein fs-check vor dem Mounten laufen haben.
Wie kriege das möglichst einfach gebacken?
Danke, Rolf
Re: Mehrere luks-Container automatisch öffnen
Ich habe da einen walkaround,rhHeini hat geschrieben: Aber ab da hängt es jetzt wieder:
- Das LVM auf der Datenplatte wird nicht erkannt/eingebunden. Es müsste da automatisch ein vgscan/vgchange angeschmissen werden.
ausgehend von beim Start verbleibenden Prozessen 'lvm pvscan --activate ...' aus der udev-Regel.
/etc/udev/rules.d/69-lvm-metad.rules
Code: Alles auswählen
...
#RUN+="/sbin/lvm pvscan --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"
# 20170604, stretch, Problem lvmetad <->? pvscan --cache [--activate] <->? systemd-udevd
# Auswirkung: boot-timeout, verbleibende udevd-pvscan-Prozesse
RUN+="/bin/echo DUMMY /sbin/lvm pvscan --cache --activate ay --major $major --minor $minor"
...
/lib/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> 69-lvm-metad.rules
Der zweite Teil ist eine Ergänzung eines für den Zweck hinreichenden service
/etc/systemd/system/lvm2-lvmetad.service.d/lokal_walkaround.conf
Code: Alles auswählen
[Service]
# Cache-Laden:
# mehrere ExecStart= nur bei Type=oneshot, also:
ExecStartPost=/bin/sleep 2
#ExecStartPost=/sbin/lvm pvscan --cache --activate ay STARKE Probleme hiermit!! (in der Boot-Phase)
ExecStartPost=/sbin/lvm pvscan --cache
#ExecStartPost=/sbin/lvm vgscan --cache unnoetig
Dadurch erreiche ich ein konfliktfreies Einlesen der PV und das Aktivieren klappt insgesamt flott,
nicht nur beim Booten.
Du könntest bei einem ext-Dateisystem 'tune2fs -c max-mount-counts -C mount-counts' ensprechend setzen.- Dann möchte ich eigentlich automatisch ein fs-check vor dem Mounten laufen haben.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Mehrere luks-Container automatisch öffnen
Hallo rendegast,
diese Regel existiert bei meinem Stretch nicht:
Warum ein pvscan? Wenn ich ein LVM manuell einbinde, mache ich immer ein vgscan.
Nachtrag: habe gerade in /dev/mapper nachgesehen, diesmal sind die LVs der Datenplatte beide da, ohne das ich da eingegriffen habe?
Gruss, Rolf
diese Regel existiert bei meinem Stretch nicht:
, wohl die
Also die aktivieren per Link?
Warum ein pvscan? Wenn ich ein LVM manuell einbinde, mache ich immer ein vgscan.
Nachtrag: habe gerade in /dev/mapper nachgesehen, diesmal sind die LVs der Datenplatte beide da, ohne das ich da eingegriffen habe?
Gruss, Rolf
Re: Mehrere luks-Container automatisch öffnen
Es ist eine Kopie der Origianldatei, nur halt mit einer dummy-Aktion.rhHeini hat geschrieben: diese Regel existiert bei meinem Stretch nicht:
/etc/udev/rules.d/69-lvm-metad.rules
Das blanke pvscan dient dazu, dem Cache des lvm-Dienstes die vorhandenen pv bekannt zu machen.Warum ein pvscan? Wenn ich ein LVM manuell einbinde, mache ich immer ein vgscan.
Das 'sleep' ist eine für mein System austarierte Verzögerung.
Der Link
/lib/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> 69-lvm-metad.rules
kommt bei Erstellung/Löschung eines pv während des Betriebs zum Einsatz.
Ich habe hier eine Umgebung mit einem Dateisystem auf mehr als einem Dutzend hintereinanderliegenden PV auf einer HDD.
Bei einem Starten des Systems habe ich einen mehrere Minuten langen Hänger,
danach verbleiben etliche Prozesse 'lvm pvscan --activate ...' (imo resultierend aus der udev-Regel).
Der ganze walkaround dient zur Umgehung dieses Verhaltens,
wohl irgendein Verschlucken durch den Versuch der parallelen Verarbeitung.
Der im TO geschilderte Fehler schien mir meinem Grundproblem ähnlich.
Zudem steckt einige Zeit in der Erarbeitung des walkarounds, sodaß ich ihn einfach mal posten wollte.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Mehrere luks-Container automatisch öffnen
@rendegast: Danke für den Hinweis auf den walkaround, ich will aber erst mal versuchen zu verstehen ob/wie ich das mit systemd-Units hinkriegen kann, da meine Konfiguration deutlich einfacher zu sein scheint als Deine.
eine Unit erstellt und nach Wiki-Artikel https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick nach /etc/systemd/system kopiert habe.
Aus irgendeinem Grunde hat das erst beim erneuten Boot heute funktioniert, oder ich habe da was übersehen. Jedenfalls wird das LVM auf der grossen Platte wiederholt auch geöffnet.
Daraufhin habe ich mal die Bootmeldungen durchgeschaut ob ich da was von einem fsck der logischen Datenträger sehe, da ist aber nichts. Kann man das nicht auch durch die gleiche Unit erreichen? Hier ist die eingefügte Unit:
Gruss, Rolf
Stimmt nicht ganz, hatte vergessen das ich mitrhHeini hat geschrieben:05.11.2017 14:00:51Nachtrag: habe gerade in /dev/mapper nachgesehen, diesmal sind die LVs der Datenplatte beide da, ohne das ich da eingegriffen habe?
Code: Alles auswählen
systemctl --system daemon-reload
Aus irgendeinem Grunde hat das erst beim erneuten Boot heute funktioniert, oder ich habe da was übersehen. Jedenfalls wird das LVM auf der grossen Platte wiederholt auch geöffnet.
Daraufhin habe ich mal die Bootmeldungen durchgeschaut ob ich da was von einem fsck der logischen Datenträger sehe, da ist aber nichts. Kann man das nicht auch durch die gleiche Unit erreichen? Hier ist die eingefügte Unit:
Code: Alles auswählen
# Automatically generated by systemd-cryptsetup-generator
[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
RequiresMountsFor=/..........key
BindsTo=dev-disk-by\x2duuid-abcdef.....device
After=dev-disk-by\x2duuid-abcdef.....device
Before=umount.target
[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/lib/systemd/systemd-cryptsetup attach 'bigdrive_crypt' '/dev/disk/by-uuid/abcdef....' '/..........key' 'luks,discard'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'bigdrive_crypt'