Demande d'aide sur rsync

will7991 · Février 21, 2016, 2:39pm

Salut à tous,

J’essaie de mettre en place un système de sauvegarde d’un serveur distant sur un serveur local via rsync.
Je considère comme source le serveur distant et la destination le serveur local.

A la mano, ça marche :

rsync -avz user@distant:/dossier_a_sauvegarder /dossier_de_sauvegarde

Je souhaite automatiser via cron, et j’ai donc passé en paramètre le fichier qui contient le mot de passe du user@distant :

rsync -avz user@distant:/dossier_a_sauvegarder /dossier_de_sauvegarde --password-file=/chemin/vers/.rsync_passwd

Or, j’ai comme erreur :

The --password-file option may only be used when acessing an rsync daemon

Quand je vérifie sur le distant, effectivement, dans /etc/default/rsync, j’ai

RSYNC_ENABLE=false

Je le passe donc à :

RSYNC_ENABLE=true

Et fais un :

/etc/init.d/rsync restart

Sauf que :

En relançant ma commande rsync, j’ai toujours la même erreur
Sur le serveur, je n’ai pas l’impression que le port 873 soit ouvert (netstat -an)
Je ne vois pas de processus rsync ou rsyncd (ps -waux|grep rsync ne me retourne rien)
Dans le fichier /etc/init.d/rsync, la variable RSYNC_ENABLE est à “false” --> Pourquoi donc est-elle forcée ici, alors qu’on la modifie dans /etc/default/rsync ?

Je ne vois pas où je me suis trompé ?
Du coup, je ne vois pas vers où concentrer mes recherches (!)

Si quelqu’un a des pistes…

Merci beaucoup !

Will

ed · Février 21, 2016, 2:39pm

RSYNC_PASSWORD est valable pour rsync en mode protocole RSYNC. (serveur rsyncd)

Pas en SSH, ce que vous semblez faire.

rsync peut fonctionner avec rsyncd, ou via ssh. Vous devez choisir quel système utiliser.

will7991 · Février 21, 2016, 2:39pm

Bonjour ed,

Merci pour la réponse.

J’en viens donc à mon problème “collatéral” : je n’arrive pas à faire fonctionner rsync en démon.

Que ce soit par /etc/init.d/rsync restart
Ou même un rsync --daemon

Je ne vois pas de rsyncd dans mes process.

Ce que j’ai du mal à comprendre, c’est qu’il faille modifier dans /etc/default/rsync la valeur de RSYNC_ENABLE mais que dans le /etc/init.d/rsync, RSYNC_ENABLE est mis à false…

etxeberrizahar · Février 21, 2016, 2:39pm

/etc/default/rsync

[quote]

Don’t forget to create an appropriate config file,

else the daemon will not start.[/quote]

/usr/share/doc/rsync/README.gz

Le manuel

$ man rsyncd.conf [code]
LAUNCHING THE RSYNC DAEMON
The rsync daemon is launched by specifying the --daemon option to rsync.

   The daemon must run with root privileges if you wish to use chroot, to bind to a port num‐
   bered under 1024 (as is the default 873), or to set file ownership.   Otherwise,  it  must
   just have permission to read and write the appropriate data, log, and lock files.

   You can launch it either via inetd, as a stand-alone daemon, or from an rsync client via a
   remote shell.  If run as a stand-alone daemon then just run the command  "rsync  --daemon"
   from a suitable startup script.

   When run via inetd you should add a line like this to /etc/services:

     rsync           873/tcp

   and a single line something like this to /etc/inetd.conf:

     rsync   stream  tcp     nowait  root   /usr/bin/rsync rsyncd --daemon

   Replace  "/usr/bin/rsync"  with the path to where you have rsync installed on your system.
   You will then need to send inetd a HUP signal to tell it to reread its config file. 

   Note that you should not send the rsync daemon a HUP signal to  force  it  to  reread  the
   rsyncd.conf file. The file is re-read on each client connection.[/code]

En résumé, d’après ces lectures, il faudrait créer /etc/rsyncd.conf.
Voir l’exemple /usr/share/doc/rsync/examples/rsyncd.conf

Pyc · Février 21, 2016, 2:39pm

Salut !

Allez, j’en rajoute une couche

C’est vrai que le fonctionnement de Rsync peut paraître étrange. Comme les autres te l’ont expliqué, cela est dû à son double mode de fonctionnement. Le premier, disons d’un usage « classique » (comme tu l’as fait avec ta première commande) est pour une utilisation ponctuelle, et à condition d’avoir les droits d’accès à la seconde machine. Le second est en mode serveur, pour mettre en place un système de sauvegardes automatisées, par exemple. Ces deux modes sont très différents. Disons que le deuxième mode de fonctionnement n’est pas une simple évolution du premier en mode serveur. Les différences sont plus profondes.

Dans le premier mode, c’est le client qui décide de ce qu’il va sauvegarder, et où dans l’arborescence de la seconde machine. Pour ce faire, l’utilisateur doit connaître l’arborescence de cette machine, et son nom d’utilisateur et mot de passe. Bref, en être l’administrateur (ou tout du moins avoir un compte utilisateur).

