Frage Warum ist es nicht möglich, zwei Fernbedienungen für rsync zu verwenden? [geschlossen]


Wenn sowohl die Quelle als auch das Ziel entfernt sind, beschwert sich rsync:

The source and destination cannot both be remote. rsync error: syntax or usage error (code 1) at main.c(1156) [Receiver=3.0.7]

Gibt es ein unüberwindbares technisches Hindernis, um rsync dazu zu bringen? Oder ist es einfach ein Fall von noch nicht implementiert? Es scheint relativ einfach zu sein, einen lokalen Puffer im Speicher zu erstellen, der die Übertragung zwischen zwei Fernbedienungen vermittelt und sowohl Hashwerte als auch Daten enthält.

BEARBEITEN

Da die Leute einige tangentiale Vorschläge machen, habe ich eine separate Frage Detaillierung meines speziellen Anwendungsfalls. Dies sind zwei separate, wirklich, und ich denke, es wäre lohnend, diese besonderen Details für rsync zu kennen


28
2017-11-17 14:09


Ursprung


Es würde eine remote src rsyncd Daten an eine Remote-Destination rsyncd senden. Sie können umgehen, indem Sie zum src-System gehen und rsync aufrufen. - Alex Holst
@AlexHolst Ich glaube nicht, dass das in meinem speziellen Fall funktionieren würde. siehe Bearbeiten - goncalopp
Es tut uns leid, Serverfehler befasst sich nicht mit theoretischen Fragen; nur Beantwortbare Fragen zu Problemen, denen Sie tatsächlich gegenüberstehen. Siehe die FAQ für mehr Details. - Chris S
Tut mir leid (Moderatoren), das ist eine beantwortbare interessante Frage: Der Grund ist, dass der rdiff-Algorithmus nicht symmetrisch sein kann. Ein größerer CPU- und Speicheraufwand ist auf der "aktiven" Seite. Die "passive" Seite muss nur Prüfsummen aller Blöcke berechnen (siehe Parameter --block-size) aller geänderten Dateien und sie erneut senden. Dies erfolgt mit sehr geringen Speicheranforderungen, und die meisten Operationen können im CPU-Cache der ersten Ebene ausgeführt werden. Die "aktive" Seite muss nach einer Prüfsumme suchen, in der sich derselbe Datenblock befindet ... - hynekcer
Das erfordert, 24 Bytes Speicher pro Block und einen häufigen Direktzugriff auf diese große temporäre Speicherdatenbank zu halten, um 4 Bytes pro Byte von fehlplatzierten Daten zu suchen, die im Vorbeigehen berechnet werden rolling hash Algorithmus für alle Bytes des Blocks. Es ist klar, dass dieser große Bereich den langsamen nicht zwischengespeicherten Speicher verwenden muss. Es wäre eine umstrittene Idee, den "aktiven" Teil auf einer entfernten Seite zu implementieren, wenn man sich vorstellt, dass es sich um einen Dateiserver handelt, der mehr gleichartige Anfragen oder sogar einen billigen NAS-Server ausführen muss ... - hynekcer


Antworten:


warum nicht versuchen, eine Verbindung mit der Remote - Maschine und starten Sie die Transfer von dort. Wenn Sie ssh-keys verwenden, können Sie einen Agenten verwenden übergeben Sie, um die Authentifizierung für Sie zu verwalten.

ssh -A remotehostA rsync /remote/file/on/host/a remoteHostB:/destination/

Dieser Befehl protokolliert Sie auf dem remoteHostA und führt rsync von dort aus.


5
2017-11-17 15:27



Es gibt einige Sicherheitsüberlegungen. Siehe Bearbeiten - goncalopp
Das funktioniert auch nicht, wenn Sie keinen direkten Zugriff zwischen den beiden Systemen haben ... Und wenn der direkte Zugriff zwei Wochen dauert, bis ein Sicherheitsabschnitt die Firewall-Regeln korrekt implementiert hat ... - Gert van den Berg
Szenario: Server A verfügt über einen schlüsselbasierten Root-Zugriff auf Server B und C. Sie möchten von B nach C synchronisieren, indem Sie den Root-Zugriff für beide verwenden. Aber Sie möchten nicht, dass B oder C Root-Zugriff aufeinander haben. - thomasrutter


scp -3r <remote src> <remote dest>

hat keine Probleme damit.


4
2017-11-17 14:16



scp tut jedoch nicht Deltas, AFAIK, und es wird in diesem Fall dringend benötigt. Mehr Details zu meiner Bearbeitung - goncalopp
Btw, scp muss mit Optionen -3 sein, wenn Sie wie ein Proxy zwischen Hosts sein möchten - alterpub


Sie können dies umgehen, indem Sie eines (oder beide) der Remote-Dateisysteme mit sshfs. Dann behandelt rsync es so, als wäre es lokal.

Leider führt dies zu einer großen Bandbreitennutzung auf dem Rechner, auf dem das Dateisystem eingebunden ist sshfs, so würde ich empfehlen, dies nur mit der Maschine zu tun, die viel Bandbreite zwischen Ihnen und der dritten Maschine hat.

Die ideale Lösung ist natürlich, dass die Maschinen direkt miteinander kommunizieren. Ich kann mir keine vorstellen gut Grund, warum sie nicht sollten.


1
2017-11-18 01:32



siehe Bearbeiten. Der Grund, auf den Sie sich beziehen, ist Sicherheit. Ein (root) Kompromiss einer der beiden Maschinen darf nicht zum Dateisystemzugriff auf den anderen führen. Aber vielleicht greife ich das aus dem falschen Winkel an und es gibt eine Lösung, die keine dritte Maschine beinhaltet ... - goncalopp
Hmm. Ich denke, diese Details sollten wirklich zu dieser Frage hinzugefügt werden. Wie bei einer Root-Kompromittierung sollten Sie SELinux wirklich verwenden. - Michael Hampton♦
Ich habe das hier gelassen, weil jemand anderes an diesem Verhalten besonders bei rsync interessiert sein könnte. AFAIK, SELinux auf einer der Maschinen kann nicht feststellen, ob die andere kompromittiert wurde, wenn das lokal ausgeführte rsync in beiden Fällen das gleiche Verhalten hat (Dateisystemzugriff auf ein bestimmtes Verzeichnis). - goncalopp
Ich bin mir nicht sicher, ob Sie verstehen, wie SELinux funktioniert. Der springende Punkt ist, dass es verhindert, dass ein Dienst (selbst ein kompromittierter Dienst) auf Dinge zugreift, auf die er nicht explizit zugreifen darf, selbst wenn dieser Dienst als root ausgeführt wird. - Michael Hampton♦
Ich habe nur ein grundlegendes Verständnis der SELinux-Richtlinien, aber rsync ist soll auf das Dateisystem zugreifen, oder? Die genau gleiche Art von (lokalen) Zugriffsmustern ist unerwünscht, wenn die Fernbedienung Maschine ist kompromittiert. - goncalopp