ทำไมถึงไม่สามารถใช้รีโมทสองตัวสำหรับ rsync ได้? [ปิด]

เมื่อทั้งต้นทางและปลายทางรีโมต 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]

มีอุปสรรคทางเทคนิคผ่านไม่ได้ในการทำ rsync ทำเช่นนี้? หรือมันเป็นเพียงกรณีของการที่ยังไม่ได้ใช้งาน? ดูเหมือนว่าค่อนข้างง่ายในการสร้างบัฟเฟอร์โลคัลในหน่วยความจำที่เป็นสื่อกลางในการถ่ายโอนระหว่างสองรีโมทโดยเก็บทั้งแฮชและข้อมูล

แก้ไข

เนื่องจากผู้คนกำลังให้คำแนะนำแทนเจนต์ฉันจึงโพสต์คำถามแยกต่างหากซึ่งระบุรายละเอียดกรณีการใช้งานเฉพาะของฉัน นี่เป็นสองแยกจริงๆและฉันคิดว่ามันจะคุ้มค่าที่จะรู้รายละเอียดเฉพาะเหล่านี้สำหรับ rsync

rsync remote

— goncalopp
แหล่งที่มา

มันจะเกี่ยวข้องกับ src rsyncd ระยะไกลส่งข้อมูลไปยังปลายทาง rsyncd ระยะไกล คุณสามารถหลีกเลี่ยงได้โดย ssh'ing กับระบบ src และเรียกใช้ rsync

— Alex Holst

@AlexHolst ฉันไม่คิดว่าจะทำงานในกรณีของฉันโดยเฉพาะ ดูการแก้ไข

— goncalopp

ขออภัยServer Faultไม่สามารถตอบคำถามเชิงทฤษฎีได้ เฉพาะคำถามที่ตอบได้เกี่ยวกับปัญหาที่คุณเผชิญ ดูคำถามที่พบบ่อยสำหรับรายละเอียดเพิ่มเติม

— Chris S

ขออภัย (ผู้ดูแล) นี่เป็นคำถามที่น่าสนใจที่สามารถตอบได้: เหตุผลก็คือว่าอัลกอริทึม rdiff ไม่สามารถสมมาตรได้ CPU และหน่วยความจำที่ใหญ่กว่านั้นอยู่ด้าน "แอคทีฟ" ด้าน "พาสซีฟ" ต้องการเพียงการคำนวณการตรวจสอบของบล็อกทั้งหมด (ดู - พารามิเตอร์ขนาดบล็อก) ของไฟล์ที่แก้ไขทั้งหมดและส่งใหม่ ทำด้วยความต้องการหน่วยความจำขนาดเล็กมากและการดำเนินการส่วนใหญ่สามารถทำได้ในแคช CPU ระดับแรก ด้าน "ใช้งาน" ความต้องการที่จะค้นหาตาม checksums ที่บล็อกข้อมูลเดียวกันตั้งอยู่ตอนนี้ ...

— hynekcer

ฉันคิดว่านี่เป็นคำถามที่ยอดเยี่ยม (ฉันมีคำถามตรงนี้นั่นคือเหตุผลที่ฉันมาที่นี่) และเหตุผลปิดคือปลอม ฉันยังต้องการทราบคำตอบ!

— reinierpost

คำตอบ:

ทำไมไม่ลองและเชื่อมต่อกับเครื่องระยะไกลและเริ่มการถ่ายโอนจากที่นั่น หากคุณใช้ ssh-keys คุณสามารถใช้การส่งผ่านเอเจนต์แม้ว่าจะจัดการการรับรองความถูกต้องสำหรับคุณ

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

คำสั่งนี้จะเข้าสู่คุณใน remoteHostA และเรียกใช้ rsync จากที่นั่น

— Kaplaa
แหล่งที่มา

มีข้อควรพิจารณาด้านความปลอดภัยที่เกี่ยวข้อง ดูการแก้ไข

— goncalopp

นอกจากนี้สิ่งนี้จะไม่ทำงานหากคุณไม่มีการเข้าถึงโดยตรงระหว่างสองระบบ ... และหากการเข้าถึงโดยตรงเกี่ยวข้องกับการรอสองสัปดาห์เพื่อให้ส่วนความปลอดภัยสามารถใช้กฎไฟร์วอลล์ได้อย่างถูกต้อง ...

— Gert van den Berg

