staging.inyokaproject.org

Ich habe den Artikel mal entspr. RvDs Wünschen angepasst. Es wird Zeit, dass er ins Wiki kommt!

Verschoben und nach Daten verschlüsseln verlinkt. Danke an die Autoren!!

Hallo,

losetup ist nicht notwendig. cryptsetup kann direkt mit der Containerdatei arbeiten, so wie jedes Dateisystem auch (z.B. mkfs.ext4 containerdatei ; mount -o loop containerdatei /mnt).

Weiters kann das Anlegen einer (großen) Containerdatei viel schneller mit fallocate erfolgen, da nur der Speicherplatz reserviert, aber kein Inhalt geschrieben wird. Ggf. ist dann jedoch darauf zu achten, welche (unverschlüsselten) Datenreste die Containerdatei im nicht benützten Bereich enthalten könnte. Das geht auch zum Vergrößern mit Offset, Beispiel:

fallocate -l 10G containerdatei ; fallocate -l 5G -o 10G containerdatei

ergibt im Endeffekt eine 15-GB-Containerdatei.

Liebe Grüße, B601

B601 schrieb:

losetup ist nicht notwendig.

+1, cryptsetup erstellt bei Bedarf seine eigenen Loop-Devices die dann auch nur solange existieren wie sie benötigt werden. Vor ein paar Jahren mag das noch anders gewesen sein.

Weiters kann das Anlegen einer (großen) Containerdatei viel schneller mit fallocate erfolgen

Wird hier denke ich absichtlich nicht so gemacht. fallocate und truncate kann man als Alternativen ja erwähnen. Bei truncate wird gar nicht allokiert (sparse file) und so gibt es auch keine unverschlüsselten Datenreste in der Containerdatei - aber dafür hat man womöglich mit Fragmentierung zu kämpfen und es gibt natürlich die Gefahr, daß ein Schreibvorgang im Container fehlschlagen kann wenn das Dateisystem zwischenzeitlich voll wurde.

Wirklich einen Unterschied macht das alles aber nur bei sehr großen Containerdateien. Bei wenigen 100M spielt es keine Rolle.

Und von riesengroßen Containerdateien kann man nur abraten. Dateisysteme können bei Stromausfall etc. ganze Dateien verlieren. Bei unverschlüsselten Dateien kann man vielleicht dann noch was machen, im Fall eines LUKS-Containers kann man mehr oder weniger einpacken. Ab einer gewissen Größe sollte man dann doch lieber bei Partitionen bleiben bzw. bei LVM ein eigenes Volume dafür erstellen.

aes-xts-plain → plain64

frostschutz schrieb:

Und von riesengroßen Containerdateien kann man nur abraten. Dateisysteme können bei Stromausfall etc. ganze Dateien verlieren. Bei unverschlüsselten Dateien kann man vielleicht dann noch was machen, im Fall eines LUKS-Containers kann man mehr oder weniger einpacken. Ab einer gewissen Größe sollte man dann doch lieber bei Partitionen bleiben bzw. bei LVM ein eigenes Volume dafür erstellen.

aes-xts-plain → plain64

"Dateisysteme" schon, moderne Linux-/Unix-Dateisysteme eher selten, und wenn, dann nur Dateien, die unmittelbar vor dem Stromausfall erstellt wurden. Dazu wurden sie ja gemacht. ☺ Der Vorteil einer Containerdatei ist ja, dass die Datei in voller Größe angelegt ist, dh. die Inodes werden entsprechend ge- (XFS) bzw. beschrieben (z.B. ext4). Danach ändert sich an der Speicherplatzzuordnung nichts mehr, egal was ich mit der Containerdatei mache. Sie bleibt ja fix an ihrem Platz und behält ihre Größe. Daher verliere ich sie auch nicht bei einem Stromausfall. Dieser kann nur den Inhalt der Containerdatei betreffen, und das kann mit einer Partition genauso passieren.

Hallo,

falls hier jemand mitliest, der sich auskennt: Wie in diesem Thema bereits vor 6 Jahren angesprochen, ist auch mir unklar, warum überhaupt losetup verwendet wird. Vor allem ist die Inkonsistenz diesbezüglich zum Artikel LUKS (Abschnitt „Erstellen“) für den naiven Leser unklar.

Falls niemand erklären kann, warum man losetup benutzen sollte, schlage ich vor, die entsprechenden Zeilen zu löschen.

Viele Grüße Aaron

Hab die Anregung nun durch Hinweisboxen umgesetzt:

Verlauf:

+wie in "LUKS" zu "-c aes-xts-plain64 -s 512 -h sha512 -y" vereinheitlicht +Getestet +2/3 Schritte zusammengefasst

Graphische Handhabung von Containern mit PCManFM/Lubuntu unter Lubuntu 16.04

PCManFM beherrscht die Handhabung von LUKS devices/partitionen, dh. luksOpen/luksClose sowie mount/unmount. Es fehlt zunächst die Verfügbarkeit des LUKS-containers als device. Dies kann mittels sudo losetup -f Container geschehen. Das Loop-device muss dann jedoch auch mittels losetup detached werden.

Eine Alternative ist das Anlegen eines Eintrags im Contextmenü für gnome-disk-image-mounter: Rechtsklick auf Container → Open with → Custom command line → "gnome-disk-image-mounter --writable %f" Als Name beispielsweise "Image mounter rw"

Der so angelegte Eintrag kann dann immer per Rechtsklick angewählt werden.

Hinweise:

gnome-disk-image-mounter mounted den Container ohne "--writable" als read-only. Eine Benennung des Containers auf *.iso oder *.img und Verwendung des Default-Menüeintrags funktioniert daher nicht (bzw. eben nur read-only)

gnome-disk-image-mounter legt das loop-device mit "auto-clear" an. Nach dem "Aushängen" des verschlüsselten, gemounteten Filesystems verschwindet auch das zugehörige loop-device.

Edit: Ich finde es gut und wichtig, dass im Artikel weiterhin der ausführliche Weg und dabei die kürzeren Varianten gezeigt werden. Ohne den ausführlichen Weg hätte ich es nicht so gut verstanden und wäre vielleicht auch nicht auf die (für mich) komfortable Lösung gekommen

Hallo,

Den Artikel habe ich heute getestet mit Xubuntu 22.04. Es klappt alles, nur beim Container vergrößern bringt

resize2fs /dev/mapper/container 

folgende Meldung:

resize2fs 1.46.5 (30-Dec-2021)
Bitte lassen Sie zuerst „e2fsck -f /dev/mapper/container“ laufen.

Nachdem man obiges e2fsck durchgeführt hat, läuft resize2fs normal durch. Ich bin leider überfragt, ob man das im Artikel erwähnen sollte.

Grüße, gartenapfel

gartenapfel schrieb:

Ich bin leider überfragt, ob man das im Artikel erwähnen sollte.

Da steht doch seit Rev. 170049 (sozusagen von Anfang an):

Man sollte vor und nach dem Befehl eine Dateisystemprüfung durchführen.

Nichts anderes macht e2fsck.

Ja, das stimmt. Dann wird es wohl so passen. Es ist halt eine minimale Abweichung, weil man direkt dazu aufgefordert wird, e2fsck auszuführen.

Vielen Dank für die Antwort!

Grüße, gartenapfel