Discussion :

[Casse-noisette]

Bonjour.

Auriez-vous une solution pour effectuer des commandes sur une machine distante (avec SSH) et garder cette session, afin de pouvoir alterner commandes locales et commandes distantes en gardant l'environnement distant et de façon efficace (cad sans recréer une connection ssh ou une session shell (BASH) distante car cela prend du temps) ?

Pour illustrer j'aimerais créer une fonction remoteExec() telle que :

Code :

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

1
2
3
4
5
6
7
 
#! /bin/bash
a=1
echo $a
remoteExec adresse-distante "a=2; echo $a"
echo $a
remoteExec adresse-distante "echo $a"

affiche :

Code :

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

1
2
3
4
5
 
1
2
1
2

Merci pour votre aide

[Glavio]

Pour lancer des commandes de ce type dans un script, je permet à l'utilisateur qui lance mon script de se connecter en ssh sans mot de passe à mon serveur, puis dans la commande passée en argument à ssh, je met le "&" afin de laisser la tâche s'exécuter en arrière fond.
Mon script se connecte donc toujours via ssh à chaque fois qu'il veux lancer une commande sur le serveur mais n'est pas obligé d'attendre la fin de l'execution de celle-ci.

[Casse-noisette]

Oui je connais le principe des jobs en arrière plan mais ce n'est pas ce que je veux ici.

J'aimerais que le client SSH soit deconnecté du terminal sur la machine locale mais reste en arrière plan pour pouvoir lancer des commandes locales puis ensuite pouvoir reconnecter le client SSH sur le terminal local afin d'executer d'autres commandes distantes, comme dans mon exemple.

[frp31]

alors il te faut simplement que le script local tourne normalement et chaque j'ai bien dit chaque execution distante etre appeléé par une session ssh unique .


par exemple

Code :

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

1
2
3
4
5
while ............ do
commande locale
ssh -l truc@machine 'commande distante &'
...
done

[Casse-noisette]

Merci de m'avoir répondu.

Oui justement c'est ce que je faisais avant mais ce que je cherche c'est quelque chose de plus efficace car chaque appel à ssh dure ~ 1 seconde (établissement de la connexion + initialisation du bash distant).
Donc quand j'ai des scripts que j'exécute souvent avec une vingtaine d'appels à ssh c'est un peu long !
Il faudrait garder la connexion à ssh et la mettre en arrière plan après chaque appel à remoteExec() pour ensuite pouvoir la raccrocher au terminal avec un nouvel appel à remoteExec() mais comment faire ? !

De plus j'aimerais garder l'environnement distant pour les prochains appels (comme dans mon exemple)

[Glavio]

A mon avis il faut que tu passe par un script sur ton serveur, qui sera lancé en ssh, qui exécute plusieurs commandes pendant que ton script initial, sur ton client, (qui a lancé le script sur le serveur via ssh) continue son job. Désolé de ne pas être plus utile mais sans savoir ce que tu veux vraiment faire, j'ai du mal à soumettre des idées

[JeitEmgie]

Pour peu que vous utilisiez OpenSSH version 4 ou supérieure :
ajouter à votre ~/.ssh/config file:

Code :

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

1
2
3
4
 
Host *
ControlMaster auto 
ControlPath /tmp/%r@%h:%p

réduira le temps de connexion de chaque commande ssh.

Si vous ne voulez pas que cela s'applique à toutes les connections SSH, mais seulement à un host particulier, remplacer * par le nom de cet host.

[Casse-noisette]

@JeitEmgie :
Oui j'ai déjà testé le multiplexage ssh avec ControlMaster mais c'est toujours très lent même si ca reste plus rapide que sans.
De plus je veux que l'environnement soit sauvé entre les différents appels distants.

@Glavio :
Tout est expliqué dans mon exemple.
Je veux faire de la programmation séquentielle (et non parallèle).
Une commande locale est exécutée, puis une distante (avec attachement à la console locale), puis une locale (avec attachement à la console locale), puis une distante (avec attachement à la console locale) ...
Le tout en gardant en mémoire les environnements local et distant.

J'ai trouvé une solution avec des clients et des serveurs mais maintenant le problème c'est, à partir d'un processus A, de pouvoir détacher un processus B de la console pour le rattacher ensuite à celle-ci.

- Le processus A envoit le signal SIGSTOP au processus B pour le détacher (le processus B est maintenant attaché à aucun terminal).
- J'ai trouver l'utilitaire "retty" pour le rattachement mais celui-ci ne fonctionne que sur un système 32 bits mais moi j'ai un système 64 bits


Connaissez-vous une alternative à "retty" qui fonctionne aussi sur un linux 64 bits ?

