Perché non è possibile utilizzare due telecomandi per rsync? [chiuso]

Quando sia l'origine che la destinazione sono remote, rsync si lamenta:

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

Esiste un ostacolo tecnico insormontabile per fare in modo che rsync faccia questo? O è semplicemente un caso di non ancora implementato? Sembra relativamente facile creare un buffer locale in memoria che media il trasferimento tra due telecomandi, trattenendo sia hash che dati.

MODIFICARE

Dato che le persone stanno dando alcuni suggerimenti tangenziali, ho pubblicato una domanda separata che descrive in dettaglio il mio caso d'uso particolare. Questi sono due separati, davvero, e penso che varrebbe la pena conoscere questi particolari dettagli per rsync

rsync remote

— goncalopp
fonte

Implicherebbe un rsyncd remoto che invia i dati a un rsyncd remoto. Puoi aggirare il problema inviando ssh'ing al sistema src e invocando rsync.

— Alex Holst,

@AlexHolst Non penso che funzionerebbe nel mio caso particolare. vedi modifica

— goncalopp

Siamo spiacenti, Server Fault non si occupa di domande teoriche; solo domande rispondibili sui problemi che effettivamente affronti. Vedi le FAQ per maggiori dettagli.

— Chris S,

Siamo spiacenti (moderatori), questa è una domanda interessante che risponde: il motivo è che l'algoritmo rdiff non può essere simmetrico. Una CPU più grande e un overhead di memoria è sul lato "attivo". Il lato "passivo" deve solo calcolare i checksum di tutti i blocchi (vedere il parametro --block-size size) di tutti i file modificati e inviarli nuovamente. Questo viene fatto con requisiti di memoria molto piccoli e la maggior parte delle operazioni può essere eseguita nella cache della CPU di primo livello. Il lato "attivo" deve cercare un checksum in cui si trova ora lo stesso blocco di dati ...

— hynekcer,

Penso che questa sia un'ottima domanda (avevo esattamente questa domanda, ecco perché sono qui) e il motivo di chiusura è falso. Voglio ancora sapere la risposta!

— reinierpost,

Risposte:

perché non provare a connettersi al computer remoto e iniziare il trasferimento da lì? Se stai usando ssh-keys puoi usare agent pass per gestire l'autenticazione per te.

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

Questo comando ti accederà su remoteHostA ed eseguirà rsync da lì.

— Kaplaa
fonte

Ci sono alcune considerazioni sulla sicurezza. Vedi modifica

— goncalopp,

Inoltre, ciò non funzionerà se non si ha accesso diretto tra i due sistemi ... E se ottenere l'accesso diretto comporta l'attesa di due settimane per una sezione di sicurezza per implementare correttamente le regole del firewall ...

— Gert van den Berg

Scenario: il server A dispone dell'accesso root basato su chiave ai server B e C. Si desidera sincronizzare da B a C utilizzando l'accesso root su entrambi. Ma non vuoi che B o C abbiano accesso root l'uno all'altro.

— thomasrutter,

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

non ha problemi a farlo.

— Karma Fusebox
fonte

scp non fa delta, AFAIK, ed è molto necessario in questo caso. Maggiori dettagli sulla mia modifica

— goncalopp,

A proposito, scp deve essere con le opzioni -3 se vuoi essere come un proxy tra host

— alterpub

Sfortunatamente a scp mancano importanti funzionalità di rsync, ad esempio: opzione per non attraversare i filesystem (ad es. Unità di rete montata nella cartella dell'utente), modalità di archiviazione (in cui vengono preservati "collegamenti simbolici, dispositivi, attributi, autorizzazioni, proprietà, ecc."), Ecc. ...

— Bastione

Puoi aggirare questo problema montando uno (o entrambi) dei filesystem remoti con sshfs . Quindi, rsync lo tratterà come se fosse locale.

Sfortunatamente, ciò comporterà un sacco di utilizzo della larghezza di banda sulla macchina con il quale è montato il filesystem sshfs, quindi consiglierei di farlo solo con la macchina che ha molta larghezza di banda tra te e la terza macchina.

Naturalmente, la soluzione ideale è che le macchine parlino direttamente tra loro. Non riesco a pensare a nessuna buona ragione per cui non dovrebbero.

— Michael Hampton
fonte

vedi modifica. Il motivo a cui ti riferisci è la sicurezza. Un compromesso (root) di una delle due macchine non deve comportare l'accesso al filesystem all'altro. Ma forse sto attaccando questo da un'angolazione sbagliata e c'è una soluzione che non coinvolge una terza macchina ...

— goncalopp,

Hmm. Penso che quei dettagli dovrebbero davvero essere aggiunti a questa domanda. Per quanto riguarda un compromesso di root, dovresti davvero usare SELinux.

— Michael Hampton

Ho lasciato questo perché qualcun altro potrebbe essere interessato a questo comportamento in particolare su rsync. AFAIK, SELinux su nessuna delle macchine non può dire se l'altra è stata compromessa se il rsync che esegue localmente ha lo stesso identico comportamento in entrambi i casi (accesso al filesystem in una particolare directory).

— goncalopp,

Non sono sicuro se capisci come funziona SELinux. Il suo punto è che impedisce a un servizio (anche un servizio compromesso) di accedere a cose a cui non è esplicitamente consentito l'accesso, anche se quel servizio viene eseguito come root.

— Michael Hampton

Ho solo una conoscenza di base delle politiche di SELinux, ma si suppone che rsync acceda al filesystem, no? Lo stesso tipo esatto di schemi di accesso (locali) è indesiderabile se la macchina remota è compromessa.

— goncalopp,