Ayant récemment lu ici un sujet a propos de rsync, je me suis souvenu
que j'avais dans ma TODO list de configurer la sauvegarde de mon daily
PC sur un linux qui traine sur mon réseau (Linux que je viens de doter
d'un disque de 1 To, ça doit être pour ça que j'ai eu l'idée de le
remplir de sauvegardes).
Pour l'instant, je monte le home de ce "serveur" sur mon daily et
j'envoie la commande :
rsync -axvuzs --progress --stats "${origine}" "${destination}"
("${origine}" valant "/home/hugo/" et ${destination} valant
"/mnt/Dottore/home/hugo/" (les plus motardisés d'entre vous auront
peut-être deviné que mon serveur de sauvegarde a pour adresse
192.168.1.46))
M'est venu l'idée de vouloir effectuer cette sauvegarde sans monter via
NFS le répertoire du serveur et donc taper plutôt la commande :
rsync -e "ssh -p 8222" -axvuzs --progress --stats /home/hugo/ hugo@192.168.1.46:/home/hugo/
Seulement voilà...
Après avoir saisi mon mot de passe sur le serveur ssh, j'obtiens un:
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(176)
[sender=3.1.1]
Tout ça parce que le bash sur le serveur (que j'utiise pour m'y
connecter de temps à autre depuis une autre machine) a été configuré
pour afficher un prompt personnalisé avec aussi un fortune tiré des
élucubrations qui ne servent de signatures sur usenet.
Bref, même après lectures de la page man de ssh, de différents tutos sur
le net, je ne sais pas quelle option passer à ssh afin qu'il reste muet
(et donc "clean") et permette à rsync de faire son boulot.
Merci de vos avis.
--
> Ouais, bon, en même temps, je n'ai pas forcément envie de bosser dans
> l'informatique, là tout de suite. Si je n'ai jamais travaillé dans ce
> secteur, c'est qu'il y a une raison...
Bof, je te parle pas de travailler mais juste de toucher un salaire.
Je n'utilise pas bash mais le fichier /etc/skel/.bashrc de ma distribution contient : ---------------------------------------------------------------------- # If not running interactively, don't do anything [[ $- != *i* ]] && return alias ls='ls --color=auto' PS1='[ W]$ ' ---------------------------------------------------------------------- Ça me parait pas mal.
En effet c'est mieux que mon grep qui crée un nouveau processus. Après j'allais arguer que mon if avait l'avantage d'être compatible shell POSIX alors que [[ $- != *i* ]] est sans doute une basherie mais bon... une basherie dans un .bashrc c'est pas incohérent. ;)
case $- in *i*) ;; *) return ;; esac Je précise que ce n'est pas de moi. A utiliser dans un .profile, par exemple, pour un ksh, un ash, ou tout autre bourne shells. A plus, -- Bruno Ducrot A quoi ca sert que Ducrot hisse des carcasses ?
On 2017-06-11, Francois Lafont wrote:
On 06/12/2017 12:37 AM, Benoit Izac wrote:
Je n'utilise pas bash mais le fichier /etc/skel/.bashrc de ma
distribution contient :
----------------------------------------------------------------------
# If not running interactively, don't do anything
[[ $- != *i* ]] && return
alias ls='ls --color=auto'
PS1='[u@h W]$ '
----------------------------------------------------------------------
Ça me parait pas mal.
En effet c'est mieux que mon grep qui crée un nouveau processus.
Après j'allais arguer que mon if avait l'avantage d'être
compatible shell POSIX alors que [[ $- != *i* ]] est sans doute
une basherie mais bon... une basherie dans un .bashrc c'est pas
incohérent. ;)
case $- in
*i*) ;;
*) return ;;
esac
Je précise que ce n'est pas de moi. A utiliser dans un .profile, par
exemple, pour un ksh, un ash, ou tout autre bourne shells.
Je n'utilise pas bash mais le fichier /etc/skel/.bashrc de ma distribution contient : ---------------------------------------------------------------------- # If not running interactively, don't do anything [[ $- != *i* ]] && return alias ls='ls --color=auto' PS1='[ W]$ ' ---------------------------------------------------------------------- Ça me parait pas mal.
En effet c'est mieux que mon grep qui crée un nouveau processus. Après j'allais arguer que mon if avait l'avantage d'être compatible shell POSIX alors que [[ $- != *i* ]] est sans doute une basherie mais bon... une basherie dans un .bashrc c'est pas incohérent. ;)
case $- in *i*) ;; *) return ;; esac Je précise que ce n'est pas de moi. A utiliser dans un .profile, par exemple, pour un ksh, un ash, ou tout autre bourne shells. A plus, -- Bruno Ducrot A quoi ca sert que Ducrot hisse des carcasses ?
Nicolas George
Hugolino , dans le message , a écrit :
Dans ton message précédent, tu me disais que "ssh true" ne doit strictement rien afficher.
Pour être parfaitement exact, la demande de mot de passe de ssh ne fait pas partie de son affichage mais d'une procédure spéciale directement sur le terminal. On peut s'en convaincre avec : ssh machine echo Bonjour | rot13 -> « Bonjour » sera chiffré, mais pas la demande de mot de passe.
Comment un fichier .bashrc pourrait-il être buggué ?
Je ne sais pas, je n'utilise pas bash. Mais si tu penses que ce n'est pas possible, essaie de rajouter « exit 42 » au début.
Hugolino , dans le message
<slrnojr82i.ggp.hugolino@Minty.Rock-n-Roll.org>, a écrit :
Dans ton message précédent, tu me disais que "ssh hugo@192.168.1.46
true" ne doit strictement rien afficher.
Pour être parfaitement exact, la demande de mot de passe de ssh ne fait
pas partie de son affichage mais d'une procédure spéciale directement
sur le terminal. On peut s'en convaincre avec :
ssh machine echo Bonjour | rot13
-> « Bonjour » sera chiffré, mais pas la demande de mot de passe.
Comment un fichier .bashrc pourrait-il être buggué ?
Je ne sais pas, je n'utilise pas bash. Mais si tu penses que ce n'est
pas possible, essaie de rajouter « exit 42 » au début.
Dans ton message précédent, tu me disais que "ssh true" ne doit strictement rien afficher.
Pour être parfaitement exact, la demande de mot de passe de ssh ne fait pas partie de son affichage mais d'une procédure spéciale directement sur le terminal. On peut s'en convaincre avec : ssh machine echo Bonjour | rot13 -> « Bonjour » sera chiffré, mais pas la demande de mot de passe.
Comment un fichier .bashrc pourrait-il être buggué ?
Je ne sais pas, je n'utilise pas bash. Mais si tu penses que ce n'est pas possible, essaie de rajouter « exit 42 » au début.
