Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 04/12/2015, à 16:34

jeffhamel

[RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Bonjour à tous

Une question qui a déjà du être rabâchée, mais pour laquelle je n'ai pas trouvé de réponses / compris les réponses apportées / été capable de mettre en œuvre les réponses proposées (choisissez la réponse la plus adaptée!)

Je veux pouvoir prendre contrôle d'une machine (qui ne sert qu'à du calcul) via mon laptop. L'idée est simple, n'avoir qu'un seul ordinateur devant moi, et pouvoir contrôler l'autre / regarder les résultats / donner des instructions à un autre ordinateur, sans nécessairement avoir besoin d'un écran spécifique, d'un clavier, etc...

Utilisation de gitso pour un bureau à distance -> ok, ça marche si le client et le serveur sont sur le réseau.
Sauf que pour que ca marche, il faut que j'indique l'adresse ip de l'ordi client sur l'ordi serveur. Et que mon laptop (le client) est connecté au réseau via DHCP, ce que je peux difficilement changer (je suis clairement pas responsable du reseau, je suis juste dans un bureau...)
Ca m'arrange pas, parce-que si mon ip change, il faudra l'indiquer sur l'ordi serveur, et que celui-ci n'a pas de clavier ni d'écran (c'est l'idée, simplifier tout, qu'il ne soit contrôlé qu'à distance)

L'idée de scanner le réseau de façon automatique par l'ordi serveur avecr nmap pourrait être envisagée, mais faire un scan de réseau sur un resau professionnel quand je suis pas propriétaire du réseau, mouais, et puis j'arriverai pas à déterminer quel ordi est le mien, et quels adresses ip ne sont pas les miennes

J'ai bien essayé un truc du genre :

sudo ifconfig eth0 10.0.0.1 netmask 255.255.255.0

pour avoir une ip fixe le temps de la connexion, mais ça marche pas. Seule l'adresse ip proposée par le DHCP est reconnue (pas celle que je propose, ici 10.0.0.1).

Je me suis dis que pas grave, pas la peine de passer par le réseau de la boite, j'ai qu'à faire un réseau local. Un cable ethernet entre le client et le serveur, et ca devrait marcher.

Bon, l'idée est bonne, mais j'arrive pas à avoir un réseau local entre mon laptop et l'ordi de calcul, et en plus etre connecté via DHCP au réseau de la boite. (Je ne dois pas avoir compris comment mettre en place un réseau local, quand j'ai essayé de suivre la doc ubuntu, j'ai juste réussi à ne plus avoir de réseau du tout...)

Si quelqu'un pouvait m'expliquer comment mettre en place ce réseau local? quand j'édite le fichier /etc/network/interfaces, tout ce que j'arrive à faire, c'est à ne plus avoir de réseau

