Re: Verschlüsselung in Lenny
On Mon, 29 Dec 2008 23:15:35 +0100
Dirk Salva <dsalva@gmx.de> wrote:
> Nö, eher nicht. Ein xfs_repair muss immer händisch und bei nicht
> gemountetem device gemacht werden.
Ich glaube wir reden hier etwas an einander vorbei. In fstab eingetragene Volumes werden meinstens automatisch beim Booten eingehängt. Ist dabei das sechste Feld ungleich 0 wird VOR dem Einhängen ein passendes fsck mit ~interaktiven Konsole durchgeführt. Also z.B. bei ext3 dann fsck.ext3 und bei xfs dann fsck.xfs.
Das soll in erster Linie bei einem Journaling-FS mit eingeschaltetem Jornal diesen "Commiten/Verwerfen" und alles nötige geradebiegen oder ohne Journal (ext2 z.B.) bei unsauberem/fehlendem unmount ein kompletes fsck durchführen.
Hier hat xfs eben eine kleine Besonderheit. Hier man-Zitat:
fsck.xfs is called by the generic Linux fsck(8) program at startup to check and repair an XFS filesystem. XFS is a journaling filesystem and performs recovery at mount(8) time if necessary, so fsck.xfs simply exits with a zero exit status.
If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_check(8) and xfs_repair(8).
XFS Journal wird also nicht von dem ensprechendem fsck.xfs "repariert", sondern von dem xfs-driver selbst beim mounten.
Im normalfall muss man also eigentlich nichts extra machen. Standard wird unter xfs aber journal-Modus verwendet, der dennoch zur Datenverlust führen kann (aber afair nicht zu Beschädigung des Dateisystems selbst). Diesen kann man afair auch nicht feststellen oder korrigieren. Da hilft ein xfs_check vermutlich auch nicht, aber ich bin mir jetzt unsicher darüber. Es gibt aber Journal-Moden, die langsamer und sicherer sind.
> > > Wenn ich das richtig in Erinnerung habe, was
> > > ich eben las, so wird aber das XFS sozusagen "in" das dm-crypt-device
> > > verbracht. Also nicht Partition->XFS->dm-crypt->Userdaten, sondern
> > > Partition->dm-crypt->XFS->Userdaten. Also müßte ich im zweiten Fall gar
>
> Ist hier die zweite Reihenfolge korrekt?
Ja sie ist.
> Wenn ja, wie kann ich entschlüsseln aber danach _nicht_ das enthaltene
> filesystem mounten?
Hat man den Verdacht, die Struktur des Dateisystem ist aus irgendwelchen Gründen beschädigt, dann wird man bei nicht gemounten Dateisystem paar Checks durchführen möchten.
Möglichkeiten:
1. unmount durchführen
2. erst garnicht mounten lassen - ist bei einem mit dm-crypt verschlüsseltem Dateisystem nicht anders als bei unverschlüsselten und darum eher OT hier.
Wenn es z.B. aus irgendwelchen gründen auch immer noch nicht durch crypttab verarbeitet wurde, dann muss man es noch "entschlüsseln". Sonst ist es bereits entschlüsselt.
Per hand geht das halt ungefähr so:
cryptsetup luksOpen /dev/bla blub
fsck /dev/mapper/blub
mount /dev/mapper/blub
...
umount /dev/mapper/blub
cryptsetup luksClose blub
Entsprechend kann man da zu dem Zustand sich bewegen, zu dem man möchte.
Noch 2 Anmerkungen:
1. xfs hatte noch ein Problemchen, fällt mir noch ein. Man sollte irgendwie sicher sein, dass Journal bereits geschrieben worden ist, bevor man irgendwie weitermacht.. Es hatte jedenfalls alles mit dem Write-Buffer von HDDs zu tun und mit zwischen-Buffers. Da hat xfs einen Trick, in dem da ein Befehl durchgereicht wird.. Irgendeine Schicht konnte das blockieren und die Situation verschlechtern. Ich weiß nicht mehr genau ob es LVM oder dm-crypt Schicht war und ob es immer noch so ist. Ich vermute, das wurde gelöst. Zu xfs gibt es eh auf deren Seiten ausführliche Dokumentation.
2. Es wird aus sicherheitstechnischen Gründen empfohlen bei Verschlüsselung eines Volumes auch noch alle swap-Volumes zu verschlüsseln. Das ist dann auch mit einem dynamisch generiertem Key möglich, wenn man auf hibernate verzichten kann.
Reply to: