Google sort un serveur NX libre

Posté par (page perso) . Modéré par baud123.
42
17
juil.
2009
Internet
NX est un protocole permettant le déport de l'affichage X par dessus internet avec une bande passante limitée, utilisant une compression dédiée pour les requêtes X et ssh pour la sécurité.

La société qui en est à l'origine, NoMachine avait libéré en GPL la majorité du code en 2003, mais le serveur est resté propriétaire. Une implémentation libre du serveur existe depuis 2004 dans le projet FreeNX mais elle est écrite dans un mélange de Bash, d'expect et de C ce qui pour Google la rend difficile à maintenir.

Il y a quelques semaines, Google a donc sorti un nouveau serveur NX sous GPLv2, Neatx, majoritairement écrit en python.
  • # Chrome OS

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

    Serait-ce pour préparer la sortie de Chrome OS? Un système minimal en local qui récupère le système qui tourne sur un serveur (Internet).

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Ça pour une nouvelle ..

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

    C'est une bonne nouvelle ;-)

    J'espère que cela ne proposera pas trop de problèmes avec FreeNX et que les 2 pourront travailler ensemble pour avoir le meilleurs code possible (FreeNX fonctionnant déjà très bien même pour un usage 'pro').

    La seule fonctionnalité qui me manquerait actuellement serait de pouvoir reprendre une session déjà ouverte en local (un peu comme RDP), mais je ne sais pas si c'est techniquement possible.

    De plus j'avais entendu parlé/trollé d'une possible intégration de NX dans Xorg, est ce que cela est toujours d'actualité ? (si quelqu'un à des infos).

    Ps: Apparement pour le moment il n'y a pas encore de release téléchargeable ? (uniquement le svn).
    • [^] # Re: Ça pour une nouvelle ..

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

      La seule fonctionnalité qui me manquerait actuellement serait de pouvoir reprendre une session déjà ouverte en local (un peu comme RDP), mais je ne sais pas si c'est techniquement possible.

      C'est disponible dans la version propriétaire gratuite de NoMachine (type de connexion shadow), ça ne marche pas trop mal sur les dernières versions.
      • [^] # Re: Ça pour une nouvelle ..

        Posté par . Évalué à 2.

        Chez moi ça marche (tm) avec serveur freenx et le client de nomachine, je peut très bien laisser une session ouverte et la reprendre plus tard en me reconnectant, ce qui est un peu particulier par contre c'est qu'il faut reprendre la session à partir du même ordinateur client, ce qui n'est pas forcément très pratique.
        • [^] # Re: Ça pour une nouvelle ..

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

          Je connais le session shadow (reprendre la même session ouverte via NX), mais je ne vois pas comment reprendre une session locale (ouverte sur le poste ou je travaille tout les jours) depuis un poste distant.

          Mais si vous avez la technique pour ce que je demande, n'hésitez pas à partager !
          • [^] # Re: Ça pour une nouvelle ..

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

            Il faut pour cela lancer un x11vnc sur le poste sur lequel tu bosses tout les jours.

            J'ai présenté une conférence sur la prise en main à distance l'année dernière. Les transparents sont ici : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)
            PDF : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)
            La partie sur x11vnc : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)

            En mode "xtightvnc" (lancé depuis le client), la prise en main sur une machine reliée à l'ADSL est assez fluide (80-90% de ce que l'on ressent sur une machine locale)
            • [^] # Re: Ça pour une nouvelle ..

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

              Cela permet-il de reprendre une session à distance comme screen le permet pour la ligne de commande ?
              • [^] # Re: Ça pour une nouvelle ..

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

                x11vnc permet d'accéder à la session de l'utilisateur X11/Xorg local (DISPLAY=:0.0). Si celui-ci a ouvert une session X ET qu'il a lancé le programme "x11vnc", alors l'utilisateur à distance peu prendre la main sur la session de l'utilisateur local, et interagir avec celle-ci. Les deux utilisateurs utilisent alors les mêmes écran/clavier/souris.

                C'est l'usage parfait pour, à distance, montrer quelque chose à l'utilisateur local.

                Tant que le programme "x11vnc" est lancé, l'utilisateur à distance peut interagir

                Sur ma passerelle Linux, les (rares) fois où j'ai besoin de lancer une application graphique à distance, je passe par un x11vnc. Le fait de fermer la session distante, puis d'y revenir plus tard, ne ferme pas les applications précédemment lancées (exactement comme un "screen" en ligne de commande).

                Les inconvénients de x11vnc :
                - il faut qu'un serveur X soit lancé : consommation de mémoire et de CPU
                - si on veut avoir plusieurs personnes connectés sur la même machine, il faut à chaque fois un serveur X différent.
                - ne peut pas fonctionner si personne n'a ouvert de session X: Si l'écran affiche uniquement un kdm/gdm/xdm/etc, alors la prise en main graphique à distance ne marche pas.

                Conclusion : Cela ne fait pas du tout le même boulot que du NX. Mais pour une utilisation mono utilisateur, cela marche très bien.
    • [^] # Re: Ça pour une nouvelle ..

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

      Étant donné qu'ils ont tout réécrit en python (plus un peu de bash et de C) parce qu'ils trouvaient le code de FreeNX trop bordélique/non maintenable, je doute qu'il puisse y avoir beaucoup d'échanges.
      • [^] # Re: Ça pour une nouvelle ..

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

        Bref au lieu d'avoir bash + expect + C, il ont bash + python + C.... Pourquoi ne pas avoir choisis un seul langage pour tout écrire ?
        • [^] # Re: Ça pour une nouvelle ..

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

          Ouais enfin quand on lit le lien donné dans la news on à ça : "It is written in Python, with the exception of very few wrapper scripts in BASH and one program written in C for performance reasons."

          Donc c'est presque que du Python.
          • [^] # Re: Ça pour une nouvelle ..

            Posté par . Évalué à 4.

            Il y a toujours plus ou moins du C dans le python.

            Python + C est un concept d'avenir et plutôt intelligent. C'est quelque chose qui se fait de plus en plus dans le calcul scientifique notamment.

            Écrire en C les parties qui ont des contraintes de performance et combiner l'utilisation de ces libraires dans du code en python.

            Comme ça tu gagnes en lisibilité et tu ne perds presque rien en performance, parce que la partie python est essentiellement de la glue.
            • [^] # Re: Ça pour une nouvelle ..

              Posté par . Évalué à 2.

              Et pour ça, il y a aussi Cython.
            • [^] # Re: Ça pour une nouvelle ..

              Posté par . Évalué à 2.

              Un concept d'avenir sauf que c'est inutilisable avec Jython et IronPython qui sont censés améliorer la vitesse de Python il me semble. (et le C reste chiant à écrire et à maintenir)
              • [^] # Re: Ça pour une nouvelle ..

                Posté par . Évalué à 1.

                L'amélioration de la vitesse n'est il me semble pas la priorité, c'est plutôt de pouvoir se servir des bibliothèques de .Net et Java.

                Sinon j'ai était voir la page du projet et j'ai une petite question, quelle sont les différences avec Rpython (langage d'implémentation de Pypy ) ? est ce que le sous ensemble utilisable est plus clairement spécifié ?
      • [^] # Re: Ça pour une nouvelle ..

        Posté par . Évalué à 4.

        A priori, le mainteneur officiel, à la base de FreeNX, ne donne plus trop de nouvelles :
        http://mail.kde.org/pipermail/freenx-knx/2009-April/008111.h(...)

        Certains développeurs ont eu exactement la même idée que Google, de leur côté :
        http://mail.kde.org/pipermail/freenx-knx/2009-April/008115.h(...)
        https://launchpad.net/tacix
    • [^] # Re: Ça pour une nouvelle ..

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

      J'espère que cela ne proposera pas trop de problèmes avec FreeNX et que les 2 pourront travailler ensemble

      Le point de départ de neatx était justement la branche freenx-redesign (le dev principal de freenx + 2-3 employés de google). Depuis, freenx est un peu mort (pas de nouvelles du dev depuis novembre), et ceux de Google ont donc continué "dans leur coin". Comme déjà cité, freenx est difficile à maintenir et à faire évoluer, et je vois neatx comme son successeur/remplaçant.

      Ps: Apparement pour le moment il n'y a pas encore de release téléchargeable ? (uniquement le svn).

      Il y a la 0.3.0 et la 0.3.1 mais elles sont déjà marquées "deprecated" ;)
  • # NX est…

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

    … une grosse usine à gaz capable de faire plein de trucs.

    En fait, ce sont deux choses :
    - un protocole de compression d'X11, très simple à utiliser avec un « proxy NX » qui encapsule et décapsule à chaque bout, à la ss -X ;
    - un serveur overkill pour faire de la session à distance.
    • [^] # Re: NX est…

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

      ssh -X, pardon, pas ss -X.
    • [^] # Re: NX est…

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

      Très simple ? Tant que j'ai pas un paquet à installer en une commande, et deux lignes à changer dans un fichier de configuration, ce sera trop compliqué :D

      Envoyé depuis mon lapin.

      • [^] # Re: NX est…

        Posté par . Évalué à 3.

        Les paquets de la freenx-team sur launchpad.net marchent très bien sur ma Debian Sid @home et ma Jaunty @work : https://launchpad.net/~freenx-team/+archive/ppa

        Rien à faire, on installe les paquets et ça tourne... Il y a même le shadowing de session locale qui marche (mais c'est pas aussi rapide et pratique que les sessions NX classique, surtout si on a des résolutions différentes entre les deux postes, ou si on utilise plusieurs écrans).
      • [^] # Re: NX est…

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

        Oui, bon, ce n'est pas forcément simple à mettre en œuvre, mais le résultat est plus simple que de se payer un bureau entier. Comme je suis à peu près le seul sur le web à avoir tenté un truc pareil, je l'ai document, si d'autres voulaient faire pareil : http://www.lea-linux.org/documentations/index.php/Leapro-pro(...)
        • [^] # Re: NX est…

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

          Super, merci, ça fait une sorte de ssh -NX comme demandé plus haut, réalisé 'manuellement', avec certes la nécessité d'avoir nxproxy de part et d'autre.
          A voir, si ça peut se scripter, mais ça correspond bien à ce que je souhaitais avoir (déporter de manière mieux compressée l'affichage de quelques fenêtres graphiques sans avoir à transporter un bureau entier, ni avoir à installer freenx trop usine à gaz pour moi).
        • [^] # Re: NX est…

          Posté par . Évalué à 4.

          Je viens d'essayer, ça marche niquel, en plus c'est fait qu'avec des composants libres donc ça me va très bien. Merci pour ce tutorial !


          Par contre j'ai suivi bêtement les instructions que tu avais rédigées, et j'avais l'erreur
          Warning: X connection failed with error 'No protocol specified'.
          à chaque fois que j'essayais de lancer une commande graphique.

          J'ai donc remplacé
          poste_distant$ xauth add poste_distant/unix:0 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703
          par
          poste_distant$ xauth add poste_distant/unix:8 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703

          C'est-à-dire le port 8 au lieu de 0. Je pense qu'il doit s'agir d'une erreur dans ton tutorial, ou nos versions de nxproxy ne fonctionnent pas pareil.


          Je vais essayer de faire un petit programme qui automatise tout ça pour avoir une version facile à mettre en oeuvre.
          • [^] # Re: NX est…

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

            Je pense qu'il doit s'agir d'une erreur dans ton tutorial

            Une erreur ? Quelle erreur, mon tuto parle bien de :8… ;-)

            Bon, sérieusement, merci, c'est corrigé.
          • [^] # Re: NX est…

            Posté par . Évalué à 2.

            J'ai fait mon petit script pour automatiser le tout, le voilà si ça intéresse quelqu'un.

            C'est fait à la main vite fait, si quelqu'un a des suggestions pour améliorer ça, n'hésitez pas !



            Sur le poste distant, il faut avoir un fichier batch, je l'ai appelé setup_nx

            #! /bin/sh
            COOKIE=$(echo "$1" | sed s/HOSTNAME/$(hostname)/)

            nxproxy -C link=adsl localhost:8 &
            xauth add $COOKIE $2 $3 $4 $5
            export DISPLAY=":8"
            xterm



            Sur le poste client, j'ai un fichier batch ssh_nx :

            #! /bin/sh

            COOKIE=$(xauth list | grep $(hostname) | sed s/$(hostname)/HOSTNAME/ | sed s/unix:0/unix:8/)

            echo $COOKIE

            nxproxy -S &

            sleep 2

            echo $COOKIE

            ssh -f -R localhost:4008:localhost:4008 $1 "/chemin/setup_nx $COOKIE"



            Les deux gros problèmes qui me restent sont :

            × je dois tuer le processus ssh du client "à la main" à la fin de ma session
            × je dois appeler xterm (ou un autre terminal graphique), parce que je n'ai pas trouvé de moyen simple de lancer des commandes et en même temps d'avoir un pseudo terminal.

            Une option que je vois (qui résoudrait les deux problèmes) est de changer le shell de mon utilisateur, mais je n'aime pas cette option...

            Si vous avez des suggestions, je suis preneur.
            • [^] # Re: NX est…

              Posté par . Évalué à 2.

              Merci pour la suggestion de script. J'ai eu quelques soucis également pour faire marcher le système, à cause des autorisations avec 'xauth' .

              J'ai modifié le script proposé pour n'avoir besoin que d'un script coté local, ssh_nx :

              #! /bin/sh

              if [ $# -lt 2 ]; then
              echo "Usage: $(basename $0) [compte@]machine commande"
              echo "Exemple: $(basename $0) fred@mamachine xclock -update 1"
              exit 1
              fi

              adresse=$1
              shift
              machineL=$(hostname)
              machineD=$(echo $adresse | sed -e 's/^.*@//')

              COOKIE=$(xauth list | grep $machineL | sed -e s/$machineL/$machineD/ -e s/unix:0/unix:8/)
              echo "COOKIE='$COOKIE'"

              nxproxy -S timeout=60 &
              nxprocessL=$!

              ssh -x -R localhost:4008:localhost:4008 $adresse " \
              set -x -e ;
              nxproxy -C link=adsl localhost:8 &
              nxprocessD=\$! ;
              xauth add $COOKIE ;
              export DISPLAY=:8 ;

              $* ;

              kill -HUP \$nxprocessD ;
              xauth remove $machineD:8 ;
              rm -f /tmp/.X11-unix/X8
              "

              # au cas où
              kill -HUP $nxprocessL 2>/dev/null
              • [^] # Re: NX est…

                Posté par . Évalué à 2.

                Super, j'avais voulu faire juste un script côté client et j'avais pas trouvé.

                Je n'avais pas pensé à mettre envoyer commandes à ssh...
  • # Et le client ?

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

    Le serveur c'est déjà une bonne chose, mais il manque encore le client libre !
  • # Question et question

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

    Question : vis à vis de SPICE (Red-Hat), les deux se positionnent comment l'un de l'autre ?

    Question subsidiaire : Google va-t'il pousser à l'intégration dans Xorg et dans ssh.

    Autre question : NX peut faire proxy VNC ou RDP. C'est très pratique pour atteindre une machine à l'intérieur de son parc mais je ne sais pas faire "simplement" avec du proxy NX ! En gros, il est plus facile depuis chez soi en ADSL d'atteindre via un serveur ssh ou il y a NX son poste de boulot Windows (RDP) que son poste Linux (X) !
  • # Comparaison

    Posté par . Évalué à 3.

    Quelqu'un pourrait comparer cette technologie avec TSE ? Car elle joue dans la même cour, nan ?
  • # Ne pas oublier xrdp !

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

    Je rappelle aussi l'existence du projet xrdp [http://xrdp.sourceforge.net/]. Qui, d'après mon expérience, marche plutôt bien en utilisant le serveur dédié (X11rdp), moins bien avec x11vnc comme back-end.

    Au chapitre des problèmes, le serveur X11rdp est casse-pieds à compiler, la redirection du son ne marche pas à ma connaissance, et les environnements de bureau ne peuvent pas faire la différence avec un serveur X standard (les machines Windows détectent que la session tourne sous RDP et dégagent un certain nombre d'effets graphiques comme le fond d'écran pour accélérer l'affichage).

    En revanche, pouvoir se connecter chez soi depuis n'importe quel PC sans installer de soft supplémentaire (un coup de mstsc, et zou !), c'est très appréciable...

    Envoyé depuis mon PDP 11/70

Suivre le flux des commentaires

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