Ok, ich hatte das etwas überlesen...
Basically copy the files you find in this git repo to your device
...bzw. bin ich mir nicht sicher, was genau warum wie geändert wurde. Und du sagst ja selbst, sogar im selben Satz:
, however please read everything before you do anything.
Für andre mag das reichen - ich find das ganze etwas umfangreich, was es schwer durchschaubar, wartbar und evtl. fehleranfälliger macht, wie du ja auch schon gedacht hast. Ich will immer alles verstehen und leicht reproduzieren können, möglichst weil es so einfach ist, dass man sich die 2-3 Befehle/ Konfigs merken kann oder leicht in einer man wiederfindet.
Vielleicht ist mein Anspruch da zu hoch, aber ich mag halt nicht irgendwas einsetzen, dessen Konsequenzen ich nicht einschätzen kann - oder wo ich mehr als 1h dran sitze, um das im Detail nachzuvollziehen. Stichproben sahen zwar gut aus, aber da stand ja auch irgendwo was von Vereinfachungsplänen.
Vielleicht könnte man noch ergänzen, warum man da z.B. etwa 20 confs in upstart kopiert werden müssen. Wobei ich hier gerade so eine Art Log sehe:
http://git.quitesimple.org/encryptedubuntutouchhome/
Da könnte man ja vielleicht noch etwas Doku draus machen. Damit sich gerade auch bei dem Thema Sicherheit und Verschlüsselung die Angsthasen wie ich rantrauen. 🦆
Grüße, Benno
Edit: Ich hab indes mal paar Ansätze wegen ecryptfs wieder rausgefischt:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/455709
...muss mir keyctl (noch-?)mal näher ansehen. Und weitere zwei Bugs könnten eine Rolle spielen, warum ich in Post 7339808 scheiterte:
Ich hab es auch noch nicht mit einer normalen PC-VM versucht, oder es ging da gleich - weiß nicht mehr auf Anhieb. Hab es auch immer nur mit einem zweiten Nutzer als Testnutzer versucht. Und letztens gingen meine Touch Emulator-VMs nicht mehr, auch keine neuen. Alles irgendwie kaputt. Da hat man irgendwann keine Zeit und Lust mehr, ewig Gespenster zu jagen. 😉 Drum das auch nur am Rande als Plauderei.
Vielleicht mag da jemand noch was testen. Ich weiß nicht, ob und wann ich damit weitermache. In andren Bugberichten stand auch systemd in Verdacht. Das sind alles ziemlich große Baustellen bzw. noch Doku-arme Großprojekte, die schon für sich allein genug Zeit fressen. 😉 Selbst Baustelle/systemd (Abschnitt „etc-rc-local“) ist noch nicht fertig - und dort der Abschnitt zur Aktivierung einer rc.local noch unbrauchbar. Wäre neben Workarounds für manches auch gut zum besseren Verständnis.
Edit 2: Vielleicht reicht hier auch ein - aus anderen Gründen - lightdm restart oder so, wie irgendwo bei den Bugs stand (aber manches dann auch wieder verworfen wurde).
Edit 3: Also im Großen und Ganzen ist deine Variante schon verständlich. Aber ein bisschen in Watte gepackte Doku wie in unsrem Wiki wäre halt nicht übel. 😉 Laut Mailingliste heute wurde ja nun doch richtig was entschieden, und zwar, dass die vivid gegen Ende des Monats vielleicht schon stable wird und die neue Entwicklerversion doch wily mit systemd wird. Vorher gab es wohl kein richtiges Feedback von der Leitung und war daher nur eine Annahme, dass wily derzeit ausfallen würde.
Dann wird das mit Upstart aus deiner Variante wohl so nicht mehr funktionieren bzw. müsste portiert werden. Die stable betrifft das dann spätestens in etwa 6 Monaten, wenn wily stable werden wird. ecryptfs wäre mir als zusätzliche Alternative sehr sympathisch (zumal ich weder einen Container noch die SD opfern und mein Home ausbremsen lassen will), kommende ext4-Verschlüsselung auch, wenn man den Kernel gebacken bekommt.
Vielleicht bekommen sie das ja dann auch eingebaut, wenn sie es mit systemd besser bzw. langfristiger einbauen können. Wieso ist eigentlich dbus nötig?
start on started dbus
Wird das zur Interprozesskommunikation für LUKS bzw. das System bereits frühzeitiger benötigt? Warum wird zeitgeist angepasst?
