/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 Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>Petit guide d'ex&eacute;cution &agrave; distance des
applications X</title>
</head>
<body>
<h1>Petit guide d'ex&eacute;cution &agrave; distance des
applications X</h1>
<h2>Version fran&ccedil;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&eacute;cembre 2001
<hr>
<em>Ce petit guide d&eacute;crit comment ex&eacute;cuter des
applications X &agrave; distance. C'est-&agrave;-dire, comment
faire pour qu'un programme X s'affiche sur un &eacute;cran
d'ordinateur diff&eacute;rent de celui sur lequel il
s'ex&eacute;cute. Ou, autrement dit, comment faire tourner un
programme X sur un ordinateur diff&eacute;rent de celui devant
lequel vous &ecirc;tes assis. L'accent de ce petit guide sera mis
sur les questions de s&eacute;curit&eacute;. Ce petit guide
contient &eacute;galement des informations sur la mani&egrave;re de
faire tourner des applications X en local, mais avec un
identificateur d'utilisateur (user-id) diff&eacute;rent ainsi que
des informations sur la fa&ccedil;on de mettre en place un
ordinateur comme terminal X. Adaptation fran&ccedil;aise&nbsp;:
Albert-Paul Bouillot, Fr&eacute;d&eacute;ric Bothamy <a href=
"mailto:fbothamy@mail.dotcom.fr">fbothamy@mail.dotcom.fr</a>.
Relecture de la version fran&ccedil;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&egrave;re de faire
tourner des applications X &agrave; distance. J'ai
r&eacute;dig&eacute; ce document pour plusieurs raisons&nbsp;:</p>
<ol>
<li>Il y a eu de nombreuses questions, sur Usenet, sur la
mani&egrave;re de faire tourner des applications X &agrave;
distance&nbsp;;</li>
<li>J'ai vu beaucoup, beaucoup de conseils d'utilisation de
&laquo;&nbsp;<code>xhost +hostname</code>&nbsp;&raquo; ou
m&ecirc;me de &laquo;&nbsp;<code>xhost +</code>&nbsp;&raquo; pour
r&eacute;aliser des connexions X. <b>C'est d'une
ins&eacute;curit&eacute; totale</b>, et il existe de bien
meilleures m&eacute;thodes&nbsp;;</li>
<li>Je n'ai pas connaissance d'un document simple d&eacute;crivant
les options dont <em>on peut</em> disposer. Si vous avez des
informations compl&eacute;mentaires, s'il vous pla&icirc;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 &eacute;t&eacute; &eacute;crit en pensant &agrave;
des syst&egrave;mes de type Unix. Si le syst&egrave;me
d'exploitation de votre ordinateur local ou de celui qui est
&agrave; distance est de type diff&eacute;rent, vous devriez
trouver ici des informations sur la mani&egrave;re dont les choses
se passent. Cependant, il vous faudra modifier les exemples par
vous-m&ecirc;me pour les utiliser sur votre propre
syst&egrave;me.</p>
<p>La version (anglaise) la plus r&eacute;cente de ce document est
toujours disponible sur le WWW &agrave; <a href=
"http://www.xs4all.nl/~zweije/xauth.html">http://www.xs4all.nl/~zweije/xauth.html</a>.
Il est &eacute;galement disponible en tant que mini-HOWTO Linux
&laquo;&nbsp;Applications X &agrave; distance&nbsp;&raquo; (Remote
X Apps) &agrave;&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&ccedil;aise la plus r&eacute;cente de ce
document est toujours disponible sur le site du projet <a href=
"http://www.traduc.org">traduc.org</a> &agrave; <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&eacute;es,
ajouts, pointeurs utiles, corrections (typo), et c&aelig;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&eacute;es vers /dev/null. Ce
document est diffus&eacute; 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 &eacute;t&eacute; mis &agrave;
jour le 8 d&eacute;cembre 2001 par <a href=
"http://www.xs4all.nl/~zweije/index.html">Vincent Zweije</a>. La
version fran&ccedil;aise de ce document a &eacute;t&eacute; mise
&agrave; jour le 4 mars 2003 par <a href=
"mailto:fbothamy@mail.dotcom.fr">Fr&eacute;d&eacute;ric
Bothamy</a>. La relecture de cette nouvelle version
fran&ccedil;aise a &eacute;t&eacute; r&eacute;alis&eacute;e par
<a href="mailto:kalou@kalou.net">Olivier Kaloudoff</a>.</p>
<h2><a name="s2" id="s2">2. Lectures
compl&eacute;mentaires</a></h2>
<p>Un document, en rapport avec cela, sur le WWW traite de
&laquo;&nbsp;Que faire quand Tk dit que votre &eacute;cran n'est
pas s&ucirc;r&nbsp;&raquo;, <a href=
"http://ce-toolkit.crd.ge.com/tkxauth/">http://ce-toolkit.crd.ge.com/tkxauth/</a>.
Il a &eacute;t&eacute; &eacute;crit par <a href=
"http://ce-toolkit.crd.ge.com/people/kennykb.html">Kevin Kenny</a>.
Il sugg&egrave;re une solution similaire &agrave; celle de ce
document pour l'authentification X (xauth). Cependant, Kevin vise
plus &agrave; l'utilisation de xdm pour diriger xauth &agrave;
votre place.</p>
<p>On m'a indiqu&eacute; que le volume 8 de la s&eacute;rie
consacr&eacute;e au syst&egrave;me X Window, le &laquo;&nbsp;Guide
de l'administrateur du syst&egrave;me X Window&nbsp;&raquo; de chez
<a href="http://www.oreilly.com/">O'Reilly and Associates</a>
&eacute;tait une bonne source d'informations. Cependant, ce guide
n'a pas &eacute;t&eacute; mis &agrave; jour depuis sa publication
d'origine en 1992. Il ne couvre donc que X11R4 et X11R5, tout ce
qui est sp&eacute;cifique &agrave; X11R6 n'est pas couvert.</p>
<p>Il y a &eacute;galement un autre document qui ressemble beaucoup
&agrave; celui que vous &ecirc;tes en train de lire, dont le titre
est &laquo;&nbsp;Securing X Windows&nbsp;&raquo;, et qui est
disponible &agrave; <a href=
"http://ciac.llnl.gov/ciac/documents/ciac2316.html">http://ciac.llnl.gov/ciac/documents/ciac2316.html</a>.</p>
<p>Consultez &eacute;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 &ecirc;tes
dans l'environnement X Window pour taper au clavier et regarder
l'&eacute;cran. Sur le second, vous effectuez un important
traitement graphique. Vous voulez que les sorties du second soient
affich&eacute;es sur l'&eacute;cran du premier. Le syst&egrave;me X
Window rend cela possible.</p>
<p>Naturellement, vous devez disposer d'une connexion &agrave; un
r&eacute;seau pour pouvoir le r&eacute;aliser. De
pr&eacute;f&eacute;rence rapide, car le protocole X est un
d&eacute;voreur de ressources r&eacute;seau. Mais, avec un peu de
patience et un protocole de compression de donn&eacute;es
adapt&eacute;, vous pouvez m&ecirc;me faire tourner des
applications par l'interm&eacute;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 &agrave; faire pour r&eacute;aliser tout
cela&nbsp;:</p>
<ol>
<li>Indiquer &agrave; l'unit&eacute; d'affichage locale (le
serveur) qu'elle doit accepter les connexions venant de
l'ordinateur &agrave; distance.</li>
<li>Dire &agrave; l'application &agrave; distance (le client) de
rediriger ses sorties vers votre unit&eacute; d'affichage
locale.</li>
</ol>
<h2><a name="s4" id="s4">4. Un peu de th&eacute;orie</a></h2>
<p>Le mot magique est <code>DISPLAY (unit&eacute;
d'affichage)</code>. Dans le syst&egrave;me X Window, une
unit&eacute; d'affichage est constitu&eacute;e (en simplifiant)
d'un clavier, d'un mulot et d'un &eacute;cran. Une unit&eacute;
d'affichage est g&eacute;r&eacute;e par un programme serveur, plus
connu sous le nom de serveur X. Le serveur fournit des
fonctionnalit&eacute;s d'affichage aux autres programmes qui se
connectent &agrave; lui.</p>
<p>Une unit&eacute; d'affichage est identifi&eacute;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&eacute; d'affichage est constitu&eacute; d'un nom
d'h&ocirc;te (par exemple&nbsp;: <code>light.uni.verse</code> et
<code>localhost</code>), du signe deux point (<code>:</code>), et
d'un num&eacute;ro de s&eacute;quence (tels que <code>0</code> et
<code>4</code>). Le nom d'h&ocirc;te de l'unit&eacute; d'affichage
est le nom de l'ordinateur sur lequel tourne le serveur X. Si le
nom de l'h&ocirc;te est omis, cela signifie qu'il s'agit de
l'ordinateur local. D'habitude, le num&eacute;ro de s&eacute;quence
est 0 &ndash; cela peut changer s'il y a plusieurs unit&eacute;s
d'affichage connect&eacute;es sur le m&ecirc;me ordinateur.</p>
<p>Si jamais il vous arrive de voir le nom d'une unit&eacute;
d'affichage avec un <code>.n</code> suppl&eacute;mentaire
accol&eacute; &agrave; son nom, c'est qu'il s'agit d'un
num&eacute;ro d'&eacute;cran. Une unit&eacute; d'affichage peut, en
th&eacute;orie, avoir plusieurs &eacute;crans. Cependant,
d'habitude, il n'y en a qu'un, qui porte le num&eacute;ro
<code>n=0</code>, et c'est le num&eacute;ro par d&eacute;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 &eacute;cran <code>S</code>
sur unit&eacute; d'affichage <code>D</code> de l'h&ocirc;te
<code>hostname</code>&nbsp;: le serveur X de cette unit&eacute;
d'affichage est &agrave; l'&eacute;coute du port TCP
<code>6000+D</code>.</li>
<li><code>host/unix:D.S</code> signifie &eacute;cran <code>S</code>
sur unit&eacute; d'affichage <code>D</code> de l'h&ocirc;te
<code>host</code>&nbsp;: le serveur X de cette unit&eacute;
d'affichage est &agrave; l'&eacute;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 &eacute;quivalent &agrave;
<code>host/unix:D.S</code>, o&ugrave; <code>host</code> est le nom
de l'h&ocirc;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 &agrave; quelle unit&eacute; d'affichage il doit se connecter
en consultant la variable d'environnement <code>DISPLAY</code>.
Cependant ce param&eacute;trage peut &ecirc;tre modifi&eacute; en
lan&ccedil;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&eacute;rieur sous le nom
light, et nous sommes dans le domaine uni.verse. Si nous
fonctionnons avec un serveur X normal, l'unit&eacute; d'affichage
est connue comme &eacute;tant <code>light.uni.verse:0</code>. Nous
voulons faire tourner le programme de dessin xfig sur un ordinateur
&agrave; distance, appel&eacute; <code>dark.matt.er</code>, et
afficher sa sortie ici, sur light.</p>
<p>Supposons que vous vous soyez d&eacute;j&agrave; connect&eacute;
par telnet &agrave; l'ordinateur distant,
<code>dark.matt.er</code>.</p>
<p>Si l'interpr&eacute;teur de commande de l'ordinateur
&eacute;loign&eacute; 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&egrave;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 &agrave;
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&ucirc;r, &eacute;galement&nbsp;:</p>
<blockquote>
<pre>
<code>dark$ xfig -display light.uni.verse:0 &amp;
</code>
</pre></blockquote>
<p>Il para&icirc;t que certaines versions de telnet transmettent
automatiquement la variable <code>DISPLAY</code> &agrave;
l'ordinateur h&ocirc;te &eacute;loign&eacute;. 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&eacute;e, sous-jacente &agrave; cette superposition, est de
r&eacute;aliser une sorte de script pour effectuer ceci&nbsp;:
avant la connexion par telnet, donnez la valeur de
<code>DISPLAY</code> &agrave; <code>TERM</code>. Puis, lancez
telnet. Du c&ocirc;t&eacute; de l'ordinateur distant, dans le
fichier <code>.*shrc</code> concern&eacute;, lisez la valeur de
<code>DISPLAY</code> &agrave; 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&ugrave;. Vous ne voulez pas que n'importe qui puisse afficher des
fen&ecirc;tres sur votre &eacute;cran. Ou lire ce vous tapez
&ndash; souvenez-vous que votre clavier fait partie de votre
unit&eacute; d'affichage&nbsp;!</p>
<p>Trop peu de gens semble r&eacute;aliser que permettre
l'acc&egrave;s &agrave; leur unit&eacute; d'affichage pose des
probl&egrave;mes de s&eacute;curit&eacute;. Quelqu'un qui dispose
d'un acc&egrave;s &agrave; votre unit&eacute; d'affichage peut lire
et &eacute;crire sur vos &eacute;crans, lire vos frappes au
clavier, et suivre les d&eacute;placements de votre mulot.</p>
<p>La plupart des serveurs disposent de deux mani&egrave;res
d'authentifier les demandes de connexions qui arrivent&nbsp;: le
m&eacute;canisme de la liste d'h&ocirc;tes (xhost) et le
m&eacute;canisme du mot de passe secret (magic cookie) (xauth). De
plus, il y a ssh, l'interpr&eacute;teur de commande
s&eacute;curis&eacute;, qui peut acheminer les connexions X.</p>
<p>Veuillez noter que certains serveurs X (de XFree86) peuvent
&ecirc;tre configur&eacute;s pour ne pas &eacute;couter sur le port
habituel TCP avec le param&egrave;tre <code>-nolisten tcp</code>.
La configuration par d&eacute;faut de Debian GNU/Linux, notamment,
d&eacute;sactive l'&eacute;coute sur le port TCP par le serveur X.
Si vous d&eacute;sirez utiliser X &agrave; distance sur un
syst&egrave;me Debian, vous devriez r&eacute;activer ceci en
modifiant la fa&ccedil;on dont est lanc&eacute; le serveur X.
Veuillez voir le fichier <code>/etc/X11/xinit/xserverrc</code> pour
un point de d&eacute;part.</p>
<h2><a name="ss6.1" id="ss6.1">6.1 Xhost</a></h2>
<p>Xhost permet les acc&egrave;s bas&eacute;s sur les nom
d'h&ocirc;tes. Le serveur entretient une liste des h&ocirc;tes qui
sont autoris&eacute;s &agrave; se connecter &agrave; lui. Il peut
aussi d&eacute;sactiver compl&egrave;tement la v&eacute;rification
des h&ocirc;tes. Attention&nbsp;: cela signifie que plus aucun
contr&ocirc;le n'est effectu&eacute;, et donc, que <em>n'importe
quel</em> h&ocirc;te peut se connecter&nbsp;!</p>
<p>Vous pouvez contr&ocirc;ler la liste des h&ocirc;tes du serveur
avec le programme <code>xhost</code>. Pour utiliser ce
m&eacute;canisme dans l'exemple pr&eacute;c&eacute;dent,
faites&nbsp;:</p>
<blockquote>
<pre>
<code>light$ xhost +dark.matt.er
</code>
</pre></blockquote>
<p>Ceci permet toutes les connexions &agrave; partir de
l'h&ocirc;te <code>dark.matt.er</code>. D&egrave;s que votre client
X a r&eacute;alis&eacute; sa connexion et affiche une
fen&ecirc;tre, par s&eacute;curit&eacute;, 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&eacute;sactiver la v&eacute;rification des
h&ocirc;tes avec&nbsp;:</p>
<blockquote>
<pre>
<code>light$ xhost +
</code>
</pre></blockquote>
<p>Ceci d&eacute;sactive la v&eacute;rification des acc&egrave;s
des h&ocirc;tes et donc permet &agrave; <em>tout le monde</em> de
se connecter. Vous ne devriez <em>jamais</em> faire cela sur un
r&eacute;seau o&ugrave; vous n'avez pas confiance dans
<em>tous</em> les utilisateurs (tel internet). Vous pouvez
r&eacute;activer la v&eacute;rification des h&ocirc;tes
avec&nbsp;:</p>
<blockquote>
<pre>
<code>light$ xhost -
</code>
</pre></blockquote>
<p><code>xhost -</code> par lui-m&ecirc;me <em>ne supprime pas</em>
tous les h&ocirc;tes de la liste d'acc&egrave;s (ce qui serait tout
&agrave; fait inutile - vous ne pourriez plus vous connecter de
n'importe o&ugrave;, pas m&ecirc;me de votre h&ocirc;te local).</p>
<p><em>Xhost est un m&eacute;canisme vraiment tr&egrave;s peu
s&ucirc;r.</em> Il ne fait pas de distinction entre les
diff&eacute;rents utilisateurs sur l'h&ocirc;te &agrave; distance.
De plus, les noms d'h&ocirc;tes (en r&eacute;alit&eacute; des
adresses) peuvent &ecirc;tre manipul&eacute;s. C'est mauvais si
vous vous trouvez sur un r&eacute;seau douteux (d&eacute;j&agrave;,
par exemple, avec un acc&egrave;s PPP t&eacute;l&eacute;phonique
&agrave; Internet).</p>
<h2><a name="ss6.2" id="ss6.2">6.2 Xauth</a></h2>
<p>Xauth autorise l'acc&egrave;s &agrave; tous ceux qui connaissent
le bon secret. On appelle un tel secret un enregistrement
d'autorisation ou cookie. Ce m&eacute;canisme d'autorisation est
d&eacute;sign&eacute; c&eacute;r&eacute;monieusement comme
&eacute;tant le MIT-MAGIC-COOKIE-1.</p>
<p>Les cookies pour les diff&eacute;rentes unit&eacute;s
d'affichage sont stock&eacute;s ensemble dans
<code>~/.Xauthority</code>. Votre fichier
<code>~/.Xauthority</code> doit &ecirc;tre inaccessible pour les
utilisateurs groupe/autres. Le programme xauth g&egrave;re ces
cookies, d'o&ugrave; le surnom xauth dans ce sch&eacute;ma.</p>
<p>Vous pouvez sp&eacute;cifier un fichier cookie diff&eacute;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&eacute;marrage d'une session, le serveur lit un cookie dans
le fichier qui est indiqu&eacute; par l'argument
<code>-auth</code>. Ensuite, le serveur ne permet la connexion que
des clients qui connaissent le m&ecirc;me cookie. Quand le cookie
dans <code>~/.Xauthority</code> change, <em>le serveur ne
r&eacute;cup&eacute;rera pas la modification</em>.</p>
<p>Les serveurs les plus r&eacute;cents peuvent
g&eacute;n&eacute;rer des cookies &agrave; la vol&eacute;e pour des
clients qui le demandent. Les cookies sont cependant encore
conserv&eacute;s dans le serveur&nbsp;: ils ne finissent pas dans
<code>~/.Xauthority</code> &agrave; moins qu'un client ne les y
mettent. Selon David Wiggins&nbsp;:</p>
<blockquote>Une possibilit&eacute; suppl&eacute;mentaire , qui peut
vous int&eacute;resser, a &eacute;t&eacute; ajout&eacute;e dans
X11R6.3. Par l'interm&eacute;diaire de la nouvelle extension
SECURITY, le serveur X lui-m&ecirc;me peut g&eacute;n&eacute;rer et
renvoyer de nouveaux cookies &agrave; la vol&eacute;e. De plus, on
peut d&eacute;signer les cookies comme &eacute;tant
&laquo;&nbsp;douteux&nbsp;&raquo; de sorte que les applications qui
se connectent avec de tels cookies auront une capacit&eacute;
op&eacute;ratoire restreinte. Par exemple, ils ne pourront pas
regarder les entr&eacute;es au clavier/mulot, ou le contenu des
fen&ecirc;tres, d'autres clients &laquo;&nbsp;fiables&nbsp;&raquo;.
Il y a une nouvelle sous-commande
&laquo;&nbsp;generate&nbsp;&raquo; de xauth pour rendre cette
fonctionnalit&eacute;, pas forc&eacute;ment facile, mais au moins
possible &agrave; utiliser.</blockquote>
<p>Xauth poss&egrave;de un avantage clair, au niveau de la
s&eacute;curit&eacute;, sur xhost. Vous pouvez limiter
l'acc&egrave;s &agrave; des utilisateurs sp&eacute;cifiques sur des
ordinateurs sp&eacute;cifiques. Il ne permet pas l'usurpation
d'adresse comme le permet xhost. Et, si vous le d&eacute;sirez,
vous pouvez encore utiliser xhost en parall&egrave;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&eacute;ez l'enregistrement d'autorisation comme
indiqu&eacute; 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&eacute;er quelques
donn&eacute;es al&eacute;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 &eacute;diter le script startx (parce que
vous n'&ecirc;tes pas root), demandez &agrave; votre administrateur
syst&egrave;me de configurer startx correctement, ou, &agrave; la
place, laissez-le configurer xdm. S'il ne peut, ou ne veut, pas,
vous pouvez &eacute;crire un script <code>~/.xserverrc</code>. Si
vous avez ce script, il sera ex&eacute;cut&eacute; par xinit au
lieu du v&eacute;ritable serveur X. Alors, vous pourrez lancer le
serveur X v&eacute;ritable &agrave; partir de ce script avec les
arguments adapt&eacute;s. Pour faire cela, faites utiliser par
votre <code>~/.xserverrc</code> le <code>mcookie</code> de la ligne
ci-dessus pour cr&eacute;er un cookie puis lancer le
v&eacute;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&eacute;rer vos sessions X, vous
pouvez utiliser xauth facilement. D&eacute;finissez les ressources
du DisplayManager.authDir dans
<code>/etc/X11/xdm/xdm-config</code>. Xdm passera l'argument
<code>-auth</code> au serveur X &agrave; son d&eacute;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&eacute; votre session X sur le
serveur h&ocirc;te <code>light.uni.verse</code> et que vous avez
votre cookie dans <code>~/.Xauthority</code>, il vous faut
transf&eacute;rer le cookie sur le client,
<code>dark.matt.er</code>. Il y a plusieurs fa&ccedil;ons de le
faire.</p>
<h3>R&eacute;pertoires personnels (home) partag&eacute;s</h3>
<p>Le plus simple est que vos r&eacute;pertoires sur
<code>light</code> et <code>dark</code> soient partag&eacute;s. Les
fichiers <code>~/.Xauthority</code> sont les m&ecirc;mes, donc le
cookie est transf&eacute;r&eacute; instantan&eacute;ment.
Cependant, il y a un pi&egrave;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&ocirc;te explicite &agrave; la
cr&eacute;ation du cookie&nbsp;: on ne peut pas faire autrement.
Vous pouvez installer le m&ecirc;me cookie pour, &agrave; 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 &agrave; distance, <code>rsh</code></h3>
<p>Si les r&eacute;pertoires <em>home</em> ne sont pas
partag&eacute;s, vous pouvez transf&eacute;rer le cookie au moyen
de rsh, le shell &agrave; 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&eacute;rer vers dark.matt.er (<code>| rsh
dark.matt.er</code>).</li>
<li>Le mettre dans <code>~/.Xauthority</code> l&agrave;
(<code>xauth nmerge -</code>).</li>
</ol>
<p>Notez l'utilisation de <code>${HOST}</code>. Vous devez
transf&eacute;rer le cookie qui est explicitement associ&eacute;
&agrave; l'h&ocirc;te local. Une application X distante
interpr&eacute;terait une valeur d'unit&eacute; d'affichage
&eacute;gale &agrave; <code>:0</code> comme &eacute;tant une
r&eacute;f&eacute;rence &agrave; la machine distante, ce qui ne
correspond pas &agrave; 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&eacute;nient en
ce qui concerne la s&eacute;curit&eacute; (noms d'h&ocirc;tes
usurp&eacute;s, si je me souviens bien). Si vous ne pouvez, ou ne
voulez, pas utiliser <code>rsh</code>, vous pouvez &eacute;galement
transf&eacute;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 &eacute;galement rsh(1) et xauth(1x) pour de plus
amples informations.</p>
<h3>En automatisant la m&eacute;thode Telnet</h3>
<p>Il doit &ecirc;tre possible de superposer le cookie sur la
variable <code>TERM</code> ou <code>DISPLAY</code> quand vous
utilisez telnet sur l'h&ocirc;te &eacute;loign&eacute;. Cela doit
fonctionner de la m&ecirc;me mani&egrave;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&eacute;s, mais cela
m'int&eacute;resse si quelqu'un peut me confirmer ou m'infirmer
cela.</p>
<p>Notez, cependant, qu'avec certains Unix les variables
d'environnement peuvent &ecirc;tre visibles par les autres et vous
ne pourrez pas emp&ecirc;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&icirc;ne une
petite difficult&eacute;. 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&eacute;fl&eacute;chit, c'est logique.
L'interpr&eacute;tation de <code>localhost</code> d&eacute;pend
enti&egrave;rement de la machine sur laquelle s'effectue cette
interpr&eacute;tation. Si ce n'&eacute;tait pas le cas, cela
causerait un horrible bazar dans le cas d'un r&eacute;pertoire
personnel (home) partag&eacute;, par exemple par
l'interm&eacute;diaire de NFS, avec plusieurs h&ocirc;tes
interf&eacute;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&eacute;seau sans codage. Si vous vous souciez de ce que l'on
puisse espionner vos connexions, utilisez ssh, le shell
s&eacute;curis&eacute;. Il effectuera des transmissions X
s&eacute;curis&eacute;es au moyen de connexions
chiffr&eacute;es.</p>
<p>Pour activer la transmission X par ssh, utilisez l'option de la
ligne de commande <code>-X</code> ou &eacute;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&ocirc;t&eacute; distant
positionnera automatiquement la variable <code>DISPLAY</code> sur
l'extr&eacute;mit&eacute; du tunnel X transmis. Le tunnel distant
r&eacute;cup&egrave;re son propre cookie&nbsp;; le serveur ssh
distant le g&eacute;n&egrave;re pour vous et le place dans
<code>~/.Xauthority</code> l&agrave;-bas. Ainsi, l'autorisation X
avec ssh est compl&egrave;tement automatique.</p>
<p>De plus, il est g&eacute;nial pour d'autres choses aussi. C'est
une bonne am&eacute;lioration structurelle de votre syst&egrave;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&eacute;dez d'autres informations sur les
m&eacute;thodes d'authentification ou de chiffrement des connexions
X, par exemple, gr&acirc;ce &agrave; Kerberos, envoyez-les moi, je
les int&eacute;grerai ici.</p>
<h2><a name="s7" id="s7">7. Les applications X avec un
identificateur d'utilisateur (User-id) diff&eacute;rent</a></h2>
<p>Supposez que vous vouliez faire tourner un outil graphique de
configuration qui n&eacute;cessite d'avoir les privil&egrave;ges du
compte <em>root</em> alors que la session X actuelle se
d&eacute;roule sous votre compte. Cela peut sembler &eacute;trange
au premier abord, mais le serveur X <em>ne</em> permettra
<em>pas</em> &agrave; cet outil d'acc&eacute;der &agrave; votre
unit&eacute; d'affichage. Comment cela est-il possible alors que
<em>root</em> peut normalement tout faire&nbsp;? Et comment
contourner ce probl&egrave;me&nbsp;?</p>
<p>&Eacute;largissons le propos au cas o&ugrave; l'on veut faire
tourner une application X, sous un identificateur d'utilisateur
<code>clientuser</code>, alors que la session X a &eacute;t&eacute;
lanc&eacute;e par <code>serveruser</code>. Si vous avez lu le
paragraphe sur les <em>cookies</em>, il est &eacute;vident que
<code>clientuser</code> ne peut pas acc&eacute;der &agrave; votre
unit&eacute; d'affichage&nbsp;:
<code>~clientuser/.Xauthority</code> ne contient pas le cookie
magique qui permet d'acc&eacute;der &agrave; l'unit&eacute;
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&ecirc;me h&ocirc;te</a></h2>
<p>Naturellement, tout ce qui marche pour un X distant marchera
aussi pour un X &agrave; partir d'un identificateur d'utilisateur
diff&eacute;rent (particuli&egrave;rement <code>slogin localhost -l
clientuser</code>). Et ici l'h&ocirc;te client et l'h&ocirc;te
serveur sont pr&eacute;cis&eacute;ment les m&ecirc;mes. Cependant,
quand les deux h&ocirc;tes sont les m&ecirc;mes, il y a quelques
raccourcis pour transf&eacute;rer le <em>cookie magique</em>.</p>
<p>On supposera que l'on utilise <code>su</code> pour passer d'un
identificateur utilisateur &agrave; l'autre. Essentiellement, il
faut &eacute;crire un script qui appelle <code>su</code>, mais
enveloppe la commande que <code>su</code> ex&eacute;cute d'un peu
de code qui effectue les t&acirc;ches n&eacute;cessaires pour le X
distant. Ces t&acirc;ches n&eacute;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&eacute;finir
<code>DISPLAY="$DISPLAY"</code> avant d'ex&eacute;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&eacute;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&eacute;diaire
d'un canal de transmission. Manque de chance, ce n'est pas si
facile de passer quelque chose &agrave; la commande <code>su</code>
par l'interm&eacute;diaire d'un canal de transmission car
<code>su</code> attend le mot de passe de l'entr&eacute;e standard.
Cependant, dans un script shell on peut jongler avec quelques
descripteurs de fichiers et arriver &agrave; le faire.</p>
<p>Donc, on &eacute;crit un script de ce style en le
param&eacute;trant avec <code>clientuser</code> et
<code>clientprogram</code>. Pendant que nous y sommes,
am&eacute;liorons un peu ce script, &ccedil;a va le rendre un peu
moins compr&eacute;hensible mais un peu plus robuste. Le tout
ressemble &agrave; 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&eacute;faut auquel je pense en ce moment est d&ucirc; &agrave;
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&icirc;ne quelque chose de vraiment g&ecirc;nant,
envoyez-moi un courrier &eacute;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 &ecirc;tre plus facile, &agrave; moins que vous
ne vous d&eacute;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&eacute; ci-dessus a
servi comme base pour un script plus &eacute;tendu appel&eacute;
<code>sux</code> qui a, apparemment, trouv&eacute; 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>&Eacute;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&eacute;rer le cookie. Tout ce qu'il y a &agrave; faire
consiste &agrave; initialiser <code>DISPLAY</code>, et &agrave;
faire pointer <code>XAUTHORITY</code> sur
<code>~serveruser/.Xauthority</code>. Donc, vous pouvez
&eacute;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&eacute;j&agrave; initialis&eacute;
<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&ecirc;tres distant</a></h2>
<p>Un gestionnaire de fen&ecirc;tres (comme <code>twm</code>,
<code>wmaker</code>, ou <code>fvwm95</code>) est une application
comme n'importe quelle autre. La proc&eacute;dure normale devrait
fonctionner.</p>
<p>Enfin, presque. Il ne peut tourner, au plus, qu'un seul
gestionnaire de fen&ecirc;tres &agrave; un instant donn&eacute;
dans une unit&eacute; d'affichage. Si vous faites
d&eacute;j&agrave; tourner un gestionnaire de fen&ecirc;tre local,
vous ne pouvez pas lancer le gestionnaire distant (il le dira et
s'arr&ecirc;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&ecirc;tre
(local) se termine, votre session se termine, et le syst&egrave;me
(xdm ou xinit) consid&egrave;re que votre session est
termin&eacute;e, et effectivement, vous d&eacute;connecte.</p>
<p>Vous aurez encore &agrave; 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 &agrave; vos fins.</p>
<p>Attention, un gestionnaire de fen&ecirc;tres permet souvent de
faire tourner de nouveaux programmes qui s'ex&eacute;cuteront sur
la machine locale. C'est-&agrave;-dire locale &agrave; la machine
sur lequel tourne le gestionnaire de fen&ecirc;tres. Si vous faites
tourner un gestionnaire de fen&ecirc;tres distant, il lancera des
applications distantes, et ce n'est peut-&ecirc;tre pas ce que vous
voulez. Naturellement, elles continueront &agrave; s'afficher sur
l'unit&eacute; 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 &agrave; votre vieux PC&nbsp;! Faites-en
un endroit suppl&eacute;mentaire pour pouvoir travailler&nbsp;! Pas
besoin d'acheter un nouveau mat&eacute;riel co&ucirc;teux&nbsp;!
Vous avez d&eacute;j&agrave; tout ce qu'il faut&nbsp;!</p>
<p>S&eacute;rieusement, vous pouvez mettre en place un vieux PC
comme terminal X. Un terminal X est un ordinateur qui
fondamentalement n'ex&eacute;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&eacute;cuteront sur l'h&ocirc;te
distant et ils utiliseront le serveur X distant pour afficher leur
sortie sur votre terminal X local. M&ecirc;me le gestionnaire de
fen&ecirc;tre s'ex&eacute;cutera &agrave; distance.</p>
<p>Un terminal X consomme peu de ressources en comparaison d'une
machine Unix compl&egrave;te. J'ai ici un terminal X
constitu&eacute; par un processeur 486, 16&nbsp;Mo de RAM et
250&nbsp;Mo d'espace disque. Oh et une connexion r&eacute;seau,
naturellement. Il n'a m&ecirc;me pas besoin d'avoir des
r&eacute;pertoires utilisateurs.</p>
<p>Pour trouver des lectures li&eacute;es &agrave; 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&egrave;te de ce qui est
possible avec XDMCP et xdm, appliqu&eacute; &agrave; 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&eacute;crit les &eacute;tapes n&eacute;cessaires
&agrave; 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&eacute;crite de fa&ccedil;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&eacute;ressantes pour vous.</li>
</ul>
<p>&Agrave; la diff&eacute;rence des documents ci-dessus, le
document que vous &ecirc;tes en train de lire se limite &agrave;
une courte description de XDMCP, mais il insiste plus sur les
probl&egrave;mes de s&eacute;curit&eacute; impliqu&eacute;s.</p>
<h2><a name="ss9.1" id="ss9.1">9.1 Une fois de plus, un peu de
th&eacute;orie en premier</a></h2>
<p>En ce qui concerne X, le terminal X va n'ex&eacute;cuter rien
d'autre qu'un serveur X. Ce serveur X sera configur&eacute; pour
dialoguer avec l'h&ocirc;te distant en utilisant XDMCP (le
protocole de contr&ocirc;le de gestion d'affichage X,
&laquo;&nbsp;X Display Manager Control Protocol&nbsp;&raquo;). Il
va demander &agrave; l'h&ocirc;te distant une session X.
L'h&ocirc;te distant fournira une fen&ecirc;tre de connexion dans
le terminal X et apr&egrave;s la connexion, il ex&eacute;cutera une
session X avec tout l'habillage y compris le gestionnaire de
fen&ecirc;tres, tout cela utilisant X distant pour l'affichage sur
le terminal X.</p>
<p>Vous aurez probablement remarqu&eacute; que l'h&ocirc;te distant
agit comme un serveur, bien que pas comme un serveur X.
L'h&ocirc;te distant fournit les sessions X aux serveurs X qui les
demandent. Ainsi, selon XDMCP, l'h&ocirc;te distant est en fait un
serveur, fournissant des sessions X, &eacute;galement connu sous le
nom de serveur XDMCP. Le serveur X joue le r&ocirc;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&eacute;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&ocirc;te distant.</p>
<p>Vous devez toujours vous rappeler que le protocole X (et le
protocole XDMCP) n'est pas chiffr&eacute;. Si vous devez utiliser X
&agrave; distance, tout ce qui transite sur le r&eacute;seau peut
&ecirc;tre espionn&eacute; par d'autres h&ocirc;tes du
r&eacute;seau. Ceci est particuli&egrave;rement n&eacute;faste avec
les sessions X distantes car la premi&egrave;re chose qui se passe
est la connexion en donnant l'utilisateur et le mot de passe.
<b>Vous ne devez donc ex&eacute;cuter X &agrave; distance que sur
un r&eacute;seau s&eacute;curis&eacute;&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&eacute;sirez mettre en place une machine Linux comme
terminal X, vous avez besoin de tr&egrave;s peu de ressources.
Fondamentalement, vous avez besoin de ce qu'il est
n&eacute;cessaire d'avoir pour faire fonctionner une machine Linux
d&eacute;pouill&eacute;e plus un serveur X. Sp&eacute;cifiquement,
vous <em>n'avez pas</em> besoin des clients et biblioth&egrave;ques
X. Il peut &ecirc;tre utile d'installer certaines polices X, mais
vous pouvez &eacute;galement utiliser un serveur de polices
situ&eacute; quelque part sur le r&eacute;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 &agrave; un serveur XDMCP connu et de lui en demander
une. Le serveur peut &eacute;galement &eacute;mettre en
multi-diffusion une requ&ecirc;te et utiliser le premier serveur
XDMCP qui r&eacute;pond. Enfin, le serveur X peut demander &agrave;
un serveur XDMCP de lui fournir une liste des h&ocirc;tes qui
acceptent de fournir une session et laisser l'utilisateur choisir
l'h&ocirc;te de session.</p>
<ol>
<li>Si vous connaissez l'h&ocirc;te qui va vous fournir une
session, utilisez-le directement. Ex&eacute;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&ecirc;tre de
connexion et, apr&egrave;s connexion, une session X.</li>
<li>Si l'h&ocirc;te duquel vous obtiendrez la session vous importe
peu, utilisez la m&eacute;thode d'&eacute;mission de
multi-diffusion. Ex&eacute;cutez
<blockquote>
<pre>
<code>X -broadcast
</code>
</pre></blockquote>
et, en supposant que <code>xdm</code> fonctionne sur un h&ocirc;te
quelque part sur le r&eacute;seau, vous obtiendrez une
fen&ecirc;tre de connexion du premier (et, on l'esp&egrave;re, du
plus rapide) <code>xdm</code> qui r&eacute;pond et, apr&egrave;s
connexion, une session X.</li>
<li>Si vous d&eacute;sirez choisir l'h&ocirc;te o&ugrave; vous
voulez avoir votre session, demandez au serveur XDMCP une liste des
h&ocirc;tes. Ex&eacute;cutez
<blockquote>
<pre>
<code>X -indirect xdmcpserver
</code>
</pre></blockquote>
et, en supposant que <code>xdm</code> est bien configur&eacute; sur
ce serveur, une liste des h&ocirc;tes vous sera
pr&eacute;sent&eacute;e parmi lesquels vous pourrez choisir.
Choisissez-en un&nbsp;; vous obtiendrez la fen&ecirc;tre de
connexion pour cet h&ocirc;te et, apr&egrave;s connexion, la
session que vous avez demand&eacute;e.</li>
</ol>
<p>Il se peut que vous ayez remarqu&eacute; l'absence de l'option
<code>-auth</code>. Le serveur X utilisera XDMCP pour
n&eacute;gocier le mot de passe secret (&laquo;&nbsp;magic
cookie&nbsp;&raquo;) avec le serveur XDMCP. Le serveur XDMCP
placera le cookie dans votre <code>~/.Xauthority</code>
apr&egrave;s la connexion.</p>
<p>Apr&egrave;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&eacute;sirez pas cela, vous pouvez utiliser l'option
<code>-once</code>. Notez que ceci ne semble pas fonctionner avec
l'option <code>-indirect</code> &agrave; cause de
l'impl&eacute;mentation du &laquo;&nbsp;chooser&nbsp;&raquo;.</p>
<p>Quand vous avez d&eacute;termin&eacute; la fa&ccedil;on dont
vous allez ex&eacute;cuter le serveur X, vous pouvez alors le
placer dans un script de d&eacute;marrage ou m&ecirc;me
l'ex&eacute;cuter directement &agrave; partir de
<code>/etc/inittab</code>. Veuillez consulter la documentation de
votre propre distribution pour savoir comment modifier vos scripts
d'amor&ccedil;age ou <code>/etc/inittab</code>.</p>
<p>N'ex&eacute;cutez <em>pas</em> un serveur X ainsi depuis le
fichier de configuration <code>Xservers</code>. <code>xdm</code>
s'attend &agrave; pouvoir se connecter &agrave; 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&eacute;n&eacute;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&ecirc;me fa&ccedil;on. Assurez-vous donc
que <code>xdm</code> ou une variante est install&eacute; sur
l'h&ocirc;te o&ugrave; vous d&eacute;sirez ex&eacute;cuter vos
sessions X. Si vous disposez d'une connexion graphique locale
depuis l'h&ocirc;te de session X, <code>xdm</code> est
d&eacute;j&agrave; install&eacute;&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&eacute;sirez ex&eacute;cuter dans une session X.
C'est-&agrave;-dire, tous les clients X comme <code>xterm</code>,
<code>xfig</code>, <code>xclock</code>, des gestionnaires de
fen&ecirc;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 &agrave; la place sur le terminal X.</p>
<p>&Agrave; 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
&agrave; permettre la connexion d'un client XDMCP et &agrave; lui
fournir une session X. Il y a &eacute;galement le service
<em>indirect</em> dans lequel le serveur fournit une liste
d'h&ocirc;tes fournissant un service direct, au choix pour le
client XDMCP.</p>
<p>Tous les services <code>xdm</code> sont configur&eacute;s dans
le fichier d'acc&egrave;s, g&eacute;n&eacute;ralement situ&eacute;
&agrave; <code>/etc/X11/xdm/Xaccess</code> ou un emplacement
semblable. Cet emplacement est en fait d&eacute;fini dans le
fichier de configuration g&eacute;n&eacute;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&eacute;faut.</p>
<ol>
<li>
<p>Si vous d&eacute;sirez autoriser <code>xdm</code> &agrave;
fournir des sessions X aux clients XDMCP, que ce soit par
multi-diffusion ou non, placez le nom d'h&ocirc;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 &agrave; plusieurs
h&ocirc;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&ocirc;te dans my.domain peut obtenir une session X
*                       # tout h&ocirc;te sur Internet peut obtenir une session X (non s&eacute;curis&eacute;)
</code>
</pre></blockquote>
<p>Vouloir fournir une session X &agrave; tout h&ocirc;te sur
Internet est discutable. De fa&ccedil;on &eacute;vidente, tout
service que vous fournissez est une faille de
s&eacute;curit&eacute; potentielle dans la s&eacute;curit&eacute;
de votre serveur. D'un autre c&ocirc;t&eacute;, le serveur devrait
&ecirc;tre s&eacute;curis&eacute; lui-m&ecirc;me et un client XDMCP
demandant une session X doit fournir une authentification valide
avant que la session X ne soit accord&eacute;e.</p>
<p>De plus, la session X utilise une connexion X distante qui n'est
pas chiffr&eacute;e. La paire nom d'utilisateur/mot de passe de
connexion sera transport&eacute;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&ecirc;me pire que d'avoir son mot de passe
secret (&laquo;&nbsp;magic cookie&nbsp;&raquo;)
espionn&eacute;.</p>
<p>Prenez vos propres d&eacute;cisions ici, mais je recommande de
ne pas activer ce service au monde entier &agrave; moins d'avoir
une bonne raison.</p>
</li>
<li>
<p>Si vous d&eacute;sirez fournir aux clients XDMCP (<code>X
-indirect xdmcpserver</code>) une liste de choix (une liste
d'h&ocirc;tes pour choisir duquel ils obtiendront une session X),
faite suivre l'expression rationnelle du client par le
mot-cl&eacute; <code>CHOOSER</code> et la liste des h&ocirc;tes que
le client peut choisir. &Agrave; la place de la liste des
h&ocirc;tes, vous pouvez &eacute;galement sp&eacute;cifier
<code>BROADCAST</code>&nbsp;; avec ceci, <code>xdm</code>
&eacute;met en multi-diffusion sur le r&eacute;seau pour interroger
les serveurs d&eacute;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 &agrave; <code>xterm023</code> de choisir
entre des sessions sur <code>seshost1</code> et sur
<code>seshost2</code>. Le deuxi&egrave;me exemple permet &agrave;
tout h&ocirc;te dans <code>my.domain</code> de choisir n'importe
quel h&ocirc;te fournissant une session X. Le troisi&egrave;me
exemple permet &agrave; tout h&ocirc;te de choisir une session
entre <code>extseshost1</code> et <code>extseshost2</code>.
<p>Ce n'est probablement pas une bonne id&eacute;e de faire <code>*
CHOOSER BROADCAST</code>. Ceci permettrait &agrave; tout h&ocirc;te
en dehors de votre r&eacute;seau d'obtenir des informations sur les
h&ocirc;tes dans votre r&eacute;seau. Vous ne voulez probablement
pas communiquer une telle information. En fait, autoriser un choix
pour tout h&ocirc;te ext&eacute;rieur n'est probablement pas
tr&egrave;s utile de toute fa&ccedil;on, car vous ne devriez pas
autoriser des connexions arbitraires directes non plus.</p>
</li>
</ol>
<p>Quand vous avez reconfigur&eacute; <code>xdm</code>, envoyez-lui
le signal <code>HUP</code> pour le forcer &agrave; 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 &agrave; fait ce &agrave; quoi vous pouvez vous attendre
d'apr&egrave;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&eacute;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&eacute;sent&eacute;e dans
l'affichage du serveur X. C'est &eacute;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&egrave;re fois que vous allez essayer de
faire tourner une application X &agrave; distance, &ccedil;a ne
marchera pas. Voici quelques-uns des messages d'erreur habituels,
leur cause probable et des solutions pour vous aider &agrave;
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&eacute;e dans votre
environnement et vous n'avez pas non plus lanc&eacute;
l'application avec le drapeau <code>-display</code>. L'application
assume que la variable display contient une cha&icirc;ne de
caract&egrave;res vide, ce qui est syntaxiquement incorrect. La
solution &agrave; cela consiste &agrave; s'assurer que la variable
DISPLAY est correctement renseign&eacute;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 &laquo;&nbsp;R&eacute;seau
inaccessible&nbsp;&raquo;. L'application n'arrive pas &agrave; se
connecter au serveur &agrave; travers le r&eacute;seau.
V&eacute;rifiez que la variable <code>DISPLAY</code> est
correctement renseign&eacute;e et que la machine serveur est
accessible &agrave; partir de votre client (ce qui devrait
&ecirc;tre le cas, car apr&egrave;s tout vous &ecirc;tes
probablement connect&eacute; 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 &laquo;&nbsp;Connexion
refus&eacute;e&nbsp;&raquo;. La machine &agrave; laquelle vous
&ecirc;tes en train d'essayer de vous connecter peut &ecirc;tre
atteinte, mais le serveur indiqu&eacute; n'existe pas &agrave; cet
endroit. V&eacute;rifiez que vous utilisez le nom d'h&ocirc;te
correct et le num&eacute;ro d'unit&eacute; d'affichage
ad&eacute;quat.</p>
<p>Sinon, il est possible que le serveur X a &eacute;t&eacute;
configur&eacute; pour <em>ne pas</em> &eacute;couter sur le port
TCP habituel. Pour savoir s'il s'agit de ce cas, regardez si le
serveur X a &eacute;t&eacute; lanc&eacute; avec le param&egrave;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&eacute;aliser une connexion avec le
serveur, mais celui-ci ne permet pas au client de l'utiliser (pas
autoris&eacute;). Assurez-vous que vous avez
transf&eacute;r&eacute; le bon cookie au client, et qu'il n'est pas
p&eacute;rim&eacute; (le serveur utilise un nouveau cookie au
d&eacute;marrage d'une nouvelle session).</p>
</body>
</html>
doc-linux-fr-html 2013.01-2 / usr / share / doc / HOWTO / fr-html / Remote-X-Apps.html
