[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] "bureau à distance"



Le jeudi 10 janvier 08 à 15:50, fully_associative-debian@yahoo.fr a écrit :
| Bonjour,

Bonjour,

| J'ai acheté un nouvel ordinateur. Bien plus puissant
| que ceux que j'avais déjà. L'idée serait que les ordinateurs
| moins puissant servent de "terminaux X".
| À la fois l'idée et la réalisabilité me semblent assez ancienne ??
| "On a des postes de travail ; ils se connectent etc, etc"
| il semble que ça existait déjà lorsqu'il y avait encore des
| dinosaurs..

L'idée et la faisabilité sont effectivement anciennes, il n'y aura aucun
problème à le mettre en place.

| Mais je n'ai pas trouvé de description d'un tel système
| sur internet..
| Sûrement pas les bon mots-clé...
| 
| J'entends parler de VNC.. (je ne sais pas si c'est de
| la technologie M...t (..) En tout cas je suis alergique à
| M.. Et encore une fois le concept semble très ancien.

VNC est un serveur réseau permettant d'afficher de manière déportée le
bureau d'une machine.
X est également un serveur réseau permettant d'afficher de manière
déportée les applications graphiques (ou tout le bureau) d'une machine.

Selon moi, VNC n'a pas beaucoup d'intérêt puisque X peut le faire !
Néanmoins, X ne permet pas de se connecter à une session déjà ouverte,
il permet d'en ouvrir une nouvelle. C'est à dire que si on laisse des
dizaines de fenêtres ouvertes sur le bureau, qu'on se déconnecte et
reconnecte, on retombera sur une session vierge.

En utilisant X, on peut (comme écrit plus haut) lancer une application
et l'afficher à distance (c'est de l'export display, je me connecte en
SSH sur la machine distante, je lance xterm, il s'affiche sur la machine
locale), mais on peut aussi ouvrir une session et accéder au bureau
complet. Pour ouvrir une session X sur une machine distante et
l'afficher sur la machine locale c'est le protocole XDMCP. C'est
directement géré par le « Display Manager » (gdm, kdm, xdm ?).

| =================================================
| 
| Outre les remarques générales que vous pourez faire et que je
| serais heureux de lire ; j'ai deux ou trois questions
| précises que je me permets de vous soumettre :) 
| 
| -Q1 : je suis en dhcp ; lorsque je fais "ssh toto.local" ssh se plaint
| parce que toto devrait correspondre à 192.168.1.12 alors que là il
| correspond à 192.168.1.14 (ce sont des exemples). (En dhcp ça peut ch-
| changer quand ça veut) (dhcp est bien pratique).

C'est pas une question ça ! mébon, j'ai compris quand-même. Peut-être
faudrait-il configurer le serveur DHCP pour qu'il mette à jour le DNS.
De cette façon, les résolutions inverses (trouver le nom d'une
machine à partir de son IP fourniront un résultat cohérent).
Je crois qu'il est également possible de spécifier à SSH qu'on ne
souhaite pas qu'il fasse la résolution inverse lors de la connexion (man
ssh_config).

| -Q2 : 
| Je suis sur la machine "titi".
| je fais "ssh -X toto.local".
| puis je fais "firefox".
| Et là, je sauvegarde la page que je suis en train de visiter.
| 
| cas A : je n'avais pas d'instances de firefox d'ouverte
| avant de me connecter à "toto".
| Ma page est sauvegardée sur la machine "toto".
| 
| cas B : j'avais une instance de firefox d'ouverte
| sur la machine titi, avant de me connecter à toto.
| Ma page est sauvegardée sur la machine "titi".
| 
| Ça vient sûrement d'une mauvaise compréhension 
| du mécanisme du tunnelling de X via ssh

Je suis souvent confronté à ce problème. Je pense que si l'application
distante tarde à démarrer, alors elle sera lancée en local, mais ce
n'est qu'une simple supposition.

| En tout cas le comportement observé n'est pas du tout conforme
| à celui espéré.

Effectivement.

| ===
| 
| Je me limite à ces deux petites questions/ remarques.
| 
| Je serai heureux de connaitre vos points de vue.

J'espère avoir fait ton bonheur !

| FA

Seb


Reply to: