expertenaustausch > linux.debian.user.german

Manfred Rebentisch (18.04.2020, 23:50)
Hallo,

wir nutzen in unserer Gemeinschaft NextCloud für die Synchronisation
gemeinsamer Daten.
Ich suche nun ein Tool, das genauso arbeitet, aber keine PHP-Umgebung
braucht. Ich brauche auch kein grafisches Tool.
Die Daten liegen auf einem Server im Rechenzentrum und einige
Verzeichnisse sollen automatisch auf drei verschiedenen Desktop-Rechnern
gespiegelt werden.

Manuell funzt das ja prima mit rsync, aber rsync ist nicht die
ultimative Lösung.

Ich könnte mir vorstellen, auf dem Desktop die NextCloud-App zu
benutzen, wenn auf dem Server ein passendes PHP-freies Tool mitarbeitet.

Natürlich habe ich recherchiert - finde aber nur Tools, die für andere
Szenarien gedacht sind.

Hat da jemand einen Tipp für mich?

Herzlichen Dank
Manfred
Norbert Preining (19.04.2020, 03:30)
On Sat, 18 Apr 2020, Manfred Rebentisch wrote:
> Die Daten liegen auf einem Server im Rechenzentrum und einige
> Verzeichnisse sollen automatisch auf drei verschiedenen Desktop-Rechnern
> gespiegelt werden.




Liebe Grüße

Norbert
Manfred Rebentisch (19.04.2020, 07:30)
Hallo Norbert,

Am 19.04.20 um 03:17 schrieb Norbert Preining:
>
> Liebe Grüße
> Norbert


Syncthing war das letzte Tool, dass ich mir angeschaut hatte, bevor ich
meine Mail an euch schrieb.
So wie ich es verstanden habe, ist Syncthing für das synchronisieren von
Geräten gedacht wie Smartphones.

Irre ich mich? Hast Du es getestet?

Grüße
Manfred
Norbert Preining (19.04.2020, 08:10)
On Sun, 19 Apr 2020, Manfred Rebentisch wrote:
> So wie ich es verstanden habe, ist Syncthing für das synchronisieren von
> Geräten gedacht wie Smartphones.


Es funktioniert auch auf smartphones, kann aber n beliebige Devices in
sync halten. Egal of das smartphones, desktops, tablets, whatever sind.

> Irre ich mich? Hast Du es getestet?


Ich verwende unison, aber hab es (vor 2 Jahren oder so) ausprobiert und
das hat geklappt damals.

Norbert
Sebastian Suchanek (19.04.2020, 09:30)
Am 18.04.2020 um 23:40 schrieb Manfred Rebentisch:
[..]
> Manuell funzt das ja prima mit rsync, aber rsync ist nicht die
> ultimative Lösung.
> [...]


Warum nicht?
Wenn's Dir nur um die Optik geht: es gibt auch GUI-Frontends für rsync.

Tschüs,

Sebastian
Martin Klaiber (19.04.2020, 10:40)
Norbert Preining <preining> wrote:

>


Aus: <https://docs.syncthing.net/users/faq.html>

The following are not synchronized;

* File or Directory Owners and Groups (not preserved)
* Directory Modification Times (not preserved)
* Hard Links (followed, not preserved)
* Extended Attributes, Resource Forks (not preserved)
* Windows, POSIX or NFS ACLs (not preserved)
* Devices, FIFOs, and Other Specials (ignored)
* Sparse file sparseness (will become sparse, when supported by the OS & filesystem)

Einiges davon wäre für mich ein No-Go.

Ich benutze für den Zweck auch unison und bin zufrieden damit.

Grüße
Martin
Norbert Preining (19.04.2020, 10:50)
On Sun, 19 Apr 2020, Martin Klaiber wrote:
> The following are not synchronized;
> * File or Directory Owners and Groups (not preserved)


Aber wenn man nur seine eigenen Files synced, ist das kein Problem.

> * Directory Modification Times (not preserved)


Ehere ein Problem.

> * Hard Links (followed, not preserved)


Irgendwie klar.

> Ich benutze für den Zweck auch unison und bin zufrieden damit.


Ich auch, bis auf die Tatsache dass wenn man Debian/unstable verwendet,
sofort eine Version kommt die mit Debian/stable nicht verträglich ist.
unison schafft es einfach nicht ein standardisiertes serialization
interface hinzubekommen, drum sind kleine Versionssprünge, oder auch nur
änderung des OCaml compilers schon Grund für
nicht-mit-einander-sprechen.
Das ist der einzige Vermuthstropfen.

