Discussion :

[Louis Griffont]

Bonjour,

Voila, j'ai un PC sous Debian et un Serveur de fichiers... sous Debian également.

Je voudrais réaliser des sauvegardes du serveur sur ce PC !

Si je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

rsync -avr -e 'ssh' serveur:/dossier/ /mnt/svg_serveur/

dans un terminal, il me demande un mot de passe et après ça roule !

Si je place cette commande dans un cron (crontab -e) il ne se passe rien !

Quelqu'un peut m'expliquer ? Je commence sérieusement à me demander si Linux était la bonne solution !

[exodev]

Hello,

La réponse est dans ton message

dans un terminal, il me demande un mot de passe et après ça roule !

La tâche cron ne lancera pas de prompt pour le password, d'où l'échec

ce passage dans le man de rsync devrait t'intéresser :

Some modules on the remote daemon may require authentication. If so,
you will receive a password prompt when you connect. You can avoid the
password prompt by setting the environment variable RSYNC_PASSWORD to
the password you want to use or using the --password-file option. This
may be useful when scripting rsync.

WARNING: On some systems environment variables are visible to all
users. On those systems using --password-file is recommended.

[ericduval]

l'idée via ssh est d'utiliser un échange de clefs entre le serveur et le client
via les fichiers authorized_keys.

Recherche sur google authorized_keys
tu trouveras des tutoriels sur le sujet.

C'est très simple à mettre en oeuvre.

[chaval]

Bonjour,

En crontab, il faut aussi mettre le chemin complet vers les binaires rsync et ssh.
En effet, le PATH n'est pas défini lors des exécutions par Crontab

[Louis Griffont]

D'abord, merci pour toutes vos réponses.

Le RSYNC_PASSWORD ne marche pas, ni le --password-file, j'ai essayé !

Pour ce qui est des chemins, ils sont complets, pas de soucis de ce coté là !

Je vais donc me tourner vers les authorized_keys !

J'espère m'en sortir (j'suis pas doué sous Linux, c'est un autre monde pour moi ! )
Si j'ai d'autres soucis, je reviens vous voir !

Et je vous tiens au courant de mes aventures sur la banquise !

[Louis Griffont]

Bon, question concernant les authorized_keys .

Dans les divers faq et forums, les exemples parlent de "ssh-keygen -t dsa ou rsa ou rien !

Quelle est la différence et que dois-mettre ?

Autre point les versions de Debian ne sont pas identiques, est-ce que ça peut être une source de problème ?

[chaval]

Par défaut, l'algorithme doit être RSA.
Après, c'est un algorithme de chiffrage....

La compatibilité de ces modes de chiffrement n'est pas fonction de la distribution (version de debian) mais de tes serveurs SSH. Néanmoins, cela devrait être comptatible (ces deux algo étant implémentés depuis assez longtemps.

Aussi, n'oublie pas d'activer le mécanisme de clés partagées sur le serveur sur lequel tu veux t'authentifier automatiquement. Il faut décommenter la ligne contenant "authorized_keys" dans le fichier sshd.conf et redémarrer le démon sshd
(c'est désactivé par défaut sur les distributions debian)

[Louis Griffont]

Merci pour ces compléments d'informations...

Euh, comment on relance le daemon ?

[chaval]

la commande suivante suffit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/ssh restart

[Louis Griffont]

Merci.

Une question qui me trouble un peu.

Si je me place dans le dossier /etc/init.d et que je fait un ssh restart
j'ai un message du genre "

ssh restart : name or service not known

si je fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/etc/init.d/ssh restart

Ca fonctionne !

Pourquoi ?

[ericduval]

C'est une question de PATH

La variable PATH est définie dans ton environnement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $PATH

Quand tu lances une commande exécutables, le shell de ta ligne de commande recherche la commande que tu souhaites exécuter dans les répertoires se trouvant renseignés dans la variable PATH. Voila pour le principe.

Dans ton cas, je ne pense pas que la variable PATH contienne le chemin /etc/init.d, donc la commande ssh n'est pas trouvée dans /etc/init.d mais plutôt dans /usr/bin/ssh.

Pour vérifier essaye : type ssh

[Louis Griffont]

Exact c'est /usr/bin/ssh

Toutefois, en étant placé dans le dossier concerné, je pensais qu'il regardait d'abord là où il était, avant de chercher dans le path.

[ericduval]

Pour cela il faut que PATH contienne le caractère point.

export PATH=.:$PATH

Mais attention, ceci peut créer des effets indésirable, exemple,

sous unix il existe la commande 'test' très utilisée en développement shell, supposons
que tu nommes un de tes fichiers 'test', que se passe t-il ?

et dans ce cas export PATH=$PATH:. que se passe t-il ?

Il faut faire attention à la variable PATH, ce n'est pas une variable anodine.

[Louis Griffont]

Je rebondie sur d'autres questions concernant RSYNC.

1. Comment faire pour appliquer un user et un group spécifiques aux fichiers sur la destination ?
2. Comment exclure des dossiers de la source que je ne vaux pas sauvegarder ?

Merci d'avance

[ericduval]

Avec rsync tu peux faire :

man rsync

Reponse à 2 :
===========

utiliser --exclude, exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

--exclude '/**/cache/' --exclude 'CACHE/' --exclude '*http-bin*'

Reponse à 1 :
===========

--owner
--group
voir aussi --numeric-ids

Je te conseille de bien lire le man à ce sujet il y a quelques précisions
intéressantes.

[chaval]

export PATH=.:$PATH

Mais attention, ceci peut créer des effets indésirable, exemple,

Ca peut être plus qu'indésirable, ca peut aussi être assez dangereux. Une personne malintentionnée peut déposer des binaires ayant des noms de commandes "standard" comme ls, rm... et qui ont un comportement indésirable.

De plus, cela peut fortement complexifier l'écriture de scripts, qui n'auront pas du tout le même comportement en shell ou en crontab.
Attention, donc !

Si tu veux exécuter un script ou un binaire se trouvant dans le répertoire courant, je te conseille très fortement de prendra l'habitude de commencer ta commande par ./ par exemple, quand tu étais dans /etc/init.d, il falait exécuter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./ssh restart

./ permet de spécifier que tu veux utiliser le fichier se trouvant dans le répertoire courant ; et donc, ne pas chercher dans les chemins de $PATH

[Louis Griffont]

OK, j'ai compris pour le PATH ! Pas de soucis !

Le problème que j'ai ce matin, c'est que le cron de root ne s'est pas lancé, en si, il s'est lancé, mais les rsync n'ont pas peu avoir lieu ! Et pas à cause d'une syntaxe foireuse, mais parceque le dossier /home/root à disparu !
Résultat, pas de /home/root/.ssh et donc pas de clé ssh et donc pas de connexion au serveur !

Comment est-ce possible, et comment réparé ?
Ce truc devient un monstre !

[ericduval]

/home/root ou /root ?

Très souvent le "home directory" de l'utilisateur root est /root.

Tu peux le vérifier en regardant dans le fichier /etc/passwd :

grep "^root:" /etc/passwd | cut -f6 -d:

[Louis Griffont]

C'est bien /home/root
la ligne de commande du grep que tu m'as fourni donne d'ailleurs "/home/root"

Et ce dossier a été viré ! Comment ? Pourquoi ? Et surtout comment réparé ?

Merci pour ton aide

[Louis Griffont]

Bon, je vais créer une nouvelle discussion, car le probleme du dossier root ne concerne pas le rsync

Je ne met pas résolu car, j'ai toujours pas réussi à réaliser mes sauvegardes, mais pour le moment le probleme est du au /home/root qui a disparu !