Syncthing | offizielles Beta-SPK von Syncthing

[Andy+]

Die interessierten von uns kennen das Syncthing-SPK von SynoCommunity, welches über die entsprechende Paketquellenangabe in das Paketzentrum eingebunden und darüber installiert werden kann. Zu finden

https://synocommunity.com/package/syncthing

Nun gibt es von Syncthing ein eigenes SPK, welches diverse Unterschiede aufweist, jedoch in gleicher Weise eingebunden wird. Syncthing gehört Kastelo, daher die entsprechende Erscheinung:

https://docs.kastelo.net/synology/installing/

Inwieweit diese Version besser funktioniert, muss abgewartet werden.

Ein wesentlicher Unterschied besteht beim User. Kastelo verwendet den "Interner Systembenutzer" mit dem Namen "syncthing.net", während SynoComm. den Gruppenuser "sc-syncthing" verwendet. Welcher Vorteil der "Interner Systembenutzer" hat, weiss ich nicht, erste Tests verlaufen bislang besser.

Ein weiterer Unterschied besteht darin, dass keine Releaseupdates mehr über die GUI möglich sind, sondern zeitgleich mit den neuen Releases entsprechend neue SPKs erscheinen und im Paketzentrum als Update auftauchen. Das ist besser gegenüber der Version von SynoComm., weil hier bei strukturellen oder tiefgreifenderen Änderungen seitens dem Release keine Änderungen am SPK erfolgen. Dadurch könnte das ganze Paket korrupt werden.

Im weiteren gibt es ein "syncthing-data" Verzeichnis, in welchem alle Basisdaten enthalten sind. Bei einer notwendigen Neuinstallation des SPKs bleiben damit alle Perrdaten erhalten. Bislang musste immer neu eingerichtet werden.

Kann noch jemand sagen, was der Vorteil eines "Interner Systembenutzer" ist?

 

[bfpears]

Hi Andy,
danke für die Infos.
Jetzt habe ich wohl keine Ausreden mehr mich doch mal mit Syncthing zu beschäftigen
BF

 

[Andy+]

Es gibt im Grunde bereits ein gleichwertiges SPK von SynoCommunity. Kastelo, als Inhaber von Syncthing, möchte eine offizielles Package bei Synology platzieren, so wie Resilio eigentlich auch, und daher gibt es nun dieses. Meine Tests haben ergeben, dass rein funktional beide gleich gut sind. Ich finde jedoch das konsequente Packagekonzept mit Updates von Kastelo jedoch besser und sicherer. Einen Nachteil im Handling sehe ich die Nutzung eines internen Systemusers, was bei der Vergabe der rechte bei vielen Hauptverzeichnissen in Arbeit ausarten kann. SynoComm. verwendet dazu einen Gruppenuser, den man mit wenigen Klicks zuordnen kann.

Ansonsten halte ich Syncthing für eine echte Alternative zu Resilio, zudem beide die Peer-to-Peer-Technologie verwenden, das ist im täglichen Umgang mit vielen Clients ein echter Vorteil. Syncthing ist in der Handhabung uU. etwas umständlicher, aber auch flexibler.

Nun denn, testen hilft. Ich habe beides im Einsatz, teilweise überschneiden sich sogar Verzeichnisse. Mit den richtigen Ignore-Patterns lässt sich das machen:

// Resilio files
.sync
.syncID
.syncIgnore
.syncArchive
*.bts
!sync
*.syncPart
*.syncTemp
*.syncOld

// syncthing files
.stfolder
.stignore
.stversion
.syncthing*
.syncthing.*
.syncthing.*.*
~syncthing~*.*.tmp
*.Identifier

 

[4bob]

Hallo Andy,

Syncthing gehört Kastelo

Wie kommst du auf das schmale Brett? Nein, Syncthing gehört der Syncthing- Community!
Kastelo ist eine Dienstleister für Enterprice Kunden hier kannst du Support oder einen SLA einkaufen. Sie haben sich spezialisiert auf Syncthing und vermarkten Ihr eigenes Produkt für große Umgebungen (Arigi)! Nebenbei treten Sie noch als Sponsor auf, bedeutet nicht das Sie dadurch zum Eigner werden!

