Forum Linux.gui Équivalent de GNU Screen pour une session X

Posté par  .
Étiquettes : aucune
2
16
sept.
2009
Bonjour,

question rapide, existe-t-il un équivalent à screen pour une session X ?
C'est à dire, je lance ma session sur mon poste à la maison, de n'importe où je me connecte à la maison et je retrouve ma session comme je l'ai laissé avant. Le même principe que screen mais en graphique.

Merci.

  • # vnc

    Posté par  . Évalué à 4.

    mais il me semble qu' il faut laisser tourner la session

    • [^] # Re: vnc

      Posté par  . Évalué à 1.

      NX aussi.
      Maintenant qu'il y a google qui a re-développé freenx, on doit avoir une alternative sympa.

      • [^] # Re: vnc

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Sauf erreur de ma part, NX ne peut pas de s'attacher à une session déjà existante, comme il est précisé dans ce journal. Me gourre-je (j'aimerais !) ?

        • [^] # Re: vnc

          Posté par  . Évalué à 2.

          sinon c'est un peu différent, mais avec virtualbox il y a un serveur rdp, et une fois une machine virtuelle démarrée (on peut la démarrer à distance par ssh), on peut se connecter dessus avec rdesktop. Je trouve cela un peu plus rapide et pratique que par vnc.

          Sinon il y a x11vnc, mais je crois qu'il ferme la session une fois la connexion coupée.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: vnc

            Posté par  . Évalué à 4.

            non x11vnc ne ferme pas forcement la session.

            x11vnc peut servir a donner acces a la session X11 existante (celle du serveur) à distance en vnc, mais il sait aussi servir des sessions. Les options de la ligne de commande sont touffues, mais on peut faire pas mal de choses.

            Par exemple:
            - ecoute sur le port tcp/5900 via xinetd (vnc standard) et demande de user+password graphiquement (en protocole vnc), puis changement d'uid pour lancer la session X11 qui sera accessible en vnc. Dans ce mode, on peut lui demander de ne pas tuer la session a la deconnection et de la récupérer quand le meme user revient. Tout ce qu'il faut sur le client c'est un client VNC.
            - ou alors, l'utilisateur se connecte grace a sa clef ssh et le protocole VNC est tunnelé dans SSH. Dans ce mode, plus besoin de user+password et la aussi la session peut rester et etre recupérée. Pour utiliser ce mode, j'ai un peu instrumenté le .profile pour que la socket de liaison avec l'agent SSH ne change pas de nom a chaque session et du coup quand je me reconnecte, tous mes xterms et autres programmes déjà lancés récupèrent également la connection vers mon agent ssh (ma clef privée reste sur mon portable, pas question de la copier sur le serveur).

            bref, on peut faire pas mal de choses. J'ai même utilisé le mode authentification ldap, et j'ai du envoyer un patch car il y a un bug quand on veut utiliser le mode xinetd et ldap.

            • [^] # Re: vnc

              Posté par  . Évalué à 2.

              Idéalement, j'aimerai me connecter en SSH.
              Je vais me renseigner sur vnc.

        • [^] # Re: vnc

          Posté par  . Évalué à 1.

          Si si, ça marche. Nativement sur une session NX classique, et même sur une session locale : c'est la session "shadow". Par contre c'est pas aussi beau et rapide qu'une session NX classique (et si les résolutions sont différentes, c'est carrément merdique à cause du zoom), sans compter que c'est plus difficile à configurer avec freenx (il faut la bonne version, pour commencer).

          Bon, ça reste mieux que VNC.

          Sinon il y a aussi la méthode "je me connecte localement avec une session NX pour pouvoir la récupérer à distance après", mais je n'ai jamais testé (et là il faut oublier tout ce qui est 3D et compagnie).

    • [^] # Re: vnc

      Posté par  . Évalué à 2.

      Il y a x11vnc, qui s'attache à un display existant (et qui nécessite par exemple un Xorg ouvert) et rend ce display accessible par vnc en plus de l'accès local ordinaire.
      Et il y a vncserver, qui crée un display, qui n'est attaché à aucun display existant, qui ne nécessite donc pas de Xorg. Et la session reste ouverte jusqu'à ce que vncserver soit killé.
      Ce qu'il lui faut, c'est vncserver.

      http://packages.debian.org/x11vnc
      http://packages.debian.org/vncserver

      • [^] # Re: vnc

        Posté par  . Évalué à 2.

        sauf si cela a changé, vncserver oblige a convenir d'un port TCP différent pour chaque utilisateur, et de définir un "mot de passe vnc" stocké dans un fichier ... beurk

        x11vnc peut utiliser Xvnc pour créer des sessions X qui ne sont pas la session Xorg ( :0 ) du serveur, et l'utilisateur peut utiliser soit sa clef ssh, soit son mot de passe unix pour s'authentifier. De plus tous les displays crées peuvent être joignables sur le port vnc par défaut (5900) et donc plus besoin de convenir a l'avance d'un port particulier pour une personne. C'est quand même plus pratique !

        • [^] # Re: vnc

          Posté par  . Évalué à 1.

          "vncserver oblige a convenir d'un port TCP différent pour chaque utilisateur"
          Comme pour Xorg, le display :0 a le port TCP 6000, :1 a le 6001...

          "mot de passe vnc stocké dans un fichier"
          Il n'est pas hashé, certes, mais sinon je ne vois pas ce que ça a de plus laid qu'/etc/shadow.

          "x11vnc peut utiliser Xvnc pour créer des sessions X qui ne sont pas la session Xorg ( :0 ) du serveur, et l'utilisateur peut utiliser soit sa clef ssh, soit son mot de passe unix pour s'authentifier. De plus tous les displays crées peuvent être joignables sur le port vnc par défaut (5900) et donc plus besoin de convenir a l'avance d'un port particulier pour une personne. C'est quand même plus pratique !"
          Et comment fait-on pour ça ? (t'as une recette ?)

          • [^] # Re: vnc

            Posté par  . Évalué à 3.

            >Et comment fait-on pour ça ? (t'as une recette ?)

            ben c'est supporté en standard par x11vnc. il faut configurer xinetd pour qu'il ecoute sur le port 5900 et passe la connexion a x11vnc avec des options pour lui dire d'utiliser le login/passwd unix, de changer de uid pour l'utilisateur qui vient de s'authentifier, et de lancer une session X si aucune n'existe.
            C'est (mal) documenté sut le site de x11vnc ( http://www.karlrunge.com/x11vnc/ ), si tu as besoin d'exemples, j'en récupererai au boulot :-)

  • # xmove... teleport...

    Posté par  . Évalué à 2.

    Pas tout a fait ce que tu demandes mais xmove peut, peut-être faire l'affaire.. mais pas sur qu'il soit encore maintenu

    ou teleport (cf. http://packages.debian.org/unstable/x11/teleport)
    Teleport permet de déplacer des applications entre des affichages X sans les fermer et les redémarrer. Il utilise les propriétés X pour demander que les applications qui supportent le protocole de migration d'affichage se déplacent vers un autre affichage.

    • [^] # Re: xmove... teleport...

      Posté par  . Évalué à 2.

      teleport nécessitent que l'application supporte un protocole spécial, ce qui n'est le cas pour aucune des applications kde/qt/gtk que j'ai essayé...

      xmove est assez embêtant à utiliser car il faut déplacer toutes les applications une par une, et en plus il faut faire gaffe car les bureaux utilisent d'autres connexions que le display X (dbus/dcop/etc.)

  • # XPRA

    Posté par  . Évalué à 2.

    Dans les versions "modernes" de ce genre de truc (qui n'a jamais été vraiment très popularisé, je me demande pourquoi), il y a XPRA :
    http://partiwm.org/browser/README.xpra
    Il utilise les possibilités de composition des serveurs X modernes. Ça a l'air sympa, mais je n'ai pas eu le temps de tester. Je veux bien un routeur si tu l'essayes.

    • [^] # Re: XPRA

      Posté par  . Évalué à 3.

      Je veux bien un _retour_, pardon ....

Suivre le flux des commentaires

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