
             Petit guide d'excution  distance des applications X

Version franaise du _Remote X Apps mini-HOWTO_

Vincent Zweije < zweije@xs4all.nl>

   V 0.7.5, 8 dcembre 2001
     _________________________________________________________________

   _Ce petit guide dcrit comment excuter des applications X  distance.
   C'est--dire, comment faire pour qu'un programme X s'affiche sur un
   cran d'ordinateur diffrent de celui sur lequel il s'excute. Ou,
   autrement dit, comment faire tourner un programme X sur un ordinateur
   diffrent de celui devant lequel vous tes assis. L'accent de ce petit
   guide sera mis sur les questions de scurit. Ce petit guide contient
   galement des informations sur la manire de faire tourner des
   applications X en local, mais avec un identificateur d'utilisateur
   (user-id) diffrent ainsi que des informations sur la faon de mettre
   en place un ordinateur comme terminal X. Adaptation franaise :
   Albert-Paul Bouillot, Frdric Bothamy fbothamy@mail.dotcom.fr.
   Relecture de la version franaise : Olivier Kaloudoff kalou@kalou.net._
     _________________________________________________________________

1. Introduction

   Ce petit guide constitue un guide sur la manire de faire tourner des
   applications X  distance. J'ai rdig ce document pour plusieurs
   raisons :

    1. Il y a eu de nombreuses questions, sur Usenet, sur la manire de
       faire tourner des applications X  distance ;
    2. J'ai vu beaucoup, beaucoup de conseils d'utilisation de  xhost
       +hostname  ou mme de  xhost +  pour raliser des connexions X.
       _C'est d'une inscurit totale_, et il existe de bien meilleures
       mthodes ;
    3. Je n'ai pas connaissance d'un document simple dcrivant les
       options dont _on peut_ disposer. Si vous avez des informations
       complmentaires, s'il vous plat, faites-le moi savoir (en
       anglais) : <zweije@xs4all.nl>.

   Ce document a t crit en pensant  des systmes de type Unix. Si le
   systme d'exploitation de votre ordinateur local ou de celui qui est 
   distance est de type diffrent, vous devriez trouver ici des
   informations sur la manire dont les choses se passent. Cependant, il
   vous faudra modifier les exemples par vous-mme pour les utiliser sur
   votre propre systme.

   La version (anglaise) la plus rcente de ce document est toujours
   disponible sur le WWW  http://www.xs4all.nl/~zweije/xauth.html. Il
   est galement disponible en tant que mini-HOWTO Linux  Applications X
    distance  (Remote X Apps)  :
   http://www.tldp.org/HOWTO/mini/Remote-X-Apps. Les (mini-)HOWTO du
   projet de documentation Linux (LDP) sont disponibles par http ou ftp
   sur www.tldp.org.

   La version franaise la plus rcente de ce document est toujours
   disponible sur le site du projet traduc.org 
   http://www.traduc.org/docs/HOWTO/mini/lecture/Remote-X-Apps.html.

   Ceci constitue la version 0.7.5. Aucune garantie, seulement de bonnes
   intentions. Je suis ouvert aux suggestions, ides, ajouts, pointeurs
   utiles, corrections (typo), et ctera. Je veux que cela reste un
   document simple et lisible, dans la bonne moyenne du style des guides
   pratiques du projet de documentation Linux. Les querelles seront
   rediriges vers /dev/null. Ce document est diffus sous la version 1.1
   de la licence GNU Free Documentation Licence. _This document is
   released under version 1.1 of the GNU Free Documentation Licence_.

   Le contenu de ce petit guide a t mis  jour le 8 dcembre 2001 par
   Vincent Zweije. La version franaise de ce document a t mise  jour
   le 4 mars 2003 par Frdric Bothamy. La relecture de cette nouvelle
   version franaise a t ralise par Olivier Kaloudoff.

2. Lectures complmentaires

   Un document, en rapport avec cela, sur le WWW traite de  Que faire
   quand Tk dit que votre cran n'est pas sr ,
   http://ce-toolkit.crd.ge.com/tkxauth/. Il a t crit par Kevin Kenny.
   Il suggre une solution similaire  celle de ce document pour
   l'authentification X (xauth). Cependant, Kevin vise plus 
   l'utilisation de xdm pour diriger xauth  votre place.

   On m'a indiqu que le volume 8 de la srie consacre au systme X
   Window, le  Guide de l'administrateur du systme X Window  de chez
   O'Reilly and Associates tait une bonne source d'informations.
   Cependant, ce guide n'a pas t mis  jour depuis sa publication
   d'origine en 1992. Il ne couvre donc que X11R4 et X11R5, tout ce qui
   est spcifique  X11R6 n'est pas couvert.

   Il y a galement un autre document qui ressemble beaucoup  celui que
   vous tes en train de lire, dont le titre est  Securing X Windows ,
   et qui est disponible 
   http://ciac.llnl.gov/ciac/documents/ciac2316.html.

   Consultez galement les forums de diffusion Usenet, tels que :
   comp.windows.x, comp.os.linux.x et comp.os.linux.networking.

3. Le contexte

   Vous utilisez deux ordinateurs. Sur le premier, vous tes dans
   l'environnement X Window pour taper au clavier et regarder l'cran.
   Sur le second, vous effectuez un important traitement graphique. Vous
   voulez que les sorties du second soient affiches sur l'cran du
   premier. Le systme X Window rend cela possible.

   Naturellement, vous devez disposer d'une connexion  un rseau pour
   pouvoir le raliser. De prfrence rapide, car le protocole X est un
   dvoreur de ressources rseau. Mais, avec un peu de patience et un
   protocole de compression de donnes adapt, vous pouvez mme faire
   tourner des applications par l'intermdiaire d'un modem. Pour un
   protocole de compression pour X, vous pouvez aller consulter les
   sites : dxpc http://www.vigor.nu/dxpc/ ou LBX
   http://www.traduc.org/docs/HOWTO/mini/lecture/LBX.html (disponible en
   version originale sur le site de l'auteur :
   http://www.paulandlesley.org/faqs/LBX-HOWTO.html).

   Vous avez deux choses  faire pour raliser tout cela :

    1. Indiquer  l'unit d'affichage locale (le serveur) qu'elle doit
       accepter les connexions venant de l'ordinateur  distance.
    2. Dire  l'application  distance (le client) de rediriger ses
       sorties vers votre unit d'affichage locale.