(mon fichier /etc/network/interfaces actuel est:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

La modification que j'ai voulu faire était pourtant simple :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.0.0.1
netmask 255.255.255.0

Pour info, si ça peut servir, je suis sous Xfce et je gérais ma connexion réseau via un truc graphique, le truc en haut à gauche sur la barre des taches, je sais même pas comment ça s'appelle, c'est rangé dans la zone de notification de la barre des taches Xfce, bref un truc graphique qui marche pas mal. J'ai bien essayé d'imposer une adresse ip fixe sur la connexion filaire via cette interface, mais ça marche pas non plus?

Merci à tous pour votre aide prochaine!

A+, JF

Dernière modification par jeffhamel (Le 01/07/2016, à 13:53)

Hors ligne

#2 Le 04/12/2015, à 21:06

krodelabestiole

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

c'est pas très clair...
la machine distante, tu peux lui attribuer une ip fixe oui ou non ?

sudo ifconfig eth0 10.0.0.1 netmask 255.255.255.0

tu sors cette ip d'où ? à titre d'information, c'est quoi l'ip de ta machine ? et celle de ton routeur ? l'idéal serait de connaitre la plage des ip attribuées en dhcp et de lui en mettre une en dehors.

jitsi c'est plutôt un client de messagerie ça me parait loin d'être l'idéal pour faire ce que tu veux, à mon avis tu ferais mieux d'utiiser un vnc ou encore mieux, un x2go si tu peux

Hors ligne

#3 Le 04/12/2015, à 21:09

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Bonjour,
le plus dur est de bien expliquer le but autant que les raisons :
quelques indications :
Applications à travers un réseau ssh :
une application est en cours sur un serveur mais affichée sur un client

ssh -X NomUtilisateur@IPServeur

pour bien comprendre prenons VLC
une fois connecté si on lance "vlc", celui ci s'affichera sur le client mais le son sortira des enceintes du serveur
si le client plante ou est déconnecté, tout s'arrête à moins de lancer l'application comme service.
le bureau à distance ou prise de contrôle à distance :
bien que différents les deux solutions arrivent au même résultat (presque)
là on a une panoplie de logiciels et protocole tout est expliqué dans les docs
VNC

X11VNC
je me garde ça sous la main pour l'utilisation :
sur le serveur
installation

sudo apt-get install x11vnc

mettre ou changer le mot de passe

x11vnc -storepasswd "UnMotDePasse" ~/.vnc_passwd

lancer le service ponctuellement

x11vnc -many -rfbauth ~/.vnc_passwd

ou

x11vnc -ncache 10 -many -rfbauth ~/.vnc_passwd

et sur le client, un client comme Remmina

X2go fait aussi très bien le job même en client sur du X11vnc

voilà une première piste

Hors ligne

#4 Le 05/12/2015, à 12:45

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Bonjour à vous, et merci pour les réponses.

Tout d'abord, mille pardons, j'ai écrit gitsi, c'est gitso qu'il fallait écrire. Gitso est bien un visioneur de bureau distant via VNC, pardon pour la coquille.

J'ai besoin d'attribuer une ip fixe uniquement sur le client, a prioori avec gitso, il n'y a que sur le serveur qu'il faut indiquer l'adresse ip du client, pas la peine d'écrire l'adresse ip du serveur sur le client.

Le client a une ip variable (via DHCP). Actuellement, son ip est 192.168.1.10. J'imagine que la plage d'ip sera donc dans une plage de type 192.168.X.X.

J'essaie de mettre une adresse ip fixe sur le client (celui qui a une ip 192.168.1.10), juste le temps que le serveur puisse se connecter sur le client. L'idée de mettre une ip fixe, c'est que je sache a priori quelle sera d'adresse du client, et que donc la connection du serveur puisse se faire automatiquement.

D'ou le

sudo ifconfig eth0 10.0.0.1 netmask 255.255.255.0

Je me disais que l'ip 10.0.0.1 serait hors des plages proposées par le DHCP du bureau, en supposant que les adresses ip ne seraient que du style 192.168.X.X

Sauf que quand j'essaie d'attribuer une ip fixe au client, ça fait que le client n'est plus connecté sur le réseau, et que donc il n'est plus accessible au serveur. En soit, ca devait peut-etre etre previsible? mais bref, pour pouvoir avoir accès au serveur via le client, actuellement, j'ai besoin d'aller sur le serveur pour indiquer l'adresse ip du client, ce qui fait que je n'ai accès à distance au serveur qu'après avoir eu un acces direct au serveur (avec ecran et clavier), ce qui ne m'arrange pas...

j'espère etre plus clair? sinon, n'hésitez pas à me redemander des explications?

Hors ligne

#5 Le 05/12/2015, à 13:24

krodelabestiole

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

il faut que ton ip fixe soit de la forme 192.168.1.xxx pour être sur le même sous réseau, sinon ton client ne pourra pas communiquer avec les autres machines

prends un truc entre 192.168.1.210 et 192.168.1.240 par ex. si tu es à 192.168.1.10 il y a des chances que les attributions avec dhcp n'en soient pas encore arrivées là.

Dernière modification par krodelabestiole (Le 05/12/2015, à 13:24)

Hors ligne

#6 Le 05/12/2015, à 18:07

wolf_larsen

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

As tu vraiment besoin de 'voir' le bureau du serveur ?
Ce n'est pas, en général, la solution la plus élégante pour en 'prendre le contrôle', sauf besoin spécifique.

Comme l'indiquait kholo, un simple

ssh -X NomUtilisateur@IPServeur

ou

ssh -X NomUtilisateur@NomServeur

sur ton poste, pour peu que tu aies un serveur X (et ça semble être le cas) te permettra de lancer le plus efficacement du monde toute application graphique ou non sur le serveur, avec déport du clavier et de l'écran sur ton poste.
J'en use et abuse, avec parfois Xming comme serveur X si je suis sous windows.

Hors ligne

#7 Le 30/06/2016, à 10:00

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Bonjour à tous

Merci pour vos réponses, et mille pardon pour mon retours tardif.

Effectivement, la solution

ssh -X NomUtilisateur@NomServeur

est assez efficace, même très élégante, j'ai pu l'utiliser avec bonheur.

Me retrouve juste avec un soucis : lorsque je l'utilise de mon portable pour lancer une appli sur le serveur, le calcul se fait effectivement bien sur le serveur, mais parfois peut durer des jours entiers. Je me retrouve à ne pas pouvoir ni étendre mon portable, ni fermer la fenetre (qui est affichée sur l'écran de ce portable), et parfois, ça m'arrange de façon relativement limitée (en gros, j'aimerais bien pouvoir fermer mon portable, laiser gentillement le serveur travailler tout seul comme un grand, revenir le lendemain, rallumer mon portable, et pouvoir regarder ou en est le calcul sur le serveur, en réouvrant les fenetres des logiciels en cours - je ne sais pas si je suis clair?)

