loop-aes per UUID einbinden
loop-aes per UUID einbinden
Ab Kernel 2.6.19 ist es ja möglich per UUID in der fstab Partitionen einzubinden. Nach meinen Erfahrungen mit Feisty und dem ständigen Switchen zwischen /dev/hda und /dev/sda habe ich auch die "normalen" Partitionen per UUID eingebunden. Mit der loop-aes Partition klappt das natürlich nicht.
Hat jemand eine Idee dazu?
Hat jemand eine Idee dazu?
Hmmh. cryptsetup und die /etc/crypttab sind doch dm-crypt, oder? Bei loop-aes verwendet man losetup und mapped ein Device auf ein Loop Device und trägt es dann in die fstab ein. Vom loop Device bekomme ich die UUID, die nutzt mir aber nichts.
Aber kannst Du denn bei dm-crypt per UUID Partitionen mounten?
Auf jeden Fall muss ich das aus der fstab rausnehmen und vielleicht per Skript booten. Dann fehlt aber der fstab Eintrag, damit ich es mounten kann. Möglicherweise wurde auch damals beim anlegen der loop-aes Partition ein UUID= key ausgespuckt - keine Ahnung. Jetzt bekomme ich den nicht mehr raus, weil das System die Partition ja nicht mehr lesen kann.
Aber kannst Du denn bei dm-crypt per UUID Partitionen mounten?
Auf jeden Fall muss ich das aus der fstab rausnehmen und vielleicht per Skript booten. Dann fehlt aber der fstab Eintrag, damit ich es mounten kann. Möglicherweise wurde auch damals beim anlegen der loop-aes Partition ein UUID= key ausgespuckt - keine Ahnung. Jetzt bekomme ich den nicht mehr raus, weil das System die Partition ja nicht mehr lesen kann.
Mit nicht mehr lesen meine ich, das bsp. /dev/hda6 vom System nicht lesbar ist und ich damit auch keine UUID bestimmen kann. Erst wenn ich /dev/hda6 bsp. auf /dev/loop2 mappe und entsprechend einbinde kann ich auf /dev/loop2 lesen.Savar hat geschrieben:wie? du kannst sie allgemein nicht mehr lesen? nicht einmal manuell?
Ja, irgendwie so. Ich muss mal schauen. Die Schwierigkeit scheint zu sein, das ich von /dev/hda6 keine UUID bekommen kann - das ich aber /dev/hda6 brauche, um es auf das loop Device zu mappen.Savar hat geschrieben:hmm.. dann wäre es wohl am sinnvollsten ein Init Script zu erstellen, welches die loop-aes Devices vor der /etc/fstab anlegt?
Spontan denke ich - das geht gar nicht.
EDIT:
Ach ja, das ist ja mittlerweile ein /dev/sda6 geworden. Danke Kernelbastler.



- Six
- Beiträge: 8071
- Registriert: 21.12.2001 13:39:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Siegburg
Ja, das war ich. Allerdings habe ich auch noch keine verschlüsselte Partition damit gemountet. Um genau zu sein, habe ich mit verschlüsselten Partitionen, die automatisch gemountet werden sollen, noch nie zu tun gehabt. Ich kann dir in deiner speziellen Situation also nicht wirklich helfen. Sorry.
Be seeing you!
Auch ok. Danke. Ich habe die Frage auch im Ubuntu Forum gepostet und keine Antwort bekommen. Für die Jungs dort müsste es eigentlich ein Thema sein, da denen bei den aktuellen Kernel Updates das Starten des Systems immer wieder neu nicht gelingen will.Six hat geschrieben:Ich kann dir in deiner speziellen Situation also nicht wirklich helfen. Sorry.

Bsp:
Kernel 2.6.17-11: /dev/hda
Kernel 2.6.20-15: /dev/sda
Kernel 2.6.20-16-28: /dev/hda
Kernel 2.6.20-16-29: /dev/sda
Naja - eine Regelmässigkeit hat es wenigstens...

