staging.inyokaproject.org

Hallo,

siehe Wiki/Syntax

Wer schreibt,

Jeder darf schreiben.

kontrolliert

Jeder darf kontrollieren

und veröffenlicht denn die Artikel

Das Wiki-Team bzw. wenn der Edit im Wiki gemacht wird ist es immer direkt online.

bzw. gibt es einen redaktionellen Workflow?

So was ähnliches. Wenn du größere Änderungen an einem Artikel machen willst, verschieben wir ihn dafür i.d.R. in die Baustelle. Komplett neue Artikel werden immer automatisch in der Baustelle anglegt.

Gruß, noisefloor

So habe es mal nach besten Wissen und Gewissen probiert. Fehlt noch die automatische Einbindung mit pam_mount und den automatische fsck durch die fstab. Habe leider vergessen die Info/Änderungsnotiz zu schreiben.

Hält es irgend jemand für nötig auf einen Dateisystemcheck zu erwähnen? Wird nicht automatisch nach X-Mountvorgängen das Dateisystem überprüft oder passiert das beim manuellen Einhängen nicht?

Alternativ könnte man ja vielleicht unter Links Hinweise auf Artikel dieser Art machen, was meint Ihr?

Ich habe die Threads mal zusammengelegt.

Wie bereits erwähnt sind das Aspekte, die in anderen Artikel beschrieben werden und entsprechend wenn, dann über die Wissensbox referenziert werden, um Redundanzen zu vermeiden.

Daten verschlüsseln enthält übrigens bereits die Komponenten, die bei pam_mount die automatische Prüfung sicherstellen. Beim manuellen Einhängen passiert das in der Tat nicht.

Sollten die Devices mit Nautilus eingehängt werden, meine ich aber, dass die Prüfung durchgeführt wird. Manchmal dauert der Mountvorgang sehr lange. Das gleiche gilt für KDE. Sollte man es in der Konsole mounten bekommt man glaube ich die entsprechende Meldung, dass man das Dateisystem überprüfen sollte.

Unabhängig davon, sobald ein Fehler auftritt wird in jedem Fall das Dateisystem überprüft von daher finde ich das nicht weiter tragisch. Natürlich könnte man im Artikel noch mit einem Satz daraufhinweisen, wenn jemand eine gute Idee hat.

Man kann scheinbar doch die Iterationen manuell anpassen (der Parameter ist -i), auch nachträglich durch hinzufügen eines neuen Keys.

Ich habe das noch nicht ausprobiert, aber wenn der Vorgang dadurch wirklich massiv beschleunigt wird, könnte man das eventuell noch als Experteninfo hinzufügen, was gerade im Fall der Schlüsselableitung sehr hilfreich sein kann. Der Key müsste ja sehr sicher sein und durch die hohe Anzahl an Iterationen wird der Bootvorgang nur ausgebremst.

Es beschleunigt auch Wörterbuch-Angriffe massiv...

Naja, es wird ein Salt verwendet und Wörterbuchangriffe auf abgeleitete Schlüssel sollten unmöglich sein, da die 256 Bit oder so lang sind. Ich meinte ja, dass es hauptsächlich sinnvoll wäre für Schlüsselableitung da mit mehreren Partitionen der Startvorgang schon ordentlich verzögert wird.

Was sollen wir jetzt mit der Dateisystemprüfung machen, wo kommt das am besten hin und ist Nautilus nicht dazu in der Lage?

Das Problem ist, dass unweigerlich irgendwelche "Experten" ihre Bootzeit tunen, indem sie das auch mit der ersten Partition tun.

Entsprechend bin ich nicht dafür - wirklich Bootzeit spart man, in dem man keine Verschlüsselung verwendet.

Ok, also wenn würde ich es - eine Iteration von 100 ms - glaube ich sowieso nur unter Schlüsselableitung einfach als Parameter einbauen ohne es groß zu erklären. Das fändest Du auch nicht sinnvoll?

Also der Artikel Dateisystemcheck ist nicht wirklich brauchbar als Link. Gibt es dazu Alternativen?

Problem unter 10.04 64 Bit, Festplatte per eSATA angeschlossen: Dateisystem: crypt-luks gparted schreibt: Warnung: Verschlüsselung durch Linux Unified Key Setup wird noch nicht unterstützt

Info für's Wiki? oder Abhilfe?

Das ist kein generelles Problem, Gparted unterstützt halt kein Luks. Dafür kommt aber der Gnome-Diskmanager damit klar und der ist im Gegenteil zu Gparted auch nach der Installation vorhanden.

unggnu schrieb:

Das ist kein generelles Problem, Gparted unterstützt halt kein Luks. Dafür kommt aber der Gnome-Diskmanager damit klar und der ist im Gegenteil zu Gparted auch nach der Installation vorhanden.

Genau da hänge ich gerade. Das Erstellen mit dem Diskmanager lief problemlos, aber aufgrund meiner Anfängerqualitäten kann ich da nirgends "hinten rein" schauen. Vielleicht wäre eine Anleitung für den Manager nicht schlecht und ein wenig ausführlichere Hintergrundinformation, wo die ganzen Daten liegen (weil sich die USB-HDD quasi selbstständig mountet, ohne dass ich ne Ahnung hab, wo die Informationen dafür liegen, um sie auch mal aus dem Terminal ausführen zu können).

Allgemeine Kritik zum Artikel (aus Sicht eines Noobs): Viel zu hoher "Nerd-Faktor" (ist ein Erstellen aus der Kommandozeile noch immer 1. Wahl?); ein Hinweis darauf, dass man zumindest bei Lucid das Ganze aus dem Diskmanager verwenden kann, ohne vorher noch was installieren zu müssen, wäre gut. Auch die Möglichkeit, das Passwort mittels Schlüsselmanager zu verwalten, wird nicht angesprochen (läuft bei mir auf Lucid, PW ist dabei nicht identisch mit User-PW).

Der Keyring login liegt im Benutzerverzeichnis und wird mit dem Benutzerpasswort verschlüsselt. Insofern funktioniert das nur wenn man bereits voll angemeldet ist.

Hallo Leute,

mal was anderes, aber ich würds gerne in die Diskussionsrunde werfen:

Sollten wir nicht den LUKS-Artikel dahingehend erweitern, dass man den Leuten IMMER rät, den LUKS-Header mit Hilfe von "cryptsetup luksHeaderBackup" zu sichern? Falls man aus Versehen / aus Dummheit / wegen Plattendefekt die ersten paar Bytes der Festplatte nicht mehr lesen kann, ist die Verschlüsselung nämlich tot und alle Daten weg.

Beispiele: http://www.effinger.org/blog/2008/10/12/daten-von-mit-luks-verschlusselter-platte-retten/ http://forum.ubuntuusers.de/topic/luks-verschluesselte-partition-beschaedigt/ http://forum.ubuntuusers.de/topic/brauche-dm-crypt-luks-experten-hilfe/

Ich würde das (nach einem Test) auch machen, allerdings wollt ich euch nicht einfach in den Artikel pfuschen.

Beste Grüße