Bref, la solution proposée avec ssh me plait sur le papier, mais reste pour moi d'un usage limité, puisque n'est possible que dans le cas de calculs "rapides" (toutes proportions gardées).

Savez vous s'il y a des possibilités de contournement des problèmes évoqués?

(actuellement, j'utilise d'autres solutions, un peu lourdes, pas très ergonomiques, genre iTALC, qui beugue allègrement, ce qui n'est pas vraiment plus pertinent...)

Encore merci pour vos retours!

JF

Hors ligne

#8 Le 30/06/2016, à 11:10

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

screen et nohup permettent de lancer des taches couper la connexion et y revenir plus tard
je travaille encore sur des montages simples et des tutos...

Dernière modification par kholo (Le 30/06/2016, à 11:12)

Hors ligne

#9 Le 30/06/2016, à 12:47

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Merci beaucoup pour la réponse!

Je crois que je vais quand même avoir besoin d'aide, parceque tout seul, je n'y arrive pas vraiment.

Pour info, très brievement :

je suis sur un portable qui s'appelle doudou@doudou. Le serveur sur lequel je veux lancer le calcul s'appelle doudou@debian-biostat. Le programme que je lance est un logiciel qui peut tourner en ligne de commande, qui s'appelle stata. Juste pour que tu comprennes, pour que je lance Stata, je dois me placer dans le répertoire ou est installé le logiciel (d'ou le "cd ~/Logiciels/stata13"). Il peut fonctionner en lui donnant un fichier d'instructions qui suit l'appel du logiciel. En l’occurrence, quand je tape "~/Logiciels/stata13/stata-mp ~/Bureau/test.do", ca dit à Stata de lancer le fichier test.do (tu t'en serais douté).

Ce que je fais :

doudou@doudou:~$ ssh -X doudou@192.168.1.16 

-> me permet de travailler sur le serveur
Puis, avec

doudou@debian-biostat:~$ cd ~/Logiciels/stata13
doudou@debian-biostat:~/Logiciels/stata13$ nohup ~/Logiciels/stata13/stata-mp ~/Bureau/test.do 0</dev/null &

ca fait qu'effectivement, stata lance les commandes du fichier test.do, et les sorties sont non pas affichées dans le terminal, mais s'enregistrent dans le fichier nohup.out. Jusque là, tout va bien. Sauf que.

(les commandes du fichier test.do provoquent volontairement un calcul un peu long, pour avoir le temps de faire deux trois tests)

Quand j'éteins le terminal (qui a servi à lancer toutes ces commandes - c'est à dire lorsque je me déconnecte de debian-biostat), le calcul ne se poursuit pas sur debian-biostat, mais s'arrète complètement (ce qui se traduit par un fichier nohup.out qui ne contient que les sorties affichées lors de la connection via ssh - je ne sais pas si je suis clair)

