Sync-Lösung, verwaltet von Clients

[Kagee]

Ich suche derzeit nach einer Synchronisationslösung für mein Heimnetz. In diesem Thread wurde eine schöne Liste mit Tools gepostet, aber so richtig passt keine davon. Ich bin aber auch offen für Vorschläge eventuell eine Dinge am Ist-Zustand zu ändern. "Hauptproblem" ist die Verschlüsselung die ich einsetze. Aber der Reihe nach. Folgendes ist die Situation:

Ich habe einen Server, der Kubuntu ausführt und in dem die Massenspeicher verbaut sind. Daneben gibt es zwei Notebooks im Netzwerk, auf denen auch ein Debian-Linux läuft. Der Server gibt ein Benutzerlaufwerk per NFSv4 frei, auf das beide Notebooks zugreifen. Dieses share beinhaltet aber ein GoCryptFs-System, welches nur auf den (verschlüsselten) Notebooks entschlüsselt wird. Daher kennt der Server keinerlei Inhalte, sonder kann maximal die Timestamps der einzelnen verschlüsselten Dateien sehen. Der Server Backupt dieses Dateisystem auf andere Laufwerke.

Nun zu meinem Problem: Wenn zwei Notebooks auf dieselben Dateien zugreifen, kann es ja passieren, dass zwischen zwei Server-Syncs beide Notebooks dieselbe Datei bearbeiten und somit zwei neue Stände erzeugen, die einen Konflikt verursachen. Prinzipiell benutzt man ja für sowas SVN o.ä. In meinem Szenario wären die ganzen Datei-Vergleichs-Features ja aber hinfällig, weil der Server die Daten ja gar nicht einsehen kann. Jeglicher Vergleich von Inhalten kann also nur auf den Notebooks stattfinden.

Gibt es eine Software, die ich auf den Notebooks ausführen kann, die das managen kann? In meiner Vorstellung müsste auf den Notebooks irgendwo (interne Datenbank oder in den Verzeichnissen selbst) hinterlegt werden mit welchem Timestamp die Datei vom Server geholt wurde. Wenn zum Zeitpunkt des Rückspielens dieser nicht mehr übereinstimmt, müsste die ältere der beiden "neuen" Versionen irgendwo hin kopiert werden.

Edit: Eine Übersicht über die Topologie:

 

[mensch183]

In meiner Vorstellung müsste auf den Notebooks irgendwo (interne Datenbank oder in den Verzeichnissen selbst) hinterlegt werden mit welchem Timestamp die Datei vom Server geholt wurde. Wenn zum Zeitpunkt des Rückspielens dieser nicht mehr übereinstimmt, müsste die ältere der beiden "neuen" Versionen irgendwo hin kopiert werden.

Wenn von dem File dann mehrere Versionen rumliegen, hättest du aber kein normales, transparent zu verwendendes Filesystem mehr auf den Clients . Kein übliches Programm würde die "automatisch irgendwohin kopierte alte Version" verwenden können, oder gezielt die neue - es weiß ja gar nicht, welches die richtige sein soll.

Programme müssen explizit dafür programmiert sein, um mit konkurrierenden Schreibzugriffen sinnvoll umgehen zu können. Anderenfalls gewinnt oft der letzte Schreiber oder es entsteht verwurschtelter Datenmüll. Übliches Mittel, mögliche konkurrierende Zugriffe zu organisieren, sind File Locks (via lockf(3) o.ä.). Das geht auch via NFS. Da dieses gocryptfs jedes vom Client zu sehenden File auch intern als einzelnes, verschlüsseltes File speichert, könnte es File Locks verarbeiten und nach unten weiterreichen, womit sie auch über NFS funktionieren würden. Ob es das wirklich tut, kann ich dir nicht sagen.