Norbert
Manfred Schmitt (19.04.2020, 16:00)
Norbert Preining schrieb:

> On Sun, 19 Apr 2020, Martin Klaiber wrote:
> > Ich benutze für den Zweck auch unison und bin zufrieden damit.

> Ich auch, bis auf die Tatsache dass wenn man Debian/unstable verwendet,
> sofort eine Version kommt die mit Debian/stable nicht verträglich ist.


Ist das so, in unstable ist ja aktuell die 2.48, die Version sollte
doch gegen stable und auch oldstable unison-clients, die ja ebenso bei
der 2.48 sind, laufen?

> unison schafft es einfach nicht ein standardisiertes serialization
> interface hinzubekommen, drum sind kleine Versionssprünge, oder auch nur
> änderung des OCaml compilers schon Grund für
> nicht-mit-einander-sprechen.
> Das ist der einzige Vermuthstropfen.


In der Vergangenheit gab es dann ja auch mal zwei Versionen mindestens
in stable (und bestimmt auch in testing und unstable, das nutze ich
aber nicht) -- eben dann zusaetzlich auch die Version die in oldstable
aktuell war.
Im Moment ist von oldstable bis unstable die 2.48 drin -- nur wenn man
einen oldoldstable Rechner mit einem aktuellerem synchronisieren will
hat man also ein Problem?
.... das sich aber vielleicht mittels backport loesen laesst.

Und wech,
Manne
Sven Hartge (19.04.2020, 18:00)
Manfred Schmitt <expires-200630> wrote:
> Norbert Preining schrieb:
>> On Sun, 19 Apr 2020, Martin Klaiber wrote:


>>> Ich benutze für den Zweck auch unison und bin zufrieden damit.

>> Ich auch, bis auf die Tatsache dass wenn man Debian/unstable
>> verwendet, sofort eine Version kommt die mit Debian/stable nicht
>> verträglich ist.


> Ist das so, in unstable ist ja aktuell die 2.48, die Version sollte
> doch gegen stable und auch oldstable unison-clients, die ja ebenso bei
> der 2.48 sind, laufen?


Unison scheint Daten in einem Format auszutauschen, welches direkt an
die ABI des verwendeten OCaml-Compilers geknüpft ist, für welche die
OCaml-Developer keine Stabilitätsgarantie geben und die sich häufig,
auch schon bei Minor-Versionen ändert.

Das führt dann dazu, dass unison z.B. selbst bei gleicher eigener
Version aber unterschiedlicher Compiler-Version schon nicht mehr mit
sich selbst kompatibel ist.

Was ich persönlich für extreme Idiotie seitens Unison halte. Wer denkt
sich soetwas aus? Serialisieren die direkt OCaml-Objekte für den Sync?

S!
Manfred Rebentisch (19.04.2020, 22:10)
Hi Sebastian,

Am 19.04.20 um 09:22 schrieb Sebastian Suchanek:
> Am 18.04.2020 um 23:40 schrieb Manfred Rebentisch:
>> Manuell funzt das ja prima mit rsync, aber rsync ist nicht die
>> ultimative Lösung.
>> [...]

> Warum nicht?
> Wenn's Dir nur um die Optik geht: es gibt auch GUI-Frontends für rsync.


Naja, Grafik will ich ja gerade nicht.

Probleme bei rsync:
* wenn ich eine Datei lösche, wird sie auf dem Server nicht gelöscht,
bei einem Re-Sync landet sie wieder auf meinem Rechner

* Wenn auf dem Server eine Datei neuer ist, wird meine lokale Datei
nicht synchronisiert, wenn ich zum Server syncen will, aber zu Beginn
vergessen hatte, vom Server zu holen (oder jemand anderes hat dran
gearbeitet)

Reicht vielleicht erstmal. Ich könnte um rsync herum ein Toolset bauen,
mit notify events auf die Verzeichnisse - aber gerade das versuche ich
erstmal zu vermeiden...

Grüße
Manfred
Spiro Trikaliotis (19.04.2020, 22:20)
Hallo,

* On Sun, Apr 19, 2020 at 10:02:28PM +0200 Manfred Rebentisch wrote:

> Probleme bei rsync:
> * wenn ich eine Datei lösche, wird sie auf dem Server nicht gelöscht,
> bei einem Re-Sync landet sie wieder auf meinem Rechner