Il y a sans doutes un truc à faire avec screen, mais pour le coup, je ne vois pas trop comment il permettrait de faire continuer la commande même lorsque le pont ssh est fermé - quand le terminal qui a lancé la commande sur une machine distante est fermé?

Je suis désolé, pour le coup, me sens un peu limité,si tu as une piste pour m'éclairer, je te serai infiniment reconnaissant, jusqu'à la 17ème génération!

JF

Hors ligne

#10 Le 30/06/2016, à 13:19

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

17 générations... ça vaut le coup de creuser alors !
je regarde autre chose sur doz mais je validerai de retour sur mon buntu !

connexion en ssh

ssh doudou@192.168.1.16

le -X uniquement si tu veux déporter l'affichage de X (pour des applications graphiques)
création d'une session screen

screen -S calcul

tu lances le calcul dans cette session

~/Logiciels/stata13/stata-mp ~/Bureau/test.do 0</dev/null &

le & (hup) de la fin doit suffire à rendre la main dans le terminal et continuer malgré la fermeture du terminal ensuite. le & doit être facultatif ; à tester !

la doc de screen a écrit :

Pour se détacher de la session du screen :
Saisir la suite de touche clavier suivante : [CTRL]+[a] suivi de [d]

il doit marquer un truc pour dire qu'il est détaché :
[detached from 12345.calcul]
puis le prompt, je sort avec exit

exit

chez moi ça donne ça :

[detached from 1506.calcul]
pi@raspberrypi:~ $ exit
déconnexion
Connection to 192.168.1.31 closed.

pour se reconnecter plus tard
connexion en ssh

ssh doudou@192.168.1.16

on relance screen qui doit contenir "calcul" créé précédemment

screen -r calcul

ou

screen -r 1506

ou, encore plus simple

screen -r

qui ouvrira le screen ou une liste si plusieurs sont en cours

j'ai fait un test avec top que j'ai retrouvé à mon retour !

Dernière modification par kholo (Le 30/06/2016, à 15:27)

Hors ligne

#11 Le 30/06/2016, à 16:15

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

'tain le mec!

(pardon, excès d’enthousiasme, trop plein de bonheur, bref, faut que je discute le coup avec ma gamine, parce que si à la seconde ça passe pas, pour les 17 générations, ca va etre tendu...)

Merci beaucoup, ca marche du tonnerre!

J'en profite pour deux trois questions subsidiaires...

1/ J'ai (évidement) également essayé avec des choses qui fonctionnent sous X, histoire de voir si extrapolable pour des logiciels avec interface graphique obligatoire... ca marche pô... (bon, c'était presque annoncé quand même), tu aurais des idées?

2/ Tu crois qu'il y a moyen d'inclure ça dans un script? (je veux dire, un script genre shell qui se connecte au serveur via ssh, puis qui du serveur ouvre un autre "terminal" via screen, puis qui lance une commande, puis qui sorte du screen (via exit, je crois), puis... etc). Le passage d'un ordi à l'autre ne va pas pauser de soucis insurmontables pour le script?

Encore merci, ta solution est super!

JF

Hors ligne

#12 Le 30/06/2016, à 17:00

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

pour le déport X, j'étais en train avec mes tests !
le déport se fera si tu passes en ssh -X mais j'ai pas réussi à me déconnecter...
ou plutôt si,... mais ça ferme pas la fenêtre distante en local.

