Page suivante Page précédente Table des matières 9. Lancement de sessions X distantes sur des clients Windows95/98/NT/Mac/PPC Par Ron Jenkins Ce travail est fourni "en l'état ". L'auteur ne fournit aucune garantie, aussi bien explicite qu'implicite, vis-à-vis de ce travail, notamment les garanties qui ont rapport à la possibilité de vendre ou à la conformité pour quelque usage que ce soit. Les corrections et suggestions sont acceptées avec joie par l'auteur qui peut être contacté par courrier électronique à rjenkins@unicom.net. Ce document est le résultat de la résolution du problème d'un client. J'ai vu cette question posée un milliard de fois sur USENET, juste à côté de "Pourquoi Linux ne peut-il voir mes (insérez ici votre nombre >64Mo) de RAM?" 9.1 Le problème d'origine Un de mes clients avait un bon vieil hôte Unix classique avec configuration en terminal, connecté à travers de nombreuses liaisons séries à des serveurs de terminaux. Ils avaient aussi un PC sur chaque bureau, également connecté à travers une bête connexion série. Le problème est qu'ils devaient administrer l'hôte ainsi qu'utiliser de nombreux programmes sur l'hôte qui nécessitaient une Interface Utilisateur Graphique (GUI). Pour faire cela, ils utilisaient des stations de travail Unix. Il est clair que cela était inacceptable car chacun se battait pour disposer de temps sur les stations de travail. La version d'Unix qu'ils utilisaient ne disposait pas d'une Interface en Ligne de Commande (CLI) autre qu'une session de telnet sur le réseau ou la configuration série mentionnée plus haut, l'administration se faisait uniquement à travers leur interface propriétaire qui fonctionnait en surcouche de X. Une rapide recherche montra qu'un serveur X tournait sur l'hôte mais qu'il n'était pas utilisé. Un consultant précédent, de la compagnie à laquelle ils avaient acheté les deux systèmes avait suggéré la solution d'utiliser des terminaux X que, par une heureuse coïncidence, ils avaient justement sous la main. Ils ne m'ont jamais dit quelle était leur cote mais la rumeur disait qu'ils étaient chancelants. (Regardez le prix d'un terminal X et vous verrez ce que je veux dire.) Voilà où intervient Linux. Tout d'abord, je me suis débarrassé des connexions séries des PC et je les ai mis sur un réseau 10 base T. Ensuite, j'ai configuré quelques 486/100 comme serveurs de fichiers et hôtes proxy, en utilisant ip_masq et Samba. Ces machines étaient alors connectées à un WAN externe via un bus 10 base 2. L'ensemble des machines disposait de quotas de stockage, pouvait utiliser l'e-mail, envoyer des mémos à chacun des autres, surfer sur le net et se comportait à merveille. 9.2 Quel rapport avec les sessions X et Windows? En un mot - LA POLITIQUE. Pour convaincre ceux qui avaient l'argent de me laisser utiliser Linux pour résoudre les problèmes des programmeurs et des administrateurs (ceux qui font le travail effectif qui rapporte de l'argent), je devais d'abord les impressionner. Bien qu'ils n'aient pas compris l'aspect technique de l'affaire, ils comprenaient parfaitement que je leur donnais l'e-mail, les services de fichiers, l'intranet et l'accès Internet pour le seul coût de mon temps puisque les 486 prenaient la poussière dans un placard. J'avais maintenant le feu vert pour la solution X que je proposais, à savoir quelques 486 de plus, déjà disponibles sur place et non utilisés, que je dotais de disques SCSI-3 Ultra Wide, que je gonflais en RAM pour qu'ils servent de proxies X, pour des raisons que je n'exposerai pas ici. Cela rajoute une barrière additionnelle entre l'hôte X et les clients. Vous ne devriez pas en avoir besoin, je vais donc faire comme si tout ce qui est derrière les 486 n'existait pas. Juste pour rendre cela vraiment amusant, on m'avait également demandé d'inclure le département de conception web sur ce sous-réseau, département qui était composé uniquement de Mac et de Power PC. Après avoir créé un sous réseau 10 base T avec les 486 et une fois les clients connectés et la couche TCP/IP configurée sur tous les clients, il était temps de leur montrer quelque chose de magique. A partir de maintenant, les 486 seront appelés hôtes X, et toute machine Windows 95/98/NT/Mac/PPC sera dénommée par le terme de client. Première étape : Sur l'hôte X, créez un compte utilisateur pour chacun des clients désirés. Seconde étape : Récupérez un logiciel de serveur X pour les clients. Je suis un fanatique du freeware, j'ai donc choisi MI/X, disponible sur http://tnt.microimages.com/www/html/freestuf/mix/ ou mon miroir, ftp.brokewing.com/pub/mix/. Une autre raison qui m'a poussée à choisir le paquetage MI/X est que celui-ci tourne sur les trois plates-formes. Installez le logiciel MI/X Note pour les clients Windows - soit vous installez le programme dans son propre répertoire, par exemple C:/mix soit vous l'installer dans Program Files, en créant alors un raccourci directement vers $BASEDIR\TNTSTART.EXE startmix (notez la présence d'un espace) car, pour une raison inconnue, les machines sous 95 peuvent vous donner un message "not enough memory" quand vous essayez de le lancer sans l'avoir créé. Troisième étape : Récupérez un logiciel Telnet pour vos clients. Dans mon cas, ils étaient déjà configurés pour telnet, du fait de la connexion série présente auparavant. Tous les clients Windows devraient déjà disposer de telnet, les Mac peuvent l'avoir ou non. Si ce n'est pas le cas, NCSA produit un client telnet qui tourne sur les plates-formes MAC. Quatrième étape : Vous devriez pouvoir commencer. Je suis certain que tout ce travail pourrait être fait d'une manière plus élégante mais voici ce que j'ai fait : Lancez MI/X sur le client. Ouvrez une session telnet vers l'hôte X : telnet 192.162.0.1 Après que vous soyez logués, vous devez dire à l'hôte X d'envoyer l'affichage de la sortie d'un programme tournant sur l'hôte X vers une machine différente (le client). En bourne shell : DISPLAY=<IP de la machine client>:0.0 Par exemple, DISPLAY=192.0.0.3:0.0 Vous devez maintenant dire à l'hôte X d'utiliser cette Variable d'Environnement pour tous les programmes qui suivent. La commande pour faire cela est : export DISPLAY En csh : setenv DISPLAY <IP du client comme ci-dessus> Vous devriez maintenant être capable de faire tourner n'importe quelle application X sur l'hôte X en redirigeant l'affichage vers la machine client. Dans la fenêtre telnet, pour lancer un xterm, tapez : xterm & Après que la xterm soit apparue dans la fenêtre MI/X, vous pouvez fermer la session telnet. C'est tout ce qu'il y a à faire! Copyright © 1998, Ron Jenkins Adaptation française de Pierre Tane Page suivante Page précédente Table des matières