mini-HOWTO : Comment exécuter des applications X à distance +<title>mini-HOWTO : Comment exécuter des applications X à distance <author><htmlurl url="http://www.xs4all.nl/~zweije/" name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl" @@ -27,7 +27,7 @@ sur la manière de faire tourner des applications X en local, mais avec un identificateur d'utilisateur (user-id) différent. -Adaptation française : +Adaptation française : Albert-Paul Bouillot <htmlurl url="mailto:apb@club-internet.fr" name="apb@club-internet.fr"> </abstract> @@ -37,21 +37,21 @@ <sect> Introduction -Ce mini-HOWTO constitue un guide sur la manière de faire +Ce mini-HOWTO constitue un guide sur la manière de faire tourner des applications X à distance. -J'ai rédigé ce document pour plusieurs raisons : +J'ai rédigé ce document pour plusieurs raisons : <enum> <item> Il y a eu de nombreuses questions, sur Usenet, sur la manière de faire -tourner des applications X à distance; +tourner des applications X à distance ; <item> J'ai vu beaucoup, beaucoup, de conseils d'utilisation de -'' <tt>xhost +hostname</tt>'' ou même de ''<tt>xhost +</tt>'' pour réaliser +« <tt>xhost +hostname</tt> » ou même de « <tt>xhost +</tt> » pour réaliser des connexions X. <bf>C'est d'une insécurité totale</bf>, - et il existe de bien meilleures méthodes; + et il existe de bien meilleures méthodes ; <item> Je n'ai pas connaissance d'un document simple décrivant les options dont on peut disposer. Si vous avez des informations complémentaires, -s'il vous plaît, faites-le moi savoir : +s'il vous plaît, faites-le moi savoir : <htmlurl url="mailto:zweije@xs4all.nl" name="<zweije@xs4all.nl>">. </enum> @@ -67,10 +67,10 @@ sur le WWW à <htmlurl url="http://www.xs4all.nl/~zweije/xauth.html" name="http://www.xs4all.nl/˜zweije/xauth.html">. Il est également disponible en tant que mini-HOWTO Linux Applications X à -distance (Remote X Apps) à : +distance (Remote X Apps) à : <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Les -(mini-)HOWTOs Linux sont disponibles par http ou ftp sur <htmlurl +(mini-)HOWTO du LDP sont disponibles par http ou ftp sur <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html" name="sunsite.unc.edu">. @@ -86,8 +86,8 @@ <sect> Lectures complémentaires -Un document, en rapport avec cela, sur le WWW traite de ''Quoi faire quand Tk -dit que votre écran n'est pas sûr'', +Un document, en rapport avec cela, sur le WWW traite de « Que faire quand Tk +dit que votre écran n'est pas sûr », <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/" name="http://ce-toolkit.crd.ge.com/tkxauth/">. Il a été écrit par <htmlurl @@ -96,20 +96,20 @@ l'authentification X (xauth). Cependant, Kevin vise plus à l'utilisation de xdm pour diriger xauth à votre place. -On m'a indiqué que le volume 8 du ``Guide de l'administrateur -du système X Window'' (X Window System Administrator's Guide Vol. 8) de +On m'a indiqué que le volume 8 du « Guide de l'administrateur +du système X Window » (X Window System Administrator's Guide Vol. 8) de chez <htmlurl url="http://www.ora.com/" name="O'Reilly and Associates"> était une bonne source d'informations. Malheureusement, je n'ai pas pu le vérifier. Il y a également un autre document qui ressemble beaucoup à celui que vous -êtes en train de lire, dont le titre est ''Securing X Windows'', et qui est +êtes en train de lire, dont le titre est « Securing X Windows », et qui est disponible à <htmlurl url="http://ciac.llnl.gov/ciac/documents/ciac2316.html" name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">. -Consultez également les listes de diffusion usenet, telles que : +Consultez également les forums de diffusion Usenet, tels que : <tt/comp.windows.x/, <tt/comp.os.linux.x/, et <tt/comp.os.linux.networking/. @@ -119,7 +119,7 @@ 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 +second soient affichées sur l'écran du premier. Le système X Window rend cela possible. @@ -128,7 +128,7 @@ 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 : +pouvez aller consulter les sites : dxpc <htmlurl url="http://www.vigor.nu/dxpc/" name="http://www.vigor.nu/dxpc/"> ou LBX <url url="http://www.paulandlesley.org/faqs/LBX-HOWTO.html" @@ -136,7 +136,7 @@ comme <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/LBX" name="LBX mini-HOWTO">). -Vous avez deux choses à faire pour réaliser tout cela : +Vous avez deux choses à faire pour réaliser tout cela : <enum> @@ -152,13 +152,13 @@ Le mot magique est <tt>DISPLAY (unité d'affichage)</tt>. Dans le système X -window, une unité d'affichage est constituée (en simplifiant) d'un clavier, +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 fourni des fonctionnalités d'affichage aux autres programmes qui se connectent à lui. -Une unité d'affichage est identifiée par un nom, de type, par exemple : +Une unité d'affichage est identifiée par un nom, de type, par exemple : <itemize> @@ -170,7 +170,7 @@ </itemize> -Un nom d'unité d'affichage est constitué d'un nom d'hôte (par exemple : +Un nom d'unité d'affichage est constitué d'un nom d'hôte (par exemple : <tt>light.uni.verse</tt> et <tt>localhost</tt>), du signe deux point (<tt/:/), et d'un numéro de séquence (tels que <tt/0/ et <tt/4/). Le nom d'hôte de l'unité d'affichage est le nom de l'ordinateur @@ -194,11 +194,11 @@ <itemize> <item> <tt/hostname:D.S/ signifie écran <tt/S/ sur unité d'affichage - <tt/D/ de l'hôte <tt/hostname/; le serveur X de cette unité + <tt/D/ de l'hôte <tt/hostname/ : le serveur X de cette unité d'affichage est à l'écoute du port TCP <tt/6000+D/. <item> <tt>host/unix:D.S</tt> signifie écran <tt/S/ sur unité d'affichage - <tt/D/ de l'hôte <tt/host/; le serveur X de cette unité d'affichage + <tt/D/ de l'hôte <tt/host/ : le serveur X de cette unité d'affichage est à l'écoute du socket de domaine UNIX <tt>/tmp/.X11-unix/XD</tt> (et donc, seul <tt/host/ peut l'atteindre). @@ -212,7 +212,7 @@ Le programme client (par exemple, votre application graphique) sait à quelle unité d'affichage il doit se connecter en consultant la -variable d'environnement <tt>DISPLAY</tt>. Cependant ce paramètrage peut être +variable d'environnement <tt>DISPLAY</tt>. Cependant ce paramétrage peut être modifié, en lançant le client avec l'argument <tt>-display hostname:0</tt> dans la ligne de commande. Quelques exemples peuvent clarifier les choses. @@ -230,20 +230,20 @@ Supposons que vous vous soyez déjà connecté par telnet à l'ordinateur distant, <tt/dark.matt.er/. -Si l'interpréteur de commande de l'ordinateur éloigné est csh : +Si l'interpréteur de commande de l'ordinateur éloigné est csh : <tscreen><verb> dark% setenv DISPLAY light.uni.verse:0 dark% xfig & </verb></tscreen> -Ou, d'une autre manière : +Ou, d'une autre manière : <tscreen><verb> dark% xfig -display light.uni.verse:0 & </verb></tscreen> -Si c'est sh qui tourne sur l'ordinateur à distance : +Si c'est sh qui tourne sur l'ordinateur à distance : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 @@ -251,13 +251,13 @@ dark$ xfig & </verb></tscreen> -Ou, autrement : +Ou, autrement : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 xfig & </verb></tscreen> -Ou, bien sûr, également : +Ou, bien sûr, également : <tscreen><verb> dark$ xfig -display light.uni.verse:0 & @@ -266,7 +266,7 @@ Il paraît que certaines versions de telnet transmettent automatiquement la variable <tt>DISPLAY</tt> -à l'ordinateur hôte éloigné. Si vous avez l'une ce celles-ci, vous avez de la +à 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 doivent transmettre la variable d'environnement <tt>TERM</tt>, et avec un bidouillage judicieux, il est @@ -275,7 +275,7 @@ sur la variable <tt>TERM</tt>. L'idée, sous-jacente à cette superposition, est de réaliser une sorte de script - pour effectuer ceci : avant la connexion par telnet, donner la valeur de + pour effectuer ceci : avant la connexion par telnet, donner la valeur de <tt/DISPLAY/ à <tt/TERM/. Puis de lancer telnet. Du côté de l'ordinateur distant, dans le fichier <tt/.*shrc/ concerné, lire la valeur de <tt/DISPLAY/ à partir de <tt/TERM/. @@ -286,7 +286,7 @@ 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! +partie de votre unité d'affichage ! Trop peu de gens semble réaliser que permettre l'accès à leur unité @@ -295,7 +295,7 @@ vos frappes au clavier, et suivre les déplacements de votre mulot. La plupart des serveurs disposent de deux manières d'authentifier les -demandes de connexions qui arrivent : +demandes de connexions qui arrivent : 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é, @@ -306,14 +306,14 @@ 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 : +aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n'est effectué, et donc, que -n'importe quel hôte peut se connecter! +n'importe quel hôte peut se connecter ! Vous pouvez contrôler la liste des hôtes du serveur avec le programme <tt>xhost</tt>. -Pour utiliser ce mécanisme dans l'exemple précédent, faites : +Pour utiliser ce mécanisme dans l'exemple précédent, faites : <tscreen><verb> light$ xhost +dark.matt.er @@ -322,13 +322,13 @@ Ceci permet toutes les connexions à partir de l'hôte <tt>dark.matt.er</tt>. 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 : +avec : <tscreen><verb> light$ xhost -dark.matt.er </verb></tscreen> -Vous pouvez désactiver la vérification des hôtes avec : +Vous pouvez désactiver la vérification des hôtes avec : <tscreen><verb> light$ xhost + @@ -338,7 +338,7 @@ tout le monde de se connecter. Vous ne devriez jamais faire cela sur un réseau où vous n'avez pas confiance dans tous les utilisateurs (tel internet). Vous pouvez réactiver la vérification -des hôtes avec : +des hôtes avec : <tscreen><verb> light$ xhost - @@ -381,19 +381,19 @@ 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; ils ne finissent pas dans <tt>˜/.Xauthority</tt> -à moins qu'un client ne les y mettent. Selon David Wiggins : +serveur : ils ne finissent pas dans <tt>˜/.Xauthority</tt> +à moins qu'un client ne les y mettent. Selon David Wiggins : <quote> 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 ``douteux'' de sorte que les +on peut désigner les cookies comme étant « douteux » 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 ``fiables''. -Il y a une nouvelle sous-commande ``generate'' de xauth pour rendre cette +au clavier/mulot, ou le contenu des fenêtres, d'autres clients « fiables ». +Il y a une nouvelle sous-commande « generate » de xauth pour rendre cette fonctionnalité, pas forcément facile, mais au moins possible à utiliser. </quote> @@ -403,7 +403,7 @@ Et, si vous le désirez, vous pouvez encore utiliser xhost en parallèle pour permettre des connexions. -<sect2> Fabrication du Cookie +<sect2> Fabrication du cookie Si vous voulez utiliser xauth, vous devez lancer le serveur X avec @@ -423,7 +423,7 @@ <htmlurl url="ftp://ftp.math.uio.no/pub/linux/" name="ftp://ftp.math.uio.no/pub/linux/">. Autrement, vous pouvez utiliser md5sum pour créer quelques données aléatoires (de, par exemple, -<tt>/dev/urandom</tt> ou <tt/ps -axl/) au format cookie : +<tt>/dev/urandom</tt> ou <tt/ps -axl/) au format cookie : <tscreen><verb> dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q @@ -438,7 +438,7 @@ lancer le serveur X véritable à partir de ce script avec les arguments adaptés. Pour faire cela, faites utiliser par votre <tt>˜/.xserverrc</tt> le <tt>mcookie</tt> de la ligne ci-dessus pour créer un cookie puis lancer le -véritable serveur X : +véritable serveur X : <tscreen><verb> #!/bin/sh @@ -454,13 +454,13 @@ <tt>˜/.Xauthority</tt> pour vous. Consultez xdm(1) pour de plus amples information. Par exemple, mon <tt>/etc/X11/xdm/xdm-config</tt> -contient la ligne suivante : +contient la ligne suivante : <tscreen><verb> DisplayManager.authDir: /var/lib/xdm </verb></tscreen> -<sect2> Transfert du Cookie +<sect2> Transfert du cookie Maintenant que vous avez lancé votre session X sur le serveur hôte @@ -474,11 +474,11 @@ Le plus simple est que vos répertoires sur <tt>light</tt> et <tt>dark</tt> soient partagés. Les fichiers <tt>˜/.Xauthority</tt> sont les mêmes, donc le cookie est transféré instantanément. -Cependant, il y a un piège : lorsque vous mettez un cookie pour <tt/:0/ +Cependant, il y a un piège : lorsque vous mettez un cookie pour <tt/:0/ dans <tt>˜/.Xauthority</tt>, 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; on ne peut pas faire autrement. Vous pouvez installer -le même cookie pour, à la fois, <tt/:0/ et <tt/light:0/ avec un peu d'astuce : +création du cookie : on ne peut pas faire autrement. Vous pouvez installer +le même cookie pour, à la fois, <tt/:0/ et <tt/light:0/ avec un peu d'astuce : <tscreen><verb> #!/bin/sh @@ -490,7 +490,7 @@ Si les répertoires home ne sont pas partagés, vous pouvez transférer le cookie -au moyen de rsh, le shell à distance : +au moyen de rsh, le shell à distance : <tscreen><verb> light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge - @@ -521,7 +521,7 @@ cela, <tt>rsh</tt> a un inconvénient en ce qui concerne la sécurité (noms d'hôtes parodiés, si je me souviens bien). Si vous ne pouvez, ou ne voulez, pas utiliser <tt>rsh</tt>, vous pouvez également transférer le -cookie manuellement, comme ceci : +cookie manuellement, comme ceci : <tscreen><verb> light$ echo $DISPLAY @@ -550,8 +550,8 @@ Il doit être possible de superposer le cookie sur la variable <tt/TERM/ ou <tt/DISPLAY/ quand vous utilisez telnet sur l'hôte éloigné. Cela doit fonctionner de la même manière que de superposer la -variable <tt/DISPLAY/ sur la variable <tt/TERM/. Regardez la section 5 : -Dire au Client. De mon point de vue, sur ce sujet, vous prenez vos +variable <tt/DISPLAY/ sur la variable <tt/TERM/. Regardez la section 5 : +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. @@ -559,7 +559,7 @@ être visibles par les autres et que que vous ne puissiez pas empêcher la visualisation du cookie dans <tt/$TERM/ si certains veulent le voir. -<sect2> Utilisation du Cookie +<sect2> Utilisation du cookie Une application X, telle que <tt>xfig</tt> ci-dessus, sur @@ -586,14 +586,14 @@ 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 cryptées. De plus, il est génial pour d'autres choses aussi. +connexions chiffrées. 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 <htmlurl url="http://www.ssh.org/" name="http://www.ssh.org/">, la page d'accueil de ssh. Qui possède d'autres informations sur les méthodes d'authentification ou -de cryptage des connexions X ? Peut-être Kerberos ? +de chiffrement des connexions X ? Peut-être Kerberos ? <sect> Les applications X avec un identificateur d'utilisateur (User-id) différent @@ -613,7 +613,7 @@ X a été lancée par <tt/serveruser/. Si vous avez lu le paragraphe sur les <em/cookies/, il est évident que <tt/clientuser/ ne peut pas accéder à votre unité d'affichage : -<tt>~clientuser/.Xauthority</tt> ne contient le cookie magique qui permet +<tt>~clientuser/.Xauthority</tt> ne contient pas le cookie magique qui permet d'accéder à l'unité d'affichage. Le cookie correct se trouve dans <tt>~serveruser/.Xauthority</tt>. @@ -648,14 +648,14 @@ Ce n'est pas tout, il faut encore transférer le cookie. On peut le retrouver en utilisant <tt/xauth list "$DISPLAY"/. Cette commande renvoie le cookie dans un format qui convient pour l'utiliser dans la commande - <tt/xauth add/; ce dont + <tt/xauth add/ : ce dont nous avons justement besoin ! On pourrait imaginer le 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 <tt/su/ par l'intermédiaire d'un canal de transmission car <tt/su/ -attends le mot de passe de l'entrée standard. Cependant, dans un script shell +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. Donc, on écrit un script de ce style en le paramétrant avec <tt/clientuser/ et @@ -749,7 +749,7 @@ </verb></tscreen> -Cependant, si vous avez déjà initialisé <tt/xsu/ , il n'y a pas de vrai +Cependant, si vous avez déjà initialisé <tt/xsu/ , il n'y a pas de vraie raison de faire cela. <sect> Faire tourner un gestionnaire de fenêtres distant @@ -770,7 +770,7 @@ Par manque de chance, beaucoup de scripts de sessions X se terminent par un <tscreen><verb> -exec le-gestionnaire-de-fenetre-de-votre-choix +exec le-gestionnaire-de-fenetres-de-votre-choix </verb></tscreen> et cela signifie que quand le gestionnaire de fenêtre (local) se termine, @@ -817,7 +817,7 @@ xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> -Erreur 101 signifie ``Réseau inaccessible''. L'application n'arrive pas à se +Erreur 101 signifie « Réseau inaccessible ». L'application n'arrive pas à se connecter au serveur à travers le réseau. Vérifiez que la variable <tt/DISPLAY/ est correctement renseignée et que la machine @@ -830,7 +830,7 @@ xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> -Erreur 111 signifie ``Connexion refusée''. La machine à laquelle vous êtes en +Erreur 111 signifie « Connexion refusée ». 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é