je l'ai fait méchant avec firefox et une vidéo en téléchargement avec VDH (videodownloadhelper)
l'idée était de lancer le téléchargement sur un poste
et le retrouver plus tard fini quand j'arrive sur le poste (dans ma chambre !)
mais ça rame, ça lag,.... tout ce que j'aime pas !
je vais rester à X11vnc pour les connexions graphiques distantes.

********************************************************************
en passant,  je te met le tuto qui va bien !
X11vnc
installation

sudo apt-get install x11vnc

mot de passe

x11vnc -storepasswd "UnMotDePasse" ~/.vnc_passwd

pas sudo... hein !!!

et c'est là que ça devient marrant
la ligne pour lancer x11vnc "simplement"

x11vnc -ncache 10 -many -rfbauth ~/.vnc_passwd

tu es sur le poste distant.
tu te connectes en ssh
puis tu ouvres une session screen
on va l'appeler vnc wink

screen -S vnc

maintenant on lance X11vnc

x11vnc -ncache 10 -many -rfbauth ~/.vnc_passwd

tu attends qu'il arrête de raconter sa vie et tu te déconnectes de screen avec Ctrl + a puis d
puis exit (ou ctrl +d) pour revenir en local

tu ouvres un client vnc... remmina par exemple
tu fais ta vie
quand c'est fini re ssh, puis

screen -r

et ctrl + c pour quitter X11vnc

exit

puis

exit

...comme si de rien était !

je vais finir  skizo à force d'ouvrir des sessions dans d'autres sessions, avec différents utilisateurs...
********************************************************************

Pour le script... pour vnc oui on peut scripter mais pas ssh, ça reste l'enfance de l'art...
et ton truc aussi :

mkdir ~/bin

~/bin est ajouté automatiquement par ubuntu à $PATH

nano ~/bin/traitement

tu choisis le nom à la place de "traitement"

#!/bin/bash
~/Logiciels/stata13/stata-mp ~/Bureau/test.do 0</dev/null
#~/Logiciels/stata13/stata-mp ~/Bureau/test.do
# à voir : pour, ou non, laisser les retours qui peuvent être une bonne info aux reconnexions si ton process est très long.
exit 0

clic droit dessus / propriétés, onglet permission et cocher exécuter...
pour le lancer

bash ~/bin/traitement

ou simplement

./traitement

je t'ai tout mis dans le désordre mais tu rectifieras ! tongue

Dernière modification par kholo (Le 30/06/2016, à 17:04)

Hors ligne

#13 Le 30/06/2016, à 17:27

sinbad83

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Bonjour,
as-tu envisagé l'utilisation de TeamViewer qui est génial pour le contrôle à distance ?
Doc sur http://doc.ubuntu-fr.org/teamviewer


La connaissance n'est pas une denrée rare, il faut la partager avec les autres.
Linux registered #484707
Site: www.coursinforev.org/doku.php
Desktop AMD Ryzen 5-3600, RAM 16GB, Ubuntu 20.10,   HP Pavillon G6 Ubuntu 20.10 et Ten, Serveur Ubuntu 18.04

Hors ligne

#14 Le 30/06/2016, à 17:33

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

teamviewer, c'est bon pour traverser les murs wink
c'est clair que ça fonctionne...
en local, ou pour peu qu'on sache traverser la box, on peut être plus léger !
et puis la LdC ça forge !

Hors ligne

#15 Le 30/06/2016, à 22:25

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

bonjour et merci à tous

Non, j'ai pas essayé teamviewer, mais j'ai essayé d'autres solutions de contrôle à distance : trucs de bureaux à distance via vnc (Remmina, vinagre, je ne sais plus lesquels), trucs de surveillance d'ordi pour lycée (iTALC et epoptes), et à chaque fois, je me retrouvais avec un soucis majeur : quand je déconnetais l'ordi "qui prend le contrôle", je n'arrivais plus à le reconnecter une seconde fois sans rallumer l'ordi "dont on prend le contrôle" (j'utilise pas les termes serveur et client, je me mélange...)