Ich habe bischen den Eindruck, dein Ziel sind konkurrierende Schreibzugriffe "dummer" Programme, die also nicht dafür programmiert sind, und jedes Programm soll seine eigenen Daten behalten können. Beispiel:
client A# echo AAA >datei
client B# echo BBB >datei
Und du willst nun, dass ein 10 Minuten später abgesetztes "cat datei" auf dem einen Rechner wieder AAA und auf dem anderen Rechner BBB ausspuckt. Richtig? Das ist mit EINEM GEMEINSAMEN Filesystem nicht drin.

Du würdest vermutlich bessere Hinweise bekommen, wenn du verrätst, um welche ganz konkreten Programme mit konkurrierender Schreiberei es dir eigentlich geht.

 

[Kagee]

Achso, nein. Sorry für das Missverständnis. Die Notebooks enthalten eine Kopie der Dateien. Jeder Notebook operiert ausschließlich auf lokalen Daten. Die Programme, die auf den entschlüsselten Daten operieren müssen daher kein Multi-User-Zugriff unterstützen. Der Konflikt entsteht erst, wenn die Notebooks alle gemachten Änderungen mit der hier gesuchten Software auf den Server "hochladen", wie bei einem SVN-Commit.
Gleichzeitiges Rückspielen wiederum soll nicht betrachtet werden.

 

[Stype]

Guck dir mal git LFS an:
https://svij.org/blog/2017/04/17/binardateien-effizienter-in-git-repositorys-nutzen-mit-git-lfs/

 

[mensch183]

Achso, nein. Sorry für das Missverständnis. Die Notebooks enthalten eine Kopie der Dateien. Jeder Notebook operiert ausschließlich auf lokalen Daten.

Du schriebst von via NFS zugreifenden Clients. Wie passt das zusammen? Bei NFS gibts keine lokalen Kopien auf den Clients.

Der Konflikt entsteht erst, wenn die Notebooks alle gemachten Änderungen mit der hier gesuchten Software auf den Server "hochladen", wie bei einem SVN-Commit.

OK, und was soll dann als "richtiges Ergebnis" auf dem Server landen, wenn auf 2 Notebooks das gleiche File geändert wurde? Man brauch ja eine Strategie, was am Ende rauskommen soll. Erst wenn man das weiß, kann man ein passendes Werkzeug finden, was diese Strategie praktisch umsetzt. Zwischen einem "Sync" (=zwei Seiten abgleichen) und einer Versionverwaltung ala svn/git bestehen himmelweite Unterschiede. Was genau willst du?

Ich verweise nochmal auf den letzten Absatz meiner ersten Antwort. Werde konkret, worum es geht! Du bist wahrscheinlich nicht der erste mit deinem Anliegen/Problem. Was ist dein gewünschter Arbeitsablauf? Vielleicht skizzierst du den gewünschten Ablauf erstmal ohne das gocryptfs und erzählst zusätzlich, welche Art Angriff dann möglich ist, gegen die du dich mit dem gocryptfs schützen willst. Vielleicht ist das CryptFS an der Stelle gar keine tolle Idee und schafft überhaupt erst die "Sync"-Probleme, die es mit einer anderen Lösung gar nicht gäbe.

 

[Kagee]

OK, und was soll dann als "richtiges Ergebnis" auf dem Server landen, wenn auf 2 Notebooks das gleiche File geändert wurde?

Die jüngste Datei soll als neue Version übernommen werden, jedoch soll die andere Version nicht verworfen werden sondern erhalten bleiben. Wie, dazu habe ich erstmal keine Vorschrift gemacht. Üblicherweise wird ja der Dateiname mit einem Suffix modifiziert.

Ich habe mal versucht das ganze grafisch aufzuzeichnen. Die SSDs der Notebooks sind insgesamt verschlüsselt. In Benutzung sind diese natürlich entschlüsselt. Jegliche Software auf den Notebooks operiert auf "Lokale Kopie (plain)". Sobald im das Verzeichnis "mounted goCryptFs (plain)" operiert wird, wird wie du richtig sagst direkt übers Netzwerk gearbeitet. Die Schnittstelle, um die es hier geht habe ich mit "Synchronisation" gekennzeichnet. Dies soll durch eine Software auf dem Notebook bewerkstelligt werden. Diese Software "sieht" ja nur zwei entschlüsselte Verzeichnisse oder? Vielleicht habe ich ja auch ein grundlegendes Verständnisproblem und habe etwas vergessen.