Das macht doch rsync mit der Option "--delete".

> * Wenn auf dem Server eine Datei neuer ist, wird meine lokale Datei
> nicht synchronisiert, wenn ich zum Server syncen will, aber zu Beginn
> vergessen hatte, vom Server zu holen (oder jemand anderes hat dran
> gearbeitet)


Das hängt davon ab, mit welchen Parametern du rsync benutzt. Bei mir ist
es sogar eher umgekehrt, dass Änderungen "gnadenlos" auf den Server
geschrieben werden, weil ich das so will. Ich bin sogar der Meinung,
dass rsync standardmäßig so eingestellt ist.

Konflikte auflösen kann rsync natürlich nicht.

Was ich je nach Anwendung gerne mache: rsync in ein *neues* Verzeichnis
auf dem Server, mit Option --link-dest. Damit werden die schon
existierenden Dateien nicht neu angelegt, sondern nur Hardlinks darauf.

Durch Anlegen eines Soft-Links auf die jeweils letzte Instanz (bei
erfolgreich abgeschlossenem rsync) kann ich darüber hinaus immer auf
eben diese letzte Instanz zugreifen.

Nachteile:
- verschobene Dateien erkennt rsync nicht, sondern lädt sie neu
hoch/runter
- Konflikte werde nicht aufgelöst. So bin ich aber zumindest sicher,
serverseitige Änderungen nicht zu überschreiben. Im Zweifel kann ich
mittels diff erkennen, was wann geändert wurde.

Beste Grüße,
Spiro.
Norbert Preining (20.04.2020, 02:30)
Hi

On Sun, 19 Apr 2020, Manfred Schmitt wrote:
> Ist das so, in unstable ist ja aktuell die 2.48, die Version sollte
> doch gegen stable und auch oldstable unison-clients, die ja ebenso bei
> der 2.48 sind, laufen?


Leider nein ... :-( Sven hat das korrekt beantwortet.

On Sun, 19 Apr 2020, Sven Hartge wrote:
> Unison scheint Daten in einem Format auszutauschen, welches direkt an
> die ABI des verwendeten OCaml-Compilers geknüpft ist, für welche die
> OCaml-Developer keine Stabilitätsgarantie geben und die sich häufig,
> auch schon bei Minor-Versionen ändert.


Genau.

> Das führt dann dazu, dass unison z.B. selbst bei gleicher eigener
> Version aber unterschiedlicher Compiler-Version schon nicht mehr mit
> sich selbst kompatibel ist.


Genau.

> Was ich persönlich für extreme Idiotie seitens Unison halte. Wer denkt


Genau. Ganz meiner Meinung. Ich habe aber bis heute keine Ahnung warum
upstream das so macht. Das muss denen doch selber bewußt sein ...

LG

Norbert
Norbert Preining (20.04.2020, 02:30)
On Sun, 19 Apr 2020, Sebastian Suchanek wrote:
> > Manuell funzt das ja prima mit rsync, aber rsync ist nicht die

> Warum nicht?


Kein 2-way sync. rsync ist schön und gut, und ich verwende es täglich,
aber es hat eine klare Richtung. unison ist da viel besser weil es in
beide Richtungen synct.

Norbert
Sven Hartge (20.04.2020, 12:10)
Norbert Preining <norbert> wrote:
> On Sun, 19 Apr 2020, Sven Hartge wrote:


>> Was ich persönlich für extreme Idiotie seitens Unison halte. Wer denkt


> Genau. Ganz meiner Meinung. Ich habe aber bis heute keine Ahnung warum
> upstream das so macht. Das muss denen doch selber bewußt sein ...


Das Ding war halt ein Forschungsprojekt und kein entwickeltes Produkt.
Da ist Protkoll-Kompatibilität halt nicht wichtig, weil das ja bei der
Entwicklung und Forschung hinderlich ist.

S!
Matthias Böttcher (20.04.2020, 14:10)
Hallo Manfred,

csync2 ("rsync mit Gedächtnis") könnte dir helfen, ist als
Debian-Paket verfügbar.
Ich setze das seit Jahren ohne Probleme ein.

Features:
- conflict detection and resolving
- replicating removals
- reacting to updates / executing commands on update



Viel Erfolg!
Matthias

Am So., 19. Apr. 2020 um 22:02 Uhr schrieb Manfred Rebentisch
<debianlist>:
[..]

Ähnliche Themen