Bref, la solution via ssh et screen me va bien, puisque ca permet d'éteindre l'ordi qui prend contrôle, et de le rallumer le lendemain, pour voir ce qui s'est passé, sans physiquement toucher à la tour (qui n'est dotée ni d'écran,ni de clavier).

En tant que fainéant notoire, la ligne de code m'amuse beaucoup, et puis (jusqu'à présent) c'est la solution qui marche le mieux (sauf pour le coup de l'interface graphique).

Dis donc, maitre Kholo, ca te dit de rester suivre cette discussion? je ne vais pas essayer de faire mon script tout de suite, mais plus tard sans aucun doute. Pour l'instant, pas certain d'avoir compris l'interet du mkdir, mais je crois qu'il vaut mieux que je mette un peu les mains dans le cambouis avant que tu ne me réexpliques, aussi, je reviendrai vers toi pour te dire si ca marche, ou pas, et si je comprends tout, ou pas.

Ca te dérange pas?

Pour les 17 générations, c'est bien parti : la réponse de ma mome, c'est "Areuh". Elle a pas dit "non"

A+, et merci encore!

JF

Hors ligne

#16 Le 01/07/2016, à 08:59

kholo

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

oki,
@sinbad83 : pour https://doc.ubuntu-fr.org/teamviewer, c'est bien mais ça marche avec wine.
donc wine et teamviewer en plus sur le système.
et, au moment des calculs, rien n'empêche de fermer l'interface graphique.
@jeffhamel et ça peut être un plan B

pour le LdC et mkdir par exemple, utilise man (le manuel) :

man mkdir

mkdir = make Directory = créer un dossier !

