rsync에 두 개의 리모컨을 사용할 수없는 이유는 무엇입니까? [닫은]


33

소스와 대상이 모두 원격 인 경우 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에 대한 이러한 특정 세부 정보를 아는 것이 좋습니다.


1
그것은 원격 목적지 rsyncd에 데이터를 보내는 원격 src rsyncd를 포함합니다. src 시스템으로 ssh하고 rsync를 호출하여이 문제를 해결할 수 있습니다.
Alex Holst

@ AlexHolst 나는 그것이 특정한 경우에는 효과가 없다고 생각합니다. 편집 참조
goncalopp

죄송합니다. 서버 결함 은 이론적 인 질문을 다루지 않습니다. 실제로 직면 한 문제에 대한 대답 만합니다. 자세한 내용은 FAQ 를 참조하십시오.
Chris S

2
죄송합니다 (변조 자). 이것은 흥미로운 흥미로운 질문입니다. 그 이유는 rdiff 알고리즘이 대칭이 될 수 없기 때문입니다. 더 큰 CPU 및 메모리 오버 헤드가 "활성"쪽에 있습니다. "수동"측은 모든 수정 된 파일의 모든 블록 (--block-size 매개 변수 참조)의 체크섬을 계산하고 다시 보내면됩니다. 이는 매우 작은 메모리 요구 사항으로 수행되며 대부분의 작업은 첫 번째 수준의 CPU 캐시에서 수행 할 수 있습니다. "활성"쪽은 현재 동일한 데이터 블록이있는 체크섬으로 검색해야합니다.
hynekcer

1
나는 이것이 질문 이라고 생각합니다 (정확하게이 질문이 있었기 때문에 여기에 있습니다). 닫는 이유는 가짜입니다. 나는 아직도 답을 알고 싶다!
reinierpost

답변:


8

원격 컴퓨터에 연결하여 연결을 시작하십시오. ssh 키를 사용하는 경우 에이전트 패스를 사용하여 인증을 관리 할 수 ​​있습니다.

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

이 명령은 remoteHostA에 로그온하여 거기서 rsync를 실행합니다.


3
보안 고려 사항이 몇 가지 있습니다. 편집 참조
goncalopp

3
또한 두 시스템간에 직접 액세스 권한이없는 경우 작동하지 않습니다. 직접 액세스 권한을 얻는 경우 보안 섹션에서 방화벽 규칙을 올바르게 구현하기 위해 2 주 동안 대기하는 경우 ...
Gert van den Berg

1
시나리오 : 서버 A에는 서버 B 및 C에 대한 키 기반 루트 액세스 권한이 있습니다. 둘 다에서 루트 액세스를 사용하여 B에서 C로 동기화하려고합니다. 그러나 B 또는 C가 서로에게 루트 액세스 권한을 갖기를 원하지 않습니다.
thomasrutter

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

이 작업을 수행하는 데 문제가 없습니다.


4
scp는 델타를 수행하지 않지만 AFAIK는이 경우 심하게 필요합니다. 내 편집에 대한 자세한 내용
goncalopp

4
Btw, scp는 호스트간에 프록시를 사용하려면 옵션 -3을 사용해야합니다.
alterpub

불행히도 scp에는 rsync의 중요한 기능이 없습니다 : 예 : 파일 시스템을 넘지 않는 옵션 (예 : 사용자 폴더에 마운트 된 네트워크 드라이브), 아카이브 모드 ( "기호 링크, 장치, 속성, 권한, 소유권 등이 보존 됨") 등 ...
요새

1

로 원격 파일 시스템 중 하나 (또는 ​​둘 다)를 마운트하여이 문제를 해결할 수 있습니다 sshfs. 그러면 rsync는 로컬 인 것처럼 처리합니다.

불행히도 이로 인해 파일 시스템이 마운트 된 머신에서 많은 대역폭을 사용하게 sshfs되므로 사용자와 세 번째 머신 사이에 대역폭이 많은 머신에서만이 작업을 수행하는 것이 좋습니다.

물론 이상적인 해결책은 기계가 서로 직접 대화하는 것입니다. 나는 그들이 왜 안되는 좋은 이유를 생각할 수 없습니다.


편집을 참조하십시오. 당신이 말하는 이유는 보안입니다. (루트) 두 시스템 중 하나가 손상되면 다른 시스템에 대한 파일 시스템 액세스로 이어지지 않아야합니다. 그러나 어쩌면 나는 이것을 잘못된 각도에서 공격하고 있으며 세 번째 기계를 포함하지 않는 해결책이 있습니다 ...
goncalopp

흠. 이러한 세부 사항을이 질문에 추가해야한다고 생각합니다. 근본 타협에 대해서는 실제로 SELinux를 사용해야합니다.
Michael Hampton

다른 사람이 특히 rsync 에서이 동작에 관심이있을 수 있기 때문에 이것을 남겨 두었습니다. 로컬로 실행중인 rsync가 두 경우 모두에서 동일한 동작 (특정 디렉토리에 대한 파일 시스템 액세스)을 갖는 경우, 어떤 시스템의 AFAIK, SELinux도 다른 시스템이 손상되었는지 알 수 없습니다.
goncalopp

SELinux의 작동 방식을 이해하고 있는지 잘 모르겠습니다. 요점은 서비스 (루트 된 서비스조차도)가 서비스가 루트로 실행 되더라도 명시 적으로 액세스가 허용되지 않은 것들에 액세스하는 것을 방지한다는 것입니다.
Michael Hampton

SELinux 정책에 대한 기본 지식 만 가지고 있지만 rsync 파일 시스템에 액세스해야합니까? 원격 시스템이 손상된 경우 정확히 동일한 종류의 (로컬) 액세스 패턴은 바람직하지 않습니다 .
goncalopp 2011
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.