Dans le second mode, l’utilisateur ne peut pas choisir librement où est-ce qu’il peut sauvegarder. C’est le serveur qui défini des pool de sauvegardes, avec des droits d’accès plus précis. Dans ce cas, c’est l’administrateur du serveur de sauvegarde qui défini les chemins de sauvegardes, qui peuvent avoir des droits d’accès différents, et qui gère les différents droits de la multitude d’utilisateurs.

Le premier mode se base simplement sur SSH. Si tu as le droit et les permissions de te connecter par SSH sur la seconde machine, tu as le droit de faire du Rsync.

Dans le deuxième mode, le serveur Rsync possède son propre système d’identification et d’autorisation d’accès. La mise en place est plus complexe. Si c’est pour déployer un serveur de sauvegarde utilisé par plusieurs clients qui ont des droits différents et qui n’ont pas à connaître l’arborescence du serveur, c’est l’idéal. Pour une utilisation mono-utilisateur ponctuelle, peut-être moins.

Dans ton cas, c’est normal qu’il te redemande ton mot de passe bien que tu aies renseigné le fichier correspondant : tu as inscrits l’utilisateur et le mot de passe SSH alors que le serveur attend un utilisateur et mot de passe Rsync. Sans compter que le démon rsyncd ne tourne pas. Bref, il n’y a aucune raison que cela fonctionne.

Une solution simple à ton problème, à mon avis, et de continuer d’utiliser ta méthode initiale, mais après avoir échangé des clefs RSA entre tes deux machines afin de pouvoir te connecter par SSH, et donc Rsync, sans mot de passe. Ce qui simplifie l’automatisation de la tâche sans avoir à déployer un serveur Rsyncd. Par sécurité, l’utilisateur qui va se connecter au serveur pour opérer les sauvegardes pourrait avoir des droits SSH limités. Par exemple, avoir le droit de se connecter par SSH à la seconde machine, mais uniquement pour utiliser Rsync.

À voir si l’utilisation est en mode push (« pousser » les sauvegardes sur le serveur) ou pull (c’est le serveur qui vient « tirer » les sauvegardes à lui). Déterminer si ce sont les clients qui font les sauvegardes vers le serveur, ou le serveur qui vient les chercher sur les clients.

En espérant t’avoir aidé sans avoir raconté trop de conneries

will7991 · Février 21, 2016, 2:39pm

Merci à vous etxeberrizahar et Pyc pour vos explications.

Pour Pyc : je m’oriente vers ce que tu appelles “pull” (mon serveur de backup va chercher les données sur le serveur de prod).
Et mon but est de faire des sauvegardes fréquentes automatiquement.

Donc si je comprends bien, j’ai deux solutions :

Soit je configure le serveur de prod avec le démon rsync, son fichier de conf et sa propre liste d’utilisateur
Soit je continue sans démon rsync, mais en procédant à l’échange de clés pour une connexion SSH sans saisie de mot de passe

Quelle méthode est la plus “secure” ? Je pencherais pour la première, où j’activerai le serveur rsync uniquement sur une tranche horaire pour faire la sauvegarde.
Mais ce choix, je le fais seulement parce que je ne connais pas trop la mécanique des échanges de clés, et que l’idée de faire des connexions SSH sans authentification, ça me fait froid dans le dos Peut être ai-je tors…
Qu’en pensez vous ?

Merci !

ricardo · Février 21, 2016, 2:39pm

[quote=“will7991”]

Donc si je comprends bien, j’ai deux solutions :

Soit je configure le serveur de prod avec le démon rsync, son fichier de conf et sa propre liste d’utilisateur
Soit je continue sans démon rsync, mais en procédant à l’échange de clés pour une connexion SSH sans saisie de mot de passe

Quelle méthode est la plus “secure” ? Je pencherais pour la première, où j’activerai le serveur rsync uniquement sur une tranche horaire pour faire la sauvegarde.
Mais ce choix, je le fais seulement parce que je ne connais pas trop la mécanique des échanges de clés, et que l’idée de faire des connexions SSH sans authentification, ça me fait froid dans le dos Peut être ai-je tors…
Qu’en pensez vous ?

Merci ![/quote]
Le principe des jeux de clefs AVEC passphrase est de loin le plus sûr selon moi.
Et ce n’est pas compliqué à comprendre.
Si tu optes pour ce système, nous serons nombreux à pouvoir te conseiller.

will7991 · Février 21, 2016, 2:40pm

Salut à tous,

J’ai finalement opté pour la solution rsync en démon avec un fichier de configuration.

Ca marche très bien.

Je vais quand même me documenter sur les échanges de clés. Si le principe est simple (envoi de la clé publique de la machine locale vers le serveur), je préfère bien en faire le tour

Merci !

Will

ricardo · Février 21, 2016, 2:40pm

Un lien si tu veux :
http://doc.fedora-fr.org/wiki/SSH_:_Authentification_par_cl%C3%A9

Pyc · Février 21, 2016, 2:40pm

Salut !

@ will7991 : après, si l’idée est de mettre en place un véritable serveur de sauvegarde, tu peux aussi regarder du coté des solutions « faites pour » tel BackupPC (backuppc.sourceforge.net) qui utilise d’ailleurs rsync (entre autres possibilités) pour communiquer avec les clients à sauvegarder. BackupPC a l’avantage de posséder une interface web simple pour le configurer ainsi que pour surveiller l’état des sauvegardes et l’évolution de l’espace disque.

ricardo · Février 21, 2016, 2:40pm

Sauvegarder sur le web