sur un serveur auquel j'accède par ssh, j'aimerais pouvoir transférer
des fichiers par scp, est-ce possible ?
je veux dire, depuis le client je lance un script sur le serveur par ssh
lequel script renverrait des fichiers et dossiers par scp.
bon, des deux côtés la connection se fait sans passphrase, elle est
exigée au login (ssh-askpass).
mais il y a, peut-être un pb d'user. des deux côtés, c'est le même user
MAIS je ne suis pas sûr du tout que le script sur le server tourne sous
le même user vu qu'il est commandé par ssh. (?)
J'ai cru comprendre qu'il voulait lancer un script sur une machine distante, afin que celle-ci construise une liste de fichiers et renvoie ces fichiers sur la machine locale.
Un truc relativement aisé à scripter sur http, non ?
c'est en partie ça. en fait, mon script distant lit des pages html et les reproduit en local après filtrage du contenu (le filtrage est la partie la plus importante du script) son boulot terminé s'il est lancé par ssh il envoie les URLs locale au client distant.
en prime il enverra les paths des fichiers téléchargés afin de pouvoir reproduire la structure localement, c'est pour avoir ces fichiers quand je ne suis pas connecté depuis mon portable.
avant je faisais un rsync, via ssh, de temps en temps. là c'est fait au fur et à mesure.
MAIS j'ai un p'tit problème à régler encore.
quand je fais du rsync depuis l'iMac, ça roule par contre depuis ubuntu, j'ai des problèmes de transcodage des noms de fichiers : sur iMac c'est UTF8-MAC sur Ubuntu c'est UTF-8
et, malheureusement (en tout cas sur 12.04) iconv côté Ubuntu ne sait pas, amha, transcoder entre UTF8-MAC et UTF-8, ce que sait faire iconv sur iMac.
ce que ça fait sur le plan pratique : si j'ai un nom de fichier accentué (ce que j'évite) par ex : cachée.html côté iMac ça me donne sur ubuntu : cacheé.html l'accent aigu est déplacé au caractère suivant...
Le 18/11/2012 16:16, Tonton Th a écrit :
J'ai cru comprendre qu'il voulait lancer un script sur une
machine distante, afin que celle-ci construise une liste de
fichiers et renvoie ces fichiers sur la machine locale.
Un truc relativement aisé à scripter sur http, non ?
c'est en partie ça.
en fait, mon script distant lit des pages html et les reproduit en local
après filtrage du contenu (le filtrage est la partie la plus importante
du script) son boulot terminé s'il est lancé par ssh il envoie les URLs
locale au client distant.
en prime il enverra les paths des fichiers téléchargés afin de pouvoir
reproduire la structure localement, c'est pour avoir ces fichiers quand
je ne suis pas connecté depuis mon portable.
avant je faisais un rsync, via ssh, de temps en temps.
là c'est fait au fur et à mesure.
MAIS j'ai un p'tit problème à régler encore.
quand je fais du rsync depuis l'iMac, ça roule
par contre depuis ubuntu, j'ai des problèmes de transcodage des noms de
fichiers :
sur iMac c'est UTF8-MAC
sur Ubuntu c'est UTF-8
et, malheureusement (en tout cas sur 12.04) iconv côté Ubuntu ne sait
pas, amha, transcoder entre UTF8-MAC et UTF-8, ce que sait faire iconv
sur iMac.
ce que ça fait sur le plan pratique : si j'ai un nom de fichier accentué
(ce que j'évite) par ex :
cachée.html côté iMac
ça me donne sur ubuntu :
cacheé.html
l'accent aigu est déplacé au caractère suivant...
J'ai cru comprendre qu'il voulait lancer un script sur une machine distante, afin que celle-ci construise une liste de fichiers et renvoie ces fichiers sur la machine locale.
Un truc relativement aisé à scripter sur http, non ?
c'est en partie ça. en fait, mon script distant lit des pages html et les reproduit en local après filtrage du contenu (le filtrage est la partie la plus importante du script) son boulot terminé s'il est lancé par ssh il envoie les URLs locale au client distant.
en prime il enverra les paths des fichiers téléchargés afin de pouvoir reproduire la structure localement, c'est pour avoir ces fichiers quand je ne suis pas connecté depuis mon portable.
avant je faisais un rsync, via ssh, de temps en temps. là c'est fait au fur et à mesure.
MAIS j'ai un p'tit problème à régler encore.
quand je fais du rsync depuis l'iMac, ça roule par contre depuis ubuntu, j'ai des problèmes de transcodage des noms de fichiers : sur iMac c'est UTF8-MAC sur Ubuntu c'est UTF-8
et, malheureusement (en tout cas sur 12.04) iconv côté Ubuntu ne sait pas, amha, transcoder entre UTF8-MAC et UTF-8, ce que sait faire iconv sur iMac.
ce que ça fait sur le plan pratique : si j'ai un nom de fichier accentué (ce que j'évite) par ex : cachée.html côté iMac ça me donne sur ubuntu : cacheé.html l'accent aigu est déplacé au caractère suivant...
Arnaud Gomes-do-Vale
Une Bévue writes:
ssh iMac '${RMT_SCRIPT}'
M'étonnerait fort que la variable soit substituée entre guilemets simples.
-- Arnaud http://blogs.glou.org/arnaud/
Une Bévue <unbewusst.sein@fai.invalid> writes:
ssh iMac '${RMT_SCRIPT}'
M'étonnerait fort que la variable soit substituée entre guilemets
simples.
M'étonnerait fort que la variable soit substituée entre guilemets simples.
-- Arnaud http://blogs.glou.org/arnaud/
Une Bévue
Le 18/11/12 15:34, Nicolas George a écrit :
Préférer $(...) à `...`.
Ah bon, pourquoi ?
> ${SRV} "zsh --login -c ${RMT_SCRIPT}" | tee $TTY |
S'il y a besoin de ce --login, c'est signe que les scripts d'initialisation sur le serveur sont foireux. C'est d'autant plus dommage que zsh a la particularité, contrairement à bash par exemple, de proposer exactement le bon découpage des script d'initialisation.
oui sans doute je n'ai pas passé assez de temps là-dessus. malheureusement, je ne me souviens même plus pourquoi j'ai du ajouter "--login -c" et même "zsh --login -c " parce que le script distant (ie. ${RMT_SCRIPT}) est en ruby.
>grep -A 1 "TODO :" | tail -n 1 `)
C'est vraiment très fragile.
ben en tout cas ça fait des mois que ça fonctionne très bien, je l'utilise 4 fois par jour ouvrable. c'est vrai qu'à la place de "TODO :" j'aurais pu mettre une clé plus sioux, bonne remarque. le "tail -n 1" n'est pas fragile lui, côté server j'envoie plusieurs "n" avant TODO.
bon là j'étais en zsh, maintenant pour gérer les commandes scp je vai passer en ruby, c'est plus souple.
Le 18/11/12 15:34, Nicolas George a écrit :
Préférer $(...) à `...`.
Ah bon, pourquoi ?
> ${SRV} "zsh --login -c ${RMT_SCRIPT}" | tee $TTY |
S'il y a besoin de ce --login, c'est signe que les scripts d'initialisation
sur le serveur sont foireux. C'est d'autant plus dommage que zsh a la
particularité, contrairement à bash par exemple, de proposer exactement le
bon découpage des script d'initialisation.
oui sans doute je n'ai pas passé assez de temps là-dessus.
malheureusement, je ne me souviens même plus pourquoi j'ai du ajouter
"--login -c" et même "zsh --login -c " parce que le script distant (ie.
${RMT_SCRIPT}) est en ruby.
>grep -A 1 "TODO :" | tail -n 1 `)
C'est vraiment très fragile.
ben en tout cas ça fait des mois que ça fonctionne très bien, je
l'utilise 4 fois par jour ouvrable.
c'est vrai qu'à la place de "TODO :" j'aurais pu mettre une clé plus
sioux, bonne remarque.
le "tail -n 1" n'est pas fragile lui, côté server j'envoie plusieurs
"n" avant TODO.
bon là j'étais en zsh, maintenant pour gérer les commandes scp je vai
passer en ruby, c'est plus souple.
> ${SRV} "zsh --login -c ${RMT_SCRIPT}" | tee $TTY |
S'il y a besoin de ce --login, c'est signe que les scripts d'initialisation sur le serveur sont foireux. C'est d'autant plus dommage que zsh a la particularité, contrairement à bash par exemple, de proposer exactement le bon découpage des script d'initialisation.
oui sans doute je n'ai pas passé assez de temps là-dessus. malheureusement, je ne me souviens même plus pourquoi j'ai du ajouter "--login -c" et même "zsh --login -c " parce que le script distant (ie. ${RMT_SCRIPT}) est en ruby.
>grep -A 1 "TODO :" | tail -n 1 `)
C'est vraiment très fragile.
ben en tout cas ça fait des mois que ça fonctionne très bien, je l'utilise 4 fois par jour ouvrable. c'est vrai qu'à la place de "TODO :" j'aurais pu mettre une clé plus sioux, bonne remarque. le "tail -n 1" n'est pas fragile lui, côté server j'envoie plusieurs "n" avant TODO.
bon là j'étais en zsh, maintenant pour gérer les commandes scp je vai passer en ruby, c'est plus souple.
Une Bévue
Le 18/11/12 22:10, Arnaud Gomes-do-Vale a écrit :
>ssh iMac '${RMT_SCRIPT}'
M'étonnerait fort que la variable soit substituée entre guilemets simples.
Ah là ! Il est fort possible qu'en m'énervant j'ai mis un truc pareil, effectivement avec ça ça ne pouvait pas marcher, m'enfin c'était un truc "transitoire". Malheureusement je suis étourdi je fais souvent des erreurs comme ça...
Le 18/11/12 22:10, Arnaud Gomes-do-Vale a écrit :
>ssh iMac '${RMT_SCRIPT}'
M'étonnerait fort que la variable soit substituée entre guilemets
simples.
Ah là !
Il est fort possible qu'en m'énervant j'ai mis un truc pareil,
effectivement avec ça ça ne pouvait pas marcher, m'enfin c'était un truc
"transitoire".
Malheureusement je suis étourdi je fais souvent des erreurs comme ça...
M'étonnerait fort que la variable soit substituée entre guilemets simples.
Ah là ! Il est fort possible qu'en m'énervant j'ai mis un truc pareil, effectivement avec ça ça ne pouvait pas marcher, m'enfin c'était un truc "transitoire". Malheureusement je suis étourdi je fais souvent des erreurs comme ça...
Nicolas George
Une Bévue , dans le message <50a9d249$0$2292$, a écrit :
Préférer $(...) à `...`.
Ah bon, pourquoi ?
Parce que l'emboîtement de différents guillemets et caractères d'échappement est infiniment plus simple.
oui sans doute je n'ai pas passé assez de temps là-dessus.
Tu devrais. Garder un bug comme celui-là te fera perdre du temps sur le long terme. Mieux vaut passer du temps pour corriger ça quand tu as du temps disponible que de te retrouver bloqué quand tu n'en as pas.
ben en tout cas ça fait des mois que ça fonctionne très bien, je l'utilise 4 fois par jour ouvrable.
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils cassent, et ça peut faire des dégâts.
Une Bévue , dans le message <50a9d249$0$2292$426a34cc@news.free.fr>, a
écrit :
Préférer $(...) à `...`.
Ah bon, pourquoi ?
Parce que l'emboîtement de différents guillemets et caractères d'échappement
est infiniment plus simple.
oui sans doute je n'ai pas passé assez de temps là-dessus.
Tu devrais. Garder un bug comme celui-là te fera perdre du temps sur le long
terme. Mieux vaut passer du temps pour corriger ça quand tu as du temps
disponible que de te retrouver bloqué quand tu n'en as pas.
ben en tout cas ça fait des mois que ça fonctionne très bien, je
l'utilise 4 fois par jour ouvrable.
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils
cassent, et ça peut faire des dégâts.
Une Bévue , dans le message <50a9d249$0$2292$, a écrit :
Préférer $(...) à `...`.
Ah bon, pourquoi ?
Parce que l'emboîtement de différents guillemets et caractères d'échappement est infiniment plus simple.
oui sans doute je n'ai pas passé assez de temps là-dessus.
Tu devrais. Garder un bug comme celui-là te fera perdre du temps sur le long terme. Mieux vaut passer du temps pour corriger ça quand tu as du temps disponible que de te retrouver bloqué quand tu n'en as pas.
ben en tout cas ça fait des mois que ça fonctionne très bien, je l'utilise 4 fois par jour ouvrable.
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils cassent, et ça peut faire des dégâts.
Luc.Habert.00__arjf
Une Bévue :
sur un serveur auquel j'accède par ssh, j'aimerais pouvoir transférer des fichiers par scp, est-ce possible ?
je veux dire, depuis le client je lance un script sur le serveur par ssh lequel script renverrait des fichiers et dossiers par scp.
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si le client est derrière un nat...).
Une Bévue :
sur un serveur auquel j'accède par ssh, j'aimerais pouvoir transférer
des fichiers par scp, est-ce possible ?
je veux dire, depuis le client je lance un script sur le serveur par ssh
lequel script renverrait des fichiers et dossiers par scp.
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le
client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si
le client est derrière un nat...).
sur un serveur auquel j'accède par ssh, j'aimerais pouvoir transférer des fichiers par scp, est-ce possible ?
je veux dire, depuis le client je lance un script sur le serveur par ssh lequel script renverrait des fichiers et dossiers par scp.
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si le client est derrière un nat...).
Une Bévue
Le 20/11/2012 19:49, Nicolas George a écrit :
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils cassent, et ça peut faire des dégâts.
je suis tellement conscient de ça, que j'ai changé ma sortie, j'envoie un fichier xml disant ce qu'il y a à faire, le fichier comporte un uuid comme clé.
Le 20/11/2012 19:49, Nicolas George a écrit :
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils
cassent, et ça peut faire des dégâts.
je suis tellement conscient de ça, que j'ai changé ma sortie, j'envoie
un fichier xml disant ce qu'il y a à faire, le fichier comporte un uuid
comme clé.
Oh oui, les trucs fragiles peuvent très bien marcher. Et puis un jour, ils cassent, et ça peut faire des dégâts.
je suis tellement conscient de ça, que j'ai changé ma sortie, j'envoie un fichier xml disant ce qu'il y a à faire, le fichier comporte un uuid comme clé.
Une Bévue
Le 20/11/2012 20:00, Luc Habert a écrit :
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si le client est derrière un nat...).
Bon, merci beaucoup, c'est une très bonne idée.
Pourquoi ?
j'ai essayé une bonne dizaine de fois mon système : - màj distante de la bd locale ; - envoi d'un fichier xml décrivant les scp à faire en local ; - le script local exécute ces scp.
ça marche "très" bien excepté le fait que ça ne gère pas les déconnections intempestives du WiFi, et comme ya 2 ordis, sur une douzaine d'essais j'ai eu deux pépins.
avec tar, je fais ça quand je veux, càd surtout quand je sais que ma connection est OK
Le 20/11/2012 20:00, Luc Habert a écrit :
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le
client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si
le client est derrière un nat...).
Bon, merci beaucoup, c'est une très bonne idée.
Pourquoi ?
j'ai essayé une bonne dizaine de fois mon système :
- màj distante de la bd locale ;
- envoi d'un fichier xml décrivant les scp à faire en local ;
- le script local exécute ces scp.
ça marche "très" bien excepté le fait que ça ne gère pas les
déconnections intempestives du WiFi, et comme ya 2 ordis, sur une
douzaine d'essais j'ai eu deux pépins.
avec tar, je fais ça quand je veux, càd surtout quand je sais que ma
connection est OK
C'est un peu limité, mais est-ce que tu ne pourrais pas faire, depuis le client:
ssh serveur 'quelque chose qui pond un tarball sur son stdout' | tar xf -
Ça évite les emmerdes de multiplier les connexions ssh (ne serait ce que si le client est derrière un nat...).
Bon, merci beaucoup, c'est une très bonne idée.
Pourquoi ?
j'ai essayé une bonne dizaine de fois mon système : - màj distante de la bd locale ; - envoi d'un fichier xml décrivant les scp à faire en local ; - le script local exécute ces scp.
ça marche "très" bien excepté le fait que ça ne gère pas les déconnections intempestives du WiFi, et comme ya 2 ordis, sur une douzaine d'essais j'ai eu deux pépins.
avec tar, je fais ça quand je veux, càd surtout quand je sais que ma connection est OK
