Pourquoi n'est-il pas possible d'utiliser deux télécommandes pour rsync? [fermé]

33

Lorsque les sources et les destinations sont distantes, rsync se plaint:

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-t-il un obstacle technique insurmontable empêchant rsync de le faire? Ou est-ce simplement un cas de non encore implémenté? Il semble relativement facile de créer un tampon local en mémoire qui assure le transfert entre deux télécommandes, contenant à la fois des hachages et des données.

MODIFIER

Étant donné que les gens font des suggestions tangentielles, j'ai posté une question distincte décrivant mon cas d'utilisation particulier. Ce sont deux choses distinctes, vraiment, et je pense qu'il serait intéressant de connaître ces détails particuliers pour rsync

rsync remote goncalopp
la source
1
Cela impliquerait qu'un rsyncd src distant envoie des données à un rsyncd distant. Vous pouvez contourner ce problème en vous connectant au système src et en appelant rsync.
Alex Holst
@ AlexHolst Je ne pense pas que cela fonctionnerait dans mon cas particulier. voir modifier
goncalopp
Désolé, Server Fault ne traite pas de questions théoriques. seulement des questions répondables sur les problèmes que vous rencontrez réellement. Voir la FAQ pour plus de détails.
Chris S
2
Désolé (modérateurs), c’est une question intéressante qui peut être posée: la raison en est que l’algorithme rdiff ne peut pas être symétrique. Une surcharge de processeur et de mémoire est plus importante du côté "actif". Le côté "passif" doit uniquement calculer les sommes de contrôle de tous les blocs (voir le paramètre --block-size) de tous les fichiers modifiés et les renvoyer. Cela se fait avec de très petites exigences en mémoire et la plupart des opérations peuvent être effectuées dans le cache de processeur de premier niveau. Le côté "actif" doit rechercher par une somme de contrôle où se trouve maintenant le même bloc de données ...
hynekcer
1
Je pense que c'est une excellente question (j'avais exactement cette question, c'est pourquoi je suis ici) et la dernière raison est fausse. Je veux toujours connaître la réponse!
reinierpost

Réponses:

8

pourquoi ne pas essayer de vous connecter à la machine distante et de lancer le transfert à partir de là. Si vous utilisez les clés ssh, vous pouvez utiliser le mot de passe agent pour gérer l'authentification pour vous.

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

Cette commande vous connectera sur le remoteHostA et lancera rsync à partir de là.

Kaplaa
la source
3
Il y a quelques considérations de sécurité impliquées. Voir edit
goncalopp
3
En outre, cela ne fonctionnera pas si vous n'avez pas d'accès direct entre les deux systèmes ... Et si obtenir un accès direct implique d'attendre deux semaines pour qu'une section de sécurité mette en œuvre correctement les règles de pare-feu ...
Gert van den Berg
1
Scénario: le serveur A dispose d'un accès racine basé sur une clé au serveur B et C. Vous souhaitez effectuer une synchronisation de B à C en utilisant un accès racine sur les deux. Mais vous ne voulez pas que B ou C aient un accès root les uns aux autres.
thomasrutter
5 
scp -3r <remote src> <remote dest>

n'a aucun problème à faire cela.

Karma Fusebox
la source
4
scp ne fait pas deltas cependant, autant que je sache, et il est absolument nécessaire dans ce cas. Plus de détails sur mon montage
goncalopp
4
Btw, scp doit être avec les options -3 si vous souhaitez être comme un proxy entre les hôtes
alterpub
Malheureusement, scp manque de fonctionnalités importantes de rsync, telles que: option pour ne pas traverser les systèmes de fichiers (lecteur réseau monté dans un dossier, par exemple), mode d’archivage (dans lequel "les liens symboliques, les périphériques, les attributs, les autorisations, les droits de propriété, etc.", etc.), etc. ...
Bastion le
1

Vous pouvez contourner ce problème en montant l'un des systèmes de fichiers distants (ou les deux) avec sshfs. Ensuite, rsync le traitera comme s'il s'agissait d'un local.

Malheureusement, cela entraînera une utilisation importante de la bande passante sur la machine sur laquelle le système de fichiers est monté sshfs, je vous recommande donc de ne le faire qu'avec la machine qui a beaucoup de bande passante entre vous et la troisième machine.

Bien entendu, la solution idéale est que les machines se parlent directement. Je ne peux pas penser à une bonne raison pour laquelle ils ne devraient pas.

Michael Hampton
la source
voir éditer. La raison pour laquelle vous parlez est la sécurité. Une compromission (racine) sur l’une des deux machines ne doit pas conduire à un accès du système de fichiers à l’autre. Mais peut-être que j'attaque ça du mauvais angle et qu'il y a une solution qui n'implique pas une troisième machine ...
goncalopp
Hmm. Je pense que ces détails devraient vraiment être ajoutés à cette question. En ce qui concerne un compromis racine, vous devriez vraiment utiliser SELinux.
Michael Hampton
J'ai quitté celui-ci car quelqu'un d'autre pourrait être intéressé par ce comportement sur rsync en particulier. Autant que je sache, SELinux sur l'une des machines ne peut pas dire si l'autre a été compromise si rsync s'exécutant localement a exactement le même comportement dans les deux cas (accès du système de fichiers à un répertoire particulier).
goncalopp
Je ne sais pas si vous comprenez comment fonctionne SELinux. Son objectif principal est d'empêcher un service (même compromis) d'accéder à des éléments auxquels il n'est pas explicitement autorisé à accéder, même si ce service est exécuté en tant que root.
Michael Hampton
Je n'ai qu'une compréhension de base des stratégies SELinux, mais rsync est supposé accéder au système de fichiers, n'est-ce pas? Le même type de modèle d'accès (local) n'est pas souhaitable si la machine distante est compromise.
Goncalopp