loop-aes muss man sich ja selber kompilieren und ist nicht im Kernel. Aus der Sicht sehe ich die Chancen auch schlecht bei loop-aes damit eine UUID zu bekommen. Deshalb interessiert mich auch, ob es bsp. bei dm-crypt geht - das kommt ja als Kernelmodul mit.Six hat geschrieben:Da fällt mir gerade ein, mounten von verschlüsselten FS wird unter CentOS per Initrd erledigt. Details kenne ich nicht.
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
Ja.ub13 hat geschrieben:Deshalb interessiert mich auch, ob es bsp. bei dm-crypt geht
Ich ziehe zwar meinst noch einen Layer (udev) ein damit ich weiß
- welche Disk
- welche Maschine
- wo (Ort)
- etc.
damit bekomme ich dann z.B. solche device nodes
/dev/iowa_cl1_st2_gateway
das kann man dann mit
Code: Alles auswählen
/etc/crypttab
/etc/fstab
/etc/init.d/cryptdisks
FAZIT
Ich würde nicht loop-aes verwenden um verschlüsselte loop devices zu machen sondern dm-crypt. loop-aes ist ein eigenständiges Userspacetool und somit dm-crypt/LUKS gegenüber klar im Nachteil.
http://feraga.com/node/51
Markus
Meine Gründe loop-aes zu verwenden sind:meandtheshell hat geschrieben:Ich würde nicht loop-aes verwenden um verschlüsselte loop devices zu machen sondern dm-crypt. loop-aes ist ein eigenständiges Userspacetool und somit dm-crypt/LUKS gegenüber klar im Nachteil.
1. ich nutze es schon recht lange
2. die Performance ist laut Vergleichen bei loop-aes besser
3. meine externe Disk ist auch loop-aes
4. man kann es extern per Knoppix bedienen
Wenn ich nun auf dm-crypt wechsle muss ich a) meine externe Disk komplett neu aufsetzen, b) meine Datenpartition komplett neu aufsetzen, c) von Knoppix auf GRML wechseln und mich in dm-crypt einarbeiten (ok, das sollte das kleinste Problem sein). Wenn ich all das zusammen bedenke, bleibe ich noch solange bei loop-aes (ohne UUID) bis ein grösserer Wechsel ansteht und ich sowieso etwas ändern muss.
Danke an alle...
Andersherum. Dmcrypt/LUKS ist ein eigenstaendiges Userspace Programm und loop-aes ersetzt das bisherige loop-Modul und patch nur tools wie mount oder losetup. Versteh eh nicht die damit zusammenhaengende Bewertung.meandtheshell hat geschrieben:Ich würde nicht loop-aes verwenden um verschlüsselte loop devices zu machen sondern dm-crypt. loop-aes ist ein eigenständiges Userspacetool und somit dm-crypt/LUKS gegenüber klar im Nachteil.
Loop-aes per UUID einbinden sollte AFAIK nicht gehen, da ab offset 0 schon verschluesselte Daten stehen. Ein Kompromiss waere die loop-devices von der initrd erzeugen zu lassen (1). Oder man schreibt die UUID an den Anfang der Partition und patch die loop-aes-utils.

- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
?uljanow hat geschrieben:Andersherum. Dmcrypt/LUKS ist ein eigenstaendiges Userspace Programm und loop-aes ersetzt das bisherige loop-Modul und patch nur tools wie mount oder losetup. Versteh eh nicht die damit zusammenhaengende Bewertung.meandtheshell hat geschrieben:Ich würde nicht loop-aes verwenden um verschlüsselte loop devices zu machen sondern dm-crypt. loop-aes ist ein eigenständiges Userspacetool und somit dm-crypt/LUKS gegenüber klar im Nachteil wenn es um die UUID geht.
- dm-crypt ist ein devicemapper der Teil des Kernels ist
- LUKS ist ein Standard welcher in Form von cryptsetup (dem Userspace Tool um das dm-crypt API des Kernels zu nutzen) seine Implementierung gefunden hat
Genau dieses fehlt loop-aes. loop-aes ist auf sich alleine gestellt bzw. benutz das eigene kernel modul da es nicht über ein internes API auf Kernelfunktionen zugreifen kann.
Zumindest hätte ich jetzt spontan keine Idee wie ich im Falle von loop-aes VOR dem mounten schon die UUID bekommen könnte. Wenn da jemand eine Idee hat dann soll er es kundtun.
Markus (dem gerade eh alles egal ist weil er im Gefecht mit dem Schlaf ist und starke territoriale Verluste einfährt)
Danke für die Einschätzung. Ich will da aber nicht rummurksen und patchen. Bei einem Update muss ich mir dann überlegen, wie ich den neuen Patch reinbekomme. Wenn ich es richtig sehe ist beim "loop-devices von der initrd erzeugen zu lassen" aber immer noch ein Eintrag in der fstab notwendig - und genau der ist ja mein Problem, da aktuell bei Feisty der Wechsel von /dev/hda zu /dev/sda schneller geht, als manche gucken können. Mit UUID wollte ich einfach ein Stück unabhängig davon werden.uljanow hat geschrieben:Loop-aes per UUID einbinden sollte AFAIK nicht gehen, da ab offset 0 schon verschluesselte Daten stehen. Ein Kompromiss waere die loop-devices von der initrd erzeugen zu lassen (1). Oder man schreibt die UUID an den Anfang der Partition und patch die loop-aes-utils.
Und die UUID an den Anfang der Partition zu schreiben traue ich mich nicht.