Ein wesentlicher Unterschied besteht beim User. Kastelo verwendet den "Interner Systembenutzer" mit dem Namen "syncthing.net", während SynoComm. den Gruppenuser "sc-syncthing" verwendet.

Beide nutzen das selbe Schema um die Anwendung auszuführen; Kastelo:
syncthing = lautet die Gruppe und über diese werden Verzeichnisberechtigungen zugewiesen
syncthing.net = Service Account, also ein technischer User der den Dienst ausführt sonst nix!

Und bei der Synocommunity lauten beide (Gruppe und Service Account) sc-syncthing !

Kann noch jemand sagen, was der Vorteil eines "Interner Systembenutzer" ist?

Wie gesagt, da gibt’s keine

Einen Nachteil im Handling sehe ich die Nutzung eines internen Systemusers, was bei der Vergabe der rechte bei vielen Hauptverzeichnissen in Arbeit ausarten kann. SynoComm. verwendet dazu einen Gruppenuser, den man mit wenigen Klicks zuordnen kann.

Das ist nicht der Fall; Das SPK von Kastelo legt eine Gruppe (syncthing) an.
An der Berechtigung ändert sich nichts.

Bob

 

[Andy+]

Du weisst das offenbar besser.

Bezüglich des Users, der Gruppen und Internem Systemuser bist Du nicht auf dem neusten Stand. Da gab es wegen dem Paket bei SynoComm. Konflikte, daher wurde geändert:

Kastelo verwendet den "Interner Systembenutzer" "syncthing.net"
SynoComm. verwendet den Gruppenuser "sc-syncthing", dass es da noch einen internen Systemuser gibt, habe ich gesehen, die Frage ist, für was dieser gut sein soll.

Um das nachzuvollziehen hilft jeweils eine Installation, läuft sogar parallel auf einer DS. Ich habe noch gelesen, dass es bez. der SynoComm. Usergruppe noch einen User "syncthing" geben soll, den habe ich auf meinen Installation bislang in keinem DSM gesehen.

 

[4bob]

Dir ist schon klar das ich die erste Ausführung deiner Antwort per Mail bekommen habe
Und ja ich habe Recht; Dir fehlt hier leider ganz klar der Durchblick.

Kastelo verwendet den "Interner Systembenutzer" "syncthing.net"
SynoComm. verwendet den Gruppenuser "sc-syncthing", dass es da noch einen internen Systemuser gibt, habe ich gesehen, die Frage ist, für was dieser gut sein soll.

Lies dir Post #4 durch. Beide Pakete arbeiten nach dem selben Prinzip, ein Service Account und eine Gruppe!

Da gab es wegen dem Paket bei SynoComm. Konflikte, daher wurde geändert

Stimmt. Die Anlage des Service Accounts war mit dem Einzug von DSM6 ein Problem, da alle postinst mit adduser gearbeitet haben; Heute wird das über synogroup gemacht.
Du kannst das auch auch auf der Konsole prüfen:

Der Service Account nach der Installation; (den siehst du nicht im DSM)

root@DiskStation:~# cat /etc/shadow | grep sc-syncthing
sc-syncthing:*:18297:0:99999:7:::

startet den Dienst:

root@DiskStation:~# ps -ef |grep sync
sc-sync+ 9377 1 0 20:28 ? 00:00:00 /volume1/@appstore/syncthing/bin/syncthing -home=/volume1/@appstore/syncthing/var
sc-sync+ 15742 9377 14 20:29 ? 00:00:05 /volume1/@appstore/syncthing/bin/syncthing -home=/volume1/@appstore/syncthing/var

Und die gleichnamige Gruppe zur Berechtigung an Verzeichnissen:

root@DiskStation:~# synogroup --get sc-syncthing
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID: [65539]
Group Members: xxxxx

