Je tourne en rond depuis un bon moment sur un problème pour lequel je ne
trouve même pas un début de piste de recherche.
J'ai 3 machines relativement similaires dans leur installation, avec
Gentoo + KDE.
Aujourd'hui, je les ai mises à jour toutes les 3. Suite à cette mise à
jour, je rencontre des bizarreries avec ssh. Les mises à jours sont
équivalentes sur les 3 postes, peut-être à quelques dépendances près
(voir liste pour l'une d'elles en bas).
Le problème, c'est la disparition de tout $DISPLAY quand j'utilise ssh,
que ce soit avec X11Forwarding yes dans /etc/ssh/sshd_config ou (et c'est
le cas qui m'a fait m'en rendre compte) que ce soit avec un ssh -x pour
lancer une commande "graphique" sur la machine distante.
J'ai tourné tout ça dans un peu tous les sens, je n'ai jamais de $DISPLAY.
Je suis quasiment certain que cela vient des mises à jour, puisque c'est
quelque chose que j'utilise tous les jours, et qui fonctionnait
parfaitement jusque là.
Je ne comprends pas ce qui, dans ces mises à jour kde, peut avoir
interféré la-dessus. Et je précise que c'est sans rapport avec screen
puisque j'ai le problème même sans l'utiliser. J'ai testé avec konsole ou
xterm, c'est pareil. J'ai essayé dans les 2 sens (de machine1 vers
machine2 et inversement), c'est pareil.
Du coup, comme je ne sais pas du tout qui peut être le fautif, j'ai bien
du mal à faire des recherches pour savoir si ça serait un bug, ou une
"feature", et donc comment y remédier.
Je continue à chercher, la nuit portant conseil dit-on. Mais si vous avez
une idée, n'hésitez pas.
Le Wed, 25 Jan 2017 15:57:14 +0000, Jo Engo a écrit :
As-tu essayé simplement DISPLAY=:0 xclock ?
C'est sûr que si j'initialise DISPLAY, forcément, il sera initialisé.
ça devrait regimber (ou pas).
Je ne connais pas le mot regimber, je vais faire des recherches.
Jo Engo
Le Wed, 25 Jan 2017 18:36:39 +0000, Christophe PEREZ a écrit :
As-tu essayé simplement DISPLAY=:0 xclock ?
C'est sûr que si j'initialise DISPLAY,
Il faut bien que tu (ou un script) le fasse à un moment ou à un autre
forcément, il sera initialisé.
Oui mais non, tant que tu n'auras pas fait ceci, et noté le résultat - affichage d'une horloge sur l'écran distant - message d'erreur sur la console ssh - autre ??? ça ne dira pas grand chose. -- L'ignorance vaut mieux qu'un savoir affecté. -+- Nicolas Boileau, Épitres -+-
Le Wed, 25 Jan 2017 18:36:39 +0000, Christophe PEREZ a écrit :
As-tu essayé simplement DISPLAY=:0 xclock ?
C'est sûr que si j'initialise DISPLAY,
Il faut bien que tu (ou un script) le fasse à un moment ou à un autre
forcément, il sera initialisé.
Oui mais non, tant que tu n'auras pas fait ceci, et noté le résultat
- affichage d'une horloge sur l'écran distant
- message d'erreur sur la console ssh
- autre ???
Le Wed, 25 Jan 2017 18:36:39 +0000, Christophe PEREZ a écrit :
As-tu essayé simplement DISPLAY=:0 xclock ?
C'est sûr que si j'initialise DISPLAY,
Il faut bien que tu (ou un script) le fasse à un moment ou à un autre
forcément, il sera initialisé.
Oui mais non, tant que tu n'auras pas fait ceci, et noté le résultat - affichage d'une horloge sur l'écran distant - message d'erreur sur la console ssh - autre ??? ça ne dira pas grand chose. -- L'ignorance vaut mieux qu'un savoir affecté. -+- Nicolas Boileau, Épitres -+-
Nicolas George
Christophe PEREZ , dans le message <o65n3d$kkm$, a écrit :
Oui, mais tu n'as sans doute pas compris l'objet du -x.
En fait, personne n'avait compris l'objet que tu mets à ce -x. Et il y a une bonne raison à ça : le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix, or tout ceux qui peuvent te répondre sont à peu près familiers de ce fonctionnement, donc n'imaginaient même pas vers où tu voulais aller. Il y a environ deux semaines, je t'ai conseillé justement de te documenter un poil sur ces principes des processus Unix. Tu as répondu avec véhémence que ce serait une perte de temps pour toi. Ce thread vient de montrer que tu avais tort et que j'avais raison. Je te conseille de prendre ce fait comme axiome à l'avenir :-Þ
Christophe PEREZ , dans le message <o65n3d$kkm$1@serveur2.novazur.fr>, a
écrit :
Oui, mais tu n'as sans doute pas compris l'objet du -x.
En fait, personne n'avait compris l'objet que tu mets à ce -x. Et il y a
une bonne raison à ça : le comportement que tu t'attendais à observer
est complètement absurde vis-à-vis du fonctionnement des processus Unix,
or tout ceux qui peuvent te répondre sont à peu près familiers de ce
fonctionnement, donc n'imaginaient même pas vers où tu voulais aller.
Il y a environ deux semaines, je t'ai conseillé justement de te
documenter un poil sur ces principes des processus Unix. Tu as répondu
avec véhémence que ce serait une perte de temps pour toi. Ce thread
vient de montrer que tu avais tort et que j'avais raison. Je te
conseille de prendre ce fait comme axiome à l'avenir :-Þ
Christophe PEREZ , dans le message <o65n3d$kkm$, a écrit :
Oui, mais tu n'as sans doute pas compris l'objet du -x.
En fait, personne n'avait compris l'objet que tu mets à ce -x. Et il y a une bonne raison à ça : le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix, or tout ceux qui peuvent te répondre sont à peu près familiers de ce fonctionnement, donc n'imaginaient même pas vers où tu voulais aller. Il y a environ deux semaines, je t'ai conseillé justement de te documenter un poil sur ces principes des processus Unix. Tu as répondu avec véhémence que ce serait une perte de temps pour toi. Ce thread vient de montrer que tu avais tort et que j'avais raison. Je te conseille de prendre ce fait comme axiome à l'avenir :-Þ
Christophe PEREZ
Le Thu, 26 Jan 2017 08:25:51 +0000, Jo Engo a écrit :
ça ne dira pas grand chose.
Tu n'as clairement pas lu le fil. Le Fri, 20 Jan 2017 16:38:42 +0000, Christophe PEREZ a écrit :
Si je fais : export DISPLAY=:0 alors le fonctionnement redevient celui que j'avais jusqu'alors. Mais qu'est-ce qui fait que ce n'est PLUS activé "automatiquement" ?
Alors évidemment, si on ne lit pas, on peut toujours me dire que je n'ai rien expliqué.
Le Thu, 26 Jan 2017 08:25:51 +0000, Jo Engo a écrit :
ça ne dira pas grand chose.
Tu n'as clairement pas lu le fil.
Le Fri, 20 Jan 2017 16:38:42 +0000, Christophe PEREZ a écrit :
Si je fais :
export DISPLAY=:0 alors le fonctionnement redevient celui que j'avais
jusqu'alors. Mais qu'est-ce qui fait que ce n'est PLUS activé
"automatiquement" ?
Alors évidemment, si on ne lit pas, on peut toujours me dire que je n'ai
rien expliqué.
Le Thu, 26 Jan 2017 08:25:51 +0000, Jo Engo a écrit :
ça ne dira pas grand chose.
Tu n'as clairement pas lu le fil. Le Fri, 20 Jan 2017 16:38:42 +0000, Christophe PEREZ a écrit :
Si je fais : export DISPLAY=:0 alors le fonctionnement redevient celui que j'avais jusqu'alors. Mais qu'est-ce qui fait que ce n'est PLUS activé "automatiquement" ?
Alors évidemment, si on ne lit pas, on peut toujours me dire que je n'ai rien expliqué.
Dominique MICOLLET
Bonjour, Ai-je bien compris en pensant que vous cherchez à démarrer depuis une machine locale, une application graphique qui s'exécute et s'affiche sur une machine distante ? Christophe PEREZ wrote:
Je tourne en rond depuis un bon moment sur un problème pour lequel je ne
....
kde-frameworks/krunner-5.29.0
Suite à ce long fil, j'ai fait quelques essais personnel pour comprendre les dires des uns et des autres : ssh ne définit pas DISPLAY ssh -x ne définit pas DISPLAY ssh -X définit DISPLAY à localhost:10:0 Donc sur une machine configurée en standard seule la dernière commande permet l'exécution d'une commande graphique sur la machine distante affichée sur la machine locale (même si en l'espèce c'est la même machine pour mes essais). Ce qui ne semble pas être ce que vous voulez faire. Toutefois, l'une ou l'autre des premières commandes permet d'exécuter et afficher une commande graphique sur la machine distante dès lors qu'on configure manuellement DISPLAY à :0. Ce qui ne me semble pas être du ressort de sshd ou ssh, sauf à modifier l'équivalent d'un "sshd.rc" qui exécuterait des commande spécifiques lors d'une connexion. Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour. Cordialement Dominique
Bonjour,
Ai-je bien compris en pensant que vous cherchez à démarrer depuis une
machine locale, une application graphique qui s'exécute et s'affiche sur une
machine distante ?
Christophe PEREZ wrote:
Je tourne en rond depuis un bon moment sur un problème pour lequel je ne
....
kde-frameworks/krunner-5.29.0
Suite à ce long fil, j'ai fait quelques essais personnel pour comprendre les
dires des uns et des autres :
ssh moi@localhost ne définit pas DISPLAY
ssh -x moi@localhost ne définit pas DISPLAY
ssh -X moi@localhost définit DISPLAY à localhost:10:0
Donc sur une machine configurée en standard seule la dernière commande
permet l'exécution d'une commande graphique sur la machine distante affichée
sur la machine locale (même si en l'espèce c'est la même machine pour mes
essais).
Ce qui ne semble pas être ce que vous voulez faire.
Toutefois, l'une ou l'autre des premières commandes permet d'exécuter et
afficher une commande graphique sur la machine distante dès lors qu'on
configure manuellement DISPLAY à :0.
Ce qui ne me semble pas être du ressort de sshd ou ssh, sauf à modifier
l'équivalent d'un "sshd.rc" qui exécuterait des commande spécifiques lors
d'une connexion.
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle
d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et
non localhost:0.0) et que cette modification a été écrasée par l'une des
mises à jour.
Bonjour, Ai-je bien compris en pensant que vous cherchez à démarrer depuis une machine locale, une application graphique qui s'exécute et s'affiche sur une machine distante ? Christophe PEREZ wrote:
Je tourne en rond depuis un bon moment sur un problème pour lequel je ne
....
kde-frameworks/krunner-5.29.0
Suite à ce long fil, j'ai fait quelques essais personnel pour comprendre les dires des uns et des autres : ssh ne définit pas DISPLAY ssh -x ne définit pas DISPLAY ssh -X définit DISPLAY à localhost:10:0 Donc sur une machine configurée en standard seule la dernière commande permet l'exécution d'une commande graphique sur la machine distante affichée sur la machine locale (même si en l'espèce c'est la même machine pour mes essais). Ce qui ne semble pas être ce que vous voulez faire. Toutefois, l'une ou l'autre des premières commandes permet d'exécuter et afficher une commande graphique sur la machine distante dès lors qu'on configure manuellement DISPLAY à :0. Ce qui ne me semble pas être du ressort de sshd ou ssh, sauf à modifier l'équivalent d'un "sshd.rc" qui exécuterait des commande spécifiques lors d'une connexion. Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour. Cordialement Dominique
Dominique MICOLLET
Bonjour, Nicolas George wrote:
le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de nombreux autres). Si j'ai bien compris ce que fait l'auteur de l'article initial, il existe une machine distante sur laquelle un utilisateur est localement connecté via l'interface graphique. Cette connexion active le serveur X et définit pour lui la variable DISPLAY et les droit d'utiliser le serveur. Il semble qu'il soit possible de se connecter par ssh sur cette même machine avec le même nom d'utilisateur. En définissant proprement DISPLAY, cette seconde connexion permet d'exécuter des commandes graphiques avec affichage sur l'écran de la première connexion. On se trouve donc dans une situation ou deux processus à priori indépendants usent d'une "même" variable d'environnement. Une application possible serait un écran d'affichage dans un lieu public, piloté à distance. Ceci étant l'auteur de l'article initial aurait effectivement du exposer les faits en totalité plutôt que filtrer ceux qui lui semblaient pertinents. Cordialement Dominique.
Bonjour,
Nicolas George wrote:
le comportement que tu t'attendais à observer
est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de
nombreux autres).
Si j'ai bien compris ce que fait l'auteur de l'article initial, il existe
une machine distante sur laquelle un utilisateur est localement connecté via
l'interface graphique. Cette connexion active le serveur X et définit pour
lui la variable DISPLAY et les droit d'utiliser le serveur.
Il semble qu'il soit possible de se connecter par ssh sur cette même machine
avec le même nom d'utilisateur. En définissant proprement DISPLAY, cette
seconde connexion permet d'exécuter des commandes graphiques avec affichage
sur l'écran de la première connexion.
On se trouve donc dans une situation ou deux processus à priori indépendants
usent d'une "même" variable d'environnement.
Une application possible serait un écran d'affichage dans un lieu public,
piloté à distance.
Ceci étant l'auteur de l'article initial aurait effectivement du exposer les
faits en totalité plutôt que filtrer ceux qui lui semblaient pertinents.
le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de nombreux autres). Si j'ai bien compris ce que fait l'auteur de l'article initial, il existe une machine distante sur laquelle un utilisateur est localement connecté via l'interface graphique. Cette connexion active le serveur X et définit pour lui la variable DISPLAY et les droit d'utiliser le serveur. Il semble qu'il soit possible de se connecter par ssh sur cette même machine avec le même nom d'utilisateur. En définissant proprement DISPLAY, cette seconde connexion permet d'exécuter des commandes graphiques avec affichage sur l'écran de la première connexion. On se trouve donc dans une situation ou deux processus à priori indépendants usent d'une "même" variable d'environnement. Une application possible serait un écran d'affichage dans un lieu public, piloté à distance. Ceci étant l'auteur de l'article initial aurait effectivement du exposer les faits en totalité plutôt que filtrer ceux qui lui semblaient pertinents. Cordialement Dominique.
Nicolas George
Dominique MICOLLET , dans le message <588a1d39$0$3348$, a écrit :
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour.
Je soupçonne qu'une explication possible est que les SSH se sont retrouvés configurés pour faire passer une partie non négligeable de l'environnement du client au serveur. À un moment, ces configurations ont été rendues plus strictes, ça peut expliquer le changement observé. Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY locale soit valide pour la machine distante, et a fortiori soit suffisante, cf. xauth(1).
Dominique MICOLLET , dans le message
<588a1d39$0$3348$426a74cc@news.free.fr>, a écrit :
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle
d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et
non localhost:0.0) et que cette modification a été écrasée par l'une des
mises à jour.
Je soupçonne qu'une explication possible est que les SSH se sont
retrouvés configurés pour faire passer une partie non négligeable de
l'environnement du client au serveur. À un moment, ces configurations
ont été rendues plus strictes, ça peut expliquer le changement observé.
Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise
idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY
locale soit valide pour la machine distante, et a fortiori soit
suffisante, cf. xauth(1).
Dominique MICOLLET , dans le message <588a1d39$0$3348$, a écrit :
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour.
Je soupçonne qu'une explication possible est que les SSH se sont retrouvés configurés pour faire passer une partie non négligeable de l'environnement du client au serveur. À un moment, ces configurations ont été rendues plus strictes, ça peut expliquer le changement observé. Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY locale soit valide pour la machine distante, et a fortiori soit suffisante, cf. xauth(1).
Nicolas George
Dominique MICOLLET , dans le message <588a1f74$0$3322$, a écrit :
le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de nombreux autres).
Tu as bien vu que je ne parlais que de l'usage de l'option -x, ici ?
Dominique MICOLLET , dans le message
<588a1f74$0$3322$426a34cc@news.free.fr>, a écrit :
le comportement que tu t'attendais à observer
est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de
nombreux autres).
Tu as bien vu que je ne parlais que de l'usage de l'option -x, ici ?
Dominique MICOLLET , dans le message <588a1f74$0$3322$, a écrit :
le comportement que tu t'attendais à observer est complètement absurde vis-à-vis du fonctionnement des processus Unix,
Je ne partage pas votre opinion sur ce point (alors que je la partage sur de nombreux autres).
Tu as bien vu que je ne parlais que de l'usage de l'option -x, ici ?
Christophe PEREZ
Le Thu, 26 Jan 2017 17:00:56 +0100, Dominique MICOLLET a écrit :
Ai-je bien compris en pensant que vous cherchez à démarrer depuis une machine locale, une application graphique qui s'exécute et s'affiche sur une machine distante ?
Oui.
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour.
Manuelle, non, je ne pense pas. Si j'avais modifié, manuellement, un fichier système sur 3 machines, juste avant les mises à jour, je pensais que je m'en serais souvenu après les mises à jour. Sachant, je le rappelle, que c'est quelque chose que j'utilise TOUS les jours. Par contre, que quelque chose ait modifié par les mises à jour, ça, oui, ça me semble évident, et c'est le sujet de mon post initial :D Mais ne vous embêtez pas plus. J'ai fini de chercher. L'ambiance et certaines interventions m'ont dégouté de continuer à échanger ici. Ça m'était déjà arrivé dans les années précédentes, donc ça me passera peut- être à nouveau. En attendant : EOT
Le Thu, 26 Jan 2017 17:00:56 +0100, Dominique MICOLLET a écrit :
Ai-je bien compris en pensant que vous cherchez à démarrer depuis une
machine locale, une application graphique qui s'exécute et s'affiche
sur une machine distante ?
Oui.
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle
d'un fichier système de votre machine distante pour forcer DISPLAY à :0
(et non localhost:0.0) et que cette modification a été écrasée par l'une
des mises à jour.
Manuelle, non, je ne pense pas. Si j'avais modifié, manuellement, un
fichier système sur 3 machines, juste avant les mises à jour, je pensais
que je m'en serais souvenu après les mises à jour.
Sachant, je le rappelle, que c'est quelque chose que j'utilise TOUS les
jours.
Par contre, que quelque chose ait modifié par les mises à jour, ça, oui,
ça me semble évident, et c'est le sujet de mon post initial :D
Mais ne vous embêtez pas plus. J'ai fini de chercher. L'ambiance et
certaines interventions m'ont dégouté de continuer à échanger ici. Ça
m'était déjà arrivé dans les années précédentes, donc ça me passera peut-
être à nouveau.
En attendant : EOT
Le Thu, 26 Jan 2017 17:00:56 +0100, Dominique MICOLLET a écrit :
Ai-je bien compris en pensant que vous cherchez à démarrer depuis une machine locale, une application graphique qui s'exécute et s'affiche sur une machine distante ?
Oui.
Je pense donc qu'avant vos mises à jour, il y a eu modification manuelle d'un fichier système de votre machine distante pour forcer DISPLAY à :0 (et non localhost:0.0) et que cette modification a été écrasée par l'une des mises à jour.
Manuelle, non, je ne pense pas. Si j'avais modifié, manuellement, un fichier système sur 3 machines, juste avant les mises à jour, je pensais que je m'en serais souvenu après les mises à jour. Sachant, je le rappelle, que c'est quelque chose que j'utilise TOUS les jours. Par contre, que quelque chose ait modifié par les mises à jour, ça, oui, ça me semble évident, et c'est le sujet de mon post initial :D Mais ne vous embêtez pas plus. J'ai fini de chercher. L'ambiance et certaines interventions m'ont dégouté de continuer à échanger ici. Ça m'était déjà arrivé dans les années précédentes, donc ça me passera peut- être à nouveau. En attendant : EOT
Dominique MICOLLET
Bonjour, Nicolas George wrote:
Je soupçonne qu'une explication possible est que les SSH se sont retrouvés configurés pour faire passer une partie non négligeable de l'environnement du client au serveur.
J'aurais plutôt pensé du serveur sshd au client ssh, voire du serveur X au client ssh.
Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY locale soit valide pour la machine distante, et a fortiori soit suffisante, cf. xauth(1).
Pourtant $ ssh $ export DISPLAY=:0 $ xclock fonctionne parfaitement sans qu'il soit nécessaire de manipuler xhost ou xauth. Il se peut que ce soit du au fait que je me connecte via ssh sur la même machine donc le même serveur X. Je vérifierai si c'est le même comportement dans une salle de TP où je dispose de machines avec compte commun et écrans côte à côte. Cordialement Dominique
Bonjour,
Nicolas George wrote:
Je soupçonne qu'une explication possible est que les SSH se sont
retrouvés configurés pour faire passer une partie non négligeable de
l'environnement du client au serveur.
J'aurais plutôt pensé du serveur sshd au client ssh, voire du serveur X au
client ssh.
Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise
idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY
locale soit valide pour la machine distante, et a fortiori soit
suffisante, cf. xauth(1).
Pourtant
moi@ici $ ssh moi@localhost
moi@localhost $ export DISPLAY=:0
moi@localhost $ xclock
fonctionne parfaitement sans qu'il soit nécessaire de manipuler xhost ou
xauth.
Il se peut que ce soit du au fait que je me connecte via ssh sur la même
machine donc le même serveur X. Je vérifierai si c'est le même comportement
dans une salle de TP où je dispose de machines avec compte commun et écrans
côte à côte.
Je soupçonne qu'une explication possible est que les SSH se sont retrouvés configurés pour faire passer une partie non négligeable de l'environnement du client au serveur.
J'aurais plutôt pensé du serveur sshd au client ssh, voire du serveur X au client ssh.
Si c'est ça, alors ça marchait par hasard, et c'est une très mauvaise idée de compter dessus. Il n'y a aucune raison que la variable DISPLAY locale soit valide pour la machine distante, et a fortiori soit suffisante, cf. xauth(1).
Pourtant $ ssh $ export DISPLAY=:0 $ xclock fonctionne parfaitement sans qu'il soit nécessaire de manipuler xhost ou xauth. Il se peut que ce soit du au fait que je me connecte via ssh sur la même machine donc le même serveur X. Je vérifierai si c'est le même comportement dans une salle de TP où je dispose de machines avec compte commun et écrans côte à côte. Cordialement Dominique