4. Un peu de thorie

   Le mot magique est DISPLAY (unit d'affichage). Dans le systme X
   Window, une unit d'affichage est constitue (en simplifiant) d'un
   clavier, d'un mulot et d'un cran. Une unit d'affichage est gre par
   un programme serveur, plus connu sous le nom de serveur X. Le serveur
   fournit des fonctionnalits d'affichage aux autres programmes qui se
   connectent  lui.

   Une unit d'affichage est identifie par un nom, de type, par
   exemple :

     * DISPLAY=light.uni.verse:0
     * DISPLAY=localhost:4
     * DISPLAY=:0

   Un nom d'unit d'affichage est constitu d'un nom d'hte (par
   exemple : light.uni.verse et localhost), du signe deux point (:), et
   d'un numro de squence (tels que 0 et 4). Le nom d'hte de l'unit
   d'affichage est le nom de l'ordinateur sur lequel tourne le serveur X.
   Si le nom de l'hte est omis, cela signifie qu'il s'agit de
   l'ordinateur local. D'habitude, le numro de squence est 0 - cela
   peut changer s'il y a plusieurs units d'affichage connectes sur le
   mme ordinateur.

   Si jamais il vous arrive de voir le nom d'une unit d'affichage avec
   un .n supplmentaire accol  son nom, c'est qu'il s'agit d'un numro
   d'cran. Une unit d'affichage peut, en thorie, avoir plusieurs
   crans. Cependant, d'habitude, il n'y en a qu'un, qui porte le numro
   n=0, et c'est le numro par dfaut.

   D'autres formes de DISPLAY existent, mais celle-ci suffira pour notre
   propos.

   Pour celui qui est curieux de technique :
     * hostname:D.S signifie cran S sur unit d'affichage D de l'hte
       hostname : le serveur X de cette unit d'affichage est  l'coute
       du port TCP 6000+D.
     * host/unix:D.S signifie cran S sur unit d'affichage D de l'hte
       host : le serveur X de cette unit d'affichage est  l'coute du
       socket de domaine UNIX /tmp/.X11-unix/XD (et donc, seul host peut
       l'atteindre).
     * :D.S est quivalent  host/unix:D.S, o host est le nom de l'hte
       local.

5. Dire au client ...

   Le programme client (par exemple, votre application graphique) sait 
   quelle unit d'affichage il doit se connecter en consultant la
   variable d'environnement DISPLAY. Cependant ce paramtrage peut tre
   modifi en lanant le client avec l'argument -display hostname:0 dans
   la ligne de commande. Quelques exemples peuvent clarifier les choses.

   Notre ordinateur est connu du monde extrieur sous le nom light, et
   nous sommes dans le domaine uni.verse. Si nous fonctionnons avec un
   serveur X normal, l'unit d'affichage est connue comme tant
   light.uni.verse:0. Nous voulons faire tourner le programme de dessin
   xfig sur un ordinateur  distance, appel dark.matt.er, et afficher sa
   sortie ici, sur light.

   Supposons que vous vous soyez dj connect par telnet  l'ordinateur
   distant, dark.matt.er.

   Si l'interprteur de commande de l'ordinateur loign est csh :

dark% setenv DISPLAY light.uni.verse:0
dark% xfig &

   Ou, d'une autre manire :

dark% xfig -display light.uni.verse:0 &

   Si c'est sh qui tourne sur l'ordinateur  distance :

dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &

   Ou, autrement :

dark$ DISPLAY=light.uni.verse:0 xfig &

   Ou, bien sr, galement :

dark$ xfig -display light.uni.verse:0 &

   Il parat que certaines versions de telnet transmettent
   automatiquement la variable DISPLAY  l'ordinateur hte loign. Si
   vous avez l'une de celles-ci, vous avez de la chance, et c'est
   effectivement automatique. Si ce n'est pas le cas, la plupart des
   versions de telnet _doivent_ transmettre la variable d'environnement
   TERM, et avec un bidouillage judicieux, il est possible de superposer
   la variable DISPLAY sur la variable TERM.

   L'ide, sous-jacente  cette superposition, est de raliser une sorte
   de script pour effectuer ceci : avant la connexion par telnet, donnez
   la valeur de DISPLAY  TERM. Puis, lancez telnet. Du ct de
   l'ordinateur distant, dans le fichier .*shrc concern, lisez la valeur
   de DISPLAY  partir de TERM.

6. Dire au serveur ...

   Le serveur n'acceptera pas de connexions venant de n'importe o. Vous
   ne voulez pas que n'importe qui puisse afficher des fentres sur votre
   cran. Ou lire ce vous tapez - souvenez-vous que votre clavier fait
   partie de votre unit d'affichage !

   Trop peu de gens semble raliser que permettre l'accs  leur unit
   d'affichage pose des problmes de scurit. Quelqu'un qui dispose d'un
   accs  votre unit d'affichage peut lire et crire sur vos crans,
   lire vos frappes au clavier, et suivre les dplacements de votre
   mulot.

   La plupart des serveurs disposent de deux manires d'authentifier les
   demandes de connexions qui arrivent : le mcanisme de la liste d'htes
   (xhost) et le mcanisme du mot de passe secret (magic cookie) (xauth).
   De plus, il y a ssh, l'interprteur de commande scuris, qui peut
   acheminer les connexions X.

   Veuillez noter que certains serveurs X (de XFree86) peuvent tre
   configurs pour ne pas couter sur le port habituel TCP avec le
   paramtre -nolisten tcp. La configuration par dfaut de Debian
   GNU/Linux, notamment, dsactive l'coute sur le port TCP par le
   serveur X. Si vous dsirez utiliser X  distance sur un systme
   Debian, vous devriez ractiver ceci en modifiant la faon dont est
   lanc le serveur X. Veuillez voir le fichier /etc/X11/xinit/xserverrc
   pour un point de dpart.

6.1 Xhost

   Xhost permet les accs bass sur les nom d'htes. Le serveur
   entretient une liste des htes qui sont autoriss  se connecter 
   lui. Il peut aussi dsactiver compltement la vrification des htes.
   Attention : cela signifie que plus aucun contrle n'est effectu, et
   donc, que _n'importe quel_ hte peut se connecter !

   Vous pouvez contrler la liste des htes du serveur avec le programme
   xhost. Pour utiliser ce mcanisme dans l'exemple prcdent, faites :

light$ xhost +dark.matt.er

   Ceci permet toutes les connexions  partir de l'hte dark.matt.er. Ds
   que votre client X a ralis sa connexion et affiche une fentre, par
   scurit, supprimez les permissions pour d'autres connexions avec :

light$ xhost -dark.matt.er

   Vous pouvez dsactiver la vrification des htes avec :

light$ xhost +

   Ceci dsactive la vrification des accs des htes et donc permet 
   _tout le monde_ de se connecter. Vous ne devriez _jamais_ faire cela
   sur un rseau o vous n'avez pas confiance dans _tous_ les
   utilisateurs (tel internet). Vous pouvez ractiver la vrification des
   htes avec :

light$ xhost -

   xhost - par lui-mme _ne supprime pas_ tous les htes de la liste
   d'accs (ce qui serait tout  fait inutile - vous ne pourriez plus
   vous connecter de n'importe o, pas mme de votre hte local).

   _Xhost est un mcanisme vraiment trs peu sr._ Il ne fait pas de
   distinction entre les diffrents utilisateurs sur l'hte  distance.
   De plus, les noms d'htes (en ralit des adresses) peuvent tre
   manipuls. C'est mauvais si vous vous trouvez sur un rseau douteux
   (dj, par exemple, avec un accs PPP tlphonique  Internet).

6.2 Xauth

   Xauth autorise l'accs  tous ceux qui connaissent le bon secret. On
   appelle un tel secret un enregistrement d'autorisation ou cookie. Ce
   mcanisme d'autorisation est dsign crmonieusement comme tant le
   MIT-MAGIC-COOKIE-1.

   Les cookies pour les diffrentes units d'affichage sont stocks
   ensemble dans ~/.Xauthority. Votre fichier ~/.Xauthority doit tre
   inaccessible pour les utilisateurs groupe/autres. Le programme xauth
   gre ces cookies, d'o le surnom xauth dans ce schma.

   Vous pouvez spcifier un fichier cookie diffrent avec la variable
   d'environnement XAUTHORITY, mais vous aurez rarement besoin de le
   faire. Si vous ne savez pas quel fichier cookie votre xauth utilise,
   faites un xauth -v et il vous l'indiquera.

   Au dmarrage d'une session, le serveur lit un cookie dans le fichier
   qui est indiqu par l'argument -auth. Ensuite, le serveur ne permet la
   connexion que des clients qui connaissent le mme cookie. Quand le
   cookie dans ~/.Xauthority change, _le serveur ne rcuprera pas la
   modification_.

   Les serveurs les plus rcents peuvent gnrer des cookies  la vole
   pour des clients qui le demandent. Les cookies sont cependant encore
   conservs dans le serveur : ils ne finissent pas dans ~/.Xauthority 
   moins qu'un client ne les y mettent. Selon David Wiggins :

     Une possibilit supplmentaire , qui peut vous intresser, a t
     ajoute dans X11R6.3. Par l'intermdiaire de la nouvelle extension
     SECURITY, le serveur X lui-mme peut gnrer et renvoyer de
     nouveaux cookies  la vole. De plus, on peut dsigner les cookies
     comme tant  douteux  de sorte que les applications qui se
     connectent avec de tels cookies auront une capacit opratoire
     restreinte. Par exemple, ils ne pourront pas regarder les entres
     au clavier/mulot, ou le contenu des fentres, d'autres clients
      fiables . Il y a une nouvelle sous-commande  generate  de
     xauth pour rendre cette fonctionnalit, pas forcment facile, mais
     au moins possible  utiliser.

   Xauth possde un avantage clair, au niveau de la scurit, sur xhost.
   Vous pouvez limiter l'accs  des utilisateurs spcifiques sur des
   ordinateurs spcifiques. Il ne permet pas l'usurpation d'adresse comme
   le permet xhost. Et, si vous le dsirez, vous pouvez encore utiliser
   xhost en parallle pour permettre des connexions.

  Fabrication du cookie

   Si vous voulez utiliser xauth, vous devez lancer le serveur X avec
   l'argument -auth authfile. Si vous utilisez le script _startx_ pour
   lancer le serveur X, c'est le bon endroit pour le faire. Crez
   l'enregistrement d'autorisation comme indiqu ci-dessous dans votre
   script startx.

   Extrait de /usr/X11R6/bin/startx :

mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

   Mcookie est un petit programme du paquet util-linux, site primaire
   ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux. Autrement, vous
   pouvez utiliser md5sum pour crer quelques donnes alatoires (de, par
   exemple, /dev/urandom ou ps -axl) au format cookie :

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

   Si vous ne pouvez pas diter le script startx (parce que vous n'tes
   pas root), demandez  votre administrateur systme de configurer
   startx correctement, ou,  la place, laissez-le configurer xdm. S'il
   ne peut, ou ne veut, pas, vous pouvez crire un script ~/.xserverrc.
   Si vous avez ce script, il sera excut par xinit au lieu du vritable
   serveur X. Alors, vous pourrez lancer le serveur X vritable  partir
   de ce script avec les arguments adapts. Pour faire cela, faites
   utiliser par votre ~/.xserverrc le mcookie de la ligne ci-dessus pour
   crer un cookie puis lancer le vritable serveur X :

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

   Si vous utilisez xdm pour grer vos sessions X, vous pouvez utiliser
   xauth facilement. Dfinissez les ressources du DisplayManager.authDir
   dans /etc/X11/xdm/xdm-config. Xdm passera l'argument -auth au serveur
   X  son dmarrage. Au moment de la connexion sous xdm, xdm place le
   cookie dans ~/.Xauthority pour vous. Consultez xdm(1) pour de plus
   amples informations. Par exemple, mon /etc/X11/xdm/xdm-config contient
   la ligne suivante :

DisplayManager.authDir: /var/lib/xdm

  Transfert du cookie

   Maintenant que vous avez lanc votre session X sur le serveur hte
   light.uni.verse et que vous avez votre cookie dans ~/.Xauthority, il
   vous faut transfrer le cookie sur le client, dark.matt.er. Il y a
   plusieurs faons de le faire.

  Rpertoires personnels (home) partags

   Le plus simple est que vos rpertoires sur light et dark soient
   partags. Les fichiers ~/.Xauthority sont les mmes, donc le cookie
   est transfr instantanment. Cependant, il y a un pige : lorsque
   vous mettez un cookie pour :0 dans ~/.Xauthority, dark va croire que
   c'est un cookie pour lui au lieu de light. Il faut que vous utilisiez
   un nom d'hte explicite  la cration du cookie : on ne peut pas faire
   autrement. Vous pouvez installer le mme cookie pour,  la fois, :0 et
   light:0 avec un peu d'astuce :

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

  En utilisant le shell  distance, rsh

   Si les rpertoires _home_ ne sont pas partags, vous pouvez transfrer
   le cookie au moyen de rsh, le shell  distance :

light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -

    1. Extraire le cookie de votre fichier local ~/.Xauthority (xauth
       nlist :0).
    2. Le transfrer vers dark.matt.er (| rsh dark.matt.er).
    3. Le mettre dans ~/.Xauthority l (xauth nmerge -).

   Notez l'utilisation de ${HOST}. Vous devez transfrer le cookie qui
   est explicitement associ  l'hte local. Une application X distante
   interprterait une valeur d'unit d'affichage gale  :0 comme tant
   une rfrence  la machine distante, ce qui ne correspond pas  ce que
   l'on veut !

  Manuellement, par Telnet

   Il est possible que rsh ne fonctionne pas chez vous. En plus de cela,
   rsh a un inconvnient en ce qui concerne la scurit (noms d'htes
   usurps, si je me souviens bien). Si vous ne pouvez, ou ne voulez, pas
   utiliser rsh, vous pouvez galement transfrer le cookie manuellement,
   comme ceci :

light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth
Using authority file /home/zweije/.Xauthority
xauth> add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926
xauth> exit
Writing authority file /home/zweije/.Xauthority
dark% xfig &
[15332]
dark% logout
light$

   Consultez galement rsh(1) et xauth(1x) pour de plus amples
   informations.

  En automatisant la mthode Telnet

   Il doit tre possible de superposer le cookie sur la variable TERM ou
   DISPLAY quand vous utilisez telnet sur l'hte loign. Cela doit
   fonctionner de la mme manire que de superposer la variable DISPLAY
   sur la variable TERM. Regardez la section 5 : Dire au client. De mon
   point de vue, sur ce sujet, vous prenez vos responsabilits, mais cela
   m'intresse si quelqu'un peut me confirmer ou m'infirmer cela.

   Notez, cependant, qu'avec certains Unix les variables d'environnement
   peuvent tre visibles par les autres et vous ne pourrez pas empcher
   la visualisation du cookie dans $TERM si certains veulent le voir.

  Utilisation du cookie

   Une application X, telle que xfig ci-dessus, sur dark.matt.er, ira
   automatiquement voir le cookie dans ~/.Xauthority pour s'authentifier.

   L'utilisation de localhost:D entrane une petite difficult. Les
   applications X clientes traduisent localhost:D en host/unix:D pour
   effectuer la recherche du cookie. Effectivement, cela signifie qu'un
   cookie pour localhost:D dans votre ~/.Xauthority n'a _aucun_ effet.

   Si l'on y rflchit, c'est logique. L'interprtation de localhost
   dpend entirement de la machine sur laquelle s'effectue cette
   interprtation. Si ce n'tait pas le cas, cela causerait un horrible
   bazar dans le cas d'un rpertoire personnel (home) partag, par
   exemple par l'intermdiaire de NFS, avec plusieurs htes interfrant
   chacun avec ses propres cookies.

6.3 Ssh

   Les enregistrements d'autorisation sont transmis sur le rseau sans
   codage. Si vous vous souciez de ce que l'on puisse espionner vos
   connexions, utilisez ssh, le shell scuris. Il effectuera des
   transmissions X scurises au moyen de connexions chiffres.

   Pour activer la transmission X par ssh, utilisez l'option de la ligne
   de commande -X ou crivez ce qui suit dans votre fichier local de
   configuration de ssh :

Host remote.host.name
  ForwardX11 yes

   Le serveur ssh (sshd) du ct distant positionnera automatiquement la
   variable DISPLAY sur l'extrmit du tunnel X transmis. Le tunnel
   distant rcupre son propre cookie ; le serveur ssh distant le gnre
   pour vous et le place dans ~/.Xauthority l-bas. Ainsi, l'autorisation
   X avec ssh est compltement automatique.

   De plus, il est gnial pour d'autres choses aussi. C'est une bonne
   amlioration structurelle de votre systme. Allez simplement voir
   http://www.ssh.org/, la page d'accueil de ssh.

   Si vous possdez d'autres informations sur les mthodes
   d'authentification ou de chiffrement des connexions X, par exemple,
   grce  Kerberos, envoyez-les moi, je les intgrerai ici.

7. Les applications X avec un identificateur d'utilisateur (User-id) diffrent

   Supposez que vous vouliez faire tourner un outil graphique de
   configuration qui ncessite d'avoir les privilges du compte _root_
   alors que la session X actuelle se droule sous votre compte. Cela
   peut sembler trange au premier abord, mais le serveur X _ne_
   permettra _pas_  cet outil d'accder  votre unit d'affichage.
   Comment cela est-il possible alors que _root_ peut normalement tout
   faire ? Et comment contourner ce problme ?

   largissons le propos au cas o l'on veut faire tourner une
   application X, sous un identificateur d'utilisateur clientuser, alors
   que la session X a t lance par serveruser. Si vous avez lu le
   paragraphe sur les _cookies_, il est vident que clientuser ne peut
   pas accder  votre unit d'affichage : ~clientuser/.Xauthority ne
   contient pas le cookie magique qui permet d'accder  l'unit
   d'affichage. Le cookie correct se trouve dans ~serveruser/.Xauthority.

7.1 Plusieurs utilisateurs sur le mme hte

   Naturellement, tout ce qui marche pour un X distant marchera aussi
   pour un X  partir d'un identificateur d'utilisateur diffrent
   (particulirement slogin localhost -l clientuser). Et ici l'hte
   client et l'hte serveur sont prcisment les mmes. Cependant, quand
   les deux htes sont les mmes, il y a quelques raccourcis pour
   transfrer le _cookie magique_.

   On supposera que l'on utilise su pour passer d'un identificateur
   utilisateur  l'autre. Essentiellement, il faut crire un script qui
   appelle su, mais enveloppe la commande que su excute d'un peu de code
   qui effectue les tches ncessaires pour le X distant. Ces tches
   ncessaires sont l'initialisation de la variable DISPLAY et le
   transfert du _cookie magique_.

   L'initialisation de DISPLAY est relativement facile ; il faut
   simplement dfinir DISPLAY="$DISPLAY" avant d'excuter l'argument de
   la commande su. Donc, il faut simplement faire :

su - clientuser -c "env DISPLAY="$DISPLAY" clientprogram &"

   Ce n'est pas tout, il faut encore transfrer le cookie. On peut le
   retrouver en utilisant xauth list "$DISPLAY". Cette commande renvoie
   le cookie dans un format qui convient pour l'utiliser dans la commande
   xauth add : ce dont nous avons justement besoin !

   On pourrait imaginer passer le cookie par l'intermdiaire d'un canal
   de transmission. Manque de chance, ce n'est pas si facile de passer
   quelque chose  la commande su par l'intermdiaire d'un canal de
   transmission car su attend le mot de passe de l'entre standard.
   Cependant, dans un script shell on peut jongler avec quelques
   descripteurs de fichiers et arriver  le faire.

   Donc, on crit un script de ce style en le paramtrant avec clientuser
   et clientprogram. Pendant que nous y sommes, amliorons un peu ce
   script, a va le rendre un peu moins comprhensible mais un peu plus
   robuste. Le tout ressemble  cela :

#!/bin/sh

if [ $# -lt 2 ]
then echo "usage: `basename $0` clientuser command" >&2
     exit 2
fi

CLIENTUSER="$1"
shift

# FD 4 becomes stdin too
exec 4>&0

xauth list "$DISPLAY" | sed -e 's/^/add /' | {

    # FD 3 becomes xauth output
    # FD 0 becomes stdin again
    # FD 4 is closed
    exec 3>&0 0>&4 4>&-

    exec su - "$CLIENTUSER" -c \
         "xauth -q <&3
          exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*' 3>&-"

}

   Je pense que c'est portable et que cela fonctionne suffisamment
   correctement dans la plupart des circonstances. Le seul dfaut auquel
   je pense en ce moment est d  l'utilisation de '$*', les guillemets
   simples dans command vont perturber les guillemets de l'argument('$*')
   de la commande su. Si cela entrane quelque chose de vraiment gnant,
   envoyez-moi un courrier lectronique.

   Nommez le script /usr/local/bin/xsu, et vous pouvez faire :

xsu clientuser 'command &'

   Cela ne peut pas tre plus facile,  moins que vous ne vous
   dbarrassiez du mot de passe. Oui, il existe des moyens pour y arriver
   (sudo), mais ce n'est pas l'endroit pour en parler.

   Le petit script xsu mentionn ci-dessus a servi comme base pour un
   script plus tendu appel sux qui a, apparemment, trouv sa place
   comme paquet dans la distribution Debian.

7.2 Root est l'utilisateur client

   videmment, tout ce qui marche pour un client non root doit
   fonctionner pour root. Cependant, avec root vous pouvez faire cela
   encore plus facilement, car celui-ci peut lire le fichier
   ~/.Xauthority de tout le monde. Il n'y a pas besoin de transfrer le
   cookie. Tout ce qu'il y a  faire consiste  initialiser DISPLAY, et 
   faire pointer XAUTHORITY sur ~serveruser/.Xauthority. Donc, vous
   pouvez crire :

su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  command"

   Et, en mettant cela dans un script, cela donne quelque chose comme

#!/bin/sh
if [ $# -lt 1 ]
then echo "usage: `basename $0` command" >&2
     exit 2
fi
su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  "'"$SHELL"'" -c '$*'"

   Nommez le script /usr/local/bin/xroot, et vous pouvez faire :

xroot 'control-panel &'

   Cependant, si vous avez dj initialis xsu , il n'y a pas de vraie
   raison de faire cela.

8. Faire tourner un gestionnaire de fentres distant

   Un gestionnaire de fentres (comme twm, wmaker, ou fvwm95) est une
   application comme n'importe quelle autre. La procdure normale devrait
   fonctionner.

   Enfin, presque. Il ne peut tourner, au plus, qu'un seul gestionnaire
   de fentres  un instant donn dans une unit d'affichage. Si vous
   faites dj tourner un gestionnaire de fentre local, vous ne pouvez
   pas lancer le gestionnaire distant (il le dira et s'arrtera). Il faut
   tuer (ou simplement quitter) le gestionnaire local en premier.

   Par manque de chance, beaucoup de scripts de sessions X se terminent
   par un

exec le-gestionnaire-de-fenetres-de-votre-choix

   et cela signifie que quand le gestionnaire de fentre (local) se
   termine, votre session se termine, et le systme (xdm ou xinit)
   considre que votre session est termine, et effectivement, vous
   dconnecte.

   Vous aurez encore  faire quelques contorsions, mais vous devez y
   arriver et ce n'est pas trop difficile. Amusez-vous un peu avec votre
   script de session (normalement ~/.xsession ou ~/.xinitrc) pour arriver
    vos fins.

   Attention, un gestionnaire de fentres permet souvent de faire tourner
   de nouveaux programmes qui s'excuteront sur la machine locale.
   C'est--dire locale  la machine sur lequel tourne le gestionnaire de
   fentres. Si vous faites tourner un gestionnaire de fentres distant,
   il lancera des applications distantes, et ce n'est peut-tre pas ce
   que vous voulez. Naturellement, elles continueront  s'afficher sur
   l'unit d'affichage qui est locale pour vous.

9. Mettre en place un terminal X

   Trouvez une utilisation  votre vieux PC ! Faites-en un endroit
   supplmentaire pour pouvoir travailler ! Pas besoin d'acheter un
   nouveau matriel coteux ! Vous avez dj tout ce qu'il faut !

   Srieusement, vous pouvez mettre en place un vieux PC comme terminal
   X. Un terminal X est un ordinateur qui fondamentalement n'excute rien
   d'autre qu'un serveur X. Vous pouvez vous connecter dessus et obtenir
   une session X, avec des xterms, xbiff, xclock et tout autre client X
   concevable. Cependant, les clients X s'excuteront sur l'hte distant
   et ils utiliseront le serveur X distant pour afficher leur sortie sur
   votre terminal X local. Mme le gestionnaire de fentre s'excutera 
   distance.

   Un terminal X consomme peu de ressources en comparaison d'une machine
   Unix complte. J'ai ici un terminal X constitu par un processeur 486,
   16 Mo de RAM et 250 Mo d'espace disque. Oh et une connexion rseau,
   naturellement. Il n'a mme pas besoin d'avoir des rpertoires
   utilisateurs.

   Pour trouver des lectures lies  ce sujet, jetez un coup d'oeil aux
   documents suivants :

     * Le _petit guide XDM et Terminal X_ (
       http://www.traduc.org/docs/HOWTO/mini/lecture/XDM-Xterm.html). Ce
       document est une description complte de ce qui est possible avec
       XDMCP et xdm, appliqu  la construction de terminaux X. Vous
       devriez vraiment le lire.
     * Le _guide pratique XDMCP_ (
       http://www.traduc.org/docs/HOWTO/lecture/XDMCP-HOWTO.html). Ce
       document dcrit les tapes ncessaires  la mise en place de xdm
       pour utiliser des serveurs X distants, comme depuis un terminal X.
       La configuration du serveur X dans une telle situation est dcrite
       de faon plus succinte.
     * Le _petit guide Xterminal_ (
       http://www.traduc.org/docs/HOWTO/mini/lecture/X-Terminal.html). Il
       n'est pas actuellement maintenu, mais il peut contenir quelques
       informations intressantes pour vous.

    la diffrence des documents ci-dessus, le document que vous tes en
   train de lire se limite  une courte description de XDMCP, mais il
   insiste plus sur les problmes de scurit impliqus.

9.1 Une fois de plus, un peu de thorie en premier

   En ce qui concerne X, le terminal X va n'excuter rien d'autre qu'un
   serveur X. Ce serveur X sera configur pour dialoguer avec l'hte
   distant en utilisant XDMCP (le protocole de contrle de gestion
   d'affichage X,  X Display Manager Control Protocol ). Il va demander
    l'hte distant une session X. L'hte distant fournira une fentre de
   connexion dans le terminal X et aprs la connexion, il excutera une
   session X avec tout l'habillage y compris le gestionnaire de fentres,
   tout cela utilisant X distant pour l'affichage sur le terminal X.

   Vous aurez probablement remarqu que l'hte distant agit comme un
   serveur, bien que pas comme un serveur X. L'hte distant fournit les
   sessions X aux serveurs X qui les demandent. Ainsi, selon XDMCP,
   l'hte distant est en fait un serveur, fournissant des sessions X,
   galement connu sous le nom de serveur XDMCP. Le serveur X joue le
   rle d'un client XDMCP ! Vous me suivez ?

   Le programme qui fournit le service XDMCP sur le serveur XDMCP est
   xdm. Donc, pour excuter un terminal X, vous devez configurer deux
   programmes : X (le client XDMCP) sur le terminal X et xdm (le serveur
   XDMCP) sur l'hte distant.

   Vous devez toujours vous rappeler que le protocole X (et le protocole
   XDMCP) n'est pas chiffr. Si vous devez utiliser X  distance, tout ce
   qui transite sur le rseau peut tre espionn par d'autres htes du
   rseau. Ceci est particulirement nfaste avec les sessions X
   distantes car la premire chose qui se passe est la connexion en
   donnant l'utilisateur et le mot de passe. _Vous ne devez donc excuter
   X  distance que sur un rseau scuris !_

9.2 Configurer X comme client XDMCP

   Si vous dsirez mettre en place une machine Linux comme terminal X,
   vous avez besoin de trs peu de ressources. Fondamentalement, vous
   avez besoin de ce qu'il est ncessaire d'avoir pour faire fonctionner
   une machine Linux dpouille plus un serveur X. Spcifiquement, vous
   _n'avez pas_ besoin des clients et bibliothques X. Il peut tre utile
   d'installer certaines polices X, mais vous pouvez galement utiliser
   un serveur de polices situ quelque part sur le rseau.

   Il existe plusieurs moyens pour un serveur X d'obtenir une session X
   d'un serveur XDMCP. La plus simple est d'aller directement  un
   serveur XDMCP connu et de lui en demander une. Le serveur peut
   galement mettre en multi-diffusion une requte et utiliser le
   premier serveur XDMCP qui rpond. Enfin, le serveur X peut demander 
   un serveur XDMCP de lui fournir une liste des htes qui acceptent de
   fournir une session et laisser l'utilisateur choisir l'hte de
   session.

    1. Si vous connaissez l'hte qui va vous fournir une session,
       utilisez-le directement. Excutez

X -query sessionhost

       et, en supposant que xdm fonctionne sur sessionhost, vous
       obtiendrez une fentre de connexion et, aprs connexion, une
       session X.
    2. Si l'hte duquel vous obtiendrez la session vous importe peu,
       utilisez la mthode d'mission de multi-diffusion. Excutez

X -broadcast

       et, en supposant que xdm fonctionne sur un hte quelque part sur
       le rseau, vous obtiendrez une fentre de connexion du premier
       (et, on l'espre, du plus rapide) xdm qui rpond et, aprs
       connexion, une session X.
    3. Si vous dsirez choisir l'hte o vous voulez avoir votre session,
       demandez au serveur XDMCP une liste des htes. Excutez

X -indirect xdmcpserver

       et, en supposant que xdm est bien configur sur ce serveur, une
       liste des htes vous sera prsente parmi lesquels vous pourrez
       choisir. Choisissez-en un ; vous obtiendrez la fentre de
       connexion pour cet hte et, aprs connexion, la session que vous
       avez demande.

   Il se peut que vous ayez remarqu l'absence de l'option -auth. Le
   serveur X utilisera XDMCP pour ngocier le mot de passe secret
   ( magic cookie ) avec le serveur XDMCP. Le serveur XDMCP placera le
   cookie dans votre ~/.Xauthority aprs la connexion.

   Aprs la fermeture d'une session, le serveur X va boucler, il
   reviendra au serveur XDMCP d'origine et lui demandera une nouvelle
   session (ou une liste de choix). Si vous ne dsirez pas cela, vous
   pouvez utiliser l'option -once. Notez que ceci ne semble pas
   fonctionner avec l'option -indirect  cause de l'implmentation du
    chooser .

   Quand vous avez dtermin la faon dont vous allez excuter le serveur
   X, vous pouvez alors le placer dans un script de dmarrage ou mme
   l'excuter directement  partir de /etc/inittab. Veuillez consulter la
   documentation de votre propre distribution pour savoir comment
   modifier vos scripts d'amorage ou /etc/inittab.

   N'excutez _pas_ un serveur X ainsi depuis le fichier de configuration
   Xservers. xdm s'attend  pouvoir se connecter  de tels serveurs et il
   pourrait les tuer s'il ne peut pas se connecter.

9.3 Configurer xdm comme serveur XDMCP

   Le programme qui fournit le service XDMCP (le service de session) est
   gnralement xdm. Il existe des variantes de celui-ci, comme wdm ou
   gdm sur Linux, mais ceux-ci fonctionnent fondamentalement de la mme
   faon. Assurez-vous donc que xdm ou une variante est install sur
   l'hte o vous dsirez excuter vos sessions X. Si vous disposez d'une
   connexion graphique locale depuis l'hte de session X, xdm est dj
   install ; la plupart des distributions Linux sont ainsi fournis de
   nos jours.

   En plus de xdm, vous aurez besoin des programmes que vous dsirez
   excuter dans une session X. C'est--dire, tous les clients X comme
   xterm, xfig, xclock, des gestionnaires de fentre et ainsi de suite.
   Cependant, pour un serveur XDMCP, vous n'avez _pas_ besoin d'installer
   de serveur X ; le serveur X fonctionnera  la place sur le terminal X.

    partir de l'histoire sur le serveur X ci-dessus, vous pouvez en
   conclure qu'il y a fondamentalement deux types de services XDMCP. Il y
   a le service _direct_ qui consiste  permettre la connexion d'un
   client XDMCP et  lui fournir une session X. Il y a galement le
   service _indirect_ dans lequel le serveur fournit une liste d'htes
   fournissant un service direct, au choix pour le client XDMCP.

   Tous les services xdm sont configurs dans le fichier d'accs,
   gnralement situ  /etc/X11/xdm/Xaccess ou un emplacement semblable.
   Cet emplacement est en fait dfini dans le fichier de configuration
   gnral de xdm /etc/X11/xdm/xdm-config par la ressource accessFile.
   Veuillez voir votre manuel xdm pour l'emplacement par dfaut.

    1. Si vous dsirez autoriser xdm  fournir des sessions X aux clients
       XDMCP, que ce soit par multi-diffusion ou non, placez le nom
       d'hte du client XDMCP (le serveur X, vous vous souvenez ?) seul
       sur une ligne dans le fichier Xaccess. En fait, vous pouvez placer
       un expression rationnelle correspondant  plusieurs htes. Voici
       quelques expressions valides :

xterm023.my.domain      # xterm023.my.domain peut obtenir une session X
*.my.domain             # tout hte dans my.domain peut obtenir une session X
*                       # tout hte sur Internet peut obtenir une session X (no
n scuris)

       Vouloir fournir une session X  tout hte sur Internet est
       discutable. De faon vidente, tout service que vous fournissez
       est une faille de scurit potentielle dans la scurit de votre
       serveur. D'un autre ct, le serveur devrait tre scuris
       lui-mme et un client XDMCP demandant une session X doit fournir
       une authentification valide avant que la session X ne soit
       accorde.
       De plus, la session X utilise une connexion X distante qui n'est
       pas chiffre. La paire nom d'utilisateur/mot de passe de connexion
       sera transporte sur cette connexion. Toute personne pourrait
       alors espionner des combinaisons valides d'utilisateur/mot de
       passe tout comme sur des connexions telnet simple. Ceci est mme
       pire que d'avoir son mot de passe secret ( magic cookie )
       espionn.
       Prenez vos propres dcisions ici, mais je recommande de ne pas
       activer ce service au monde entier  moins d'avoir une bonne
       raison.
    2. Si vous dsirez fournir aux clients XDMCP (X -indirect
       xdmcpserver) une liste de choix (une liste d'htes pour choisir
       duquel ils obtiendront une session X), faite suivre l'expression
       rationnelle du client par le mot-cl CHOOSER et la liste des htes
       que le client peut choisir.  la place de la liste des htes, vous
       pouvez galement spcifier BROADCAST ; avec ceci, xdm met en
       multi-diffusion sur le rseau pour interroger les serveurs
       dsirant fournir une session. Des exemples valides :

xterm023.my.domain      CHOOSER seshost1 seshost2
*.my.domain             CHOOSER BROADCAST
*                       CHOOSER extseshost1 extseshost2

       Le premier exemple permet  xterm023 de choisir entre des sessions
       sur seshost1 et sur seshost2. Le deuxime exemple permet  tout
       hte dans my.domain de choisir n'importe quel hte fournissant une
       session X. Le troisime exemple permet  tout hte de choisir une
       session entre extseshost1 et extseshost2.
       Ce n'est probablement pas une bonne ide de faire * CHOOSER
       BROADCAST. Ceci permettrait  tout hte en dehors de votre rseau
       d'obtenir des informations sur les htes dans votre rseau. Vous
       ne voulez probablement pas communiquer une telle information. En
       fait, autoriser un choix pour tout hte extrieur n'est
       probablement pas trs utile de toute faon, car vous ne devriez
       pas autoriser des connexions arbitraires directes non plus.

   Quand vous avez reconfigur xdm, envoyez-lui le signal HUP pour le
   forcer  relire ses fichiers de configuration.

# kill -HUP pid-of-xdm
#

9.4 XDMCP techniquement

   Techniquement, pour autant que je puisse le voir, XDMCP n'est pas tout
    fait ce  quoi vous pouvez vous attendre d'aprs la description
   ci-dessus. xdm peut rediriger des serveurs X se connectant, vers un
   autre endroit et il utilise cette astuce pour implmenter la liste de
   choix. Ainsi, le choix se produit dans xdm et non dans le serveur X
   bien que la liste de choix soit reprsente dans l'affichage du
   serveur X. C'est galement pour cela que l'option -once du serveur X
   ne se combine pas avec -indirect.

10. Maintenance

   D'ordinaire, la premire fois que vous allez essayer de faire tourner
   une application X  distance, a ne marchera pas. Voici quelques-uns
   des messages d'erreur habituels, leur cause probable et des solutions
   pour vous aider  progresser.

xterm Xt error: Can't open display:

   Il n'y a pas de variable DISPLAY renseigne dans votre environnement
   et vous n'avez pas non plus lanc l'application avec le drapeau
   -display. L'application assume que la variable display contient une
   chane de caractres vide, ce qui est syntaxiquement incorrect. La
   solution  cela consiste  s'assurer que la variable DISPLAY est
   correctement renseigne dans l'environnement (avec setenv ou export
   selon votre shell).

_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0

   Erreur 101 signifie  Rseau inaccessible . L'application n'arrive
   pas  se connecter au serveur  travers le rseau. Vrifiez que la
   variable DISPLAY est correctement renseigne et que la machine serveur
   est accessible  partir de votre client (ce qui devrait tre le cas,
   car aprs tout vous tes probablement connect au serveur en ayant une
   session telnet avec votre client).

_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0

   Erreur 111 signifie  Connexion refuse . La machine  laquelle vous
   tes en train d'essayer de vous connecter peut tre atteinte, mais le
   serveur indiqu n'existe pas  cet endroit. Vrifiez que vous utilisez
   le nom d'hte correct et le numro d'unit d'affichage adquat.

   Sinon, il est possible que le serveur X a t configur pour _ne pas_
   couter sur le port TCP habituel. Pour savoir s'il s'agit de ce cas,
   regardez si le serveur X a t lanc avec le paramtre -nolisten tcp
   et si oui, enlevez-le.

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0

   Le client pourrait raliser une connexion avec le serveur, mais
   celui-ci ne permet pas au client de l'utiliser (pas autoris).
   Assurez-vous que vous avez transfr le bon cookie au client, et qu'il
   n'est pas prim (le serveur utilise un nouveau cookie au dmarrage
   d'une nouvelle session).