Das Ganze ohne Verschlüsselung sähe wie folgt aus. In diesem Szenario könnte ich gut auf dem Server etwas wie nextCloud, SVN oder Git einsetzen (also hier die Schnittstelle "NFS" ersetzen), um ein Versionsmanagement zu haben und somit konfliktbehaftete Dateien in mehreren Versionen vorhalten zu können.

 

[lokked]

Ja ich glaube schon...ich seh das Problem nicht, so wie git arbeitet brauchst du eigtl. keine Extras mehr im Grunde.
Lies dich mal da ein: https://de.atlassian.com/git/tutorials/comparing-workflows
Das Hauptrepository wäre also im transparent verschlüsselten Filesystemordner auf dem Server. Dort fummelt niemand direkt herum, und das wird dann agnostisch vom Serverbackup halt periodisch gesichert und gut.

Die User arbeiten also nicht direkt an der NFS Share, sondern klonen von dort nur ihr lokales Arbeitsrepo.
Editiert wird somit nur lokal und Konflikte bzw Änderungsvorschläge (merge request etc) der Notebookuser in das Hauptrepository zu übernehmen ist dann klassiche Versionswaltungsarbeit -> Aufgabe des Repoverwalters.

Weder gehen die Änderungsvorschläge der User verloren, wenn sie noch nicht abgesegnet waren als das Backup gemacht wurde (sie sind ja in deren Schattenrepo noch vorhanden) noch ergibt sich ein Dateisystemkonflikt auf dem Hauptrepo.

Arbeitest du mit Binärdateien, wird es komplizierter, da bist du mit Perforce besser beraten. Aber prinzipiell kann man sagen das die Versionswaltungsgeschichte getrennt von der reinen Serverlogistik zu sehen ist.
Mit Git wäre es halt lächerlich einfach, sofern es auf die Art der Dateien anwendbar ist.

 

[mensch183]

ich seh das Problem nicht, so wie git arbeitet brauchst du eigtl. keine Extras mehr

Das ist auch mein Gedanke.

Möglicherweise reden wir an @Kegee vorbei, weil wir dir Begründung für das gocryptfs falsch verstanden haben? Meine Interpretation: Der Server soll "dummer, nicht vertrauenswürdiger File- und Backupserver sein" der die Daten nie unverschlüsselt zu greifen bekommt. Es reicht, ggf. durch den Server gemachte Manipulationen zu erkennen. Die Client-Notebooks(und deren Nutzer) gelten alle als vertrauenswürdig. Habe ich was vergessen?

 

[Kagee]

Meine Interpretation: Der Server soll "dummer, nicht vertrauenswürdiger File- und Backupserver sein" der die Daten nie unverschlüsselt zu greifen bekommt. Es reicht, ggf. durch den Server gemachte Manipulationen zu erkennen. Die Client-Notebooks(und deren Nutzer) gelten alle als vertrauenswürdig. Habe ich was vergessen?

Alles korrekt. Ich vermute stark, dass Ihr recht habt. Ich habe mich mit git nur als Konsument beschäftigt, nicht als Betreiber eines Repos. Die Daten, die ich verwalten will sind sehr gemischt. Es sind viele binäre Daten Dabei (JPG, Raw, Office dokumente, Creative Suite Dokumente) und nur einige Textdaten (primär Quellcode). Als verschlüsselte Dateien erscheinen sie jedoch immer als Binärdaten, wenn der Server nicht entschlüsseln kann. Ich benötige die Versionierung eigentlich nur für die Konfliktauflösung. Ich habe für SVN auch gelesen, dass Binärdaten eher ineffizient verwaltet werden (müssen). Von daher war der Hinweis von @Stype auch sehr interessant.