-mini-HOWTO : Comment exécuter des applications X à distance +<title>mini-HOWTO : Comment exécuter des applications X à distance <author><htmlurl url="http://www.xs4all.nl/~zweije/" name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl" @@ -27,7 +27,7 @@ sur la manière de faire tourner des applications X en local, mais avec un identificateur d'utilisateur (user-id) différent. -Adaptation française : +Adaptation française : Albert-Paul Bouillot <htmlurl url="mailto:apb@club-internet.fr" name="apb@club-internet.fr"> </abstract> @@ -37,21 +37,21 @@ <sect> Introduction -Ce mini-HOWTO constitue un guide sur la manière de faire +Ce mini-HOWTO constitue un guide sur la manière de faire tourner des applications X à distance. -J'ai rédigé ce document pour plusieurs raisons : +J'ai rédigé ce document pour plusieurs raisons : <enum> <item> Il y a eu de nombreuses questions, sur Usenet, sur la manière de faire -tourner des applications X à distance; +tourner des applications X à distance ; <item> J'ai vu beaucoup, beaucoup, de conseils d'utilisation de -'' <tt>xhost +hostname</tt>'' ou même de ''<tt>xhost +</tt>'' pour réaliser +« <tt>xhost +hostname</tt> » ou même de « <tt>xhost +</tt> » pour réaliser des connexions X. <bf>C'est d'une insécurité totale</bf>, - et il existe de bien meilleures méthodes; + et il existe de bien meilleures méthodes ; <item> Je n'ai pas connaissance d'un document simple décrivant les options dont on peut disposer. Si vous avez des informations complémentaires, -s'il vous plaît, faites-le moi savoir : +s'il vous plaît, faites-le moi savoir : <htmlurl url="mailto:zweije@xs4all.nl" name="<zweije@xs4all.nl>">. </enum> @@ -67,10 +67,10 @@ sur le WWW à <htmlurl url="http://www.xs4all.nl/~zweije/xauth.html" name="http://www.xs4all.nl/˜zweije/xauth.html">. Il est également disponible en tant que mini-HOWTO Linux Applications X à -distance (Remote X Apps) à : +distance (Remote X Apps) à : <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps" name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Les -(mini-)HOWTOs Linux sont disponibles par http ou ftp sur <htmlurl +(mini-)HOWTO du LDP sont disponibles par http ou ftp sur <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html" name="sunsite.unc.edu">. @@ -86,8 +86,8 @@ <sect> Lectures complémentaires -Un document, en rapport avec cela, sur le WWW traite de ''Quoi faire quand Tk -dit que votre écran n'est pas sûr'', +Un document, en rapport avec cela, sur le WWW traite de « Que faire quand Tk +dit que votre écran n'est pas sûr », <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/" name="http://ce-toolkit.crd.ge.com/tkxauth/">. Il a été écrit par <htmlurl @@ -96,20 +96,20 @@ l'authentification X (xauth). Cependant, Kevin vise plus à l'utilisation de xdm pour diriger xauth à votre place. -On m'a indiqué que le volume 8 du ``Guide de l'administrateur -du système X Window'' (X Window System Administrator's Guide Vol. 8) de +On m'a indiqué que le volume 8 du « Guide de l'administrateur +du système X Window » (X Window System Administrator's Guide Vol. 8) de chez <htmlurl url="http://www.ora.com/" name="O'Reilly and Associates"> était une bonne source d'informations. Malheureusement, je n'ai pas pu le vérifier. Il y a également un autre document qui ressemble beaucoup à celui que vous -êtes en train de lire, dont le titre est ''Securing X Windows'', et qui est +êtes en train de lire, dont le titre est « Securing X Windows », et qui est disponible à <htmlurl url="http://ciac.llnl.gov/ciac/documents/ciac2316.html" name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">. -Consultez également les listes de diffusion usenet, telles que : +Consultez également les forums de diffusion Usenet, tels que : <tt/comp.windows.x/, <tt/comp.os.linux.x/, et <tt/comp.os.linux.networking/. @@ -119,7 +119,7 @@ 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 +second soient affichées sur l'écran du premier. Le système X Window rend cela possible. @@ -128,7 +128,7 @@ 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 : +pouvez aller consulter les sites : dxpc <htmlurl url="http://www.vigor.nu/dxpc/" name="http://www.vigor.nu/dxpc/"> ou LBX <url url="http://www.paulandlesley.org/faqs/LBX-HOWTO.html" @@ -136,7 +136,7 @@ comme <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/LBX" name="LBX mini-HOWTO">). -Vous avez deux choses à faire pour réaliser tout cela : +Vous avez deux choses à faire pour réaliser tout cela : <enum> @@ -152,13 +152,13 @@ Le mot magique est <tt>DISPLAY (unité d'affichage)</tt>. Dans le système X -window, une unité d'affichage est constituée (en simplifiant) d'un clavier, +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 fourni des fonctionnalités d'affichage aux autres programmes qui se connectent à lui. -Une unité d'affichage est identifiée par un nom, de type, par exemple : +Une unité d'affichage est identifiée par un nom, de type, par exemple : <itemize> @@ -170,7 +170,7 @@ </itemize> -Un nom d'unité d'affichage est constitué d'un nom d'hôte (par exemple : +Un nom d'unité d'affichage est constitué d'un nom d'hôte (par exemple : <tt>light.uni.verse</tt> et <tt>localhost</tt>), du signe deux point (<tt/:/), et d'un numéro de séquence (tels que <tt/0/ et <tt/4/). Le nom d'hôte de l'unité d'affichage est le nom de l'ordinateur @@ -194,11 +194,11 @@ <itemize> <item> <tt/hostname:D.S/ signifie écran <tt/S/ sur unité d'affichage - <tt/D/ de l'hôte <tt/hostname/; le serveur X de cette unité + <tt/D/ de l'hôte <tt/hostname/ : le serveur X de cette unité d'affichage est à l'écoute du port TCP <tt/6000+D/. <item> <tt>host/unix:D.S</tt> signifie écran <tt/S/ sur unité d'affichage - <tt/D/ de l'hôte <tt/host/; le serveur X de cette unité d'affichage + <tt/D/ de l'hôte <tt/host/ : le serveur X de cette unité d'affichage est à l'écoute du socket de domaine UNIX <tt>/tmp/.X11-unix/XD</tt> (et donc, seul <tt/host/ peut l'atteindre). @@ -212,7 +212,7 @@ Le programme client (par exemple, votre application graphique) sait à quelle unité d'affichage il doit se connecter en consultant la -variable d'environnement <tt>DISPLAY</tt>. Cependant ce paramètrage peut être +variable d'environnement <tt>DISPLAY</tt>. Cependant ce paramétrage peut être modifié, en lançant le client avec l'argument <tt>-display hostname:0</tt> dans la ligne de commande. Quelques exemples peuvent clarifier les choses. @@ -230,20 +230,20 @@ Supposons que vous vous soyez déjà connecté par telnet à l'ordinateur distant, <tt/dark.matt.er/. -Si l'interpréteur de commande de l'ordinateur éloigné est csh : +Si l'interpréteur de commande de l'ordinateur éloigné est csh : <tscreen><verb> dark% setenv DISPLAY light.uni.verse:0 dark% xfig & </verb></tscreen> -Ou, d'une autre manière : +Ou, d'une autre manière : <tscreen><verb> dark% xfig -display light.uni.verse:0 & </verb></tscreen> -Si c'est sh qui tourne sur l'ordinateur à distance : +Si c'est sh qui tourne sur l'ordinateur à distance : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 @@ -251,13 +251,13 @@ dark$ xfig & </verb></tscreen> -Ou, autrement : +Ou, autrement : <tscreen><verb> dark$ DISPLAY=light.uni.verse:0 xfig & </verb></tscreen> -Ou, bien sûr, également : +Ou, bien sûr, également : <tscreen><verb> dark$ xfig -display light.uni.verse:0 & @@ -266,7 +266,7 @@ Il paraît que certaines versions de telnet transmettent automatiquement la variable <tt>DISPLAY</tt> -à l'ordinateur hôte éloigné. Si vous avez l'une ce celles-ci, vous avez de la +à 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 doivent transmettre la variable d'environnement <tt>TERM</tt>, et avec un bidouillage judicieux, il est @@ -275,7 +275,7 @@ sur la variable <tt>TERM</tt>. L'idée, sous-jacente à cette superposition, est de réaliser une sorte de script - pour effectuer ceci : avant la connexion par telnet, donner la valeur de + pour effectuer ceci : avant la connexion par telnet, donner la valeur de <tt/DISPLAY/ à <tt/TERM/. Puis de lancer telnet. Du côté de l'ordinateur distant, dans le fichier <tt/.*shrc/ concerné, lire la valeur de <tt/DISPLAY/ à partir de <tt/TERM/. @@ -286,7 +286,7 @@ 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! +partie de votre unité d'affichage ! Trop peu de gens semble réaliser que permettre l'accès à leur unité @@ -295,7 +295,7 @@ vos frappes au clavier, et suivre les déplacements de votre mulot. La plupart des serveurs disposent de deux manières d'authentifier les -demandes de connexions qui arrivent : +demandes de connexions qui arrivent : 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é, @@ -306,14 +306,14 @@ 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 : +aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n'est effectué, et donc, que -n'importe quel hôte peut se connecter! +n'importe quel hôte peut se connecter ! Vous pouvez contrôler la liste des hôtes du serveur avec le programme <tt>xhost</tt>. -Pour utiliser ce mécanisme dans l'exemple précédent, faites : +Pour utiliser ce mécanisme dans l'exemple précédent, faites : <tscreen><verb> light$ xhost +dark.matt.er @@ -322,13 +322,13 @@ Ceci permet toutes les connexions à partir de l'hôte <tt>dark.matt.er</tt>. 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 : +avec : <tscreen><verb> light$ xhost -dark.matt.er </verb></tscreen> -Vous pouvez désactiver la vérification des hôtes avec : +Vous pouvez désactiver la vérification des hôtes avec : <tscreen><verb> light$ xhost + @@ -338,7 +338,7 @@ tout le monde de se connecter. Vous ne devriez jamais faire cela sur un réseau où vous n'avez pas confiance dans tous les utilisateurs (tel internet). Vous pouvez réactiver la vérification -des hôtes avec : +des hôtes avec : <tscreen><verb> light$ xhost - @@ -381,19 +381,19 @@ 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; ils ne finissent pas dans <tt>˜/.Xauthority</tt> -à moins qu'un client ne les y mettent. Selon David Wiggins : +serveur : ils ne finissent pas dans <tt>˜/.Xauthority</tt> +à moins qu'un client ne les y mettent. Selon David Wiggins : <quote> 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 ``douteux'' de sorte que les +on peut désigner les cookies comme étant « douteux » 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 ``fiables''. -Il y a une nouvelle sous-commande ``generate'' de xauth pour rendre cette +au clavier/mulot, ou le contenu des fenêtres, d'autres clients « fiables ». +Il y a une nouvelle sous-commande « generate » de xauth pour rendre cette fonctionnalité, pas forcément facile, mais au moins possible à utiliser. </quote> @@ -403,7 +403,7 @@ Et, si vous le désirez, vous pouvez encore utiliser xhost en parallèle pour permettre des connexions. -<sect2> Fabrication du Cookie +<sect2> Fabrication du cookie Si vous voulez utiliser xauth, vous devez lancer le serveur X avec @@ -423,7 +423,7 @@ <htmlurl url="ftp://ftp.math.uio.no/pub/linux/" name="ftp://ftp.math.uio.no/pub/linux/">. Autrement, vous pouvez utiliser md5sum pour créer quelques données aléatoires (de, par exemple, -<tt>/dev/urandom</tt> ou <tt/ps -axl/) au format cookie : +<tt>/dev/urandom</tt> ou <tt/ps -axl/) au format cookie : <tscreen><verb> dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q @@ -438,7 +438,7 @@ lancer le serveur X véritable à partir de ce script avec les arguments adaptés. Pour faire cela, faites utiliser par votre <tt>˜/.xserverrc</tt> le <tt>mcookie</tt> de la ligne ci-dessus pour créer un cookie puis lancer le -véritable serveur X : +véritable serveur X : <tscreen><verb> #!/bin/sh @@ -454,13 +454,13 @@ <tt>˜/.Xauthority</tt> pour vous. Consultez xdm(1) pour de plus amples information. Par exemple, mon <tt>/etc/X11/xdm/xdm-config</tt> -contient la ligne suivante : +contient la ligne suivante : <tscreen><verb> DisplayManager.authDir: /var/lib/xdm </verb></tscreen> -<sect2> Transfert du Cookie +<sect2> Transfert du cookie Maintenant que vous avez lancé votre session X sur le serveur hôte @@ -474,11 +474,11 @@ Le plus simple est que vos répertoires sur <tt>light</tt> et <tt>dark</tt> soient partagés. Les fichiers <tt>˜/.Xauthority</tt> sont les mêmes, donc le cookie est transféré instantanément. -Cependant, il y a un piège : lorsque vous mettez un cookie pour <tt/:0/ +Cependant, il y a un piège : lorsque vous mettez un cookie pour <tt/:0/ dans <tt>˜/.Xauthority</tt>, 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; on ne peut pas faire autrement. Vous pouvez installer -le même cookie pour, à la fois, <tt/:0/ et <tt/light:0/ avec un peu d'astuce : +création du cookie : on ne peut pas faire autrement. Vous pouvez installer +le même cookie pour, à la fois, <tt/:0/ et <tt/light:0/ avec un peu d'astuce : <tscreen><verb> #!/bin/sh @@ -490,7 +490,7 @@ Si les répertoires home ne sont pas partagés, vous pouvez transférer le cookie -au moyen de rsh, le shell à distance : +au moyen de rsh, le shell à distance : <tscreen><verb> light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge - @@ -521,7 +521,7 @@ cela, <tt>rsh</tt> a un inconvénient en ce qui concerne la sécurité (noms d'hôtes parodiés, si je me souviens bien). Si vous ne pouvez, ou ne voulez, pas utiliser <tt>rsh</tt>, vous pouvez également transférer le -cookie manuellement, comme ceci : +cookie manuellement, comme ceci : <tscreen><verb> light$ echo $DISPLAY @@ -550,8 +550,8 @@ Il doit être possible de superposer le cookie sur la variable <tt/TERM/ ou <tt/DISPLAY/ quand vous utilisez telnet sur l'hôte éloigné. Cela doit fonctionner de la même manière que de superposer la -variable <tt/DISPLAY/ sur la variable <tt/TERM/. Regardez la section 5 : -Dire au Client. De mon point de vue, sur ce sujet, vous prenez vos +variable <tt/DISPLAY/ sur la variable <tt/TERM/. Regardez la section 5 : +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. @@ -559,7 +559,7 @@ être visibles par les autres et que que vous ne puissiez pas empêcher la visualisation du cookie dans <tt/$TERM/ si certains veulent le voir. -<sect2> Utilisation du Cookie +<sect2> Utilisation du cookie Une application X, telle que <tt>xfig</tt> ci-dessus, sur @@ -586,14 +586,14 @@ 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 cryptées. De plus, il est génial pour d'autres choses aussi. +connexions chiffrées. 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 <htmlurl url="http://www.ssh.org/" name="http://www.ssh.org/">, la page d'accueil de ssh. Qui possède d'autres informations sur les méthodes d'authentification ou -de cryptage des connexions X ? Peut-être Kerberos ? +de chiffrement des connexions X ? Peut-être Kerberos ? <sect> Les applications X avec un identificateur d'utilisateur (User-id) différent @@ -613,7 +613,7 @@ X a été lancée par <tt/serveruser/. Si vous avez lu le paragraphe sur les <em/cookies/, il est évident que <tt/clientuser/ ne peut pas accéder à votre unité d'affichage : -<tt>~clientuser/.Xauthority</tt> ne contient le cookie magique qui permet +<tt>~clientuser/.Xauthority</tt> ne contient pas le cookie magique qui permet d'accéder à l'unité d'affichage. Le cookie correct se trouve dans <tt>~serveruser/.Xauthority</tt>. @@ -648,14 +648,14 @@ Ce n'est pas tout, il faut encore transférer le cookie. On peut le retrouver en utilisant <tt/xauth list "$DISPLAY"/. Cette commande renvoie le cookie dans un format qui convient pour l'utiliser dans la commande - <tt/xauth add/; ce dont + <tt/xauth add/ : ce dont nous avons justement besoin ! On pourrait imaginer le 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 <tt/su/ par l'intermédiaire d'un canal de transmission car <tt/su/ -attends le mot de passe de l'entrée standard. Cependant, dans un script shell +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. Donc, on écrit un script de ce style en le paramétrant avec <tt/clientuser/ et @@ -749,7 +749,7 @@ </verb></tscreen> -Cependant, si vous avez déjà initialisé <tt/xsu/ , il n'y a pas de vrai +Cependant, si vous avez déjà initialisé <tt/xsu/ , il n'y a pas de vraie raison de faire cela. <sect> Faire tourner un gestionnaire de fenêtres distant @@ -770,7 +770,7 @@ Par manque de chance, beaucoup de scripts de sessions X se terminent par un <tscreen><verb> -exec le-gestionnaire-de-fenetre-de-votre-choix +exec le-gestionnaire-de-fenetres-de-votre-choix </verb></tscreen> et cela signifie que quand le gestionnaire de fenêtre (local) se termine, @@ -817,7 +817,7 @@ xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> -Erreur 101 signifie ``Réseau inaccessible''. L'application n'arrive pas à se +Erreur 101 signifie « Réseau inaccessible ». L'application n'arrive pas à se connecter au serveur à travers le réseau. Vérifiez que la variable <tt/DISPLAY/ est correctement renseignée et que la machine @@ -830,7 +830,7 @@ xterm Xt error: Can't open display: love.dial.xs4all.nl:0 </verb></tscreen> -Erreur 111 signifie ``Connexion refusée''. La machine à laquelle vous êtes en +Erreur 111 signifie « Connexion refusée ». 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é