Merci

[JeitEmgie]

et 2 processus qui communiqueraient par un named pipe ?

[Casse-noisette]

Comment ça ?

Tu as un exemple ?

[Glavio]

Désolé, mais là je n'ai pas encore le niveau. Typiquement je ne vois pas du tout comment tu peux faire çà:

puis une distante (avec attachement à la console locale)

Je connais simplement les classiques "&", "fg" et "bg" pour manipuler les processus en arrière plan de l'environnement...
Je suis le thread, ça m'intéresse....

[Casse-noisette]

Y'a pas de mal. C'est sympa d'avoir voulu m'aider.
Je cherche la solution à ce problème depuis plus d'un mois !

[JeitEmgie]

Comment ça ?

Tu as un exemple ?

Code :

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

1
2
3
4
5
 
#!/bin/sh
# ssh_proxy.sh
 
tail -f $1 | ssh login@remote.server.com "cat | /bin/sh"

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#!/bin/sh
# mixed.sh interleaves local with remote bash commands
 
PIPE=/tmp/ssh_pipe
mkfifo $PIPE
./ssh_proxy.sh $PIPE &
 
echo "LOCAL ls"
ls
 
echo "REMOTE ls"
echo "ls" > $PIPE
 
rm $PIPE

évidemment il faut encore travailler sur la récupération des stdout et stderr des appels remote…

[Casse-noisette]

Pas mal l'idée du pipe local.
Mais justement tout le problème est de connecter stdin, stdout et stderr de ssh, à la console locale
Il faudrait que je puisse executer sur la machine distante :

Code :

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

echo 'x : ' ; read x; echo x = $x

et que sur la machine locale je vois "x : ", ensuite que je puisse entrer une valeur pour x, et ensuite que "x = laValeur" s'affiche.

[JeitEmgie]

Pas mal l'idée du pipe local.
Mais justement tout le problème est de connecter stdin, stdout et stderr de ssh, à la console locale
Il faudrait que je puisse executer sur la machine distante :

Code :

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

echo 'x : ' ; read x; echo x = $x

et que sur la machine locale je vois "x : ", ensuite que je puisse entrer une valeur pour x, et ensuite que "x = laValeur" s'affiche.

Çà n'a aucun sens de faire des read sur la machine distante pour que l'utilisateur de la machine locale soumette des paramètres. Si l'utilisateur local a des paramètres à entrer c'est la machine locale qui doit lui demander et éventuellement construire la commande remote en fonction des réponses.

Pendant que la machine remote va exécuter les commandes soumises, le script principal va continuer à avancer et donc les streams de sortie vont se mélanger.
De plus le fait de piper les commandes dans un shell remote limitera très fortement le type de commandes que l'on pourra faire exécuter par le remote : pas question de commande qui prennent le stdin comme source de données par exemple…

Soit vous avez un réel problème technique qui a une application pratique et vous posez clairement le problème à résoudre avec des "use cases " réalistes et donc pas des echo et des read…
soit vous jouez à résoudre une question stupide posée quand un cadre scolaire et dites le clairement (avec l'ensemble de l'énoncé) qu'on ne perde pas son temps à y deviner un sens et chercher une solution réaliste.

[Casse-noisette]

Ce n'est pas un problème scolaire.
Les "read" c'est pour avoir un exemple simple.
Ca à du sens si on réflechit bien. En effet on peut avoir besoin d'effectuer des appels à des programmes sur une machine distante qui lisent l'entrée standard pour récupérer des informations.
Le client openSSH lui même gère bien les entrées/sorties.

Ce que j'aimerais c'est créer un client ssh qui ne créé pas de nouvelle connexion et garde son environnement à chaque appel, ni plus ni moins.
Mais je crois que je vais laisser tomber l'idée pour l'instant.
Je pense que C est plus adapté que BASH pour ce genre de chose.

Merci de m'avoir aidé

[JeitEmgie]

Ce n'est pas un problème scolaire.
Les "read" c'est pour avoir un exemple simple.
Ca à du sens si on réflechit bien. En effet on peut avoir besoin d'effectuer des appels à des programmes sur une machine distante qui lisent l'entrée standard pour récupérer des informations.
Le client openSSH lui même gère bien les entrées/sorties.

des informations comme un stream, ce qui permet de faire des backups par exemple… oui…

Code :

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

1
2
 
tar … | ssh login@server "cat > backup.tar"

pas de l'interaction utilisateur…

mais çà ne marche plus si le stdin est déjà utiliser pour spécifier la commande à exécuter comme ci-dessus… à moins d'écrire son propre programme côté serveur…