Tại sao không thể sử dụng hai điều khiển từ xa cho rsync? [đóng cửa]

Khi cả nguồn và đích đều ở xa, rsync sẽ phàn nàn:

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

Có một trở ngại kỹ thuật không thể vượt qua để làm cho rsync làm điều này? Hay nó chỉ đơn giản là một trường hợp chưa được thực hiện? Dường như tương đối dễ dàng để tạo một bộ đệm cục bộ trong bộ nhớ làm trung gian chuyển giữa hai điều khiển từ xa, giữ cả băm và dữ liệu.

CHỈNH SỬA

Vì mọi người đang đưa ra một số gợi ý tiếp tuyến, tôi đã đăng một câu hỏi riêng chi tiết về trường hợp sử dụng cụ thể của tôi. Đây thực sự là hai phần riêng biệt và tôi nghĩ rằng thật đáng để biết những chi tiết cụ thể này cho rsync

rsync remote

— goncalopp
nguồn

Nó sẽ liên quan đến một rsyncd src từ xa gửi dữ liệu đến một rsyncd từ xa. Bạn có thể làm việc xung quanh nó bằng cách ssh'ing vào hệ thống src và gọi rsync.

— Alex Holst

@AlexHolst Tôi không nghĩ rằng nó sẽ hoạt động trong trường hợp cụ thể của tôi. xem chỉnh sửa

— goncalopp

Xin lỗi, Server Fault không giải quyết các câu hỏi lý thuyết; chỉ có thể trả lời câu hỏi về các vấn đề bạn thực sự phải đối mặt. Xem FAQ để biết thêm chi tiết.

— Chris S

Xin lỗi (người điều hành), đây là một câu hỏi thú vị có thể trả lời: Lý do là thuật toán thứ ba không thể đối xứng. CPU và bộ nhớ lớn hơn nằm ở phía "hoạt động". Phía "thụ động" chỉ cần tính toán tổng của tất cả các khối (xem - tham số kích thước chặn) của tất cả các tệp đã sửa đổi và gửi lại chúng. Điều đó được thực hiện với các yêu cầu bộ nhớ rất nhỏ và hầu hết các hoạt động có thể được thực hiện trong bộ đệm CPU cấp độ đầu tiên. Phía "hoạt động" cần tìm kiếm bằng một tổng kiểm tra nơi có cùng một khối dữ liệu ...

— hynekcer

Tôi nghĩ rằng đây là một câu hỏi tuyệt vời (tôi đã có chính xác câu hỏi này, đó là lý do tại sao tôi ở đây) và lý do kết thúc là không có thật. Tôi vẫn muốn biết câu trả lời!

— rebierpost

Câu trả lời:

tại sao không thử và kết nối với máy từ xa và bắt đầu chuyển từ đó. Nếu bạn đang sử dụng khóa ssh, bạn có thể sử dụng pass pass mặc dù để quản lý xác thực cho bạn.

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

Lệnh này sẽ đăng nhập bạn trên remotehostA và chạy rsync từ đó.

— Kaplaa
nguồn

Có một số cân nhắc về an ninh liên quan. Xem chỉnh sửa

— goncalopp

Ngoài ra, điều đó sẽ không hoạt động nếu bạn không có quyền truy cập trực tiếp giữa hai hệ thống ... Và nếu việc truy cập trực tiếp liên quan đến việc chờ hai tuần để phần bảo mật có thể thực hiện chính xác các quy tắc tường lửa ...

— Gert van den Berg

Kịch bản: Máy chủ A có quyền truy cập root dựa trên khóa vào máy chủ B và C. Bạn muốn đồng bộ hóa từ B đến C bằng quyền truy cập root trên cả hai. Nhưng bạn không muốn B hoặc C có quyền truy cập root với nhau.

— thomasrutter

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

không gặp khó khăn khi làm điều này.

— Karma Fusebox
nguồn

scp không làm deltas mặc dù, AFAIK, và nó rất cần thiết trong trường hợp này. Thêm chi tiết về chỉnh sửa của tôi

— goncalopp

Btw, scp phải có các tùy chọn -3 nếu bạn muốn giống như một proxy giữa các máy chủ

— thay đổi

Thật không may, scp thiếu các tính năng quan trọng của rsync, ví dụ: tùy chọn không vượt qua các hệ thống tệp (ví dụ: ổ đĩa mạng được gắn trong thư mục người dùng), chế độ lưu trữ (trong đó "liên kết tượng trưng, thiết bị, thuộc tính, quyền, quyền sở hữu, v.v.", v.v. ...

— Bastion

Bạn có thể giải quyết vấn đề này bằng cách gắn một (hoặc cả hai) hệ thống tập tin từ xa với sshfs. Sau đó, rsync sẽ coi nó như thể nó là cục bộ.

Thật không may, điều này sẽ dẫn đến việc sử dụng nhiều băng thông trên máy có hệ thống tệp được gắn kết sshfs, vì vậy tôi khuyên bạn chỉ nên làm điều này với máy có nhiều băng thông giữa bạn và máy thứ ba.

Tất nhiên, giải pháp lý tưởng là cho các máy nói chuyện trực tiếp với nhau. Tôi không thể nghĩ ra bất kỳ tốt lý do tại sao họ không nên.

— Michael Hampton
nguồn

xem chỉnh sửa. Lý do bạn đề cập đến là bảo mật. Một (root) thỏa hiệp bất kỳ một trong hai máy không được dẫn đến quyền truy cập hệ thống tập tin vào máy kia. Nhưng có lẽ tôi đang tấn công nó từ góc độ sai và có một giải pháp không liên quan đến máy thứ ba ...

— goncalopp

Hừm. Tôi nghĩ những chi tiết đó thực sự nên được thêm vào câu hỏi này. Đối với một thỏa hiệp gốc, bạn thực sự nên sử dụng SELinux.

— Michael Hampton

Tôi đã bỏ cái này vì người khác có thể quan tâm đến hành vi này trên rsync nói riêng. AFAIK, SELinux trên bất kỳ máy nào cũng không thể biết liệu máy kia có bị xâm phạm hay không nếu rsync thực thi cục bộ có hành vi giống hệt nhau trong cả hai trường hợp (truy cập hệ thống tệp vào một thư mục cụ thể).

— goncalopp

Tôi không chắc bạn có hiểu cách thức hoạt động của SELinux không. Toàn bộ quan điểm của nó là nó ngăn chặn một dịch vụ (thậm chí là một dịch vụ bị xâm nhập) truy cập vào những thứ mà nó không được phép truy cập rõ ràng, ngay cả khi dịch vụ đó chạy dưới quyền root.

— Michael Hampton

Tôi chỉ có hiểu biết cơ bản về các chính sách của SELinux, nhưng rsync có nghĩa vụ truy cập hệ thống tập tin, phải không? Các kiểu truy cập (cục bộ) chính xác là không mong muốn nếu máy từ xa bị xâm phạm.

— goncalopp