Mengapa tidak mungkin menggunakan dua remote untuk rsync? [Tutup]

Ketika sumber dan tujuan keduanya jauh, rsync mengeluh:

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

Apakah ada hambatan teknis yang tidak dapat diatasi untuk membuat rsync melakukan ini? Atau itu hanya kasus yang belum diimplementasikan? Tampaknya relatif mudah untuk membuat buffer lokal dalam memori yang memediasi transfer antara dua remote, memegang hash dan data.

EDIT

Karena orang-orang membuat beberapa saran singgung, saya telah memposting pertanyaan terpisah yang merinci kasus penggunaan khusus saya. Ini adalah dua yang terpisah, sungguh, dan saya pikir akan bermanfaat untuk mengetahui detail khusus ini untuk rsync

rsync remote

— goncalopp
sumber

Ini akan melibatkan remote rsyncd src mengirim data ke remote rsyncd. Anda dapat mengatasinya dengan ssh'ing ke sistem src dan menjalankan rsync.

— Alex Holst

@AlexHolst Saya tidak berpikir itu akan berhasil dalam kasus khusus saya. lihat edit

— goncalopp

Maaf, Server Fault tidak berurusan dengan pertanyaan teoritis; hanya pertanyaan yang dapat Dijawab tentang masalah yang Anda hadapi. Lihat FAQ untuk lebih jelasnya.

— Chris S

Maaf (moderator), ini adalah pertanyaan menarik yang dapat dijawab: Alasannya adalah algoritma rdiff tidak dapat simetris. CPU dan memori yang lebih besar ada di sisi "aktif". Sisi "pasif" hanya perlu menghitung checksum dari semua blok (lihat --block-size parameter) dari semua file yang dimodifikasi dan untuk mengirim ulang. Itu dilakukan dengan persyaratan memori yang sangat kecil dan sebagian besar operasi dapat dilakukan di cache CPU tingkat pertama. Sisi "aktif" perlu dicari oleh sebuah checksum di mana blok data yang sama berada sekarang ...

— hynekcer

Saya pikir ini adalah pertanyaan yang bagus (saya punya pertanyaan ini, itu sebabnya saya di sini) dan alasan penutupnya adalah palsu. Saya masih ingin tahu jawabannya!

— reinierpost

Jawaban:

mengapa tidak mencoba dan terhubung ke mesin jarak jauh dan mulai transfer dari sana. Jika Anda menggunakan ssh-keys, Anda dapat menggunakan pass agen untuk mengelola autentikasi untuk Anda.

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

Perintah ini akan mencatat Anda di remoteHostA dan menjalankan rsync dari sana.

— Kaplaa
sumber

Ada beberapa pertimbangan keamanan yang terlibat. Lihat edit

— goncalopp

Juga, itu tidak akan berfungsi jika Anda tidak memiliki akses langsung antara kedua sistem ... Dan jika mendapatkan akses langsung melibatkan menunggu dua minggu untuk bagian keamanan untuk mungkin menerapkan aturan firewall dengan benar ...

— Gert van den Berg

Skenario: Server A memiliki akses root berbasis kunci ke server B dan C. Anda ingin menyinkronkan dari B ke C menggunakan akses root pada keduanya. Tetapi Anda tidak ingin B atau C memiliki akses root satu sama lain.

— thomasrutter

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

tidak kesulitan melakukan ini.

— Karma Fusebox
sumber

scp tidak melakukan delta, AFAIK, dan itu sangat dibutuhkan dalam kasus ini. Rincian lebih lanjut tentang hasil edit saya

— goncalopp

Btw, scp harus dengan opsi -3 jika Anda ingin menjadi seperti proxy antara host

— alterpub

Sayangnya scp tidak memiliki fitur-fitur penting rsync misalnya: opsi untuk tidak melintasi sistem file (misalnya drive jaringan yang dipasang di folder pengguna), mode arsip (di mana "tautan simbolis, perangkat, atribut, izin, kepemilikan, dll. Dipertahankan"), dll ...

— Bastion

Anda dapat mengatasi ini dengan memasang satu (atau keduanya) dari sistem file jarak jauh dengan sshfs. Kemudian, rsync akan memperlakukannya seolah-olah itu lokal.

Sayangnya, ini akan menghasilkan banyak penggunaan bandwidth pada mesin yang memiliki sistem file yang terpasang sshfs, jadi saya akan merekomendasikan hanya melakukan ini dengan mesin yang memiliki banyak bandwidth antara Anda dan mesin ketiga.

Tentu saja, solusi ideal adalah agar mesin berbicara langsung satu sama lain. Saya tidak bisa memikirkan alasan bagus mengapa mereka tidak boleh.

— Michael Hampton
sumber

lihat edit. Alasan yang Anda maksudkan adalah keamanan. Kompromi (root) salah satu dari dua mesin tidak boleh mengarah ke akses sistem file ke yang lain. Tapi mungkin saya menyerang ini dari sudut yang salah dan ada solusi yang tidak melibatkan mesin ketiga ...

— goncalopp

Hmm. Saya pikir detail-detail itu benar-benar harus ditambahkan ke pertanyaan ini. Sedangkan untuk kompromi root, Anda benar-benar harus menggunakan SELinux.

— Michael Hampton

Saya meninggalkan yang ini karena orang lain mungkin tertarik pada perilaku ini pada rsync pada khususnya. AFAIK, SELinux pada salah satu mesin tidak dapat memastikan apakah yang lain telah dikompromikan jika rsync yang menjalankan secara lokal memiliki perilaku yang sama persis dalam kedua kasus (akses sistem file ke direktori tertentu).

— goncalopp

Saya tidak yakin apakah Anda memahami cara kerja SELinux. Intinya adalah mencegah layanan (bahkan layanan yang dikompromikan) mengakses hal-hal yang tidak diizinkan untuk diakses, bahkan jika layanan tersebut berjalan sebagai root.

— Michael Hampton

Saya hanya memiliki pemahaman dasar tentang kebijakan SELinux, tapi rsync adalah seharusnya untuk mengakses filesystem, bukan? Jenis pola akses (lokal) yang persis sama tidak diinginkan jika mesin jarak jauh terganggu.

— goncalopp