Bob

 

[Andy+]

Klar ist das klar, ich fand das erste Posting nicht ganz passend.

Mit Syncthing gibt es ein Problem, bei dem Du vlt. helfen kannst. Mit 2 von fast 50 Verzeichnissen habe ich folgendes Problem:

Error while trying to start filesystem watcher for folder “xxx” (yyy), trying again in 1min: error while traversing zzz: permission denied

Im Internet gibt es einige Beiträge darüber, jedoch scheint es keine schlüssige Lösung zu geben. Eine der naheliegenden Lösungen mit den Synology-ACLs funktionierte ebenfalls nicht. Es spielt keine Rolle, ob mit oder ohne "+" am Ende der Berechtigungen, d.h. mit oder ohne Synology-ACLs. Die erwähnte Meldung erscheint trotzdem. Aber was mich wundert, es gibt kein Schema dazu, indem es nur die beiden Hauptverzeichnisse, z.B. /volume1/subdirectory_1 betrifft, obwohl sie alle ähnliche Rechte haben. Die betroffenen Hauptverzeichnisse werden trotzdem als „aktuell“ angezeigt. Alles scheint synchron zu sein.

Es scheint, als ob es keine Rechte zur Überwachung des Dateisystems gibt. Die Frage wäre nach dem Grund. Ich habe verschiedene Tests gestartet. Grundsätzlich ist die Benutzergruppe "sc-syncthing" in den betreffenden Hauptverzeichnissen hinterlegt, welche in die Unterverzeichnisse vererbt werden, parallel zu weiteren Benutzergruppen, Benutzern und Systembenutzern.

Im ersten Test entfernte ich die ACLs im Unterordner, indem ich die Gruppe und den Besitzer auf "root" stellte und zusammen mit den Rechten oktal auf "0777" setzte zu "drwxrwxrwx". Dann habe ich die Synology ACL im Hauptordner von Synology DSM wieder in alle Unterordner vererbt. In der Vergangenheit hat diese Methode of geholfen, hier jedoch nicht. Schlussendlich hatten die Unterordner wieder die Rechte d---------+ mit dem "+" am Ende.

Im weiteren test wiederholte ich das und stellte die Gruppe und den Besitzer auf "sc-syncthing". Die Unterordner hatten wieder d---------+ mit dem "+", jedoch mit demselben Ergebnis.

Dann habe ich die ACLs im Unterordner wieder entfernt und nur die Synology-ACLs für den Hauptordner (d --------- +) belassen, da der Zugriff auf die Synology spezifisch ist. Alle Unterordner hatten jedoch oktal 0777, also drwxrwxrwx, also ohne ein „+“, jedoch wieder mit dem gleichen Ergebnis.

Daher sind für mich die Synology ACLs für diese Fehlermeldung irrelevant, obwohl dies oft vermutet wurde.

 

[4bob]

Jetzt vom hölzchen aufs stöckchen …

Mit Syncthing gibt es ein Problem, bei dem Du vlt. helfen kannst.

Ohne Garantie und die Informationsqualität von dir muss sich definitiv bessern
Deiner Ausführung nach liegt das Problem eher am Verständnis für Linux Dateiberechtigungen.
Wenn du Ordner über das DSM erstellst (Systemsteuerung Gemeinsame Ordner) und dort Syno-ACL vergibst gehören diese root (d --------- +); Ich hab seit Jahren das DSM mit Syncthing in Verwendung und noch nie einen Grund gehabt diese Berechtigung anzupassen! Ich halte das für keine gute Idee und dein Test untermauert das ja; Es ist also durch eine hausgemachte DSM Eigenschaft hinfällig.

