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

Wenn sowohl Quelle als auch Ziel remote sind, beklagt 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überwindliches technisches Hindernis dafür, dass rsync dies tut? 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 Remotes vermittelt und sowohl Hashes als auch Daten enthält.

BEARBEITEN

Da die Leute einige tangentiale Vorschläge machen, habe ich eine separate Frage gepostet , die meinen speziellen Anwendungsfall beschreibt. Eigentlich sind es zwei, und ich denke, es lohnt sich, diese besonderen Details für rsync zu kennen

rsync remote

— Goncalopp
quelle

Es würde einen entfernten src rsyncd beinhalten, der Daten an einen entfernten Ziel-rsyncd sendet. Sie können dies umgehen, indem Sie ssh'ing an das src-System senden und rsync aufrufen.

— Alex Holst

@AlexHolst Ich glaube nicht, dass das in meinem speziellen Fall funktionieren würde. siehe edit

— goncalopp 18.11.12

Entschuldigung, Server Fault beschäftigt sich nicht mit theoretischen Fragen. Nur beantwortbare Fragen zu Problemen, mit denen Sie konfrontiert sind. Weitere Informationen finden Sie in den FAQ .

— Chris S

Entschuldigung (Moderatoren), dies ist eine beantwortbare interessante Frage: Der Grund dafür ist, dass der rdiff-Algorithmus nicht symmetrisch sein kann. Ein größerer CPU- und Speicher-Overhead ist auf der "aktiven" Seite. Die "passive" Seite muss lediglich die Prüfsummen aller Blöcke (siehe --block-size-Parameter) aller geänderten Dateien berechnen und erneut senden. Dies geschieht mit sehr geringem Speicherbedarf, und die meisten Vorgänge können im CPU-Cache der ersten Ebene ausgeführt werden. Die "aktive" Seite muss nach einer Prüfsumme suchen, in der sich jetzt derselbe Datenblock befindet ...

— hynekcer 13.11.16

Ich denke, das ist eine großartige Frage (ich hatte genau diese Frage, deshalb bin ich hier) und der Schlussgrund ist falsch. Ich möchte immer noch die Antwort wissen!

— Reinierpost

Antworten:

Warum nicht versuchen, eine Verbindung zum Remote-Computer herzustellen und die Übertragung von dort aus zu starten? Wenn Sie SSH-Schlüssel verwenden, können Sie den Agentenpass verwenden, um die Authentifizierung für Sie zu verwalten.

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

Dieser Befehl meldet Sie bei remoteHostA an und führt von dort aus rsync aus.

— Kaplaa
quelle

Es gibt einige Sicherheitsaspekte. Siehe Bearbeiten

— Goncalopp

Das funktioniert auch nicht, wenn Sie keinen direkten Zugriff zwischen den beiden Systemen haben ... Und wenn der direkte Zugriff zwei Wochen in Anspruch nimmt, bis ein Sicherheitsabschnitt die Firewall-Regeln korrekt implementiert hat ...

— Gert van den Berg

Szenario: Server A verfügt über schlüsselbasierten Stammzugriff auf Server B und C. Sie möchten die Synchronisierung von B nach C über den Stammzugriff auf beiden Servern durchführen. Sie möchten jedoch nicht, dass B oder C root-Zugriff aufeinander haben.

— Thomasrutter

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

hat keine Probleme damit.

— Karma Fusebox
quelle

scp macht aber keine Deltas, AFAIK, und in diesem Fall wird es dringend benötigt. Weitere Details zu meiner Bearbeitung

— Goncalopp

Übrigens muss scp mit Optionen -3 sein, wenn Sie wie ein Proxy zwischen Hosts sein

— möchten

Leider hat scp keine wichtigen Funktionen von rsync, zB: Option, keine Dateisysteme zu überqueren (zB Netzwerklaufwerk im Benutzerordner), Archivierungsmodus (in dem "symbolische Links, Geräte, Attribute, Berechtigungen, Eigentumsrechte usw. erhalten bleiben") usw ...

— Bastion

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

Leider führt dies zu einer hohen Bandbreitennutzung auf dem Computer, auf dem das Dateisystem eingehängt ist. Daher sshfswürde ich empfehlen, dies nur auf dem Computer zu tun, auf dem sich zwischen Ihnen und dem dritten Computer eine hohe Bandbreite befindet.

Die ideale Lösung ist natürlich, dass die Maschinen direkt miteinander sprechen. Mir fällt kein guter Grund ein, warum sie es nicht sollten.

— Michael Hampton
quelle

siehe bearbeiten Der Grund, auf den Sie sich beziehen, ist Sicherheit. Ein (Root-) Kompromiss auf einer der beiden Maschinen darf nicht dazu führen, dass das Dateisystem auf die andere zugreift. Aber vielleicht greife ich das aus dem falschen Blickwinkel 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. Als Root-Kompromiss sollten Sie wirklich SELinux verwenden.

— Michael Hampton

Ich habe dieses verlassen, weil sich jemand anderes für dieses Verhalten bei rsync interessiert. AFAIK, SELinux auf einem der Computer kann nicht feststellen, ob der andere Computer kompromittiert wurde, wenn das lokal ausgeführte rsync in beiden Fällen genau dasselbe Verhalten aufweist (Dateisystemzugriff auf ein bestimmtes Verzeichnis).

— Goncalopp

Ich bin mir nicht sicher, ob Sie verstehen, wie SELinux funktioniert. Der springende Punkt ist, dass verhindert wird, dass ein Dienst (auch 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 von SELinux - Richtlinien, aber rsync ist angeblich das Dateisystem zugreifen zu können , ist es nicht? Die genau gleiche Art von (lokalen) Zugriffsmustern ist unerwünscht, wenn der Remotecomputer gefährdet ist.

— Goncalopp