Почему невозможно использовать два пульта дистанционного управления для 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.

— Алекс Холст

@ AlexHolst Не думаю, что это сработает в моем конкретном случае. см. редактирование

— goncalopp

Извините, ошибка сервера не имеет отношения к теоретическим вопросам; только отвечающие вопросы о проблемах, с которыми вы действительно сталкиваетесь. Смотрите FAQ для более подробной информации.

— Крис С

Извините (модераторы), это интересный интересный вопрос: причина в том, что алгоритм rdiff не может быть симметричным. Большая загрузка ЦП и памяти находится на «активной» стороне. «Пассивная» сторона должна только вычислять контрольные суммы всех блоков (см. Параметр --block-size) всех измененных файлов и повторно отправлять их. Это делается при очень небольших требованиях к памяти, и большинство операций может выполняться в кэш-памяти ЦП первого уровня. «Активная» сторона должна искать по контрольным суммам, где сейчас находится один и тот же блок данных ...

— hynekcer

Я думаю, что это отличный вопрос (у меня был именно этот вопрос, поэтому я здесь), и причина закрытия - фальшивка. Я все еще хочу знать ответ!

— reinierpost

Ответы:

почему бы не попробовать подключиться к удаленной машине и начать передачу оттуда. Если вы используете ssh-ключи, вы можете использовать Agent Pass для управления аутентификацией за вас.

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

Эта команда зарегистрирует вас на remoteHostA и оттуда запустит rsync.

— Kaplaa
источник

Есть некоторые соображения безопасности. См редактировать

— goncalopp

Кроме того, это не сработает, если у вас нет прямого доступа между двумя системами ... А если для получения прямого доступа нужно подождать две недели, чтобы раздел безопасности, возможно, правильно реализовал правила брандмауэра ...

— Герт ван ден Берг,

Сценарий: Сервер A имеет корневой доступ на основе ключей к серверам B и C. Вы хотите синхронизировать данные от B до C, используя root-доступ на обоих. Но вы не хотите, чтобы B или C имели root-доступ друг к другу.

— Томасруттер

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

не имеет проблем с этим.

— Карма Fusebox
источник

Хотя scp не делает дельты, AFAIK, и в этом случае он крайне необходим. Более подробная информация о моем редактировании

— goncalopp

Кстати, scp должен быть с параметрами -3, если вы хотите быть как прокси между хостами

— alterpub

К сожалению, в scp отсутствуют важные функции rsync, например: возможность не пересекать файловые системы (например, сетевой диск, смонтированный в папке пользователя), режим архива (в котором «сохраняются символические ссылки, устройства, атрибуты, разрешения, владельцы и т. Д.») И т. Д. ...

— Бастион

Вы можете обойти это, смонтировав одну (или обе) из удаленных файловых систем sshfs. Затем rsync будет рассматривать его как локальный.

К сожалению, это приведет к значительному использованию полосы пропускания на машине, на которой смонтирована файловая система sshfs, поэтому я рекомендую делать это только на той машине, у которой есть большая полоса пропускания между вами и третьей машиной.

Конечно, идеальным решением для машин является непосредственное общение друг с другом. Я не могу придумать вескую причину, почему они не должны.

— Майкл Хэмптон
источник

см редактировать Причина, по которой вы говорите, это безопасность. (Корневой) компрометация любой из двух машин не должна приводить к доступу файловой системы к другой. Но, может быть, я атакую это с неправильной точки зрения, и есть решение, которое не включает третью машину ...

— goncalopp

Хм. Я думаю, что эти детали действительно должны быть добавлены к этому вопросу. Что касается корневого компромисса, вы действительно должны использовать SELinux.

— Майкл Хэмптон

Я оставил этот, потому что кто-то еще может быть заинтересован в этом поведении на rsync в частности. AFAIK, SELinux ни на одной из машин не может определить, была ли скомпрометирована другая, если локально выполняющийся rsync имеет одинаковое поведение в обоих случаях (доступ файловой системы к определенному каталогу).

— goncalopp

Я не уверен, что вы понимаете, как работает SELinux. Весь смысл в том, что он предотвращает доступ службы (даже скомпрометированной службы) к вещам, к которым у нее нет явного доступа, даже если эта служба запускается с правами root.

— Майкл Хэмптон

У меня есть только базовое понимание политики SELinux, но Rsync это предполагается доступ к файловой системе, не так ли? Точно такие же (локальные) шаблоны доступа нежелательны, если удаленный компьютер скомпрометирован.

— goncalopp