Da so ziemlich alle Wichtigen Infos fehlt wie Ordnertyp; Anzahl der Knoten; Berechtigungen (Erweiterte Einstellungen) … kann ich dir einen allgemeinen Tipp geben. Erstelle einen neuen Ordner nur für diesen Test; Setze die Syno-ACLs und dokumentieren das; Ebenfalls die Berechtigungen auf der Konsole das ist sehr wichtig. Das machst du von allen Knoten die sich diesen Ordner teilen. Im Fehlerfall überprüfst du erst mal an welchen Punkten sich die Ordner oder Datei Rechte verändert haben. Stimmen die Ordner Acls noch oder sind es nur Dateien die sich geändert haben?

Bob

 

[Andy+]

Meine Informationsqualität ist nur so gut, wie mein Know-How und wie gut zB. Du nun Details wissen möchtest. Ich bin nicht der Linuxexperte oder Programmierer, eher ambitionierter Anwender. Du kennst sicherlich aus dem Syncthing-Forum @calmh (Jakob Borg, Syncthing Maintainer), von ihm stammt der Tip bezüglich der ACLs, weil sich bis heute dort niemand richtig erklären kann, mit was wir es zu tun haben. Ich habe dann auch rasch bemerkt, dass es eine Sackgasse ist.

Unabhängig von dem Test, vielleicht auch mal ein paar Antworten zu den Details:

Ordnertyp: Nur Senden, Senden und Empfangen, im DSM unverschlüsselt
Anzahl der Knoten: In beiden Fällen nur ein Knoten zu einem anderen Server
Berechtigungen (Erweiterte Einstellungen): Berechtigungen sind ignoriert, im DSM sind jeweils vollständige Lese- und Schreibrechte hinterlegt. Im Ergebnis macht es keinen Unterschied, ob zudem Rechte zur Administration hinterlegt werden oder nicht.

Für das bestehende Dateisystem kann ich nur soviel sagen, die vorhandenen Rechte sowie Eigentümer und Gruppe bleiben in der Regel unverändert. Werden jedoch neue Dateien angelegt oder Updates gespeichert, kann es zu Änderungen bei den Rechten, Gruppen, Eigentümer kommen. Zu Syncproblemen kommt es aber deshalb nicht.

 

[4bob]

Ich hab das auf die Informationen bezogen die du zu Syncthing selbst hattest, aber auch der Zugriffsfehler aus Post #7.
Damit möchte ich dir nur einen Tipp geben, die eingestellte Konfiguration zu egal welchen Produkt ,was einen Fehler ausgibt, ist immer notwendig und unterstützen zu können.

Die Details zur Konfiguration finde ich interessant. Wie hast du die Ordner erstellt an denen du die Berechtigungen in Post #7 angepasst hast und wie wurden die Berechtigungen geändert.
Wenn du das im Detail noch erklärst ist ggf. der Test zu den Syno ACL noch nicht abgeschlossen.

Bob

 

[Andy+]

..........entfernte ich die ACLs im Unterordner, indem ich die Gruppe und den Besitzer auf "root" stellte und zusammen mit den Rechten oktal auf "0777" setzte zu "drwxrwxrwx".........

Das erledigte ich über WinSCP, markieren aller Unterordner des betroffenen Hauptverzeichnisses, Eigenschaften, setzen von "root" für Gruppe und Eigentümer der Rechte oktal auf "0777" (zu "drwxrwxrwx") und dann rekursiver Übernahme und damit in alle weiteren Unterordner.

..........Dann habe ich die Synology ACL im Hauptordner von Synology DSM wieder in alle Unterordner vererbt.........

Im DSM in der Filestation im betroffenen Hauptverzeichnis auf Eigenschaften, Genehmigung und "Auf diesen Ordner, die Unterordner und Dateien anwenden" gehen. Damit war sichergestellt, dass u.a. die Gruppe "sc-syncthing" überall hin vererbt wurde.

....Wie hast du die Ordner erstellt an denen du die Berechtigungen in Post #7 angepasst hast.....

Ganz ursprünglich zwar im DSM, später bei jeder neuen DS dann durch Übertragung durch "Synchronistion von gemeinsamen Ordnern" und nach dessen Abschluss von einer Vor-DS durch Anpassung der Rechte über das Einlesen einer passenden Systemkonfiguration.