Forum Linux.debian/ubuntu Déport d'affichage.

Posté par (page perso) .
Tags : aucun
0
7
oct.
2011

Bonjour,

je mets actuellement en place une debian virtualisée. Et je souhaite accéder à l'interface graphique de cette machine via le réseau local.
Je suis donc à la recherche d'un dispositif de déport d'affichage qui soit le plus performant possible. J'ai essayé vnc, mais bof ;o))
J'ai essayé également NX qui fonctionne plutôt bien.

Avez vous d'autres solutions pour faire du déport d'affichage ? J'ai lu des articles sur spice qui semble pas mal, quelqu'un a déjà testé ?

Merci de vos réponses...

Denis

  • # xdmcp

    Posté par . Évalué à 5.

    ça dépend juste pour une console pour un outils graphique
    ssh -X lamachine
    et tu lance ton aplli.

    Si c'est tout le bureaux tu peux utiliser la même approche en lançant un startkde, mais c'est plutôt moyen si tu as déjà un affichage.

    Tu peux aussi regarder du coté de login distant avec du xdmcp une question s'était posé ici http://linuxfr.org/forums/linuxredhat/posts/accès-xdmcp

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Pour quoi faire

    Posté par . Évalué à 4.

    Ce que tu décris n'est pas ce qu'on appelle habituellement du déport d'affichage.

    Le cas habituel est le lancement d'une application sur la machine distante avec affichage sur la machine locale. Il suffit d'avoir un serveur X sur la machine locale; et de paramétrer l'environnement pour que l'affichage des applications que tu lances sur la machine distante se fasse sur la machine locale (variable DISPLAY, xhost..). SSH dispose d'un mode tunnel X qui gère cela.

    Toutes les applications X lancées depuis ta session sur la machine distante s'affiche sur ta machine locale.

    Le cas que tu évoques est plutôt de la connexion à distance sur un bureau qui tourne lui-même sur la machine distante. Il existe beaucoup de solutions, vnc, nx...

    Ça dépends beaucoup de ce que tu veux faire:

    • Si ta machine distante est un serveur que tu aimes administrer via une interface graphique, alors la première solution est bien plus simple et légère; il n'est pas nécessaire d'installer X sur le serveur ni d'occuper la mémoire avec un serveur X.

    • Si tu as besoin d'un bureau distant que tu retrouves tel quel à chaque connection, avec tes applications lancées et tes documents ouverts tels que tu les as laissé; alors on est plutôt dans la seconde solution. Un serveur X virtuel tel que Xvfb ou vnc-server propose d'avoir un bureau sans carte graphique ni souris/clavier, sur lequel on peu se connecter à distance pour interagir.

    • [^] # Re: Pour quoi faire

      Posté par (page perso) . Évalué à 1.

      alors je vais préciser mon besoin car il est vrai que j'ai employé les termes "déport d'affichage" dans le mauvais sens.

      Je souhaite effectivement utiliser le bureau qui est sur la machine virtuelle depuis différentes machines du réseau local.

      J'ai fait des tests avec ssh -X, et même si cela fonctionne bien, l'affichage n'est pas assez réactif pour l'utilisation du bureau à distance. De plus effectuant par cette méthode un startkde, kde se crash régulièrement.

      Pour le moment, selon les tests que j'ai pu effectuer, c'est bien NX qui donne un affichage le plus réactif.

      Merci à tous pour vos messages...

  • # X11 par réseau

    Posté par (page perso) . Évalué à 5.

    Si c'est en réseau local, tu peux faire directement de l'X11 par réseau.

    Sur la machine locale, mettons qu'elle s'appelle muscadet.local :

    musadet$ xauth list
    muscadet.local:0  MIT-MAGIC-COOKIE-1  f16075da6976d91f04d90d8224c4f09b
    
    

    Tu récupères la valeur du cookie MIT-MAGIC correspondant à l'affichage local :0. Puis, sur la machine distante, appelons-la bourgogne, par exemple par SSH, tu ajoutes ce cookie :

    bourgogne$ xauth add muscadet.local:0   MIT-MAGIC-COOKIE-1  f16075da6976d91f04d90d8224c4f09b
    
    

    Tu peux dès lors lancer des logiciels graphiques sur bourgogne en leur demandant de s'afficher sur muscadet.local :

    bourgogne$ DISPLAY=muscadet.local:0 xclock
    
    
    • [^] # Re: X11 par réseau

      Posté par (page perso) . Évalué à 1.

      .... y a plus simple quand même au final si c'est pour utiliser ssh ...

      ssh -X bourgogne

      (même si c'est toujours intéressant d'expliquer comment ça marche réellement)

      • [^] # Re: X11 par réseau

        Posté par (page perso) . Évalué à 1.

        Loupé, ce n'est pas comme ça que ça marche réellement, le SSH avec déport d'affichage et le déport d'affichage tout court sont deux choses différentes.

        ssh -X, ça lance le client OpenSSL de façon à ce qu'il :

        1. fasse un tranfert de socket Unix locale vers le serveur SSH ;
        2. transfère temporairement le cookie MIT-MAGIC local ;
        3. fixe la variable DISPLAY pour utiliser le socket Unix transféré.

        Au contraire, le transfert d'affichage direct, ça utilise directement le serveur X11 en TCP. Ça ne chiffre donc pas le X11, SSH n'étant utilisé que pour lancer le logiciel.

        • [^] # Re: X11 par réseau

          Posté par (page perso) . Évalué à 2.

          X11 est tout de même chiffré via le cookie...

          • [^] # Re: X11 par réseau

            Posté par (page perso) . Évalué à 2.

            Euuuuuuh, sûr, ça ? Il me semblait que c'était juste un secret partagé, passé en clair pour prouver qu'on est autorisé à utiliser l'affichage…

            • [^] # Re: X11 par réseau

              Posté par (page perso) . Évalué à 2.

              Il me semblait que le cookie X11 servait à chiffrer avec un 3DES. Donc le cookie ne passe pas en clair et il faut que les deux cotés l'ai par une méthode ou un autre. D'où les commandes xauth un peu pénible et donc au final ssh -X qui fait le boulot à notre place bien mieux dans 99,99% des cas ;-)

              • [^] # Re: X11 par réseau

                Posté par (page perso) . Évalué à 2.

                Il me semblait que le cookie X11 servait à chiffrer avec un 3DES.

                Ça me surprend énormément, parce que cela signifierait que nos sessions X11 sont chiffrées, même en local, ce qui serait idiot.

                donc au final ssh -X qui fait le boulot à notre place bien mieux dans 99,99% des cas

                Si c'était le cas, faire du déport d'affichage par SSH, cela signifierait surchiffrer par SSH un flux X11 déjà chiffré en 3DES, ce qui serait un beau gaspillage de ressources.

                • [^] # Re: X11 par réseau

                  Posté par (page perso) . Évalué à 2.

                  Il me semble que le cookie ne sers pas sur localhost donc pas de chiffrement (X11) local ni via ssh (car avec ssh, le DISPLAY est localhost aussi).

                  Bref, si mes souvenirs sont bons, le chiffrement X11 n'a pas lieu tout le temps mais seulement pour une connexion distante avec les réglages actuels des distributions.

                  • [^] # Re: X11 par réseau

                    Posté par (page perso) . Évalué à 2.

                    Il me semble que le cookie ne sers pas sur localhost donc pas de chiffrement (X11) local

                    Bien, donc je peux corriger cela : le cookie sert toujours. Essaie un peu de le retirer (xauth list, xauth remove) et regarde le résultat : tu ne peux plus lancer aucun logiciel graphique.

                    Donc j'imagine que le reste de ce que tu pensais a des chances d'être faux aussi. :-)

                    • [^] # Re: X11 par réseau

                      Posté par (page perso) . Évalué à 2.

                      Effectivement tu as raison, après quelques recherches (cela faisait longtemps que j'avais pas regardé de ce coté là, merci ssh), le cookie ne sers qu'a l'authentification. C'est idiot qu'ils n'aient pas associé a ce cookie un DES et une compression depuis le temps, enfin comme ssh règle un peu tous ces problèmes, je pense que personne n'était motivé pour rajouter ces petites extensions ;-)

    • [^] # Re: X11 par réseau

      Posté par (page perso) . Évalué à 0.

      Merci pour l'info

      Juste pour compléter car je ne comprenais pas pourquoi cela ne marchait pas, il faut que coté local le serveur X accepte les connexions IP. Par défaut, sur beaucoup de distributions il semble que X ne les accepte pas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.