Dlaczego nie można używać dwóch pilotów do rsync? [Zamknięte]

Gdy źródło i miejsce docelowe są zdalne, rsync narzeka:

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

Czy istnieje nie do pokonania przeszkoda techniczna, aby zmusić rsync do zrobienia tego? Czy jest to po prostu przypadek jeszcze nie wdrożony? Relatywnie łatwe jest utworzenie lokalnego bufora w pamięci, który pośredniczy w transferze między dwoma pilotami, przechowując zarówno skróty, jak i dane.

EDYTOWAĆ

Ponieważ ludzie przedstawiają pewne styczne sugestie, opublikowałem osobne pytanie szczegółowo opisujące mój konkretny przypadek użycia. Są to naprawdę dwa osobne i myślę, że warto poznać te szczegółowe informacje dotyczące rsync

rsync remote

— goncalopp
źródło

Wymagałoby to zdalnego zdalnego src rsyncd wysyłającego dane do zdalnego dest rsyncd. Możesz obejść ten problem, ssh'ing do systemu src i wywołując rsync.

— Alex Holst,

@AlexHolst Nie sądzę, aby to zadziałało w moim konkretnym przypadku. patrz edycja

— goncalopp,

Przepraszamy, awaria serwera nie dotyczy teoretycznych pytań; tylko odpowiedzi na pytania dotyczące problemów, które faktycznie napotykasz. Zobacz FAQ, aby uzyskać więcej informacji.

— Chris S

Przepraszamy (moderatorzy), jest to interesujące interesujące pytanie: Powodem jest to, że algorytm rdiff nie może być symetryczny. Większy narzut procesora i pamięci jest po „aktywnej” stronie. Strona „pasywna” musi tylko obliczyć sumy kontrolne wszystkich bloków (patrz parametr --block-size) wszystkich zmodyfikowanych plików i wysłać je ponownie. Odbywa się to przy bardzo małych wymaganiach dotyczących pamięci, a większość operacji można wykonać w pamięci podręcznej procesora pierwszego poziomu. Strona „aktywna” musi wyszukiwać według sum kontrolnych, w których znajduje się teraz ten sam blok danych ...

— hynekcer

Myślę, że to świetne pytanie (miałem dokładnie to pytanie, dlatego tu jestem), a końcowy powód jest fałszywy. Nadal chcę znać odpowiedź!

— reinierpost

Odpowiedzi:

dlaczego nie spróbować połączyć się ze zdalnym urządzeniem i rozpocząć transfer z tego miejsca. Jeśli używasz kluczy ssh, możesz jednak użyć hasła agenta do zarządzania uwierzytelnieniem.

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

To polecenie zaloguje cię do remoteHostA i uruchomi z tego rsync.

— Kaplaa
źródło

W grę wchodzą pewne względy bezpieczeństwa. Zobacz edycję

— goncalopp,

To też nie zadziała, jeśli nie będziesz mieć bezpośredniego dostępu między dwoma systemami ... A jeśli uzyskanie bezpośredniego dostępu wymaga odczekania dwóch tygodni, aż sekcja bezpieczeństwa może poprawnie wdrożyć reguły zapory ...

— Gert van den Berg

Scenariusz: serwer A ma oparty na kluczach dostęp do roota na serwerach B i C. Chcesz synchronizować z B do C, używając dostępu root na obu. Ale nie chcesz, aby B lub C miały dostęp do roota.

— thomasrutter,

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

nie ma z tym problemu.

— Karma Fusebox
źródło

scp nie robi jednak delt, AFAIK i jest w tym przypadku bardzo potrzebne. Więcej szczegółów na temat mojej edycji

— goncalopp,

Btw, scp musi być z opcjami -3, jeśli chcesz być jak serwer proxy między hostami

— alterpub

Niestety scp nie ma ważnych funkcji rsync, np .: opcji nieprzekazywania systemów plików (np. Dysk sieciowy zamontowany w folderze użytkownika), trybu archiwizacji (w którym zachowane są „dowiązania symboliczne, urządzenia, atrybuty, uprawnienia, prawa własności itp.”) Itp. ...

— Bastion

Można obejść ten problem, montując jeden (lub oba) zdalne systemy plików za pomocą sshfs. Następnie rsync potraktuje to tak, jakby było lokalne.

Niestety spowoduje to duże wykorzystanie przepustowości na komputerze, na którym zamontowany jest system plików sshfs, dlatego polecam robić to tylko na komputerze, który ma dużą przepustowość między tobą a trzecim komputerem.

Oczywiście idealnym rozwiązaniem jest bezpośrednie komunikowanie się maszyn. Nie mogę wymyślić żadnego dobrego powodu, dla którego mieliby tego nie robić.

— Michael Hampton
źródło

patrz edycja. Powodem, dla którego masz na myśli, jest bezpieczeństwo. Naruszenie (root) jednego z dwóch komputerów nie może prowadzić do dostępu systemu plików do drugiego. Ale może atakuję to pod niewłaściwym kątem i istnieje rozwiązanie, które nie wymaga trzeciej maszyny ...

— goncalopp,

Hmm Myślę, że te szczegóły naprawdę powinny zostać dodane do tego pytania. Jeśli chodzi o kompromis roota, naprawdę powinieneś używać SELinux.

— Michael Hampton

Zostawiłem to, ponieważ ktoś inny może być zainteresowany tym zachowaniem, szczególnie na rsync. AFAIK, SELinux na żadnym komputerze nie może stwierdzić, czy inny komputer został naruszony, jeśli lokalnie wykonujące się rsync zachowuje się dokładnie tak samo w obu przypadkach (dostęp systemu plików do określonego katalogu).

— goncalopp,

Nie jestem pewien, czy rozumiesz, jak działa SELinux. Chodzi o to, że uniemożliwia dostęp do usługi (nawet usługi z naruszeniem bezpieczeństwa) do rzeczy, do których nie ma wyraźnego pozwolenia, nawet jeśli ta usługa działa jako root.

— Michael Hampton

Mam tylko podstawową wiedzę na temat polityki SELinux, ale rsync jest ma dostęp do systemu plików, prawda? Dokładnie taki sam rodzaj (lokalnych) wzorców dostępu jest niepożądany w przypadku naruszenia bezpieczeństwa komputera zdalnego .

— goncalopp,