Discussion :

[Ceubex]

Bonjour,

J'ai besoin d'utiliser plink pour envoyer des commandes en SSH via Putty (je ne peux pas utiliser les librairies en SSH, il n'y a pas assez de flexibilité pour installer tout un serveur ou gérer des panneaux de configuration graphiques).
Ca marche parfaitement mais j'ai un soucis avec la gestion du Shell, en fait j'ai mis un commentaire dans le programme (//MON PROBLEME). Normalement je met Thread.sleep (1000); pour attendre que le programme affiche la sortie avant de lancer les prochaines commandes.

Le souci c'est que lors d'une installation serveur le temps que ça prend est très variable et qu'il faut que je le minimise. Il faudrait donc que je détecte quand ça me rend la main pour que je passe à la suite. Mais j'ai essayé toutes les commandes waitFor, wait, etc qui me passait par la tête et je ne trouve pas de solution à ce souci.

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
 
 
public class Console {
 
	private InputStream std;
	private OutputStream out;
	private InputStream err;
	Process p;
	Runtime r;
 
 
    private BufferedReader getOutput(Process p) {
        return new BufferedReader(new InputStreamReader(p.getInputStream()));
    }
 
    private BufferedReader getError(Process p) {
        return new BufferedReader(new InputStreamReader(p.getErrorStream()));
    }
 
	void commande(String commande) throws IOException, InterruptedException
	{
		commande(commande,false);
	}
 
	void commande(String commande,boolean cacherCommande) throws IOException, InterruptedException
	{
		out.write((commande+"\n").getBytes ());
	    out.flush();
 
        if(!cacherCommande) System.out.println ("< "+commande);
 
        //MON PROBLEME
        //p.waitFor();
	    //Thread.sleep (1000);
 
	    viderFlux() ;
	}
 
	void viderFlux() throws IOException
	{
	    int value = 0;
	    if (std.available () > 0) {
	        System.out.print("> ");
	        value = std.read ();
	        System.out.print ((char) value);
 
	        while (std.available () > 0) {
	            value = std.read ();
	            System.out.print ((char) value);
	        }
	    }
 
	    if (err.available () > 0) {
	        System.out.println ("ERREUR:");
	        value = err.read ();
	        System.out.print ((char) value);
 
	        while (err.available () > 0) {
	            value = err.read ();
	            System.out.print ((char) value);
	        }
	    }
	}
 
	void demarrer()
	{
		try {
			String adresseServeur="000.000.000.000";
 
		    String command = "plink "+adresseServeur;
 
		    r = Runtime.getRuntime ();
		    p = r.exec (command);
		    std = p.getInputStream ();
		    out = p.getOutputStream ();
		    err = p.getErrorStream ();
 
		    viderFlux();
 
 
		    commande("root");
		    commande("******");
 
 
		    p.destroy ();
		}
		catch (Exception e) {
		    e.printStackTrace ();
		}
	}
}

[tchize_]

y a pas d'avance, si tu veux attendre la fin de la commande, il faut regarder ce que tu reçois dans ton inputstream et répérer des messages clés qui t'indiquent que la commande est terminée. Piloter un shell à distance, c'est pas du genre facile Bref ton videflux va devoir être plus intelligent que ce que tu fais actuellement.

Le available() sur les flux, tu laisse tomber. C'est pas parce que available te retourne 0 que le programme à fini de l'autre coté. Ca veux juste dire que de ton coté t'as lu tout ce qu'il y avait dans la socket. Si ta connection est un peu lente et que tu lit plus vite que les packets n'arrivent, ton available va très souvent tomber à 0
Le Thread.sleep, mauvaise idée. Le fait de ne pas lire les flux pendant ce temps là peux remplir le buffer coté serveur et au final mettre le programme en attente sur le serveur. Pas cool.
waitFor ça attends que le procss (plink) aie complètement fini. Ca ne peut arriver que si la connexion ssh est coupée.


Ce que tu dois faire c'est lire tes flux en permanences avec des thread séparé et stocker les informations que tu y trouve, que ton programme de pilotage puisse savoir ce qui s'est passé et analyser la situation pour lancer les commandes suivantes...

[Ceubex]

OK ce que je pense faire c'est détecter effectivement un mot clé en lançant des commandes en ssh du type :

Code :

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

apt-get install machinTruc  && echo 'mot-clé'

Sinon pour les entrées genre le mot de passe je vais plutot faire une attente d'une seconde.

Mais ça me pose quand même un souci pour les interfaces graphiques. Par exemple après un apt-get install postfix, un panneau bleu apparait dans Putty pour séléctionner des options et on ne sait pas trop quand ça apparait, de plus il n'y a pas de possibilité de détecter un mot clé (à par peut être en interprétant le code graphique (mais c'est un truc bizarre encodé qui changera dès la première mise à jour).

Il y a vraiment aucun moyen de détecter quand on a à nouveau le curseur ?

[tchize_]

bon si c'est pour piloter une installation type debian / ubuntu à distance:

1) Il y a des options qu'on peux fournir à apt-get pour qu'il ne pose aucune question (mode non interactif quoi):

Code :

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

export DEBIAN_FRONTEND=noninteractive

et "assume-yes" dans les paramètres
2) Des outils comme puppet sont déjà prévu pour faire ce genre d'install controllée.
3) pour une install complète, ubuntu / debian fournissent déjà des outils d'install auto préconfigurée.


Pour le reste, tu peux lancer toutes tes commandes avec

Code :

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

commande && echo ==============fini || echo =================kaput

mais ça te sauvera pas si tu veux réagir avec de l'interactif

Pour le mot de passe, une clé ssh et plus de mot passe à donner, c'est plus simple pour du pilotage.