สถานการณ์จำลอง: เซิร์ฟเวอร์ A มีการเข้าถึงรูทตามคีย์ไปยังเซิร์ฟเวอร์ B และ C คุณต้องการซิงค์จาก B ถึง C โดยใช้การเข้าถึงรูทบนทั้งสอง แต่คุณไม่ต้องการให้ B หรือ C มีสิทธิ์เข้าถึงรูทซึ่งกันและกัน

— thomasrutter

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

ไม่มีปัญหาในการทำเช่นนี้

— กรรม Fusebox
แหล่งที่มา

scp ไม่ทำ delta แม้ว่า AFAIK และเป็นสิ่งที่ไม่ดีในกรณีนี้ รายละเอียดเพิ่มเติมเกี่ยวกับการแก้ไขของฉัน

— goncalopp

Btw, SCP จะต้องมีความพร้อมกับตัวเลือก -3 ถ้าคุณต้องการที่จะเป็นเหมือนพร็อกซี่ระหว่างโฮสต์

— alterpub

น่าเสียดายที่ scp ขาดคุณสมบัติที่สำคัญของ rsync เช่น: ตัวเลือกที่จะไม่ข้ามระบบไฟล์ (เช่นไดรฟ์เครือข่ายที่ติดตั้งในโฟลเดอร์ผู้ใช้), โหมดเก็บถาวร (ซึ่ง "ลิงก์สัญลักษณ์, อุปกรณ์, คุณสมบัติ, สิทธิ์, การเป็นเจ้าของ ฯลฯ ") ...

— Bastion

คุณสามารถทำงานรอบนี้โดยการติดตั้งหนึ่ง (หรือทั้งสอง) sshfsของระบบไฟล์ระยะไกลด้วย จากนั้น rsync จะจัดการกับมันราวกับว่าอยู่ในพื้นที่

น่าเสียดายที่สิ่งนี้จะส่งผลให้มีการใช้แบนด์วิดท์จำนวนมากบนเครื่องที่ติดตั้งระบบไฟล์sshfsไว้ดังนั้นฉันขอแนะนำให้ทำเช่นนี้กับเครื่องที่มีแบนด์วิดท์ระหว่างคุณกับเครื่องที่สามค่อนข้างมาก

แน่นอนทางออกที่ดีที่สุดสำหรับเครื่องที่จะพูดคุยกันโดยตรง ฉันไม่สามารถคิดเหตุผลที่ดีว่าทำไมพวกเขาไม่ควร

— Michael Hampton
แหล่งที่มา

ดูการแก้ไข เหตุผลที่คุณอ้างถึงคือความปลอดภัย A (root) ประนีประนอมหนึ่งในสองเครื่องใด ๆ จะต้องไม่นำไปสู่การเข้าถึงระบบไฟล์ไปยังอีกเครื่องหนึ่ง แต่บางทีฉันกำลังโจมตีสิ่งนี้จากมุมที่ผิดและมีวิธีแก้ปัญหาที่ไม่เกี่ยวข้องกับเครื่องที่สาม ...

— goncalopp

อืมมม ฉันคิดว่ารายละเอียดเหล่านั้นควรถูกเพิ่มลงในคำถามนี้ ในเรื่องของการประนีประนอมคุณควรใช้ SELinux

— Michael Hampton

ฉันออกจากที่นี่เพราะคนอื่นอาจสนใจพฤติกรรมนี้ใน rsync โดยเฉพาะ AFAIK, SELinux บนเครื่องใด ๆ ไม่สามารถบอกได้ว่าอีกอันถูกบุกรุกถ้า rsync ที่ดำเนินการในเครื่องนั้นมีพฤติกรรมเหมือนกันทั้งสองกรณี (ระบบไฟล์เข้าถึงไดเรกทอรีเฉพาะ)

— goncalopp

ฉันไม่แน่ใจว่าคุณเข้าใจวิธีการทำงานของ SELinux หรือไม่ จุดรวมของมันคือมันป้องกันบริการ (แม้แต่บริการที่ถูกบุกรุก) จากการเข้าถึงสิ่งต่าง ๆ ที่ไม่ได้รับอนุญาตให้เข้าถึงอย่างชัดเจนแม้ว่าบริการนั้นจะทำงานเหมือนรูทก็ตาม

— Michael Hampton

ฉันมีเพียงแค่ความเข้าใจพื้นฐานของนโยบาย SELinux แต่ rsync ถูกควรจะเข้าถึงระบบไฟล์ที่ไม่ได้หรือไม่ รูปแบบการเข้าถึง (ท้องถิ่น) ชนิดเดียวกันนั้นไม่เป็นที่ต้องการหากเครื่องระยะไกลถูกบุกรุก

— goncalopp