Unison: Konzept

Aus Ethersex_Wiki
Wechseln zu: Navigation, Suche

Konzept

Um das Ganze zu veranschaulichen habe ich es gezeichnet: ::

TikiImage182.jpg

(nicht lachen, ich musste mir das erstmal notieren, um nicht den Überblick zu verlieren)

Übergeordnet wird ein sshfs (grauer Hintergrund) gefahren, dass unser home-Verzeichnis auf dem Server als Mountpoint auf dem Client zur Verfügung stellt.

Die versteckten Verzeichnisse .domina_crypt und .home_crypt enthalten die eigentlichen Daten in verschlüsselter Form- das sieht dann ungefähr so aus:

user@ssh-Client:~/.home_crypt$ ls
05axqSYsgEzw25XI5AZqaweO
09iZ8ErGcml0GqGjQbWu6CQ3
0E8yxwxCx8pvUL5o9c2dINo,
1voIYDvpHUEjXfUEIFYVj6UX
3FLqheIiwI4A9gdfYnwp5ll9
8FbOBeRjcA7XVh5UL1NpzCd7
8himxOky8UeUBBIN3jWDhmVo
8rZwyBtwVm5PhRyyL4pVqdiS7dtxpeucwhu52XocXMD0N0

Es sind also nicht nur der Inhalt, sondern auch der Name der Dateien verschlüsselt. Jetzt wird klar, warum wir das obere encfs zwischen .domina_crypt auf dem ssh-Server und domina_klar auf dem ssh_Client brauchen: ohne könnten wir die Daten auf dem Server niemals im Klartext anschauen.

Das untere encfs zwischen .home_crypt und home_klar befindet sich nur auf dem ssh-Client. Das verschlüsselte .home_crypt wird in mit unison regelmässig mit dem verschlüsselten .domina_crypt auf dem ssh-Server abgeglichen.

Kurz nach dem Abgleich sollte der Inhalt von domina_klar und home_klar identisch sein. Noch ein Hinweis: deswegen wird natürlich nicht der doppelte Speicherplatz benötigt, das entschlüsselte Verzeichnis zeigt lediglich die Dateinamen an ;)

Jetzt fragt sich jeder vernünftige Mensch: warum der Aufwand mit zwei encfs? Man könnte unison doch einfach die beiden Klartextverzeichnisse synchronisieren lassen? Antwort: das geht prinzipiell schon, aber dann funktionieren die inkrementellen Updates nicht mehr, und das ist ja gerade das Sahnestück an dem Verfahren, dass den enormen Geschwindigkeitsvorteil bringt!

Aber dazu später mehr! Weiter geht´s mit Unison: Benötigte Pakete