  mini-HOWTO : Comment excuter des applications X  distance
  Vincent Zweije, zweije@xs4all.nl
  V 0.6.1, 19 Novembre 1999

  Ce mini-HOWTO 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 mini-
  HOWTO sera mis sur les questions de scurit. Ce mini-HOWTO contient
  galement des informations sur la manire de faire tourner des appli
  cations X en local, mais avec un identificateur d'utilisateur (user-
  id) diffrent.  Adaptation franaise : Albert-Paul Bouillot apb@club-
  internet.fr
  ______________________________________________________________________

  Table des matires


  1. Introduction

  2. Lectures complmentaires

  3. Le contexte

  4. Un peu de thorie

  5. Dire au client ...

  6. Dire au serveur ...

     6.1 Xhost
     6.2 Xauth
        6.2.1 Fabrication du Cookie
        6.2.2 Transfert du Cookie
        6.2.3 Utilisation du Cookie
     6.3 Ssh

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

     7.1 Plusieurs utilisateurs sur le mme hte
     7.2 Root est l'utilisateur client

  8. Faire tourner un gestionnaire de fentres distant

  9. Maintenance



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  Ce mini-HOWTO 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 des
     connexions X.  CC''eesstt dd''uunnee iinnssccuurriitt ttoottaallee, et il existe de bien
     meilleures mthodes;


  3. Je n'ai pas connaissance d'un document simple dcrivant les options
     dont _o_n _p_e_u_t disposer. Si vous avez des informations
     complmentaires, s'il vous plat, faites-le moi savoir :
     <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 (vos) propre(s) systmes(s).

  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://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps. Les (mini-)HOWTOs
  Linux sont disponibles par http ou ftp sur sunsite.unc.edu.

  Ceci constitue la version 0.6.1. Aucunes garanties, seulement de
  bonnes intentions. Je suis ouvert aux suggestions, ides, ajouts,
  pointeurs utiles, corrections (typo), etc... Je veux que cela reste un
  document simple et lisible, dans la bonne moyenne du style HOWTO.  Les
  querelles seront rediriges vers /dev/null.

  Le contenu de ce mini-HOWTO a t mis  jour le 19 Novembre 1999 par
  Vincent Zweije


  22..  LLeeccttuurreess ccoommppllmmeennttaaiirreess

  Un document, en rapport avec cela, sur le WWW traite de ''Quoi 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 du ``Guide de l'administrateur du
  systme X Window'' (X Window System Administrator's Guide Vol. 8) de
  chez O'Reilly and Associates tait une bonne source d'informations.
  Malheureusement, je n'ai pas pu le vrifier.

  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 listes de diffusion usenet, telles que :
  comp.windows.x, comp.os.linux.x, et comp.os.linux.networking.


  33..  LLee ccoonntteexxttee

  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 disposez de connexions  un rseau pour
  pouvoir le raliser. De prfrence rapides, 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://ccwf.cc.utexas.edu/~zvonler/dxpc/> ou LBX
  <http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html> (galement connu
  comme tant le LBX mini-HOWTO).

  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4..  UUnn ppeeuu ddee tthhoorriiee

  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
  fourni 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5..  DDiirree aauu cclliieenntt ......

  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 ce 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 _d_o_i_v_e_n_t 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, donner
  la valeur de DISPLAY  TERM. Puis de lancer telnet. Du ct de
  l'ordinateur distant, dans le fichier .*shrc concern, lire la valeur
  de DISPLAY  partir de TERM.


  66..  DDiirree aauu sseerrvveeuurr ......

  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.


  66..11..  XXhhoosstt

  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_'_i_m_p_o_r_t_e _q_u_e_l 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 
  _t_o_u_t _l_e _m_o_n_d_e de se connecter. Vous ne devriez _j_a_m_a_i_s faire cela sur
  un rseau o vous n'avez pas confiance dans _t_o_u_s les utilisateurs (tel
  internet). Vous pouvez ractiver la vrification des htes avec :



       light$ xhost -




  xhost - par lui-mme _n_e _s_u_p_p_r_i_m_e _p_a_s 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).

  _X_h_o_s_t _e_s_t _u_n _m__c_a_n_i_s_m_e _v_r_a_i_m_e_n_t _t_r__s _p_e_u _s__r_. 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6..22..  XXaauutthh

  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
  ensembles dans ~/.Xauthority.Votre fichier ~/.Xauthority doit tre
  inaccessible pour les utilisateurs groupe/autres. Le programme xauth
  gre ces cookies, donc le surnom xauth dans ce schma.

  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, _l_e _s_e_r_v_e_u_r _n_e _r__c_u_p__r_e_r_a _p_a_s _l_a
  _m_o_d_i_f_i_c_a_t_i_o_n.


  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 nou
       velle 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.


  66..22..11..  FFaabbrriiccaattiioonn dduu CCooookkiiee

  Si vous voulez utiliser xauth, vous devez lancer le serveur X avec
  l'argument -auth authfile. Si vous utilisez le script ssttaarrttxx 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 paquetage util-linux, site primaire
  ftp://ftp.math.uio.no/pub/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 de 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 information.  Par exemple, mon /etc/X11/xdm/xdm-config contient
  la ligne suivante :



       DisplayManager.authDir: /var/lib/xdm





  66..22..22..  TTrraannssffeerrtt dduu CCooookkiiee

  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.


  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 :



       #!/bin/sh
       cookie=`mcookie`
       xauth add :0 . $cookie
       xauth add "$HOST:0" . $cookie
       exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"




  Si les rpertoires _h_o_m_e 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 !

  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
  parodis, 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 add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
       dark% xfig &
       [15332]
       dark% logout
       light$




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

  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.


  66..22..33..  UUttiilliissaattiioonn dduu CCooookkiiee

  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.
  L'application X cliente peut traduire localhost:D en host/unix:D pour
  les besoins de recherche du cookie.  Effectivement, cela signifie
  qu'un cookie pour localhost:D dans votre ~/.Xauthority n'a _a_u_c_u_n
  effet.


  66..33..  SSsshh

  Les enregistrements d'autorisation sont transmis 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 cryptes. De plus, il est gnial pour d'autres
  choses aussi.  C'est une bonne amlioration structurelle de votre
  systme. Allez voir simplement http://www.cs.hut.fi/ssh/, la page
  d'accueil de ssh.

  Qui possde d'autres informations sur les mthodes d'authentification
  ou de cryptage des connexions X ?  Peut-tre Kerberos ?




  77..  LLeess aapppplliiccaattiioonnss XX aavveecc uunn iiddeennttiiffiiccaatteeuurr dd''uuttiilliissaatteeuurr ((UUsseerr--iidd))
  ddiiffffrreenntt

  Supposez que vous vouliez faire tourner un outil graphique de
  configuration qui ncessite d'avoir les privilges du compte _r_o_o_t
  alors que la session X actuelle se droule sous votre compte. Cela
  peut sembler trange au premier abord, mais le serveur X _n_e permettra
  _p_a_s  cet outil d'accder  votre unit d'affichage. Comment cela est-
  il possible alors que _r_o_o_t 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 _c_o_o_k_i_e_s, il est vident que clientuser ne peut pas
  accder  votre unit d'affichage : ~clientuser/.Xauthority ne
  contient le cookie magique qui permet d'accder  l'unit d'affichage.
  Le cookie correct se trouve dans ~serveruser/.Xauthority.


  77..11..  PPlluussiieeuurrss uuttiilliissaatteeuurrss ssuurr llee mmmmee hhttee

  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 _c_o_o_k_i_e _m_a_g_i_q_u_e.


  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 _c_o_o_k_i_e _m_a_g_i_q_u_e.


  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 le mettre dans xauth; ce
  dont nous avons justement besoin ! Donc, on met le cookie obtenu dans
  xauth dans le commande su, on initialise DISPLAY ici, et on lance la
  commande dsire



       su - clientuser -c "xauth add `xauth list $DISPLAY`; \
                           exec env DISPLAY=$DISPLAY clientprogram"




  On peut crire un script pour raliser tout cela, en le paramtrant
  avec clientuser et clientprogram. Amliorons un peu le script pendant
  que nous y sommes, 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
       exec su - "$CLIENTUSER" -c "xauth add `xauth list \"$DISPLAY\"`; \
                                   exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*'"





  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 &'





  Facile, non ?


  77..22..  RRoooott eesstt ll''uuttiilliissaatteeuurr cclliieenntt

  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 &'





  Encore plus facile, non ??


  88..  FFaaiirree ttoouurrnneerr uunn ggeessttiioonnnnaaiirree ddee ffeennttrreess ddiissttaanntt

  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-fenetre-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9..  MMaaiinntteennaannccee

  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.



       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).





























