bin (binaire) sert à mettre des "programmes" (ou des scripts)
comme ça on ne s’étale pas et ceux qui passent derrière savent de quoi on parle.
(si personne ne passe derrière, c'est bien de connaître et suivre des normes)

$PATH est une variable globale
elle permet de définir des dossiers pour les recherches de pgms.
quand tu tapes mkdir (justement on va parler de lui),
le système cherche mkdir où tu te trouves et, en cas d'échec,
va chercher dans les dossiers définis dans le $PATH
pour connaître ton $PATH :

echo $PATH

pour le suivi, pas d'inquiétude, je suis et d'autres regardent wink
pour les demandes ponctuelles, tu as les MP (sans abus !)
... encore que je check plus souvent le forum que mon courrier !

Dernière modification par kholo (Le 01/07/2016, à 09:05)

Hors ligne

#17 Le 01/07/2016, à 13:23

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Salut

Pardon,j'avais pas été super clair... effectivement,le mkdir, je connaissais (encore que vu mon niveau, tu avais raison de te poser la question), je ne voyais juste pas trop pourquoi utiliser $PATH, jusqu'à maintenant, je n'ai jamais déclaré mes scripts comme étant dans un répertoire marqué du fer $PATH

(simplement déclarés comme exécutables, et lancés avec le chemin complet, ca marchait à peu près aussi bien que ce que j'attendais? L'utilisation du $PATH, c'est que c'est plus propre? que ca évite de donner le chemin complet, c'est ca? c'est plus un point de vu philosophique, ou bien pragmatiquement, en plus, c'est utile? pardon pour la naïveté de ma question...)

Bon, je poursuis mon petit bonhomme de chemin, je crois avoir avancé sur mon script devant permettre de lancer la connexion ssh, et envoyer via ce canal des commandes utilisant screen à l'ordinateur distant

Le script pondu, enregistré sous le doux nom de "commande.sh" :

ssh -X doudou@192.168.1.16 'bash -s' <<'ENDSSH'
	echo "cd ~/Logiciels/stata13" > test.sh
	echo "~/Logiciels/stata13/stata-mp ~/Bureau/test.do" >> test.sh
	chmod +x test.sh
	screen -m -d -S test2 /home/doudou/test.sh
ENDSSH
ssh doudou@192.168.1.16 'rm /home/doudou/test.sh'

(curieusement, intégrer le rm /home/doudou/test.sh juste après screen -m -d -S test2 /home/doudou/test.sh et avant ENDSSH empêchait la commande screen -m -d -S test2 /home/doudou/test.sh de fonctionner???)

Ca marche plutot bien, il n'y a plus qu'à utiliser deux trois macro pour que ce sript soit un peu plus souple (permette d'envoyer de façon un peu plus interactive d'autres fichiers à analyser que le fichier ~/Bureau/test.do, et permette de vérifier l'adresse ip - possiblement changée de temps en temps, je sus en DHCP, mais c'est un détail)

Ma question (parceque oui, j'ai quand même une question)

Vous savez si il y a moyen d'afficher directement à la fin de mon script shell le contenu de la fenêtre test2? (j'avais essayé avec un ssh doudou@192.168.1.16 'screen -r test2' à la fin du script, mais ca marche pô!) Bon, ok, je suis d'accord, c'est de la customisation, il y a moyen de s'en passer, mais bon, ce serait joli, non?

En tous cas, mille mercis, sans vous (et certainement sans Kholo), je n'y serais jamais arrivé!

JF

Dernière modification par jeffhamel (Le 01/07/2016, à 13:34)

Hors ligne

#18 Le 01/07/2016, à 15:29

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

EDITÉ
Bon, l'aventure continue... et certains raffinements du shell restent manifestement mal maîtrisés.

Mon super top top script qui ne marche pas

echo -n "Ordi à contacter = doudou@192.168.1.16 Y/N : "
read ouinon
if [ "$ouinon" = "y" ] || [ "$ouinon" = "Y" ]; then
    IPdef=doudou@192.168.1.16
elif [ "$ouinon" = "n" ] || [ "$ouinon" = "N" ]; then
    xfce4-terminal --hide-menubar --hide-toolbar --title=IP -H -x nmap 192.168.1.0/24 
    echo "nom@ip:"
    read IPdef
fi

echo -n "fichier .do = ~/ssh.do Y/N : "
read ouinon
if [ "$ouinon" = "y" ] || [ "$ouinon" = "Y" ]; then
    pDO=$HOME/ssh.do
elif [ "$ouinon" = "n" ] || [ "$ouinon" = "N" ]; then
    echo -n "chemin du fichier .do: "
	read pDO
fi

mkdir $HOME/.codessh -p
cp $pDO $HOME/.codessh/file.do

ssh $IPdef 'mkdir ~/.codessh -p'
ssh $IPdef 'rm ~/.codessh/file.do -rf'
scp $HOME/.codessh/file.do $IPdef:~/.codessh

echo -n "nom screen : "
read scr

ssh -X $IPdef 'bash -s' <<ENDSSH
	echo "cd ~/Logiciels/stata13" > ~/.codessh/prg.sh
	echo "~/Logiciels/stata13/stata-mp ~/.codessh/file.do" >> ~/.codessh/prg.sh
	chmod +x ~/.codessh/prg.sh
	screen -m -d -S $scr ~/.codessh/prg.sh
ENDSSH

Ce qui ne marche pas, c'est vers la fin, je crois que lorsque j'appelle la variable $scr après avoir passé via ssh, et bé... $scr ne réfère plus à grand chose (variable locale qui doit avoir du sens pour l'ordinateur appelant, mais sans doutes pas définie chez l'ordinateur appelé? Y a-t-il moyen de faire transiter le contenu de variables locales via ssh également? pour qu'une variable définie chez le client le soit également chez le serveur?)

En fait, ça ne marchait pas parcequ'à la fin, j'écrivais

ssh -X $IPdef 'bash -s' <<'ENDSSH'
	...
ENDSSH

à la place de

ssh -X $IPdef 'bash -s' <<ENDSSH
	...
ENDSSH

(Il va faloir que je creuse pour comprendre pourquoi des fois il faut mettre des guillemets, et pourquoi non... Question naive, il y a de la documentation bien faite là dessus? j'ai tendance à trouver des bouts de ode sur internet, chercher à comprendre, mais bon, ce genre de détails, des guillemets parfois mis, parfois pas mis, vraiment pas facile à comprendre sans un bon bouquin qui explique?)


Merci pour le coup de main!

Dernière modification par jeffhamel (Le 01/07/2016, à 15:52)

Hors ligne

#19 Le 01/07/2016, à 19:24

jeffhamel

Re : [RESOLU, même si la discussion se poursuit] Accès à distance, ssh, etc

Le script, tel qu'il en est maintenant (permet de lancer des commandes stata via des fichiers .do au serveur distant, mais également de regarder ou on en est des commandes déja lancées via des screnns potentiellement multiples)

echo -n "Ordi à contacter = doudou@192.168.1.16 Y/N : "
read ouinon
if [ "$ouinon" = "y" ] || [ "$ouinon" = "Y" ]; then
    IPdef=doudou@192.168.1.16
elif [ "$ouinon" = "n" ] || [ "$ouinon" = "N" ]; then
    xfce4-terminal --hide-menubar --hide-toolbar --title=IP -H -x nmap 192.168.1.0/24 
    echo "nom@ip:"
    read IPdef
fi
echo -n "Lancer commande ou Regarder processus : L/R : "
read LR
if [ "$LR" = "L" ] || [ "$LR" = "l" ]; then
	echo -n "fichier .do = ~/ssh.do Y/N : "
	read ouinon
	if [ "$ouinon" = "y" ] || [ "$ouinon" = "Y" ]; then
		pDO=$HOME/ssh.do
	elif [ "$ouinon" = "n" ] || [ "$ouinon" = "N" ]; then
		echo -n "chemin du fichier .do: "
		read pDO
	fi
	mkdir $HOME/.codessh -p
	cp $pDO $HOME/.codessh/file.do
	ssh $IPdef 'mkdir ~/.codessh -p'
	ssh $IPdef 'rm ~/.codessh/file.do -rf'
	scp $HOME/.codessh/file.do $IPdef:~/.codessh
	echo -n "nom screen : "
	read scr
	ssh -X $IPdef 'bash -s' <<ENDSSH
		echo "cd ~/Logiciels/stata13" > ~/.codessh/prg.sh
		echo "~/Logiciels/stata13/stata-mp ~/.codessh/file.do" >> ~/.codessh/prg.sh
		chmod +x ~/.codessh/prg.sh
		screen -m -d -S $scr ~/.codessh/prg.sh
	ENDSSH
	echo -n "Regarder processus : Y/N : "
	read LR
fi
if [ "$LR" = "R" ] || [ "$LR" = "r" ] || [ "$LR" = "Y" ] || [ "$LR" = "y" ]; then
	cont=y
	while [ "$cont" = "y" ] || [ "$cont" = "Y" ]
	do
		ssh -X $IPdef 'bash -s' <<ENDSSH
			xfce4-terminal --hide-menubar --hide-toolbar --title="Lecture de screens" -H -x bash ~/.codessh/sortie.sh
		ENDSSH
		echo -n "Regarder autre processus : Y/N : "
		read cont
	done	
fi

Le code fonctionne, ce qui fait que je suis content. Maintenant, il doit etre dégeulasse, j'ai deux trois messages d'errer qui se glissent dans l'histoire (mais qui n'empèchent pas mon script de tourner)

Genre, j'ai un

(xfce4-terminal:18781): GLib-WARNING **: (/build/glib2.0-y6934K/glib2.0-2.42.1/./glib/gerror.c:381):g_error_new_valist: runtime check failed: (domain != 0)
Failed to connect to session manager: Échec de connexion au gestionnaire de session : SESSION_MANAGER environment variable not defined

qui s'affiche, sans que je ne comprenne pourquoi, bon...

Aucune urgence, puisque ca marche (et que ca me satisfait, d'un point de vu pragmatique), mais si quelqu'un passe et voit là ou j'ai été un peu brutos dans mon code?

Merci encore pour l'aide!

JF

Hors ligne