/usr/share/doc/HOWTO/fr-html/Remote-X-Apps.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Petit guide d'exécution à distance des applications
X</title>
</head>
<body>
<h1>Petit guide d'exécution à distance des applications X</h1>
<h2>Version française du <em>Remote X Apps mini-HOWTO</em></h2>
<h2><a href="http://www.xs4all.nl/~zweije/">Vincent Zweije</a> &lt;
<a href="mailto:zweije@xs4all.nl">zweije@xs4all.nl</a>&gt;</h2>
V 0.7.5, 8 décembre 2001
<hr>
<em>Ce petit guide décrit comment exécuter des applications X à
distance. C'est-à-dire, comment faire pour qu'un programme X
s'affiche sur un écran d'ordinateur différent de celui sur lequel
il s'exécute. Ou, autrement dit, comment faire tourner un programme
X sur un ordinateur différent de celui devant lequel vous êtes
assis. L'accent de ce petit guide sera mis sur les questions de
sécurité. Ce petit guide contient également des informations sur la
manière de faire tourner des applications X en local, mais avec un
identificateur d'utilisateur (user-id) différent ainsi que des
informations sur la façon de mettre en place un ordinateur comme
terminal X. Adaptation française&nbsp;: Albert-Paul Bouillot,
Frédéric Bothamy <a href=
"mailto:fbothamy@mail.dotcom.fr">fbothamy@mail.dotcom.fr</a>.
Relecture de la version française&nbsp;: Olivier Kaloudoff <a href=
"mailto:kalou@kalou.net">kalou@kalou.net</a>.</em>
<hr>
<h2><a name="s1" id="s1">1. Introduction</a></h2>
<p>Ce petit guide constitue un guide sur la manière de faire
tourner des applications X à distance. J'ai rédigé ce document pour
plusieurs raisons&nbsp;:</p>
<ol>
<li>Il y a eu de nombreuses questions, sur Usenet, sur la manière
de faire tourner des applications X à distance&nbsp;;</li>
<li>J'ai vu beaucoup, beaucoup de conseils d'utilisation de
«&nbsp;<code>xhost +hostname</code>&nbsp;» ou même de
«&nbsp;<code>xhost +</code>&nbsp;» pour réaliser des connexions X.
<b>C'est d'une insécurité totale</b>, et il existe de bien
meilleures méthodes&nbsp;;</li>
<li>Je n'ai pas connaissance d'un document simple décrivant les
options dont <em>on peut</em> disposer. Si vous avez des
informations complémentaires, s'il vous plaît, faites-le moi savoir
(en anglais)&nbsp;: <a href=
"mailto:zweije@xs4all.nl">&lt;zweije@xs4all.nl&gt;</a>.</li>
</ol>
<p>Ce document a été écrit en pensant à des systèmes de type Unix.
Si le système d'exploitation de votre ordinateur local ou de celui
qui est à distance est de type différent, vous devriez trouver ici
des informations sur la manière dont les choses se passent.
Cependant, il vous faudra modifier les exemples par vous-même pour
les utiliser sur votre propre système.</p>
<p>La version (anglaise) la plus récente de ce document est
toujours disponible sur le WWW à <a href=
"http://www.xs4all.nl/~zweije/xauth.html">http://www.xs4all.nl/~zweije/xauth.html</a>.
Il est également disponible en tant que mini-HOWTO Linux
«&nbsp;Applications X à distance&nbsp;» (Remote X Apps) à&nbsp;:
<a href=
"http://www.tldp.org/HOWTO/mini/Remote-X-Apps">http://www.tldp.org/HOWTO/mini/Remote-X-Apps</a>.
Les (mini-)HOWTO du projet de documentation Linux (LDP) sont
disponibles par http ou ftp sur <a href=
"http://www.tldp.org">www.tldp.org</a>.</p>
<p>La version française la plus récente de ce document est toujours
disponible sur le site du projet <a href=
"http://www.traduc.org">traduc.org</a> à <a href=
"http://www.traduc.org/docs/HOWTO/mini/lecture/Remote-X-Apps.html">http://www.traduc.org/docs/HOWTO/mini/lecture/Remote-X-Apps.html</a>.</p>
<p>Ceci constitue la version 0.7.5. Aucune garantie, seulement de
bonnes intentions. Je suis ouvert aux suggestions, idées, ajouts,
pointeurs utiles, corrections (typo), et cætera. 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 redirigées vers /dev/null. Ce document est diffusé
sous la version 1.1 de la licence <a href=
"http://www.gnu.org/">GNU</a> Free Documentation Licence. <em>This
document is released under version 1.1 of the <a href=
"http://www.gnu.org/">GNU</a> Free Documentation Licence</em>.</p>
<p>Le contenu de ce petit guide a été mis à jour le 8 décembre 2001
par <a href="http://www.xs4all.nl/~zweije/index.html">Vincent
Zweije</a>. La version française de ce document a été mise à jour
le 4 mars 2003 par <a href=
"mailto:fbothamy@mail.dotcom.fr">Frédéric Bothamy</a>. La relecture
de cette nouvelle version française a été réalisée par <a href=
"mailto:kalou@kalou.net">Olivier Kaloudoff</a>.</p>
<h2><a name="s2" id="s2">2. Lectures complémentaires</a></h2>
<p>Un document, en rapport avec cela, sur le WWW traite de
«&nbsp;Que faire quand Tk dit que votre écran n'est pas sûr&nbsp;»,
<a href=
"http://ce-toolkit.crd.ge.com/tkxauth/">http://ce-toolkit.crd.ge.com/tkxauth/</a>.
Il a été écrit par <a href=
"http://ce-toolkit.crd.ge.com/people/kennykb.html">Kevin Kenny</a>.
Il suggère 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.</p>
<p>On m'a indiqué que le volume 8 de la série consacrée au système
X Window, le «&nbsp;Guide de l'administrateur du système X
Window&nbsp;» de chez <a href="http://www.oreilly.com/">O'Reilly
and Associates</a> é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 spécifique à X11R6 n'est pas couvert.</p>
<p>Il y a également un autre document qui ressemble beaucoup à
celui que vous êtes en train de lire, dont le titre est
«&nbsp;Securing X Windows&nbsp;», et qui est disponible à <a href=
"http://ciac.llnl.gov/ciac/documents/ciac2316.html">http://ciac.llnl.gov/ciac/documents/ciac2316.html</a>.</p>
<p>Consultez également les forums de diffusion Usenet, tels
que&nbsp;: <code>comp.windows.x</code>,
<code>comp.os.linux.x</code> et
<code>comp.os.linux.networking</code>.</p>
<h2><a name="s3" id="s3">3. Le contexte</a></h2>
<p>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 affichées sur l'écran
du premier. Le système X Window rend cela possible.</p>
<p>Naturellement, vous devez disposer d'une connexion à un réseau
pour pouvoir le réaliser. De préférence rapide, car le protocole X
est un dévoreur de ressources réseau. Mais, avec un peu de patience
et un protocole de compression de données adapté, vous pouvez même
faire tourner des applications par l'intermédiaire d'un modem. Pour
un protocole de compression pour X, vous pouvez aller consulter les
sites&nbsp;: dxpc <a href=
"http://www.vigor.nu/dxpc/">http://www.vigor.nu/dxpc/</a> ou LBX
<a href=
"http://www.traduc.org/docs/HOWTO/mini/lecture/LBX.html">http://www.traduc.org/docs/HOWTO/mini/lecture/LBX.html</a>
(disponible en version originale sur le site de l'auteur&nbsp;:
<a href=
"http://www.paulandlesley.org/faqs/LBX-HOWTO.html">http://www.paulandlesley.org/faqs/LBX-HOWTO.html</a>).</p>
<p>Vous avez deux choses à faire pour réaliser tout cela&nbsp;:</p>
<ol>
<li>Indiquer à l'unité d'affichage locale (le serveur) qu'elle doit
accepter les connexions venant de l'ordinateur à distance.</li>
<li>Dire à l'application à distance (le client) de rediriger ses
sorties vers votre unité d'affichage locale.</li>
</ol>
<h2><a name="s4" id="s4">4. Un peu de théorie</a></h2>
<p>Le mot magique est <code>DISPLAY (unité d'affichage)</code>.
Dans le système X Window, une unité d'affichage est constituée (en
simplifiant) d'un clavier, d'un mulot et d'un écran. Une unité
d'affichage est gérée par un programme serveur, plus connu sous le
nom de serveur X. Le serveur fournit des fonctionnalités
d'affichage aux autres programmes qui se connectent à lui.</p>
<p>Une unité d'affichage est identifiée par un nom, de type, par
exemple&nbsp;:</p>
<ul>
<li><code>DISPLAY=light.uni.verse:0</code></li>
<li><code>DISPLAY=localhost:4</code></li>
<li><code>DISPLAY=:0</code></li>
</ul>
<p>Un nom d'unité d'affichage est constitué d'un nom d'hôte (par
exemple&nbsp;: <code>light.uni.verse</code> et
<code>localhost</code>), du signe deux point (<code>:</code>), et
d'un numéro de séquence (tels que <code>0</code> et
<code>4</code>). Le nom d'hôte de l'unité d'affichage est le nom de
l'ordinateur sur lequel tourne le serveur X. Si le nom de l'hôte
est omis, cela signifie qu'il s'agit de l'ordinateur local.
D'habitude, le numéro de séquence est 0 – cela peut changer s'il y
a plusieurs unités d'affichage connectées sur le même
ordinateur.</p>
<p>Si jamais il vous arrive de voir le nom d'une unité d'affichage
avec un <code>.n</code> supplémentaire accolé à son nom, c'est
qu'il s'agit d'un numéro d'écran. Une unité d'affichage peut, en
théorie, avoir plusieurs écrans. Cependant, d'habitude, il n'y en a
qu'un, qui porte le numéro <code>n=0</code>, et c'est le numéro par
défaut.</p>
<p>D'autres formes de <code>DISPLAY</code> existent, mais celle-ci
suffira pour notre propos.</p>
<p>Pour celui qui est curieux de technique&nbsp;:</p>
<ul>
<li><code>hostname:D.S</code> signifie écran <code>S</code> sur
unité d'affichage <code>D</code> de l'hôte
<code>hostname</code>&nbsp;: le serveur X de cette unité
d'affichage est à l'écoute du port TCP <code>6000+D</code>.</li>
<li><code>host/unix:D.S</code> signifie écran <code>S</code> sur
unité d'affichage <code>D</code> de l'hôte <code>host</code>&nbsp;:
le serveur X de cette unité d'affichage est à l'écoute du socket de
domaine UNIX <code>/tmp/.X11-unix/XD</code> (et donc, seul
<code>host</code> peut l'atteindre).</li>
<li><code>:D.S</code> est équivalent à <code>host/unix:D.S</code>,
où <code>host</code> est le nom de l'hôte local.</li>
</ul>
<h2><a name="s5" id="s5">5. Dire au client&nbsp;...</a></h2>
<p>Le programme client (par exemple, votre application graphique)
sait à quelle unité d'affichage il doit se connecter en consultant
la variable d'environnement <code>DISPLAY</code>. Cependant ce
paramétrage peut être modifié en lançant le client avec l'argument
<code>-display hostname:0</code> dans la ligne de commande.
Quelques exemples peuvent clarifier les choses.</p>
<p>Notre ordinateur est connu du monde extérieur 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
<code>light.uni.verse:0</code>. Nous voulons faire tourner le
programme de dessin xfig sur un ordinateur à distance, appelé
<code>dark.matt.er</code>, et afficher sa sortie ici, sur
light.</p>
<p>Supposons que vous vous soyez déjà connecté par telnet à
l'ordinateur distant, <code>dark.matt.er</code>.</p>
<p>Si l'interpréteur de commande de l'ordinateur éloigné est
csh&nbsp;:</p>
<blockquote>
<pre><code>
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &amp;
</code></pre></blockquote>
<p>Ou, d'une autre manière&nbsp;:</p>
<blockquote>
<pre><code>
dark% xfig -display light.uni.verse:0 &amp;
</code></pre></blockquote>
<p>Si c'est sh qui tourne sur l'ordinateur à distance&nbsp;:</p>
<blockquote>
<pre><code>
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &amp;
</code></pre></blockquote>
<p>Ou, autrement&nbsp;:</p>
<blockquote>
<pre><code>
dark$ DISPLAY=light.uni.verse:0 xfig &amp;
</code></pre></blockquote>
<p>Ou, bien sûr, également&nbsp;:</p>
<blockquote>
<pre><code>
dark$ xfig -display light.uni.verse:0 &amp;
</code></pre></blockquote>
<p>Il paraît que certaines versions de telnet transmettent
automatiquement la variable <code>DISPLAY</code> à l'ordinateur
hôte é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 <em>doivent</em> transmettre la
variable d'environnement <code>TERM</code>, et avec un bidouillage
judicieux, il est possible de superposer la variable
<code>DISPLAY</code> sur la variable <code>TERM</code>.</p>
<p>L'idée, sous-jacente à cette superposition, est de réaliser une
sorte de script pour effectuer ceci&nbsp;: avant la connexion par
telnet, donnez la valeur de <code>DISPLAY</code> à
<code>TERM</code>. Puis, lancez telnet. Du côté de l'ordinateur
distant, dans le fichier <code>.*shrc</code> concerné, lisez la
valeur de <code>DISPLAY</code> à partir de <code>TERM</code>.</p>
<h2><a name="s6" id="s6">6. Dire au serveur&nbsp;...</a></h2>
<p>Le serveur n'acceptera pas de connexions venant de n'importe où.
Vous ne voulez pas que n'importe qui puisse afficher des fenêtres
sur votre écran. Ou lire ce vous tapez – souvenez-vous que votre
clavier fait partie de votre unité d'affichage&nbsp;!</p>
<p>Trop peu de gens semble réaliser que permettre l'accès à leur
unité d'affichage pose des problèmes de sécurité. Quelqu'un qui
dispose d'un accès à votre unité d'affichage peut lire et écrire
sur vos écrans, lire vos frappes au clavier, et suivre les
déplacements de votre mulot.</p>
<p>La plupart des serveurs disposent de deux manières
d'authentifier les demandes de connexions qui arrivent&nbsp;: le
mécanisme de la liste d'hôtes (xhost) et le mécanisme du mot de
passe secret (magic cookie) (xauth). De plus, il y a ssh,
l'interpréteur de commande sécurisé, qui peut acheminer les
connexions X.</p>
<p>Veuillez noter que certains serveurs X (de XFree86) peuvent être
configurés pour ne pas écouter sur le port habituel TCP avec le
paramètre <code>-nolisten tcp</code>. La configuration par défaut
de Debian GNU/Linux, notamment, désactive l'écoute sur le port TCP
par le serveur X. Si vous désirez utiliser X à distance sur un
système Debian, vous devriez réactiver ceci en modifiant la façon
dont est lancé le serveur X. Veuillez voir le fichier
<code>/etc/X11/xinit/xserverrc</code> pour un point de départ.</p>
<h2><a name="ss6.1" id="ss6.1">6.1 Xhost</a></h2>
<p>Xhost permet les accès basés sur les nom d'hôtes. Le serveur
entretient une liste des hôtes qui sont autorisés à se connecter à
lui. Il peut aussi désactiver complètement la vérification des
hôtes. Attention&nbsp;: cela signifie que plus aucun contrôle n'est
effectué, et donc, que <em>n'importe quel</em> hôte peut se
connecter&nbsp;!</p>
<p>Vous pouvez contrôler la liste des hôtes du serveur avec le
programme <code>xhost</code>. Pour utiliser ce mécanisme dans
l'exemple précédent, faites&nbsp;:</p>
<blockquote>
<pre><code>
light$ xhost +dark.matt.er
</code></pre></blockquote>
<p>Ceci permet toutes les connexions à partir de l'hôte
<code>dark.matt.er</code>. Dès que votre client X a réalisé sa
connexion et affiche une fenêtre, par sécurité, supprimez les
permissions pour d'autres connexions avec&nbsp;:</p>
<blockquote>
<pre><code>
light$ xhost -dark.matt.er
</code></pre></blockquote>
<p>Vous pouvez désactiver la vérification des hôtes avec&nbsp;:</p>
<blockquote>
<pre><code>
light$ xhost +
</code></pre></blockquote>
<p>Ceci désactive la vérification des accès des hôtes et donc
permet à <em>tout le monde</em> de se connecter. Vous ne devriez
<em>jamais</em> faire cela sur un réseau où vous n'avez pas
confiance dans <em>tous</em> les utilisateurs (tel internet). Vous
pouvez réactiver la vérification des hôtes avec&nbsp;:</p>
<blockquote>
<pre><code>
light$ xhost -
</code></pre></blockquote>
<p><code>xhost -</code> par lui-même <em>ne supprime pas</em> tous
les hôtes de la liste d'accès (ce qui serait tout à fait inutile -
vous ne pourriez plus vous connecter de n'importe où, pas même de
votre hôte local).</p>
<p><em>Xhost est un mécanisme vraiment très peu sûr.</em> Il ne
fait pas de distinction entre les différents utilisateurs sur
l'hôte à distance. De plus, les noms d'hôtes (en réalité des
adresses) peuvent être manipulés. C'est mauvais si vous vous
trouvez sur un réseau douteux (déjà, par exemple, avec un accès PPP
téléphonique à Internet).</p>
<h2><a name="ss6.2" id="ss6.2">6.2 Xauth</a></h2>
<p>Xauth autorise l'accès à tous ceux qui connaissent le bon
secret. On appelle un tel secret un enregistrement d'autorisation
ou cookie. Ce mécanisme d'autorisation est désigné cérémonieusement
comme étant le MIT-MAGIC-COOKIE-1.</p>
<p>Les cookies pour les différentes unités d'affichage sont stockés
ensemble dans <code>~/.Xauthority</code>. Votre fichier
<code>~/.Xauthority</code> doit être inaccessible pour les
utilisateurs groupe/autres. Le programme xauth gère ces cookies,
d'où le surnom xauth dans ce schéma.</p>
<p>Vous pouvez spécifier un fichier cookie différent avec la
variable d'environnement <code>XAUTHORITY</code>, mais vous aurez
rarement besoin de le faire. Si vous ne savez pas quel fichier
cookie votre xauth utilise, faites un <code>xauth -v</code> et il
vous l'indiquera.</p>
<p>Au démarrage d'une session, le serveur lit un cookie dans le
fichier qui est indiqué par l'argument <code>-auth</code>. Ensuite,
le serveur ne permet la connexion que des clients qui connaissent
le même cookie. Quand le cookie dans <code>~/.Xauthority</code>
change, <em>le serveur ne récupérera pas la modification</em>.</p>
<p>Les serveurs les plus récents peuvent générer des cookies à la
volée pour des clients qui le demandent. Les cookies sont cependant
encore conservés dans le serveur&nbsp;: ils ne finissent pas dans
<code>~/.Xauthority</code> à moins qu'un client ne les y mettent.
Selon David Wiggins&nbsp;:</p>
<blockquote>Une possibilité supplémentaire , qui peut vous
intéresser, a été ajoutée dans X11R6.3. Par l'intermédiaire de la
nouvelle extension SECURITY, le serveur X lui-même peut générer et
renvoyer de nouveaux cookies à la volée. De plus, on peut désigner
les cookies comme étant «&nbsp;douteux&nbsp;» de sorte que les
applications qui se connectent avec de tels cookies auront une
capacité opératoire restreinte. Par exemple, ils ne pourront pas
regarder les entrées au clavier/mulot, ou le contenu des fenêtres,
d'autres clients «&nbsp;fiables&nbsp;». Il y a une nouvelle
sous-commande «&nbsp;generate&nbsp;» de xauth pour rendre cette
fonctionnalité, pas forcément facile, mais au moins possible à
utiliser.</blockquote>
<p>Xauth possède un avantage clair, au niveau de la sécurité, sur
xhost. Vous pouvez limiter l'accès à des utilisateurs spécifiques
sur des ordinateurs spécifiques. Il ne permet pas l'usurpation
d'adresse comme le permet xhost. Et, si vous le désirez, vous
pouvez encore utiliser xhost en parallèle pour permettre des
connexions.</p>
<h3>Fabrication du cookie</h3>
<p>Si vous voulez utiliser xauth, vous devez lancer le serveur X
avec l'argument <code>-auth authfile</code>. Si vous utilisez le
script <b>startx</b> pour lancer le serveur X, c'est le bon endroit
pour le faire. Créez l'enregistrement d'autorisation comme indiqué
ci-dessous dans votre script startx.</p>
<p>Extrait de <code>/usr/X11R6/bin/startx</code>&nbsp;:</p>
<blockquote>
<pre><code>
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</code></pre></blockquote>
<p>Mcookie est un petit programme du paquet util-linux, site
primaire <a href=
"ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux">ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux</a>.
Autrement, vous pouvez utiliser md5sum pour créer quelques données
aléatoires (de, par exemple, <code>/dev/urandom</code> ou <code>ps
-axl</code>) au format cookie&nbsp;:</p>
<blockquote>
<pre><code>
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</code></pre></blockquote>
<p>Si vous ne pouvez pas éditer le script startx (parce que vous
n'êtes pas root), demandez à votre administrateur système de
configurer startx correctement, ou, à la place, laissez-le
configurer xdm. S'il ne peut, ou ne veut, pas, vous pouvez écrire
un script <code>~/.xserverrc</code>. Si vous avez ce script, il
sera exécuté par xinit au lieu du véritable serveur X. Alors, vous
pourrez lancer le serveur X véritable à partir de ce script avec
les arguments adaptés. Pour faire cela, faites utiliser par votre
<code>~/.xserverrc</code> le <code>mcookie</code> de la ligne
ci-dessus pour créer un cookie puis lancer le véritable serveur
X&nbsp;:</p>
<blockquote>
<pre><code>
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</code></pre></blockquote>
<p>Si vous utilisez xdm pour gérer vos sessions X, vous pouvez
utiliser xauth facilement. Définissez les ressources du
DisplayManager.authDir dans <code>/etc/X11/xdm/xdm-config</code>.
Xdm passera l'argument <code>-auth</code> au serveur X à son
démarrage. Au moment de la connexion sous xdm, xdm place le cookie
dans <code>~/.Xauthority</code> pour vous. Consultez xdm(1) pour de
plus amples informations. Par exemple, mon
<code>/etc/X11/xdm/xdm-config</code> contient la ligne
suivante&nbsp;:</p>
<blockquote>
<pre><code>
DisplayManager.authDir: /var/lib/xdm
</code></pre></blockquote>
<h3>Transfert du cookie</h3>
<p>Maintenant que vous avez lancé votre session X sur le serveur
hôte <code>light.uni.verse</code> et que vous avez votre cookie
dans <code>~/.Xauthority</code>, il vous faut transférer le cookie
sur le client, <code>dark.matt.er</code>. Il y a plusieurs façons
de le faire.</p>
<h3>Répertoires personnels (home) partagés</h3>
<p>Le plus simple est que vos répertoires sur <code>light</code> et
<code>dark</code> soient partagés. Les fichiers
<code>~/.Xauthority</code> sont les mêmes, donc le cookie est
transféré instantanément. Cependant, il y a un piège&nbsp;: lorsque
vous mettez un cookie pour <code>:0</code> dans
<code>~/.Xauthority</code>, dark va croire que c'est un cookie pour
lui au lieu de light. Il faut que vous utilisiez un nom d'hôte
explicite à la création du cookie&nbsp;: on ne peut pas faire
autrement. Vous pouvez installer le même cookie pour, à la fois,
<code>:0</code> et <code>light:0</code> avec un peu
d'astuce&nbsp;:</p>
<blockquote>
<pre><code>
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&amp;/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</code></pre></blockquote>
<h3>En utilisant le shell à distance, <code>rsh</code></h3>
<p>Si les répertoires <em>home</em> ne sont pas partagés, vous
pouvez transférer le cookie au moyen de rsh, le shell à
distance&nbsp;:</p>
<blockquote>
<pre><code>
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
</code></pre></blockquote>
<ol>
<li>Extraire le cookie de votre fichier local
<code>~/.Xauthority</code> (<code>xauth nlist :0</code>).</li>
<li>Le transférer vers dark.matt.er (<code>| rsh
dark.matt.er</code>).</li>
<li>Le mettre dans <code>~/.Xauthority</code> là (<code>xauth
nmerge -</code>).</li>
</ol>
<p>Notez l'utilisation de <code>${HOST}</code>. Vous devez
transférer le cookie qui est explicitement associé à l'hôte local.
Une application X distante interpréterait une valeur d'unité
d'affichage égale à <code>:0</code> comme étant une référence à la
machine distante, ce qui ne correspond pas à ce que l'on
veut&nbsp;!</p>
<h3>Manuellement, par Telnet</h3>
<p>Il est possible que <code>rsh</code> ne fonctionne pas chez
vous. En plus de cela, <code>rsh</code> a un inconvénient en ce qui
concerne la sécurité (noms d'hôtes usurpés, si je me souviens
bien). Si vous ne pouvez, ou ne voulez, pas utiliser
<code>rsh</code>, vous pouvez également transférer le cookie
manuellement, comme ceci&nbsp;:</p>
<blockquote>
<pre><code>
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&gt; add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926
xauth&gt; exit
Writing authority file /home/zweije/.Xauthority
dark% xfig &amp;
[15332]
dark% logout
light$
</code></pre></blockquote>
<p>Consultez également rsh(1) et xauth(1x) pour de plus amples
informations.</p>
<h3>En automatisant la méthode Telnet</h3>
<p>Il doit être possible de superposer le cookie sur la variable
<code>TERM</code> ou <code>DISPLAY</code> quand vous utilisez
telnet sur l'hôte éloigné. Cela doit fonctionner de la même manière
que de superposer la variable <code>DISPLAY</code> sur la variable
<code>TERM</code>. Regardez la section 5&nbsp;: Dire au client. De
mon point de vue, sur ce sujet, vous prenez vos responsabilités,
mais cela m'intéresse si quelqu'un peut me confirmer ou m'infirmer
cela.</p>
<p>Notez, cependant, qu'avec certains Unix les variables
d'environnement peuvent être visibles par les autres et vous ne
pourrez pas empêcher la visualisation du cookie dans
<code>$TERM</code> si certains veulent le voir.</p>
<h3>Utilisation du cookie</h3>
<p>Une application X, telle que <code>xfig</code> ci-dessus, sur
<code>dark.matt.er</code>, ira automatiquement voir le cookie dans
<code>~/.Xauthority</code> pour s'authentifier.</p>
<p>L'utilisation de <code>localhost:D</code> entraîne une petite
difficulté. Les applications X clientes traduisent
<code>localhost:D</code> en <code>host/unix:D</code> pour effectuer
la recherche du cookie. Effectivement, cela signifie qu'un cookie
pour <code>localhost:D</code> dans votre <code>~/.Xauthority</code>
n'a <em>aucun</em> effet.</p>
<p>Si l'on y réfléchit, c'est logique. L'interprétation de
<code>localhost</code> dépend entièrement de la machine sur
laquelle s'effectue cette interprétation. Si ce n'était pas le cas,
cela causerait un horrible bazar dans le cas d'un répertoire
personnel (home) partagé, par exemple par l'intermédiaire de NFS,
avec plusieurs hôtes interférant chacun avec ses propres
cookies.</p>
<h2><a name="ss6.3" id="ss6.3">6.3 Ssh</a></h2>
<p>Les enregistrements d'autorisation sont transmis sur le réseau
sans codage. Si vous vous souciez de ce que l'on puisse espionner
vos connexions, utilisez ssh, le shell sécurisé. Il effectuera des
transmissions X sécurisées au moyen de connexions chiffrées.</p>
<p>Pour activer la transmission X par ssh, utilisez l'option de la
ligne de commande <code>-X</code> ou écrivez ce qui suit dans votre
fichier local de configuration de ssh&nbsp;:</p>
<blockquote>
<pre><code>
Host remote.host.name
  ForwardX11 yes
</code></pre></blockquote>
<p>Le serveur ssh (<code>sshd</code>) du côté distant positionnera
automatiquement la variable <code>DISPLAY</code> sur l'extrémité du
tunnel X transmis. Le tunnel distant récupère son propre
cookie&nbsp;; le serveur ssh distant le génère pour vous et le
place dans <code>~/.Xauthority</code> là-bas. Ainsi, l'autorisation
X avec ssh est complètement automatique.</p>
<p>De plus, il est génial pour d'autres choses aussi. C'est une
bonne amélioration structurelle de votre système. Allez simplement
voir <a href="http://www.ssh.org/">http://www.ssh.org/</a>, la page
d'accueil de ssh.</p>
<p>Si vous possédez d'autres informations sur les méthodes
d'authentification ou de chiffrement des connexions X, par exemple,
grâce à Kerberos, envoyez-les moi, je les intégrerai ici.</p>
<h2><a name="s7" id="s7">7. Les applications X avec un
identificateur d'utilisateur (User-id) différent</a></h2>
<p>Supposez que vous vouliez faire tourner un outil graphique de
configuration qui nécessite d'avoir les privilèges du compte
<em>root</em> alors que la session X actuelle se déroule sous votre
compte. Cela peut sembler étrange au premier abord, mais le serveur
X <em>ne</em> permettra <em>pas</em> à cet outil d'accéder à votre
unité d'affichage. Comment cela est-il possible alors que
<em>root</em> peut normalement tout faire&nbsp;? Et comment
contourner ce problème&nbsp;?</p>
<p>Élargissons le propos au cas où l'on veut faire tourner une
application X, sous un identificateur d'utilisateur
<code>clientuser</code>, alors que la session X a été lancée par
<code>serveruser</code>. Si vous avez lu le paragraphe sur les
<em>cookies</em>, il est évident que <code>clientuser</code> ne
peut pas accéder à votre unité d'affichage&nbsp;:
<code>~clientuser/.Xauthority</code> ne contient pas le cookie
magique qui permet d'accéder à l'unité d'affichage. Le cookie
correct se trouve dans <code>~serveruser/.Xauthority</code>.</p>
<h2><a name="ss7.1" id="ss7.1">7.1 Plusieurs utilisateurs sur le
même hôte</a></h2>
<p>Naturellement, tout ce qui marche pour un X distant marchera
aussi pour un X à partir d'un identificateur d'utilisateur
différent (particulièrement <code>slogin localhost -l
clientuser</code>). Et ici l'hôte client et l'hôte serveur sont
précisément les mêmes. Cependant, quand les deux hôtes sont les
mêmes, il y a quelques raccourcis pour transférer le <em>cookie
magique</em>.</p>
<p>On supposera que l'on utilise <code>su</code> pour passer d'un
identificateur utilisateur à l'autre. Essentiellement, il faut
écrire un script qui appelle <code>su</code>, mais enveloppe la
commande que <code>su</code> exécute d'un peu de code qui effectue
les tâches nécessaires pour le X distant. Ces tâches nécessaires
sont l'initialisation de la variable <code>DISPLAY</code> et le
transfert du <em>cookie magique</em>.</p>
<p>L'initialisation de <code>DISPLAY</code> est relativement
facile&nbsp;; il faut simplement définir
<code>DISPLAY="$DISPLAY"</code> avant d'exécuter l'argument de la
commande su. Donc, il faut simplement faire&nbsp;:</p>
<blockquote>
<pre><code>
su - clientuser -c "env DISPLAY="$DISPLAY" clientprogram &amp;"
</code></pre></blockquote>
<p>Ce n'est pas tout, il faut encore transférer le cookie. On peut
le retrouver en utilisant <code>xauth list "$DISPLAY"</code>. Cette
commande renvoie le cookie dans un format qui convient pour
l'utiliser dans la commande <code>xauth add</code>&nbsp;: ce dont
nous avons justement besoin&nbsp;!</p>
<p>On pourrait imaginer passer le cookie par l'intermédiaire d'un
canal de transmission. Manque de chance, ce n'est pas si facile de
passer quelque chose à la commande <code>su</code> par
l'intermédiaire d'un canal de transmission car <code>su</code>
attend le mot de passe de l'entrée standard. Cependant, dans un
script shell on peut jongler avec quelques descripteurs de fichiers
et arriver à le faire.</p>
<p>Donc, on écrit un script de ce style en le paramétrant avec
<code>clientuser</code> et <code>clientprogram</code>. Pendant que
nous y sommes, améliorons un peu ce script, ça va le rendre un peu
moins compréhensible mais un peu plus robuste. Le tout ressemble à
cela&nbsp;:</p>
<blockquote>
<pre><code>
#!/bin/sh

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

CLIENTUSER="$1"
shift

# FD 4 becomes stdin too
exec 4&gt;&amp;0

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

    # FD 3 becomes xauth output
    # FD 0 becomes stdin again
    # FD 4 is closed
    exec 3&gt;&amp;0 0&gt;&amp;4 4&gt;&amp;-

    exec su - "$CLIENTUSER" -c \
         "xauth -q &lt;&amp;3
          exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*' 3&gt;&amp;-"

}
</code></pre></blockquote>
<p>Je pense que c'est portable et que cela fonctionne suffisamment
correctement dans la plupart des circonstances. Le seul défaut
auquel je pense en ce moment est dû à l'utilisation de
<code>'$*'</code>, les guillemets simples dans <code>command</code>
vont perturber les guillemets de l'argument(<code>'$*'</code>) de
la commande <code>su</code>. Si cela entraîne quelque chose de
vraiment gênant, envoyez-moi un courrier électronique.</p>
<p>Nommez le script <code>/usr/local/bin/xsu</code>, et vous pouvez
faire&nbsp;:</p>
<blockquote>
<pre><code>
xsu clientuser 'command &amp;'
</code></pre></blockquote>
<p>Cela ne peut pas être plus facile, à moins que vous ne vous
débarrassiez du mot de passe. Oui, il existe des moyens pour y
arriver (<code>sudo</code>), mais ce n'est pas l'endroit pour en
parler.</p>
<p>Le petit script <code>xsu</code> mentionné ci-dessus a servi
comme base pour un script plus étendu appelé <code>sux</code> qui
a, apparemment, trouvé sa place comme paquet dans la distribution
<a href="http://www.debian.org/">Debian</a>.</p>
<h2><a name="ss7.2" id="ss7.2">7.2 Root est l'utilisateur
client</a></h2>
<p>É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
<code>~/.Xauthority</code> de tout le monde. Il n'y a pas besoin de
transférer le cookie. Tout ce qu'il y a à faire consiste à
initialiser <code>DISPLAY</code>, et à faire pointer
<code>XAUTHORITY</code> sur <code>~serveruser/.Xauthority</code>.
Donc, vous pouvez écrire&nbsp;:</p>
<blockquote>
<pre><code>
su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  command"
</code></pre></blockquote>
<p>Et, en mettant cela dans un script, cela donne quelque chose
comme&nbsp;</p>
<blockquote>
<pre><code>
#!/bin/sh
if [ $# -lt 1 ]
then echo "usage: `basename $0` command" &gt;&amp;2
     exit 2
fi
su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  "'"$SHELL"'" -c '$*'"
</code></pre></blockquote>
<p>Nommez le script <code>/usr/local/bin/xroot</code>, et vous
pouvez faire&nbsp;:</p>
<blockquote>
<pre><code>
xroot 'control-panel &amp;'
</code></pre></blockquote>
<p>Cependant, si vous avez déjà initialisé <code>xsu</code> , il
n'y a pas de vraie raison de faire cela.</p>
<h2><a name="s8" id="s8">8. Faire tourner un gestionnaire de
fenêtres distant</a></h2>
<p>Un gestionnaire de fenêtres (comme <code>twm</code>,
<code>wmaker</code>, ou <code>fvwm95</code>) est une application
comme n'importe quelle autre. La procédure normale devrait
fonctionner.</p>
<p>Enfin, presque. Il ne peut tourner, au plus, qu'un seul
gestionnaire de fenêtres à un instant donné dans une unité
d'affichage. Si vous faites déjà tourner un gestionnaire de fenêtre
local, vous ne pouvez pas lancer le gestionnaire distant (il le
dira et s'arrêtera). Il faut tuer (ou simplement quitter) le
gestionnaire local en premier.</p>
<p>Par manque de chance, beaucoup de scripts de sessions X se
terminent par un</p>
<blockquote>
<pre><code>
exec le-gestionnaire-de-fenetres-de-votre-choix
</code></pre></blockquote>
<p>et cela signifie que quand le gestionnaire de fenêtre (local) se
termine, votre session se termine, et le système (xdm ou xinit)
considère que votre session est terminée, et effectivement, vous
déconnecte.</p>
<p>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 <code>~/.xsession</code> ou
<code>~/.xinitrc</code>) pour arriver à vos fins.</p>
<p>Attention, un gestionnaire de fenêtres permet souvent de faire
tourner de nouveaux programmes qui s'exécuteront sur la machine
locale. C'est-à-dire locale à la machine sur lequel tourne le
gestionnaire de fenêtres. Si vous faites tourner un gestionnaire de
fenêtres 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.</p>
<h2><a name="s9" id="s9">9. Mettre en place un terminal X</a></h2>
<p>Trouvez une utilisation à votre vieux PC&nbsp;! Faites-en un
endroit supplémentaire pour pouvoir travailler&nbsp;! Pas besoin
d'acheter un nouveau matériel coûteux&nbsp;! Vous avez déjà tout ce
qu'il faut&nbsp;!</p>
<p>Sérieusement, vous pouvez mettre en place un vieux PC comme
terminal X. Un terminal X est un ordinateur qui fondamentalement
n'exécute 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'exécuteront sur l'hôte distant et ils utiliseront le serveur X
distant pour afficher leur sortie sur votre terminal X local. Même
le gestionnaire de fenêtre s'exécutera à distance.</p>
<p>Un terminal X consomme peu de ressources en comparaison d'une
machine Unix complète. J'ai ici un terminal X constitué par un
processeur 486, 16&nbsp;Mo de RAM et 250&nbsp;Mo d'espace disque.
Oh et une connexion réseau, naturellement. Il n'a même pas besoin
d'avoir des répertoires utilisateurs.</p>
<p>Pour trouver des lectures liées à ce sujet, jetez un coup d'oeil
aux documents suivants&nbsp;:</p>
<ul>
<li>Le <em>petit guide XDM et Terminal X</em> ( <a href=
"http://www.traduc.org/docs/HOWTO/mini/lecture/XDM-Xterm.html">http://www.traduc.org/docs/HOWTO/mini/lecture/XDM-Xterm.html</a>).
Ce document est une description complète de ce qui est possible
avec XDMCP et xdm, appliqué à la construction de terminaux X. Vous
devriez vraiment le lire.</li>
<li>Le <em>guide pratique XDMCP</em> ( <a href=
"http://www.traduc.org/docs/HOWTO/lecture/XDMCP-HOWTO.html">http://www.traduc.org/docs/HOWTO/lecture/XDMCP-HOWTO.html</a>).
Ce document décrit les étapes nécessaires à 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 décrite
de façon plus succinte.</li>
<li>Le <em>petit guide Xterminal</em> ( <a href=
"http://www.traduc.org/docs/HOWTO/mini/lecture/X-Terminal.html">http://www.traduc.org/docs/HOWTO/mini/lecture/X-Terminal.html</a>).
Il n'est pas actuellement maintenu, mais il peut contenir quelques
informations intéressantes pour vous.</li>
</ul>
<p>À la différence 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 problèmes de sécurité impliqués.</p>
<h2><a name="ss9.1" id="ss9.1">9.1 Une fois de plus, un peu de
théorie en premier</a></h2>
<p>En ce qui concerne X, le terminal X va n'exécuter rien d'autre
qu'un serveur X. Ce serveur X sera configuré pour dialoguer avec
l'hôte distant en utilisant XDMCP (le protocole de contrôle de
gestion d'affichage X, �&nbsp;X Display Manager Control
Protocol&nbsp;�). Il va demander à l'hôte distant une session X.
L'hôte distant fournira une fenêtre de connexion dans le terminal X
et après la connexion, il exécutera une session X avec tout
l'habillage y compris le gestionnaire de fenêtres, tout cela
utilisant X distant pour l'affichage sur le terminal X.</p>
<p>Vous aurez probablement remarqué que l'hôte distant agit comme
un serveur, bien que pas comme un serveur X. L'hôte distant fournit
les sessions X aux serveurs X qui les demandent. Ainsi, selon
XDMCP, l'hôte distant est en fait un serveur, fournissant des
sessions X, également connu sous le nom de serveur XDMCP. Le
serveur X joue le rôle d'un client XDMCP&nbsp;! Vous me
suivez&nbsp;?</p>
<p>Le programme qui fournit le service XDMCP sur le serveur XDMCP
est <code>xdm</code>. Donc, pour exécuter un terminal X, vous devez
configurer deux programmes&nbsp;: <code>X</code> (le client XDMCP)
sur le terminal X et xdm (le serveur XDMCP) sur l'hôte distant.</p>
<p>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 réseau peut être espionné par
d'autres hôtes du réseau. Ceci est particulièrement néfaste avec
les sessions X distantes car la première chose qui se passe est la
connexion en donnant l'utilisateur et le mot de passe. <b>Vous ne
devez donc exécuter X à distance que sur un réseau
sécurisé&nbsp;!</b></p>
<h2><a name="ss9.2" id="ss9.2">9.2 Configurer <code>X</code> comme
client XDMCP</a></h2>
<p>Si vous désirez mettre en place une machine Linux comme terminal
X, vous avez besoin de très peu de ressources. Fondamentalement,
vous avez besoin de ce qu'il est nécessaire d'avoir pour faire
fonctionner une machine Linux dépouillée plus un serveur X.
Spécifiquement, vous <em>n'avez pas</em> besoin des clients et
bibliothèques X. Il peut être utile d'installer certaines polices
X, mais vous pouvez également utiliser un serveur de polices situé
quelque part sur le réseau.</p>
<p>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 requête et
utiliser le premier serveur XDMCP qui répond. Enfin, le serveur X
peut demander à un serveur XDMCP de lui fournir une liste des hôtes
qui acceptent de fournir une session et laisser l'utilisateur
choisir l'hôte de session.</p>
<ol>
<li>Si vous connaissez l'hôte qui va vous fournir une session,
utilisez-le directement. Exécutez
<blockquote>
<pre><code>
X -query sessionhost
</code></pre></blockquote>
et, en supposant que <code>xdm</code> fonctionne sur
<code>sessionhost</code>, vous obtiendrez une fenêtre de connexion
et, après connexion, une session X.</li>
<li>Si l'hôte duquel vous obtiendrez la session vous importe peu,
utilisez la méthode d'émission de multi-diffusion. Exécutez
<blockquote>
<pre><code>
X -broadcast
</code></pre></blockquote>
et, en supposant que <code>xdm</code> fonctionne sur un hôte
quelque part sur le réseau, vous obtiendrez une fenêtre de
connexion du premier (et, on l'espère, du plus rapide)
<code>xdm</code> qui répond et, après connexion, une session
X.</li>
<li>Si vous désirez choisir l'hôte où vous voulez avoir votre
session, demandez au serveur XDMCP une liste des hôtes. Exécutez
<blockquote>
<pre><code>
X -indirect xdmcpserver
</code></pre></blockquote>
et, en supposant que <code>xdm</code> est bien configuré sur ce
serveur, une liste des hôtes vous sera présentée parmi lesquels
vous pourrez choisir. Choisissez-en un&nbsp;; vous obtiendrez la
fenêtre de connexion pour cet hôte et, après connexion, la session
que vous avez demandée.</li>
</ol>
<p>Il se peut que vous ayez remarqué l'absence de l'option
<code>-auth</code>. Le serveur X utilisera XDMCP pour négocier le
mot de passe secret (�&nbsp;magic cookie&nbsp;�) avec le serveur
XDMCP. Le serveur XDMCP placera le cookie dans votre
<code>~/.Xauthority</code> après la connexion.</p>
<p>Après 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 désirez pas cela, vous
pouvez utiliser l'option <code>-once</code>. Notez que ceci ne
semble pas fonctionner avec l'option <code>-indirect</code> à cause
de l'implémentation du �&nbsp;chooser&nbsp;�.</p>
<p>Quand vous avez déterminé la façon dont vous allez exécuter le
serveur X, vous pouvez alors le placer dans un script de démarrage
ou même l'exécuter directement à partir de
<code>/etc/inittab</code>. Veuillez consulter la documentation de
votre propre distribution pour savoir comment modifier vos scripts
d'amorçage ou <code>/etc/inittab</code>.</p>
<p>N'exécutez <em>pas</em> un serveur X ainsi depuis le fichier de
configuration <code>Xservers</code>. <code>xdm</code> s'attend à
pouvoir se connecter à de tels serveurs et il pourrait les tuer
s'il ne peut pas se connecter.</p>
<h2><a name="ss9.3" id="ss9.3">9.3 Configurer <code>xdm</code>
comme serveur XDMCP</a></h2>
<p>Le programme qui fournit le service XDMCP (le service de
session) est généralement <code>xdm</code>. Il existe des variantes
de celui-ci, comme <code>wdm</code> ou <code>gdm</code> sur Linux,
mais ceux-ci fonctionnent fondamentalement de la même façon.
Assurez-vous donc que <code>xdm</code> ou une variante est installé
sur l'hôte où vous désirez exécuter vos sessions X. Si vous
disposez d'une connexion graphique locale depuis l'hôte de session
X, <code>xdm</code> est déjà installé&nbsp;; la plupart des
distributions Linux sont ainsi fournis de nos jours.</p>
<p>En plus de <code>xdm</code>, vous aurez besoin des programmes
que vous désirez exécuter dans une session X. C'est-à-dire, tous
les clients X comme <code>xterm</code>, <code>xfig</code>,
<code>xclock</code>, des gestionnaires de fenêtre et ainsi de
suite. Cependant, pour un serveur XDMCP, vous n'avez <em>pas</em>
besoin d'installer de serveur X&nbsp;; le serveur X fonctionnera à
la place sur le terminal X.</p>
<p>À 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 <em>direct</em> qui consiste à permettre
la connexion d'un client XDMCP et à lui fournir une session X. Il y
a également le service <em>indirect</em> dans lequel le serveur
fournit une liste d'hôtes fournissant un service direct, au choix
pour le client XDMCP.</p>
<p>Tous les services <code>xdm</code> sont configurés dans le
fichier d'accès, généralement situé à
<code>/etc/X11/xdm/Xaccess</code> ou un emplacement semblable. Cet
emplacement est en fait défini dans le fichier de configuration
général de <code>xdm</code> <code>/etc/X11/xdm/xdm-config</code>
par la ressource <code>accessFile</code>. Veuillez voir votre
manuel <code>xdm</code> pour l'emplacement par défaut.</p>
<ol>
<li>
<p>Si vous désirez autoriser <code>xdm</code> à fournir des
sessions X aux clients XDMCP, que ce soit par multi-diffusion ou
non, placez le nom d'hôte du client XDMCP (le serveur X, vous vous
souvenez&nbsp;?) seul sur une ligne dans le fichier
<code>Xaccess</code>. En fait, vous pouvez placer un expression
rationnelle correspondant à plusieurs hôtes. Voici quelques
expressions valides&nbsp;:</p>
<blockquote>
<pre><code>
xterm023.my.domain      # xterm023.my.domain peut obtenir une session X
*.my.domain             # tout hôte dans my.domain peut obtenir une session X
*                       # tout hôte sur Internet peut obtenir une session X (non sécurisé)
</code></pre></blockquote>
<p>Vouloir fournir une session X à tout hôte sur Internet est
discutable. De façon évidente, tout service que vous fournissez est
une faille de sécurité potentielle dans la sécurité de votre
serveur. D'un autre côté, le serveur devrait être sécurisé lui-même
et un client XDMCP demandant une session X doit fournir une
authentification valide avant que la session X ne soit
accordée.</p>
<p>De plus, la session X utilise une connexion X distante qui n'est
pas chiffrée. La paire nom d'utilisateur/mot de passe de connexion
sera transportée 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 même pire que
d'avoir son mot de passe secret (�&nbsp;magic cookie&nbsp;�)
espionné.</p>
<p>Prenez vos propres décisions ici, mais je recommande de ne pas
activer ce service au monde entier à moins d'avoir une bonne
raison.</p>
</li>
<li>
<p>Si vous désirez fournir aux clients XDMCP (<code>X -indirect
xdmcpserver</code>) une liste de choix (une liste d'hôtes pour
choisir duquel ils obtiendront une session X), faite suivre
l'expression rationnelle du client par le mot-clé
<code>CHOOSER</code> et la liste des hôtes que le client peut
choisir. À la place de la liste des hôtes, vous pouvez également
spécifier <code>BROADCAST</code>&nbsp;; avec ceci, <code>xdm</code>
émet en multi-diffusion sur le réseau pour interroger les serveurs
désirant fournir une session. Des exemples valides&nbsp;:</p>
<blockquote>
<pre><code>
xterm023.my.domain      CHOOSER seshost1 seshost2
*.my.domain             CHOOSER BROADCAST
*                       CHOOSER extseshost1 extseshost2
</code></pre></blockquote>
Le premier exemple permet à <code>xterm023</code> de choisir entre
des sessions sur <code>seshost1</code> et sur
<code>seshost2</code>. Le deuxième exemple permet à tout hôte dans
<code>my.domain</code> de choisir n'importe quel hôte fournissant
une session X. Le troisième exemple permet à tout hôte de choisir
une session entre <code>extseshost1</code> et
<code>extseshost2</code>.
<p>Ce n'est probablement pas une bonne idée de faire <code>*
CHOOSER BROADCAST</code>. Ceci permettrait à tout hôte en dehors de
votre réseau d'obtenir des informations sur les hôtes dans votre
réseau. Vous ne voulez probablement pas communiquer une telle
information. En fait, autoriser un choix pour tout hôte extérieur
n'est probablement pas très utile de toute façon, car vous ne
devriez pas autoriser des connexions arbitraires directes non
plus.</p>
</li>
</ol>
<p>Quand vous avez reconfiguré <code>xdm</code>, envoyez-lui le
signal <code>HUP</code> pour le forcer à relire ses fichiers de
configuration.</p>
<blockquote>
<pre><code>
# kill -HUP pid-of-xdm
#
</code></pre></blockquote>
<h2><a name="ss9.4" id="ss9.4">9.4 XDMCP techniquement</a></h2>
<p>Techniquement, pour autant que je puisse le voir, XDMCP n'est
pas tout à fait ce à quoi vous pouvez vous attendre d'après la
description ci-dessus. <code>xdm</code> peut rediriger des serveurs
X se connectant, vers un autre endroit et il utilise cette astuce
pour implémenter la liste de choix. Ainsi, le choix se produit dans
xdm et non dans le serveur X bien que la liste de choix soit
représentée dans l'affichage du serveur X. C'est également pour
cela que l'option <code>-once</code> du serveur X ne se combine pas
avec <code>-indirect</code>.</p>
<h2><a name="s10" id="s10">10. Maintenance</a></h2>
<p>D'ordinaire, la première 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.</p>
<blockquote>
<pre><code>
xterm Xt error: Can't open display:
</code></pre></blockquote>
<p>Il n'y a pas de variable DISPLAY renseignée dans votre
environnement et vous n'avez pas non plus lancé l'application avec
le drapeau <code>-display</code>. L'application assume que la
variable display contient une chaîne de caractères vide, ce qui est
syntaxiquement incorrect. La solution à cela consiste à s'assurer
que la variable DISPLAY est correctement renseignée dans
l'environnement (avec <code>setenv</code> ou <code>export</code>
selon votre shell).</p>
<blockquote>
<pre><code>
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</code></pre></blockquote>
<p>Erreur 101 signifie «&nbsp;Réseau inaccessible&nbsp;».
L'application n'arrive pas à se connecter au serveur à travers le
réseau. Vérifiez que la variable <code>DISPLAY</code> est
correctement renseignée et que la machine serveur est accessible à
partir de votre client (ce qui devrait être le cas, car après tout
vous êtes probablement connecté au serveur en ayant une session
telnet avec votre client).</p>
<blockquote>
<pre><code>
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</code></pre></blockquote>
<p>Erreur 111 signifie «&nbsp;Connexion refusée&nbsp;». La machine
à laquelle vous êtes en train d'essayer de vous connecter peut être
atteinte, mais le serveur indiqué n'existe pas à cet endroit.
Vérifiez que vous utilisez le nom d'hôte correct et le numéro
d'unité d'affichage adéquat.</p>
<p>Sinon, il est possible que le serveur X a été configuré pour
<em>ne pas</em> é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
paramètre <code>-nolisten tcp</code> et si oui, enlevez-le.</p>
<blockquote>
<pre><code>
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
</code></pre></blockquote>
<p>Le client pourrait réaliser une connexion avec le serveur, mais
celui-ci ne permet pas au client de l'utiliser (pas autorisé).
Assurez-vous que vous avez transféré le bon cookie au client, et
qu'il n'est pas périmé (le serveur utilise un nouveau cookie au
démarrage d'une nouvelle session).</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Remote-X-Apps.html
