¿Por qué no es posible usar dos controles remotos para rsync? [cerrado]

Cuando tanto el origen como el destino son remotos, rsync se queja:

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

¿Existe un obstáculo técnico insuperable para que rsync haga esto? ¿O es simplemente un caso de aún no implementado? Parece relativamente fácil crear un búfer local en la memoria que media la transferencia entre dos controles remotos, que contiene tanto hashes como datos.

EDITAR

Como la gente hace algunas sugerencias tangenciales, publiqué una pregunta por separado que detalla mi caso de uso particular. Estos son dos por separado, realmente, y creo que valdría la pena conocer estos detalles particulares para rsync

rsync remote

— goncalopp
fuente

Implicaría que un src rsyncd remoto envíe datos a un rsyncd de destino remoto. Puede solucionarlo enviando ssh al sistema src e invocando rsync.

— Alex Holst

@AlexHolst No creo que eso funcione en mi caso particular. ver edición

— goncalopp

Lo sentimos, la falla del servidor no trata con preguntas teóricas; solo preguntas con respuesta sobre los problemas que realmente enfrenta. Vea las preguntas frecuentes para más detalles.

— Chris S

Lo sentimos (moderadores), esta es una pregunta interesante que se puede responder: la razón es que el algoritmo rdiff no puede ser simétrico. Una mayor sobrecarga de CPU y memoria está en el lado "activo". El lado "pasivo" solo necesita calcular sumas de verificación de todos los bloques (ver - parámetro de tamaño de bloque) de todos los archivos modificados y reenviarlos. Esto se realiza con requisitos de memoria muy pequeños y la mayoría de las operaciones se pueden realizar en el caché de CPU de primer nivel. La parte "activa" tiene que buscar por una suma de comprobación que se encuentra el mismo bloque de datos ahora ...

— hynekcer

Creo que esta es una gran pregunta (tenía exactamente esta pregunta, por eso estoy aquí) y la razón de cierre es falsa. ¡Todavía quiero saber la respuesta!

— reinierpost

Respuestas:

¿por qué no intentas conectarte a la máquina remota e iniciar la transferencia desde allí? Si está utilizando ssh-keys, puede usar el pase de agente para administrar la autenticación por usted.

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

Este comando lo registrará en remoteHostA y ejecutará rsync desde allí.

— Kaplaa
fuente

Hay algunas consideraciones de seguridad involucradas. Ver edición

— goncalopp

Además, eso no funcionará si no tiene acceso directo entre los dos sistemas ... Y si obtener acceso directo implica esperar dos semanas para que una sección de seguridad pueda implementar correctamente las reglas de firewall ...

— Gert van den Berg

Escenario: el servidor A tiene acceso raíz basado en claves al servidor B y C. Desea sincronizar de B a C utilizando el acceso raíz en ambos. Pero no desea que B o C tengan acceso raíz entre sí.

— thomasrutter

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

No tiene problemas para hacer esto.

— Karma Fusebox
fuente

scp no hace deltas, AFAIK, y es muy necesario en este caso. Más detalles sobre mi edición

— goncalopp

Por cierto, scp tiene que estar con las opciones -3 si desea ser como un proxy entre hosts

— alterpub

Desafortunadamente, scp carece de características importantes de rsync, por ejemplo: opción de no cruzar los sistemas de archivos (por ejemplo, unidad de red montada en la carpeta del usuario), modo de archivo (en el que se conservan "enlaces simbólicos, dispositivos, atributos, permisos, propiedades, etc."), etc. ...

— Bastión

Puede solucionar este problema montando uno (o ambos) de los sistemas de archivos remotos con sshfs. Entonces, rsync lo tratará como si fuera local.

Desafortunadamente, esto resultará en un gran uso de ancho de banda en la máquina cuyo sistema de archivos está montado sshfs, por lo que recomendaría hacerlo solo con la máquina que tiene mucho ancho de banda entre usted y la tercera máquina.

Por supuesto, la solución ideal es que las máquinas se comuniquen directamente entre sí. No se me ocurre ninguna buena razón por la que no deberían hacerlo.

— Michael Hampton
fuente

ver editar La razón a la que te refieres es la seguridad. Un compromiso (raíz) de cualquiera de las dos máquinas no debe conducir al acceso del sistema de archivos a la otra. Pero tal vez estoy atacando a esto desde el ángulo equivocado y no hay una solución que no implique una tercera máquina ...

— goncalopp

Hmm Creo que esos detalles realmente deberían agregarse a esta pregunta. En cuanto a un compromiso de raíz, realmente debería usar SELinux.

— Michael Hampton

Dejé este porque alguien más puede estar interesado en este comportamiento en particular en rsync. AFAIK, SELinux en cualquiera de las máquinas no puede decir si la otra ha sido comprometida si el rsync que se ejecuta localmente tiene el mismo comportamiento exacto en ambos casos (acceso del sistema de archivos a un directorio en particular).

— goncalopp

No estoy seguro si entiendes cómo funciona SELinux. Todo su punto es que evita que un servicio (incluso un servicio comprometido) acceda a cosas a las que no tiene acceso explícito, incluso si ese servicio se ejecuta como root.

— Michael Hampton

Solo tengo una comprensión básica de las políticas de SELinux, pero se supone que rsync tiene acceso al sistema de archivos, ¿no es así? No se desea exactamente el mismo tipo de patrones de acceso (local) si la máquina remota se ve comprometida.

— goncalopp