Lies dich mal da ein: https://de.atlassian.com/git/tutorials/comparing-workflows

Super, das werde ich mal machen, vielen Dank.

 

[lokked]

Eine Best-Practice-Liste für das Absichern von Git repos:
https://resources.infosecinstitute.com/security-best-practices-for-git-users/

Ich finde deinen Ansatz gar nicht so schlecht, weil er ein einfaches Handling mit Git ohne PGP ermöglicht.
Das ganze is natürlich für die Katz, wenn jemand deinen Netzwerkverkehr lesen kann.

Von sich aus unterstützt Git nicht direkt Verschüsselung, es kann aber recht einfach in die einzelnen Vorgänge eingebaut werden. Gängig ist, entweder einzelne Dateien im Repo zu transparent zu verschlüsseln (git-crypt) oder
so etwas: https://caolan.org/posts/encrypted_git_repositories.html (git-remote-gcrypt).
Also andersrum, dafür internettauglich.
Bist du in einem sicheren LAN oder kannst du dein NFS verschlüsseln ist dein Ansatz bequemer.

 

[Kagee]

Ich finde deinen Ansatz gar nicht so schlecht, weil er ein einfaches Handling mit Git ohne PGP ermöglicht.
Das ganze is natürlich für die Katz, wenn jemand deinen Netzwerkverkehr lesen kann.

Also ich befinde mich in einem sicheren LAN, aber das interessiert mich dennoch: Wie kann man im verschlüsselten Ansatz oben durch mitlesen des LAN-Traffics die Verschlüsselung aushebeln? Mein NFS verwenden tatsächlich kein Kerberos zur Zeit.

 

[lokked]

Bin jetzt mal vom einfachen Ansatz ausgegangen, wo der gemountete Ordner per NFS geteilt wird.
Ich denke mal, das der Ansatz, den verschlüsselten Ordner zu teilen und auf dem Client dann mit Passwort zu öffnen und dort Synchronisation zu betreiben zu kompliziert und fehleranfällig ist. Das Verschlüsselte Ordner-Prinzip auf so einen komplexen Use case zurechtzubiegen ist wohl etwas zu viel des Guten.

Ein einfacherer und an Git angepasster Ansatz wäre, SSH auf dem Server einzurichten und mittels git-crypt (https://www.agwa.name/projects/git-crypt/) das Repo zu verschlüsseln. Also gar keine Shares.

Die Notebook User kommunizieren dann direkt per ssh mit dem repo (das ist eingebaut). Somit wären sowohl die Verbindung verschlüsselt als auch die Daten auf dem Server.
Nachteil hierbei: Schulungsaufwand
Vorteil: Sicher und bewährt, verhältnismässig einfach zu handhaben (Integritätschecks in Git etc)

 

[chithanh]

Es gibt Software die das kann was du planst, Resilio Sync. Dabei kann der Server als Untrusted Encrypted Node eingerichtet sein und sieht niemals den Klartext. Leider ist das kein Open Source.

 

[mensch183]

Der Rat in #12 passt nicht zu unserem Szenario, wo der Server komplett als nicht vertrauenswürdig behandelt werden soll. Man lese den Limitations-Absatz auf der von @lokked verlinkten Seite. "git-crypt does not encrypt file names, commit messages" ist beispielsweise ein NoGo.

Außerdem müssen sich bei git-crypt die git-Nutzer explizit manuell um die Verschlüsselung kümmern, statt git ganz normal verwenden zu können, während die Verschlüsselung transparent im Hintergrund erfolgt. Nie und nimmer, wenn komplette Verschlüsselung das Ziel ist.

Meine Alternativlösung, um das gocryptfs+NFS zu vermeiden, wäre folgender:
Setze einen vertrauenswürdigen Git-Server auf. Verwende den o.g. Server nur als Lager für ein verschlüsseltes Backup dieses vertrauenswürdigen Servers.