Linux Term HOWTO v1.1, version française. <author> par Patrick Reijnen, <tt>patrickr@cs.kun.nl</tt> </author> <date> 12 Mai 1995 </date> <abstract> Ce document expose les bases de l'installation et du fonctionnement de <tt>term</tt>, programme grâce auquel il est possible de multiplexer une liaison série entre deux machines dont l'une est connectée à un réseau. On peut ainsi mettre en place une connexion au réseau sur la seconde machine. </abstract>  <toc>  <sect>Informations légales <sect1>Version française <sect2>Copyright Ce document peut être librement distribué, sous quelque forme que ce soit, s'il l'est gratuitement et dans son intégralité. Des extraits peuvent en être diffusés, sous réserve que les présentes informations de <it>copyright</it> soient incluses et que le lecteur soit informé du fait qu'il ne s'agit pas de la version intégrale, dont on indiquera comment se la procurer. Ce document pourra être inclus dans des distributions commerciales sans consentement explicite préalable. L'auteur souhaite cependant être averti de telles utilisations. Ce <tt>HOWTO</tt> pourra être traduit dans toute langue, à condition que les informations de <it>copyright</it> et de limitation de garantie soient fournies sous leur forme originelle et que l'identité du traducteur soit indiquée dans la traduction<footnote> Le traducteur est en l'occurence Arnaud Ruch (ruch@labri.u-bordeaux.fr).</footnote>. Le traducteur souhaite de plus être informé de toute utilisation de ce document dans une distribution commerciale. <sect2>Limitation de garantie Bien que l'auteur ait essayé de fournir les informations les plus exactes et récentes possibles, il ne peut garantir que l'utilisation de ce document ne provoquera pas la perte de données. Il ne fournit donc <bf>AUCUNE GARANTIE</bf> sur les informations contenues dans ce <tt>HOWTO</tt> et ne pourra en aucun cas être tenu pour responsable de quelconques dommages résultant de son utilisation<footnote> Il en va bien entendu de même du traducteur.</footnote>. <sect1>Version originale <sect2>Copyright statement This document may be distributed freely as a whole in any form and free of charge. Parts of this document may be distributed, provided that this copyright message is included and the reader is informed that this is not the full <tt>HOWTO</tt> document. Furthermore, there is to be a pointer as to where the full document can be obtained. Specifically, it may be included in commercial distributions, without prior consent. However, I would like to be informed of such usage. This <tt>HOWTO</tt> may be translated into any language, whatsoever, provided that you leave this copyright statement and the disclaimer intact, and that a notice is appended stating who translated the document. <sect2>DISCLAIMER While I have tried to include the most correct and up-to-date information available, I cannot guarantee that usage of the information in this document does not result in loss of data. I provide <bf>NO WARRANTY</bf> about the information in this <tt>HOWTO</tt> and I cannot be made liable for any consequences for any damage resulting from using information in this <tt>HOWTO</tt>. <sect>Introduction <sect1>À propos de ce document Ce <tt>HOWTO</tt> tente de dissiper la confusion que peut engendrer l'utilisation de <tt>term</tt>, remarquable programme de Michael O'Reilly grâce auquel il est possible de multiplexer une liaison série, afin de mettre en place une connexion à un réseau. La documentation fournie avec <tt>term</tt> étant de relativement bonne qualité, ce document ne vise en aucun cas à la remplacer. Son intention est d'expliquer sur quelles bases fonctionne <tt>term</tt> et de détailler les étapes nécessaires à la mise en place de quelques-uns des services réseau les plus courants. L'auteur insiste sur le fait que ce document ne couvre pas l'ensemble de ce qu'il y a à connaître sur <tt>term</tt>. Après l'avoir parcouru, reportez-vous aux pages du manuel qui contiennent de nombreuses informations complémentaires. <sect1>Qu'est-ce que <tt>term</tt> ? <tt>term</tt> est un programme écrit par Michael O'Reilly (<tt>michael@iinet.com.au</tt>) et maintenu par Bill Riemers (<tt>bcr@physics.purdue.edu</tt>), qui permet à plusieurs connexions d'opérer simultanément sur une même liaison série. Il est par exemple possible de télécharger un fichier tout en travaillant sur un site distant différent, et ce grâce à la même liaison modem. <tt>term</tt> permet également de lancer des clients <tt>X Windows</tt> par l'intermédiaire de cette même liaison. Grâce aux utilitaires <tt>tredir</tt> et <tt>tudpredir</tt>, <tt>term</tt> est en mesure de fournir la plupart des services réseau <tt>TCP/IP</tt> et <tt>UDP</tt> traditionnels : <it>mail</it>, <it>news</it>, <tt>ftp</tt>, <tt>telnet</tt>, <tt>xarchie</tt>, etc. D'un certain point de vue, <tt>term</tt> est très semblable aux autres protocoles série tel que <tt>SLIP</tt> et <tt>PPP</tt>, mais son avantage est d'être exécuté intégralement depuis l'espace utilisateur. Il ne requiert donc aucune intervention d'administrateurs système ou réseau. Contrairement à <tt>SLIP</tt> ou <tt>PPP</tt>, votre machine ne possède pas sa propre adresse <tt>IP</tt>. Tout le trafic à destination de votre machine doit donc être adressé à une machine distante, qui se charge de le rediriger vers elle par l'intermédiaire de <tt>term</tt>. <sect>Comment <tt>term</tt> fonctionne-t-il ? Avant de vous lancer dans l'expérimentation de <tt>term</tt>, il est vivement recommandé de lire ce chapître dans son intégralité et de parcourir le fichier '<tt>INSTALLATION</tt>' fourni avec <tt>term</tt>. Examinez également les pages de manuel de <tt>linecheck</tt>, <tt>(term)test</tt> et <tt>term</tt>. Vous pourrez alors travailler plus facilement et plus rapidement. <sect1>Nomenclature Supposons que vous appelez une machine par l'intermédiaire d'un quelconque serveur de terminal. Les termes <it>local</it> et <it>distant</it> se réfèrent respectivement au système local et à la machine distante, qui est connectée au réseau. La machine locale n'est pas directement reliée au réseau. <tt>term</tt> est cependant capable, en utilisant la connexion au réseau dont dispose la machine distante, de lui fournir des services réseau, par l'intermédiaire de la liasion série. Examinons comment une machine dotée d'une connexion réseau traditionnelle fournit ces services. Dans un premier temps, l'utilisateur lance un programme tel que <tt>ftp</tt> ou <tt>telnet</tt>. Ce programme demande un service réseau par un appel système. Le système d'exploitation obtient alors ce service de son interface réseau (par exemple, il envoie et reçoit des paquets <it>éthernet</it>). <tt>SLIP</tt> et <tt>PPP</tt> procèdent exactement de la même façon, en transformant en interface réseau votre liaison modem. En pratique en effet, une liaison série n'est guère différente d'une liaison <it>éthernet</it>. L'inconvénient majeur de ces protocoles est qu'ils font de la machine connectée par modem une part intégrante du réseau, avec les nombreuses charges d'administration qui en découlent (plus, en fait, puisque la liaison modem doit également être administrée). En l'absence d'une connexion réseau telle que <tt>SLIP</tt> ou <tt>PPP</tt>, que fait-on habituellement ? Et bien, on appelle une machine connectée au réseau, on lit son courrier, ses <it>news</it>, etc. Lorsqu'on a besoin d'un fichier, on commence par le transférer sur la machine distante, puis on le rapatrie sur la machine locale grâce à <tt>kermit</tt> ou un autre programme de communication. Tout ceci est quelque peu astreignant, d'autant plus que vous ne pouvez utiliser votre liaison modem que pour une opération à la fois. L'idée à la base de <tt>term</tt> est d'automatiser et de multiplexer ces opérations. <tt>term</tt> est lancé à la fois sur la machine locale et sur la machine distante, les deux processus communiquant par la liaison modem. Lorsque vous avez besoin d'un service réseau, vous adressez une requête au démon <tt>term</tt> local, qui la retransmet au démon <tt>term</tt> qui s'exécute sur la machine connectée au réseau. Le résultat est alors renvoyé par l'intermédiaire de la liaison modem. Pour être plus concrêt, disons que vous souhaitez récupérer un fichier grâce à <tt>ftp</tt>. Tout d'abord, il vous faut une version de <tt>ftp</tt> capable de dialoguer avec <tt>term</tt>. Vous lancez ce <tt>termftp</tt> comme un <tt>ftp</tt> classique, par la commande <tt>termftp nethost.gov</tt>, par exemple. La différence est que cette version particulière de <tt>ftp</tt> adresse sa requête au démon <tt>term</tt> local plutôt qu'au noyau. Le démon <tt>term</tt> local retransmet cette requête au <tt>term</tt> distant par l'intermédiaire de la liaison modem, celui-ci se chargeant alors d'ouvrir une connexion <tt>ftp</tt> avec <tt>nethost.gov</tt> et de renvoyer les données. <tt>term</tt> est suffisament astucieux pour vous permettre de gérer de nombreuses actions à, la fois de telle sorte qu'il vous est possible d'avoir plusieurs sessions ouvertes simultanément sur la même liaison modem (par exemple, vous pouvez être connecté à une machine distante par <tt>termtelnet</tt> pendant que le transfert <tt>termftp</tt> se poursuit). Ne vous inquiétez pas si tout ceci vous semble trop abstrait (ou bien confus) : ce qu'il faut ici retenir est qu'il y a <it>deux</it> occurences de <tt>term</tt> qui s'exécutent, chacune à une extrêmité de la liaison modem. <sect>Mise en place <sect1>Ce dont vous devez disposer Avant de commencer à construire <tt>term</tt>, il vous faut être sûr que votre noyau a été compilé avec l'option <tt>TCP/IP</tt>. L'interface <tt>TCP/IP loopback</tt> doit également avoir été activée. Une fois que ceci est fait, vous pouvez parcourir le reste de ce paragraphe. <sect1>Explication des concepts Dans les dernières versions de <tt>term</tt>, deux nouveaux concepts ont fait leur apparition. Les deux paragraphes suivants y sont consacrés. <sect2>Le partage Depuis la version 1.16 de <tt>term</tt>, le concept de <it>partage</it> de la connexion <tt>term</tt> avec d'autres utilisateurs est apparu. Si, par exemple, vous travaillez sur la machine distante via votre connexion <tt>term</tt> (vous avez utilisé <tt>trsh</tt> pour vous connecter depuis votre machine locale), un autre utilisateur peut utiliser la même connexion pour transférer par <tt>ftp</tt> un fichier sur son compte sur la machine locale, depuis un site <tt>ftp</tt> distant. Lorsque vous désactivez les possibilités de partage (c'est-à-dire que vous utilisez <tt>term</tt> en mode <it>privé</it>), vous seul (en plus de <it>root</it> :-) pouvez utiliser la connexion <tt>term</tt>. Bien sûr, vous n'avez besoin d'installer le <tt>term</tt> partagé qu'à l'extrêmité à laquelle vous voulez permettre à d'autres utilisateurs de profiter de la même connexion <tt>term</tt> que vous. Ainsi, si d'autres utilisateurs ont un compte sur votre machine locale et souhaitent l'utiliser depuis une autre machine du réseau distant, il vous faut activer le partage à l'extrêmité distante de la connexion <tt>term</tt>. De cette façon, ces personnes peuvent se connecter à votre machine locale en utilisant la même connexion <tt>term</tt> que vous. (NOTE : le premier exemple supposait que le partage soit activé à l'extrêmité locale de la connexion). <bf>NOTE sur l'installation en tant que root :</bf> Lorsque vous installez <tt>term</tt> en tant que <it>root</it>, il vous faut au préalable créer un groupe <it>term</it> (avant la compilation) ne contenant aucun utilisateur. Ceci se fait par l'ajout de la ligne suivante au fichier '<tt>/etc/group</tt>' : <verb> term::16:root </verb> ou tout <it>GID</it> inutilisé autre que 16, si 16 est déjà attribué. Après la compilation et l'installation, rendez <tt>term</tt> et ses clients <it>SUID</it>, grâce aux commandes : <verb> chgrp term <client_term> chmod g+s <client_term> </verb> Procédez de même avec tout autre programme utilisant <tt>term</tt>. <sect2>Réseau <tt>term</tt> intégral On utilise l'expression de <it>réseau term intégral</it> depuis la version 2.0.0 de <tt>term</tt>. Lorsque votre seule connexion au monde extérieur est une connexion <tt>term</tt>, vous disposez d'un <it>réseau term intégral</it>. Il vous faut alors compiler <tt>term</tt> avec cette option. Dans ce cas, un fichier '<tt>termnet</tt>' est placé dans votre répertoire partagé. Ceci indique à <tt>term</tt> qu'il assure votre unique connexion avec le monde extérieur. Si vous avez également un autre type de connexion réseau vers l'extérieur, les programmes qui savent utiliser <tt>term</tt> tenteront dans un premier temps d'utiliser cette connexion. Si cela échoue, <tt>term</tt> sera lancé et une nouvelle tentative sera effectuée, avec la connexion <tt>term</tt>. Pour être plus clair, voici un exemple qui utilise la version <tt>term</tt> de <tt>telnet</tt>, laquelle peut fonctionner avec ou sans <tt>term</tt>. <verb> telnet localhost </verb> n'utilise pas <tt>term</tt> pour réaliser la connexion alors que : <verb> telnet zeus.cs.kun.nl </verb> utlisera <tt>term</tt> si vous n'avez pas d'autre type de connexion réseau. Un <it>réseau term intégral</it> suppose que l'on mente à propos du nom de la machine locale, en prétendant qu'il s'agit de la machine distante. De plus, cela implique que <tt>bind(0)</tt> agisse toujours sur la machine distante. Sommairement, cela signifie que de nombreux programmes n'utilisant pas <tt>term</tt> deviennent inutilisables lorsque <tt>term</tt> est actif. Malheureusement, c'est le cas de la plupart des programmes et démons <tt>UDP</tt>. <sect1>Compilation de <tt>term</tt> Si vous avez de la chance, un simple <tt>make</tt> devrait suffire. Il est cependant probable que vous aurez un peu plus de travail. Du fait des nouvelles possibilités des version récentes de <tt>term</tt>, la construction de l'exécutable est désormais un peu compliquée. On peut procéder de plusieurs façons. Afin de détailler toutes ces manières de construire <tt>term</tt>, cette section est divisée en trois parties : <enum> <item>Compilation de <tt>term</tt>, versions 2.0.0 et ultérieures.</item> <item>Compilation de <tt>term</tt>, versions 1.16 à 1.19.</item> <item>Compilation de <tt>term</tt>, versions 1.15 et antérieures.</item> </enum> <sect2>Compilation de <tt>term</tt>, versions 2.0.0 et ultérieures Tout d'abord, assurez-vous d'avoir bien lu la partie '<it>réseau term intégral</it>' ci-dessus. Il existe plusieurs façons de compiler l'exécutable et les clients <tt>term</tt> des versions 2.0.0 et ultérieures. Toutes peuvent être utilisées par <it>root</it> ou par un utilisateur normal : <enum> <item>Compilation de <tt>term</tt> en mode privé sans <it>réseau term intégral</it>.</item> <item>Compilation de <tt>term</tt> en mode privé avec <it>réseau term intégral</it>.</item> <item>Compilation de <tt>term</tt> en mode partagé sans <it>réseau term intégral</it>.</item> <item>Compilation de <tt>term</tt> en mode partagé avec <it>réseau term intégral</it>.</item> </enum> Dans ces versions de <tt>term</tt>, une nouvelle procédure de compilation est apparue, grâce au <it>script</it> <tt>configure</tt>. Lorsque <tt>configure</tt> est lancé, il détermine le système d'exploitation, si le répertoire source est accessible ou non et si des options d'exécution ont été choisies. En fonction de ce qu'il a trouvé, il crée un fichier '<tt>Makefile</tt>' à partir du '<tt>Makefile.in</tt>' fourni avec <tt>term</tt>. Deux des plus importantes options à configurer sont <tt>--root</tt> et <tt>--user</tt> qui déterminent si <tt>term</tt> doit être installé par <it>root</it> ou par un utilisateur classique. D'autres options peuvent être utilisées pour installer <tt>term</tt> à votre goût (dans une arborescence non standard, par exemple). <enum> <item>Compilation de <tt>term</tt> en mode privé sans <it>réseau term intégral</it>. Pour installer <tt>term</tt> de cette façon, vous devez lancer les commandes (que ce soit en tant que <it>root</it> ou en tant qu'utilisateur ordinaire) : <verb> ./configure --root OU --user make install installman </verb> Ceci construit les exécutables, les installe et installe les pages de manuel. </item> <item>Compilation de <tt>term</tt> en mode privé avec <it>réseau term intégral</it>. Pour installer <tt>term</tt> de cette façon, vous devez lancer les commandes (que ce soit en tant que <it>root</it> ou en tant qu'utilisateur ordinaire) : <verb> ./configure --root OU --user make installnet installman </verb> Ceci construit les exécutables, les installe et installe les pages de manuel. </item> <item>Compilation de <tt>term</tt> en mode partagé sans <it>réseau term intégral</it>. Pour installer <tt>term</tt> de cette façon, vous devez lancer les commandes (que ce soit en tant que <it>root</it> ou en tant qu'utilisateur ordinaire) : <verb> ./configure --root OU --user make share installman </verb> Ceci construit les exécutables, les installe et installe les pages de manuel. </item> <item>Compilation de <tt>term</tt> en mode partagé avec <it>réseau term intégral</it>. Pour installer <tt>term</tt> de cette façon, vous devez lancer les commandes (que ce soit en tant que <it>root</it> ou en tant qu'utilisateur ordinaire) : <verb> ./configure --root OU --user make share installnet installman </verb> Ceci construit les exécutables, les installe et installe les pages de manuel. </item> </enum> <sect2>Compilation de <tt>term</tt>, versions 1.16 à 1.19 Pour installer ces versions de <tt>term</tt> vous pouvez choisir l'une des procédures suivantes : <enum> <item>Compilation de <tt>term</tt> en mode privé, en tant qu'utilisateur ordinaire.</item> <item>Compilation de <tt>term</tt> en mode partagé, en tant qu'utilisateur ordinaire.</item> <item>Compilation de <tt>term</tt> en mode privé, en tant que <it>root</it>.</item> <item>Compilation de <tt>term</tt> en mode partagé, en tant que <it>root</it>.</item> </enum> Comment activer/désactiver les fonctionnalités de partage de <tt>term</tt> durant la compilation est expliqué ci-après. <enum> <item>Vous êtes un utilisateur ordinaire (pas de compte <it>root</it>) et vous ne souhaitez PAS partager votre connexion <tt>term</tt> avec d'autres utilisateurs. Installez <tt>term</tt> de la façon suivante : <verb> make DO=install OS-type make installman </verb> Ceci compile puis installe <tt>term</tt>, ses clients et les pages de manuel. Il vous faut de plus créer un répertoire '<tt>$HOME/.term</tt>'. C'est le répertoire dans lequel <tt>term</tt> recherchera son fichier '<tt>termrc</tt>'. </item> <item>Vous êtes un utilisateur ordinaire (pas de compte <it>root</it>) et vous souhaitez partager votre connexion <tt>term</tt> avec d'autres utilisateurs. Installez <tt>term</tt> de la façon suivante : <verb> make DO=installshare USERSHARE=$HOME/term OS-type make installman </verb> Ceci compile puis installe <tt>term</tt>, ses clients et les pages de manuel. Il vous faut de plus créer un répertoire '<tt>$HOME/.term</tt>' (nom par défaut) avec les droits <tt>drwxrwxr-x</tt>. Dans ce répertoire, vous trouverez au moins la <it>socket</it> utilisée par <tt>term</tt> pour sa connexion ('<tt>tmp/private/socket=</tt>'). </item> <item>Vous êtes <it>root</it> et vous ne souhaitez PAS partager votre connexion <tt>term</tt> avec d'autres utilisateurs. Installez <tt>term</tt> de la façon suivante : <verb> make DO=install OS-type make installman </verb> Ceci compile puis installe <tt>term</tt>, ses clients et les pages de manuel. Il vous faut de plus créer un répertoire '<tt>/usr/local/lib/term</tt>' (nom par défaut) avec les droits <tt>drwxrwxr-x</tt>. Dans ce répertoire, vous trouverez au moins la <it>socket</it> utilisée par <tt>term</tt> pour sa connexion ('<tt>tmp/private/socket=</tt>'). </item> <item>Vous êtes <it>root</it> et vous souhaitez partager votre connexion <tt>term</tt> avec d'autres utilisateurs. Tout d'abord, assurez-vous d'avoir lu la partie concernant le partage. Installez <tt>term</tt> de la façon suivante : <verb> make DO=installshare OS-type make installman </verb> Ceci compile puis installe <tt>term</tt>, ses clients et les pages de manuel. Il vous faut de plus créer un répertoire '<tt>/usr/local/lib/term</tt>' (nom par défaut) dont le propriétaire est le groupe <it>term</it>, avec les droits <tt>drwxrwxr-x</tt>. Dans ce répertoire, vous trouverez au moins la <it>socket</it> utilisée par <tt>term</tt> pour sa connexion ('<tt>tmp/private/socket=</tt>'). </item> </enum> <sect2>Compilation de <tt>term</tt>, versions 1.15 et antérieures La compilation de ces versions de <tt>term</tt> ne devrait pas requérir d'autres commandes que : <verb> make DO=install OS-type make installman </verb> Ceci compile puis installe <tt>term</tt>, ses clients et les pages de manuel. Tout est alors prêt à l'emploi. Il vous faut de plus créer un répertoire '<tt>$HOME/.term</tt>'. C'est le répertoire dans lequel <tt>term</tt> recherchera son fichier '<tt>termrc</tt>'. Les seules choses que vous pourrez souhaiter modifier sont certains des chemins du '<tt>Makefile</tt>' et certaines options du compilateur. <sect1><tt>client.a, libtermnet.a, libtermnet.sa, libtermnet.so</tt> Une bibliothèque est fournie avec <tt>term</tt>. Elle propose des fonctions pour les clients <tt>term</tt>. Jusqu'à la version 1.16, cette bibliothèque était nommée <tt>client.a</tt>. Elles était bâtie lors de la compilation de <tt>term</tt>, puis utilisée lors de celle des clients. Elle n'était installée dans aucun répertoire. Depuis la version 1.16, cette bibliothèque s'appelle <tt>libtermnet.a</tt>. Jusqu'à la version 1.19, elle est créée dans le répertoire <tt>term</tt>, puis utilisée pour la compilation des clients <tt>term</tt>. Elle n'est installée nulle part ailleurs. A partir de la version 2.0.0, <tt>libtermnet.so</tt> et <tt>libtermnet.sa</tt> (bibliothèque partagée et données exportées et initialisées pour la bibliothèque) sont également créées lors de la compilation de <tt>term</tt>. Lors de l'installation de l'ensemble des composantes du paquetage, ces trois bibliothèques (<tt>libtermnet.a, libtermnet.so</tt> et <tt>libtermnet.sa</tt>) sont installées dans le répertoire '<tt>/usr/local/lib</tt>' (par défaut). Un lien est ensuite créé de <tt>libtermnet.so.2.x.x</tt> vers <tt>libtermnet.so.2</tt>. Finalement, <tt>ldconfig</tt> est lancé pour créer les liens et le cache nécessaires (pour le <it>linkage</it> à l'exécution, par <tt>ld.so</tt>). <tt>ld.so</tt> tient compte des versions les plus récentes des bibliothèques trouvées dans les répertoires précisés dans la ligne de commande, dans le fichier '<tt>/etc/ld.so.conf</tt>' et dans les répertoires '<tt>/usr/lib</tt>' et '<tt>/lib</tt>'. Si l'installation est effectuée correctement, ces trois bibliothèques peuvent alors être utilisées par tous les clients <tt>term</tt> qui sont construits avec des bibliothèques dynamiques plutôt que statiques. Ces bibliothèques peuvent également être utilisées pour le portage de vos propres programmes afin de leur permettre d'utiliser les fonctionnalités de <tt>term</tt> (voir plus loin). <sect1>Variables d'environnement <tt>term</tt> reconnaît un certain nombre de variables d'environnement qui peuvent être positionnées par les utilisateurs. Les trois premières à être détaillées sont : <itemize> <item><tt>termDIR</tt></item> <item><tt>termSHARE</tt></item> <item><tt>termMODE</tt></item> </itemize> Grâce à ces variables, il vous est possible de contrôler la façon dont <tt>term</tt> s'exécute. Pour les versions de <tt>term</tt> 1.15 et antérieures, seule la variable <tt>termDIR</tt> est importante (ces versions ne proposent pas le mode partagé). Pour ces versions, positionnez <tt>termDIR</tt> de la façon suivante : <verb> setenv termDIR $HOME (csh ou tcsh) export termDIR=$HOME (ksh ou bash) </verb> A partir de la version 1.16, <tt>term</tt> reconnait également les variables <tt>termSHARE</tt> et <tt>termMODE</tt>. Grâce à ces variables, on peut indiquer à <tt>term</tt> s'il doit fonctionner en mode privé ou partagé. Comment positionner ces variales pour les modes privé et partagé est expliqué ci-après. <tt>termMODE</tt> peut avoir l'une des trois valeurs suivantes : <itemize> <item> 0 = privé</item> <item> 1 = partagé (système)</item> <item> 2 = partagé (utilisateur)</item> </itemize> <enum> <item>On peut utiliser <tt>term</tt> en mode privé en positionnant les variables <tt>termDIR</tt> et <tt>termMODE</tt> de la façon suivante : En csh ou tcsh : <verb> setenv termDIR $HOME setenv termMODE 0 </verb> En ksh ou bash : <verb> export termDIR=$HOME export termMODE=0 </verb> </item> <item>Il y a deux manières de positionner les variables pour utiliser <tt>term</tt> en mode partagé : <enum> <item>Lorsque <tt>term</tt> est installé comme un programme <it>SUID</it>, seule <tt>termMODE</tt> doit être positionnée. <verb> setenv termMODE 2 (csh ou tcsh) export termMODE=2 (ksh ou bash) </verb> </item> <item>Lorsque <tt>term</tt> est installé comme un programme <it>SGID</it>, il faut positionner les variables comme suit : En csh ou tcsh : <verb> setenv termMODE 1 setenv termDIR /usr/local/lib/term setenv termSHARE $termDIR </verb> En ksh ou bash : <verb> export termMODE=1 export termDIR=/usr/local/lib/term export termSHARE=$termDIR </verb> Positionner les variables de cette manière permet d'utiliser les anciens clients (<it>linkés</it> avec une ancienne version de <tt>client.a</tt>) en mode partagé. </item> </enum> </enum> A partir de la version 2.0.0, <tt>term</tt> reconnaît également la variable <tt>termSERVER</tt>. Celle-ci doit être positionnée si vous possédez plusieurs modems et utilisez plus d'une connexion à la fois. Pour préciser quelle connexion utiliser, il faut lancer <tt>term</tt> avec le nom d'un serveur. <verb> nohup term -v /dev/modem1 Connection1 & nohup term -v /dev/modem2 Connection2 & </verb> Les utilisateurs doivent alors positionner la variable <tt>termSERVER</tt> sur le nom de la connexion qu'ils souhaitent utiliser : <verb> setenv termSERVER Connection1 (csh ou tcsh) export termSERVER=Connection2 (ksh ou bash) </verb> <sect1>Test de <tt>term</tt> Tapez <tt>make test</tt> (ou <tt>make termtest</tt> pour les versions récentes de <tt>term</tt>) afin de compiler le démon de test de <tt>term</tt>. <tt>(term)test</tt> fonctionne en exécutant deux occurences de <tt>term</tt> sur votre système, une copie 'locale' et une copie 'distante'. Chacune d'elles lira votre '<tt>termrc</tt>' de façon à ce que vous puissiez en ajuster le comportement. Lancez <tt>(term)test</tt> maintenant. Vous devriez être en mesure de lancer un <tt>trsh</tt> et un <tt>tupload</tt>. Essayez : <verb> tupload ./term /usr/tmp </verb> ceci devrait placer une copie de l'exécutable <tt>term</tt> dans le repértoire '<tt>/usr/tmp</tt>'. La sortie du <tt>term</tt> local apparaît dans le fichier '<tt>local.log</tt>', celle du <tt>term</tt> distant dans '<tt>remote.log</tt>'. Vous pouvez lancer <tt>term</tt> avec l'option <tt>-d255</tt> de façon à ce que des informations de déboguage soient incluses dans ces fichiers ou pour vous permettre de déboguer votre '<tt>termrc</tt>'. NOTE : lancez <tt>test</tt> par la commande <tt>./test</tt> de façon à ne pas lancer le <tt>test</tt> du système. <sect1><tt>term</tt> et les programmes de communication Avant de pouvoir utiliser <tt>term</tt>, il faut avoir établi une connexion par modem, par l'intermédiaire d'un programme de communication tel que <tt>kermit</tt> ou <tt>seyon</tt>. La documentation de votre programme de communication vous fournira les informations dont vous aurez besoin pour vous connecter à une machine distante. Lorsque vous avez établi la connexion avec la machine distante, il vous faut interrompre ou quitter votre programme de communication pour pouvoir utiliser <tt>term</tt>, mais sans couper la connexion. Ceci est nécessaire pour éviter que le programme de communication subtilise des caractères à <tt>linecheck</tt> ou <tt>term</tt>. Comment s'assurer que la connexion reste active et que le programme de communication ne s'approprie pas certains caractères est expliqué ci-après, pour quelques exemples. <sect2><tt>kermit</tt> Il est facile de lancer <tt>term</tt> lorsque vous utilisez <tt>kermit</tt> : à l'invite de <tt>kermit</tt>, tapez la commande <tt>suspend</tt>. Vous voila de retour à l'invite de <tt>Linux</tt>. A partir de là, vous pouvez établir votre connexion <tt>term</tt>. <sect2><tt>seyon</tt> Un moyen facile de lancer <tt>linecheck</tt> ou <tt>term</tt> à partir de <tt>seyon</tt> est de les placer dans le menu <it>Transfer</it> (contrôlé par le fichier '<tt>$HOME/.seyon/protocols</tt>'). Dans le fichier '<tt>$HOME/.seyon/protocols</tt>', ajoutez : <verb> "linecheck" "$cd /tmp; linecheck" "term" "$term -c off -w 10 -t 150 -s 38400 -l $HOME/tlog" </verb> Ainsi, lorsque vous voulez lancer <tt>linecheck</tt> ou <tt>term</tt> sur la machine locale, vous pouvez sélectionner le menu <it>Transfer</it>, choisir l'option <it>linecheck</it> ou <it>term</it>, puis <it>Go</it>. Bien entendu, il est toujours possible d'utiliser le bouton <it>shell command</it> et de taper 'linecheck' ou 'term' dans la boîte de dialogue <it>pop-up</it>. Ceci redirige automatiquement l'entrée et la sortie. <sect1>Rendons la liaison transparente Supposons que vous savez établir une connexion modem entre vos machines locale et distante. De façon typique, vous numérotez grâce à un serveur de terminal quelconque pour vous connecter à la machine distante. Vous utilisez également quelque logiciel d'émulation de terminal, tel que <tt>kermit</tt> ou <tt>seyon</tt> pour dialoguer avec votre modem (les exemples fournis dans ce document utilisent <tt>kermit</tt>, puisque c'est ce dont l'auteur se sert). Si vous avez des problèmes avec votre modem ou avec votre logiciel de terminal, reportez-vous au <tt>Serial-HOWTO</tt>, il devrait vous permettre de les régler. Une fois votre liaison établie, il faut la rendre aussi transparente que possible. Etudiez les commandes de votre serveur de terminal (<it>help</it> ou <it>?</it> sont en général un bon début). Choisissez les options 8 bits chaque fois que cela est possible. Il est possible que cela influe sur la façon de vous connecter à un système. Si le serveur utilise <tt>rlogin</tt>, par exemple, il faudra peut-être utiliser l'option <tt>-8</tt> afin de le rendre transparent. Faites particulièrement attention à ne pas utiliser le contrôle de flux <tt>XON/XOFF</tt>. Essayez plutôt d'utiliser le contrôle de flux <tt>RTS/CTS</tt> (<it>hardware</it>). L'étude de la documentation de votre modem vous apprendra certainement comment le configurer pour des communications <tt>RTS/CTS</tt> 8 bits. <sect1>Lançons <tt>linecheck</tt> <bf>ATTENTION :</bf> dans certains documents, les options de <tt>linecheck</tt> sont données dans un ordre incorrect. L'auteur les a contrôlées et en donne ici l'ordre correct. <bf>NOTE :</bf> à partir de la version 2.3.0, il n'est plus nécessaire de fournir à <tt>linecheck</tt> le nom d'un fichier de <it>log</it>. La sortie sera écrite dans le fichier '<tt>linecheck.log</tt>', dans le répertoire d'où <tt>linecheck</tt> a été lancé. <tt>linecheck</tt> est un programme fourni avec <tt>term</tt> qui vérifie la transparence d'une liaison et fournit des informations utiles pour une configuration correcte de <tt>term</tt>. <tt>linecheck</tt> envoie chacun des 256 caractères 8 bits possibles sur la liaison et vérifie que tous ont été transmis correctement. Il faut indiquer à <tt>term</tt> quels caractères ne peuvent pas être transmis sur la liaison, ce que <tt>linecheck</tt> permet de repérer. <tt>linecheck</tt> doit être utilisé une fois que la liaison modem est aussi transparente que possible. Pour lancer <tt>linecheck</tt>, procédez comme suit : <enum> <item> Sur le système distant, lancez : <verb> linecheck linecheck.log </verb> </item> <item> Revenez à votre système local et interrompez votre programme de communication (voir au-dessus).</item> <item> Sur le système local, lancez : <verb> linecheck linecheck.log > /dev/modem < /dev/modem </verb> </item> </enum> Lorsque <tt>linecheck</tt> est terminé, les fichiers '<tt>linecheck.log</tt>' contiennent un ensemble de nombres, placés à la fin. Ce sont les caractères qui doivent être <it>évités</it> dans le '<tt>termrc</tt>' placé à l'autre extrêmité de la liaison. Sur le système de l'auteur, par exemple, le '<tt>linecheck.log</tt>' local ne disait rien et le '<tt>linecheck.log</tt>' distant indiquait d'<it>éviter</it> 29 et 157. C'est pourquoi son '<tt>termrc</tt>' local <it>évite</it> ces caractères, alors que son '<tt>termrc</tt>' distant n'en <it>évite</it> aucun. Si l'on <it>évite</it> des caractères d'un côté, il faut les <it>ignorer</it> de l'autre. C'est pourquoi, l'auteur doit <it>ignorer</it> 29 et 157 sur son système distant. Si <tt>linecheck</tt> se plante, essayez : <verb> linecheck linecheck.log 17 19 </verb> sur le système distant et : <verb> linecheck linecheck.log 17 19 > /dev/modem < /dev/modem </verb> sur le système local. Ceci a pour effet de ne pas envoyer les caractères de contrôle de flux <tt>XON/XOFF</tt> qui plantent votre ligne si vous utilisez un contrôle de flux logiciel. Si cela résoud le problème, <it>évitez/ignorez</it> 17 et 19 dans les deux '<tt>termrc</tt>'. Si votre serveur de terminal est sensible à d'autres caractères, procédez de même. Il est possible d'identifier de tels caractères lorsque <tt>linecheck</tt> se plante : tuez-le puis examinez les fichiers de <it>log</it>. Les derniers caractères transmsis sont de bons coupables potentiels. Essayez à nouveau en <it>évitant</it> ces caractères. En résumé, le '<tt>termrc</tt>' local de l'auteur se présente ainsi : <verb> escape 29 escape 157 </verb> et son '<tt>termrc</tt>' distant ainsi : <verb> ignore 29 ignore 157 </verb> puisque le '<tt>linecheck.log</tt>' <it>distant</it> indiquait <it>d'éviter</it> 29 et 157. <sect1>Essayons de lancer <tt>term</tt> Connectez-vous au système distant et rendez la liaison aussi transparente que possible (si ça n'est déjà fait). Lancez-y <tt>term</tt>, par exemple de la façon suivante : <verb> exec term -r -l $HOME/tlog -s 38400 -c off -w 10 -t 150 </verb> Examinons une à une les options de cette ligne de commande (que nous aurions tout aussi bien pu inclure dans le '<tt>termrc</tt>', mais au prix d'une édition de fichier). <tt>exec</tt> signifie que le programme (<tt>term</tt>, en l'occurence) remplace le <it>shell</it> à partir duquel il est lancé. On utilise <tt>exec</tt> lorsque l'on n'a plus l'intention de se servir du <it>shell</it> concerné; on économise ainsi la mémoire. Cependant, lors de la mise au point de la liaison, il peut être prudent de ne pas faire un <tt>exec</tt>, de façon à pouvoir tuer le <tt>term</tt> distant. L'option <tt>-r</tt> doit être utilisée à une et une seule extrêmité. Celle-ci sera alors vue par <tt>term</tt> comme l'extrêmité distante de la liaison (qui peut donc être votre machine locale). Si cette option n'est pas utilisée d'un côté ou de l'autre, <tt>term</tt> se plantera spontanément. <tt>-l $HOME/tlog</tt> permet de consigner toutes les erreurs dans le fichier '<tt>tlog</tt>', placé dans votre répertoire utilisateur. Celui-ci étant très utile pour les mises au point, il n'y a pas de raison de ne pas utiliser cette option. <tt>-s 38400</tt> : l'auteur dispose d'un modem 14400 <it>bps</it>, avec compression. Afin d'obtenir des taux de compression optimaux, il faut envoyer les bits aussi vite que possible. Pour un modem plus lent, il faut utiliser une valeur plus faible. Notez que si vous possédez une machine <sq>lente</sq> dotée de ports séries disposant d'<tt>UART 16450</tt>, des valeurs de <it>bps</it> trop importantes risquent de provoquer des pertes de données en surchargeant le port série. <tt>term</tt> est capable de corriger ceci, mais si les fichiers de <it>log</it> comportent de nombreux messages d'erreur (ou si vous recevez de nombreux <it>warnings</it> des noyaux <tt>linux</tt> 0.99pl15 ou plus récents), il serait plus sage de diminuer cette valeur. <tt>-c off</tt> : cette option désactive la compression. Lorsque l'on dispose d'un modem qui assure déjà la compression des données, il n'est nul besoin de les compresser une seconde fois. <tt>-w 10 -t 150</tt> : ici encore, cette option permet d'optimiser une liaison modem rapide. La valeur de la fenêtre est 10 et celle du <it>timeout</it> 150, selon les recommendations de la page de manuel de <tt>term_setup</tt>. Revenez sur votre machine locale et interrompez votre programme de communication (voir ci-dessus). Il est préférable qu'il ne tourne pas en même temps que <tt>term</tt>, car il risque d'entrer en conflit avec lui au niveau du port série. Si vous parvenez à convaincre votre programme de communication de ne pas raccrocher la ligne lorsque vous en sortez, vous pouvez le quitter. Il faut maintenant lancer le <tt>term</tt> local : <verb> term -c off -l $HOME/tlog -s 38400 -w 10 -t 150 < /dev/modem > /dev/modem & </verb> Il faut indiquer à <tt>term</tt> où se trouve le modem. C'est pourquoi à la fois l'entrée et la sortie standards sont redirigées vers '<tt>/dev/modem</tt>' (c'est le rôle de <tt><</tt> et <tt>></tt>). Enfin, la commande est lancée en arrière-plan, de façon à pouvoir continuer à utiliser le terminal pour autre chose, si on le souhaite. <tt>term</tt> devrait maintenant fonctionner :-). Essayez un <tt>trsh</tt> et regardez ce qui se produit. Si cela plante ou si votre liaison semble excessivement lente, jetez un coup d'oeil aux fichiers '<tt>tlog</tt>' placés à chaque extrêmité. Contiennent-ils des <it>timeouts</it> ou des messages d'erreur ? Si c'est le cas, quelque chose ne va pas dans votre configuration. Essayez à nouveau (après avoir fini de lire ceci :-)). Notez qu'il est normal que la connexion ne semble pas rapide comme l'éclair, surtout si vous utilisez la compression. Les meilleures performances sont obtenues lors d'échanges tels que le transfert de fichiers. <sect1>Mettre fin à une connexion <tt>term</tt> Il est probable qu'après avoir effectué un certain nombre de travaux, vous souhaiterez mettre fin à votre connexion <tt>term</tt>. Ceci peut être fait de quatre façons : <enum> <item>Tuer les programmes <tt>term</tt> à chaque extrêmité de la liaison. C'est la méthode la moins recommandée.</item> <item>Une méthode un peu plus élégante est de taper la commande suivante sur la machine locale : <verb> echo '00000' > /dev/modem </verb> Ceci devrait mettre fin à votre connexion <tt>term</tt> proprement. Cette méthode fonctionne avec toutes les versions de <tt>term</tt>. Assurez vous que la suite de zéros en contient bien au moins <it>cinq</it>.</item> <item>Dans le '<tt>termrc</tt>' des versions de <tt>term</tt> 2.0.0 et ultérieures, vous pouvez ajouter une entrée <tt>terminate '<une chaîne de caractères>'</tt>. Ceci indique la chaîne qu'utilisera <tt>term</tt> pour s'interrompre ('00000' par défaut). Elle doit être longue d'au moins cinq caractères afin d'éviter toute terminaison intempestive.</item> <item>À partir de la version 1.14, un programme <tt>tshutdown</tt> est fourni (en fait, il s'agit d'un <it>patch</it> pour la version 1.14 et est dans le paquetage pour les versions plus récentes). <tt>tshutdown</tt> permet de mettre fin proprement à votre connexion <tt>term</tt>.</item> </enum> <sect1>Effacer <tt>term</tt> Bien, vous l'aurez voulu ! Puisque certains d'entre vous veulent se débarasser de <tt>term</tt>, nous indiquons ici les étapes à suivre. <itemize> <item>Effacez les répertoires et leur contenu. Suivant la façon dont vous avez installé <tt>term</tt>, un ou plusieurs des répertoires suivants est présent sur votre machine : <verb> $HOME/.term/termrc $HOME/.term/termrc.<server> $HOME/term/termrc $HOME/term/termrc.<server> /usr/local/lib/term/termrc /usr/local/lib/term/termrc.<server> /etc/termrc /etc/termrc.<server> </verb> Vous pouvez effacer simultanément ces répertoires et leur contenu. Pour ce faire, utilisez la commande <tt>rm -rf</tt>. </item> <item>Dans certains cas, vous avez créé un groupe <it>term</it> lors de l'installation. Vérifiez le fichier '<tt>/etc/group</tt>' et effacez la ligne qui concerne ce groupe, si elle s'y trouve.</item> <item>Il faut maintenant effacer le paquetage <tt>term</tt> ainsi que tous les exécutables modifiés pour <tt>term</tt>. C'est la partie la plus délicate. Les exécutables du paquetage de <tt>term</tt> doivent normalement se trouver dans le répertoire '<tt>/usr/local/bin</tt>' ou le répertoire '<tt>$HOME/bin</tt>'. En ce qui concerne les exécutables que vous avez modifiés vous-même pour une utilisation avec <tt>term</tt>, c'est à vous de voir, nous ne pouvons pas vous aider. Pensez également à effacer les fichiers de configuration ou autres qui correspondent à ces programmes.</item> <item>Pour effacer les bibliothèques, lancez les commandes suivantes : <verb> cd / find . -name 'libtermnet*' -exec /bin/rm {} </verb> Ceci localisera et effacera les bibliothèques.</item> <item>Pour effacer le fichier 'termnet.h', le plus simple est de taper : <verb> cd / find . -name termnet.h -exec /bin/rm {} </verb> </item> <item>Si vous avez installé les pages de manuel de <tt>term</tt>, elles doivent se trouver dans l'un des répertoires suivants : <verb> /usr/local/man/man1 /usr/local/man/cat1 $HOME/man/man1 $HOME/man/cat1 </verb> Il vous faut au minimum contrôler la présence des pages de manuel suivantes : <tt>term</tt>, <tt>term_clients</tt>, <tt>term_setup</tt>, <tt>tdownload</tt>, <tt>linecheck</tt>, <tt>trdate</tt>, <tt>trdated</tt>, <tt>termrc</tt>, <tt>termtest</tt>, <tt>tmon</tt>, <tt>tredir</tt>, <tt>trsh</tt>, <tt>tshutdown</tt>, <tt>tudpredir</tt>, <tt>tupload</tt>, <tt>txconn</tt> et finalement <tt>tiptest</tt>.</item> <item>Effacez le répertoire utilisateur temporaire et son contenu. Il s'agit du répertoire '<tt>/usr/tmp/private</tt>'.</item> </itemize> Une fois ce petit exercice terminé, vous pouvez être quasiment certain d'avoir effacé tout ce qui concerne <tt>term</tt>. <sect1>Optimisation de la liaison Une fois que vous avez réussi à faire fonctionner <tt>term</tt>, pourquoi ne pas essayer d'optimiser un peu les choses ? Un bon moyen de mesurer la vitesse de transmission de votre liaison est de lancer <tt>tmon</tt> dans une fenêtre tout en téléchargeant un fichier dans une autre. Essayez avec de gros fichiers de texte et avec des fichiers compressés. Les fichiers textes devraient être transférés environ deux fois plus vite que les fichiers compressés. Les paramètres sur lesquels vous pouvez jouer sont les <it>bps</it><footnote>(N.D.T.) Le document original parle de <it>baud</it>, mais il s'agit d'une erreur commune :-)</footnote> (<tt>-s</tt>), la compression (<tt>-c</tt>), la taille de fenêtre (<tt>-w</tt>), les <it>timeouts</it> (<tt>-t</tt>) et le recyclage (<tt>-A</tt>). Attention au paramètre de recyclage. Avec <tt>term</tt> version 1.19, l'auteur a obtenu une perte de 80% à 90% lorsqu'il a utilisé ce paramètre. Peut-être est-ce une bogue de la version 1.19 et n'est-ce valable que pour cette version. <tt>bps</tt> : il s'agit du nombre maximal de bits que <tt>term</tt> tentera d'envoyer sur la liaison série. <tt>term</tt> évitera d'envoyer des caractères plus rapidement. Par défaut, utilisez la vitesse des ports série de votre ordinateur, mais soyez conscient que cela risque d'être trop rapide si votre modem fonctionne à une vitesse plus faible sur la ligne téléphonique. Cette option est prévue pour les systèmes qui placent les données dans un tampon. Lors de l'installation et de la mise au point, il est conseillé d'utiliser des valeurs faibles plutôt que des valeurs trop importantes. Pour des liaisons à haute vitesse (> 38400), il peut être avantageux de ne pas imposer de limite en utilisant la valeur '<tt>off</tt>'. <tt>term</tt> ne s'appuiera alors que sur le noyau pour effectuer le contrôle de flux. <tt>Compression</tt> : à utiliser si votre modem n'effectue pas lui-même la compression. S'il la fournit, désactivez cette option afin de ne pas compresser deux fois les mêmes données, ce qui <it>augmente</it> à coup sûr le volume de données transmis. Les modems assurant la compression sont ceux qui utilisent les protocoles <tt>MNP-5</tt> ou <tt>V42.bis</tt>. Consultez la documentation de votre modem et les messages qu'il envoie lors d'une connexion. <tt>Fenêtre</tt> : c'est le nombre de paquets de données que <tt>term</tt> accepte d'envoyer sur la liaison avant de recevoir un acquittement de la part du <tt>term</tt> distant. Avec un modem rapide, il peut être avantageux d'augmenter ce paramètre. Pour les liaisons plus lentes, cela risque de surcharger l'extrêmité distante. <tt>Timeout</tt> : il s'agit de la durée pendant laquelle <tt>term</tt> attend un acquittement. Si vous avez augmenté la taille de la fenêtre et obtenez de nombreux <it>timeouts</it> dans vos fichiers de <it>log</it>, essayez d'augmenter ce paramètre. Pour un modem <tt>14400/V42.bis</tt>, l'auteur utilise <tt>-c off -w 10 -t 150</tt> et obtient environ 1700 <it>cps</it> pour les fichiers compressés et 3500 <it>cps</it> pour les fichiers texte, les transfert étant effectués avec <tt>tupload</tt>. <sect1>Problèmes classiques Dans cette partie sont exposées quelques démarches classiques à suivre lorsque l'utilisation de <tt>term</tt> ou de l'un de ses clients vous pose problème. <itemize> <item>Avez-vous bien nettoyé l'arborescence de <tt>term</tt> ? L'apparition de nouvelles versions de <tt>term</tt> est allée de pair avec de nombreuses modifications de l'arborescence '<tt>/usr/local/lib/term</tt>'. Si vous n'êtes pas conscient de cela, vous risquez de voir apparaître de nombreux messages d'erreur. Le mieux dans ce cas est d'effacer l'arborescence '<tt>/usr/local/lib/term</tt>' (en prenant soin de sauvegarder votre '<tt>termrc</tt>') et d'installer ensuite votre nouvelle version de <tt>term</tt>. Ainsi, vous devriez éviter de vous créer des problèmes avec une arborescence inadéquate. </item> <item>Avez-vous effacé les vieilles <it>sockets</it> ? Lors de la mise à jour de <tt>term</tt>, effacez toutes les <it>sockets</it> (appelées '<tt>socket=</tt>') créées par <tt>term</tt>. Ne pas le faire vous expose à d'étranges problèmes. Afin de déterminer à l'écoute de quelle <it>socket</it> se trouve <tt>term</tt>, vous pouvez utiliser le programme <tt>netstat</tt>.</item> <item><tt>term</tt> ne se compile pas corectement sous <tt>SunOS 4.1.3</tt> ? C'est que vous avez probablement configuré <tt>term</tt> avec <tt>./configure --user</tt>. Lors de la compilation, vous voyez apparaître une erreur d'assembleur à propos d'une option '<tt>-k</tt>'. La cause de cette erreur est inconnue. La solution est de configurer <tt>term</tt> avec des bibliothèques statiques. Il vous faut donc utiliser <tt>./configure --user --static</tt> et continuer la compilation de façon normale. Tout devrait alors se dérouler normalement.</item> <item><tt>termtest</tt> vous donne une erreur : '<tt>term: failed to connect to term socket '/root/.term/sockettest'</tt>' ? Lorsqu'il est lancé, <tt>termtest</tt> s'attend à trouver l'exécutable <tt>term</tt> dans le répertoire où il est lui-même. Lorsque vous faîtes un <tt>make install</tt> avant de lancer <tt>termtest</tt>, l'exécutable <tt>term</tt> est déplacé dans '<tt>/usr/local/bin</tt>' (ou dans un autre répertoire d'exécutables). La solution consiste à créer un lien vers l'exécutable dans le répertoire source : <verb> ln -s /usr/local/bin/term /usr/src/term-<numero_version>/term </verb> <item>Lancez-vous bien le bon exécutable ? <tt>term</tt> a été mis à jour à de nombreuses reprises et bon nombre de systèmes en possèdent différentes versions. Assurez-vous d'utiliser la bonne version. Notez que cela s'applique également à <tt>linecheck</tt>. Vous pouvez utiliser la commande <tt>type -a</tt> de <tt>bash</tt> ou bien la commande <tt>whereis</tt> pour déterminer quel est le programme qui est exécuté. Les versions de <tt>term</tt> postérieures à la 1.11 affichent normalement leur numéro de version au démarrage (bien que la 1.14 prétende n'être que la 1.12. Et oui !).</item> <item>Avez-vous mis le bon '<tt>termrc</tt>' au bon endroit ? Suivant les versions de <tt>term</tt> que vous utilisez et la façon dont vous l'avez installé (en tant que <it>root</it> ou en tant qu'utilisateur), ce fichier peut se trouver dans l'un des répertoires suivants : <verb> $HOME/.term/termrc $HOME/.term/termrc.<server> $HOME/term/termrc $HOME/term/termrc.<server> /usr/local/lib/term/termrc /usr/local/lib/term/termrc.<server> /etc/termrc /etc/termrc.<server> </verb> Certains systèmes sont fournis avec des fichiers '<tt>termrc</tt>' pré-installés. Assurez-vous de les avoir détruit avant de procéder à l'installation. Si vous faîtes l'installation en tant que <it>root</it>, vérifiez '<tt>/.term</tt>'. Lors de son exécution, <tt>term</tt> crée des fichiers (qui sont en fait des <it>sockets</it>). C'est pourquoi il possède son propre répertoire '<tt>$HOME/.term</tt>' dans lequel est placé le fichier '<tt>termrc</tt>' (notez qu'il n'y a PAS de . devant '<tt>termrc</tt>' !).</item> <item><tt>term</tt> trouve-t-il son fichier '<tt>termrc</tt>' ? Lorsque vous lancez <tt>term</tt> des deux côtés, vous devriez voir des messages tels que : <verb> term version: 2.2.9 Reading file: /usr/local/lib/term/termrc Using shared mode. </verb> Si la seconde ligne n'apparaît pas, c'est que <tt>term</tt> ne trouve pas le fichier '<tt>termrc</tt>' et vous pouvez être sûr que quelque chose ne s'est pas déroulé normalement lors de l'installation (sauf si vous n'utilisez pas de fichier '<tt>termrc</tt>' et entrez tous les paramètres dans la ligne de commande :-)). Vérifier la localisation et les droits du fichier '<tt>termrc</tt>' sur le système où <tt>term</tt> ne le trouve pas.</item> <item><tt>term</tt> ou votre répertoire '<tt>.term</tt>' est-il monté par <tt>NFS</tt> ? Si tel est le cas, il faut utiliser l'option <tt>-Dterm_NFS_DIR</tt> dans la ligne <tt>CFLAGS</tt> du '<tt>Makefile</tt>'. Malheureusement, en ce qui concerne l'auteur, ce paramètre provoque une erreur de compilation lorsque <tt>term 1.19</tt> est compilé sur une machine sous <tt>SunOS 4.*</tt>.</item> <item>Tous les fichiers et répertoires ont-ils les bons propriétaires et des droits adéquats ? Cela ne devrait pas être un problème dans la mesure où les propriétaires et les droits sont déterminés lors de l'installation. Néanmoins, soyez conscient de ce fait si vous effectuez le portage pour <tt>term</tt> de vos propres applications. Si de plus vous modifier le mode d'exécution de <tt>term</tt> (c'est-à-dire du mode <it>privé</it> vers le mode <it>partagé</it>), il faut changer en conséquence les propriétaires et les droits des fichiers.</item> <item>Si vous obtenez une erreur <tt>gethostbyname: <hostname>: Non-authoritative `host not found'</tt>, ou <tt>server failed</tt>, il vous faut vérifier les points suivants : <enum> <item>Le fichier '<tt>/etc/hosts</tt>' est-il configuré correctement ? Si <tt><hostname></tt> n'est pas le nom de votre machine (les vieilles distributions <it>SLS</it> et les distributions <it>Slackware</it> sont fournies avec '<tt>darkstar</tt>' pour nom de machine, par exemple), il vous faut modifier ce fichier. Il doit au minimum contenir une ligne telle que : <verb> # Local Hosts Format: # IP_NUMBER HOSTNAME ALIASES # # Here is the name of your host, first, followed by any aliases 127.0.0.1 localhost linuxpc.domain linuxpc </verb> </item> <item>Vos fichiers '<tt>/etc/rc*</tt>' et '<tt>/etc/resolv.conf</tt>' sont-ils lisibles (<tt>chmod ugo+r</tt>) ?</item> <item>Vérifez enfin que vous avez installé l'interface <tt>TCP/IP loopback</tt> sur votre machine.</item> </enum> </item> <item>Les fichiers de <it>log</it> de <tt>term</tt> sont remplis de messages '<tt>timed out</tt>' de tous types ? Cela signifie que votre connexion n'est pas optimisée. Quelques messages de ce type de temps en temps ne posent guère de problème. Ils sont sans doute dus à des facteurs temporels influant sur la qualité de la connexion physique entre vos machines locale et distante. Si, en revanche, le nombre de ces messages est très élevé, votre connexion sera fortement ralentie. Il vous faut alors jouer sur les paramètres présentés dans la partie '<it>Optimisation de la liaison</it>'. C'est malheureusement la partie la plus expérimentale de l'installation. Aucune règle définitive concernant les valeurs des paramètres ne peut être donnée, tant les facteurs susceptibles d'influencer la qualité de la connexion sont nombreux. Ces facteurs varient d'une connexion à l'autre et même d'un moment à l'autre pour une même connexion.</item> <item>Un <tt>ftp</tt> normal avec des ports redirigés ne fonctionne pas chez vous ? C'est un problème connu : la redirection des ports requis par <tt>ftp</tt> (les ports 20 et 21) ne permet pas à <tt>ftp</tt> de fonctionner. La seule solution est de récupérer un <tt>ftp</tt> modifié pour fonctionner avec <tt>term</tt>. Malheureusement, même de telles versions de <tt>ftp</tt> semblent ne pas fonctionner.</item> </itemize> <sect>Les clients <tt>term</tt> Un certain nombre d'utilitaires sont fournis dans le paquetage <tt>term</tt>, en particulier : <tt>trsh</tt>, <tt>tmon</tt>, <tt>tupload</tt>, <tt>tredir</tt>, <tt>txconn</tt> et, dans les versions les plus récentes, <tt>trdate</tt> et <tt>trdated</tt>. De plus, depuis la version 2.1.0, <tt>tdownload</tt> s'est ajouté à cette liste. Cette partie traite de <tt>trsh</tt>, <tt>tmon</tt>, <tt>tupload</tt>, <tt>tdownload</tt>, <tt>trdate</tt> et <tt>trdated</tt>. Les autres clients sont décrits dans des parties qui leur sont propres. Aucun client <tt>term</tt> ne peut fonctionner tant que vous n'avez pas mis en route une liaison <tt>term</tt>. <tt>tmon</tt> est un utilitaire simple qui vous permet de surveiller les performances de votre liaison. Il imprime un histogramme des caractères envoyés et reçus. On le lance par la simple commande <tt>tmon</tt>. Attention, les versions 1.11 et ultérieures comportent une bogue qui tronque certaines données. <tt>trsh</tt> est similaire à <tt>rsh</tt>. Sans argument, il lance un <it>shell</it> interactif sur le système distant (autrement dit, il vous y loge). <tt>trsh</tt> est un des moyens de base pour accéder à l'extrémité distante de la liaison <tt>term</tt>. Si un argument est passé, celui-ci est exécuté comme commande sur le système distant. Par exemple : <verb> trsh ls </verb> renvoie la liste des fichiers de votre répertoire utilisateur (<tt>$HOME</tt>) sur le système distant. <tt>tupload</tt> transfère un fichier dont le nom est passé en argument d'une extrémité à l'autre de la liaison. Par défaut, ce fichier est placé dans le répertoire d'où vous avez lancé <tt>term</tt> (de l'autre côté de la liaison). Pour placer les fichiers dans un autre répertoire, donnez son nom comme second argument. Par exemple, si vous souhaitez copier le fichier '<tt>term114.tar.gz</tt>' dans le répertoire '<tt>/usr/tmp</tt>' de la machine distante, tapez : <verb> tupload term114.tar.gz /usr/tmp </verb> Lorsque vous utilisez <tt>tupload</tt>, vous avez à votre disposition des <it>jokers</it> comme, par exemple, dans la commande '<tt>tupload a.*</tt>'. Le <it>shell</it> se charge d'effectuer les correspondances et la commande effectivement exécutée est '<tt>tupload a.1 a.2 ......</tt>'. <tt>tdownload</tt> permet le transfert d'un fichier dont le nom est passé en argument de la machine distante vers la machine locale. Par défaut, les fichiers seront placés dans le répertoire duquel vous avez lancé <tt>term</tt> sur la machine locale. Pour placer les fichiers dans un autre répertoire, passez son nom comme second argument à <tt>tdownload</tt>. Par exemple, si vous souhaitez copier le fichier '<tt>term114.tar.gz</tt>' dans '<tt>/usr/tmp</tt>' sur la machine locale, tapez : <verb> tdownload term114.tar.gz /usr/tmp </verb> Il n'est PAS possible d'utiliser les <it>jokers</it> avec <tt>tdownload</tt> pour la simple raison que le répertoire distant n'est pas accessible au <it>shell</it> et que toute expansion de <it>jokers</it> se réfère au répertoire courant sur la machine locale (où est exécuté le <it>shell</it>). <tt>trdate</tt> est un utilitaire qui lit l'heure sur la machine distante et la modifie en conséquence sur la machine locale. Il doît être exécuté en tant que <it>root</it>. <tt>trdated</tt> est la version démon de <tt>trdate</tt>. Lorsqu'il est lancé dans '<tt>rc.local</tt>', il est exécuté comme un démon et met l'heure à jour toues les 5 minutes (par défaut). <tt>trdated</tt> fonctionne même si aucune connexion <tt>term</tt> n'est active; il commence à modifier l'heure dès que la connexion est effectivement établie. <sect>X et <tt>term</tt> <tt>term</tt> permet à plusieurs utilisateurs d'ouvrir des fenêtres <it>X windows</it> sur la machine locale, à partir de clients s'exécutant sur une machine du réseau. C'est le rôle de <tt>txconn</tt>, qui est lancé sur le système distant par la simple commande <tt>txconn</tt>. Il se place en arrière-plan et renvoie un nombre sur la sortie standard. Ce nombre est le numéro de <it>display</it> que doivent utiliser les clients pour accéder au serveur <tt>X</tt> de la machine locale. Voici un exemple qui devrait clarifier les choses. Nous sommes connectés via <tt>trsh</tt> à l'hôte <tt>term</tt> distant, nommé <tt>toto</tt>. Sur <tt>toto</tt>, nous lançons les commandes suivantes : <verb> toto$ txconn Xconn bound to screen 10 :10 toto$ </verb> Désormais, sur chaque hôte dont nous voulons qu'il exécute un client <tt>X</tt> et envoie l'affichage sur la machine locale, il suffit de faire : <verb> setenv DISPLAY toto:10 </verb> (en <tt>bash</tt> utiliser <tt>export DISPLAY=toto:10</tt>). Dans certains cas, il sera de plus nécessaire de faire un : <verb> xhost + toto </verb> ou même un : <verb> xhost + </verb> sur la machine locale. Maintenant, à chaque fois que nous démarrons un client, il tente de se connecter au <it>display</it> 10 de la machine <tt>toto</tt>. Comme <tt>txconn</tt> est à l'écoute de ce <it>display</it> et retransmet tous les paquets du protocole <tt>X</tt> vers le serveur <tt>X</tt> de la machine locale, via <tt>term</tt>, la fenêtre s'ouvrira sur la machine locale. Il est également possible de faire le contraire, à savoir de lancer un client sur la machine locale et d'envoyer l'affichage sur la machine distante. Nous ne détaillerons cependant cette procédure qu'après avoir présenté <tt>tredir</tt>. Le protocole <tt>X</tt> n'est pas particulièrement efficace et gaspille une grande largeur de bande. C'est rarement un problème dans le cas d'un réseau <it>éthernet</it>, mais cela devient désastreux pour une liaison par modem. Il paraît que <tt>X11R6</tt> met en place une version à faible largeur de bande du protocole, <tt>LBX</tt>. Si cependant vous utilisez <tt>X11R5</tt>, vous pouvez avoir recours à un utilitaire appelé <tt>sxpc</tt> qui compresse le protocole <tt>X</tt> et améliore ainsi les temps de réponse lors de l'utilisation de liaisons séries. Le paquetage <tt>sxpc</tt> contient un article sur son fonctionnement avec <tt>term</tt> et en est d'autant plus recommandé. <sect><tt>tredir</tt> <tt>tredir</tt> est l'un des utilitaires les plus puissants parmi ceux fournis avec <tt>term</tt>. Il permet d'utiliser avec <tt>term</tt> les plus importants services réseau. Avant d'en expliquer l'usage, il est nécessaire de donner quelques bases sur le fonctionnement de ces services. Nous les avons déjà évoqués, mais sans expliquer précisément en quoi ils consistent. Comme leur nom l'indique, ce sont des services qui sont fournis par le réseau. Des exemples de tels services sont : <tt>telnet</tt> qui permet de se <it>loger</it> sur une machine à partir d'une autre, le protocole de transfert de fichiers <tt>ftp</tt> qui permet l'envoi de fichiers entre machines et <tt>smtp</tt> (<it>Simple Mail Transfer Protocol</it>) qui est sollicité à chaque fois que vous envoyez du courrier électronique. Chaque service réseau est associé à un numéro de port. L'affectation des numéros de ports aux différents services est donnée par le fichier '<tt>/etc/services</tt>' qui doit être identique sur toutes les machines reliées à un même réseau. Comment ces services sont-ils appelés ? Sur chaque machine du réseau tourne un démon nommé <tt>inetd</tt> qui est à l'écoute des tentatives de connexion sur les ports réseau. Ces tentatives proviennent soit du réseau, soit de la machine locale. On obtient un service réseau donné en se connectant au port <tt>inetd</tt> adéquat. Lorsqu'une requête de service réseau est envoyée, <tt>inetd</tt> sait exactement quel service est demandé grâce au numéro du port sollicité. S'il est configuré pour, il fournit alors le service adapté à la connexion qui le demande. La configuration d'<tt>inetd</tt> est donnée par le fichier '<tt>/etc/inetd.conf</tt>' qui contient la liste des services fournis. Pour plus d'informations, reportez-vous aux pages de manuel d'<tt>inetd</tt> et <tt>inetd.conf</tt>. Il est possible de communiquer directement avec les services réseau en utilisant <tt>telnet</tt> (et non <tt>termtelnet</tt> ). Par exemple, pour dialoguer avec le démon <tt>sendmail</tt> (<tt>smtp</tt>) de la machine <tt>nom_de_la_machine</tt>, vous pouvez utiliser <tt>telnet nom_de_la_machine smtp</tt> ou bien <tt>telnet nom_de_la_machine 25</tt> (puisque 25 est le numéro de port affecté à <tt>smtp</tt> dans '<tt>/etc/services</tt>'). Vous devriez alors recevoir un gentil message de bienvenue de la part du démon de la machine distante. C'est une astuce très utile pour résoudre les problèmes réseau et contrôler les ports redirigés par <tt>tredir</tt> (voir ci-après). <tt>tredir</tt> fonctionne de façon très similaire à <tt>inetd</tt>. Il s'exécute en arrière-plan comme un démon et est à l'écoute des différents ports, dans l'attente d'une requête. Lors qu'une demande de service est faite, plutôt que de fournir ce service comme le fait <tt>inetd</tt>, <tt>tredir</tt> retransmet la requête au <tt>term</tt> distant qui transmet la requête au réseau et renvoie le résultat à la machine locale. <tt>tredir</tt> peut envoyer la requête à n'importe quelle machine du réseau, mais la dirige par défaut vers la machine placée à l'autre extrémité de la liaison <tt>term</tt>. <tt>tredir</tt> REDIRige les services réseau <tt>TCP</tt> (<it>Transimssion Control Protocol</it>). La syntaxe classique de <tt>tredir</tt> est la suivante : <verb> tredir [cet_ordinateur_ci:]port [cet_ordinateur_la:] port </verb> Un exemple devrait clarifier tout ceci. Redirigeons un port local sur le port <tt>telnet</tt> de la machine distante. Pour ce faire, nous utilisons : <verb> tredir 2023 23 </verb> Maintenant, quiconque se connecte au port 2023 de la machine locale sera redirigé vers le port 23 (<tt>telnet</tt>) de la machine distante. Voici un exemple de session où la machine locale est <tt>ma_machine.modem.maison</tt> et la machine distante se nomme <tt>netsun</tt>. <verb> $ tredir 2023 23 Redirecting 2023 to 23 $ telnet localhost 2023 Trying 127.0.0.1... Connected to ma_machine.modem.maison Escape character is '^]'. SunOS UNIX (netsun) login: </verb> Cet exemple est particulièrement utile. Si nous avions fait le <tt>tredir</tt> sur <tt>netsun</tt>, nous pourrions alors faire un <tt>telnet</tt> vers <tt>ma_machine</tt> depuis le réseau, simplement en nous connectant au port redirigé de <tt>netsun</tt>, <it>i.e.</it> <tt>telnet netsun 2023</tt>. Le principe général de l'utilisation de <tt>tredir</tt> est de rediriger le service souhaité vers une machine du réseau. L'exemple suivant nous permet de lire les <it>news</it> sur la machine locale à partir d'un serveur de <it>news</it> du réseau, en utilisant la liaison <tt>term</tt>. Les <it>news</it> sont fournies par le service <tt>nntp</tt> dont le numéro de port est le 119. Tout lecteur de <it>news</it> digne de ce nom vous permet de spécifier le numéro de port à utiliser, grâce à un fichier de configuration ou une variable d'environnement. Donnons à ce port local le numéro 2119 et supposons maintenant que notre serveur de <it>news</it> est <tt>news.domain.org</tt>. Nous allons rediriger le port 2119 vers le port 119 de <tt>news.domain.org</tt>, puis nous indiquerons à notre lecteur de <it>news</it> que le serveur <tt>nntp</tt> se trouve sur le port 2119 de la machine locale. Etant donné que cela dépend du lecteur de <it>news</it> utilisé, nous allons juste tester la liaison avec <tt>telnet</tt> plutôt que de vraiment lancer un tel programme. <verb> $ tredir 2119 news.domain.org:119 Redirecting 2199 to news.domain.org:119 $ telnet localhost 2119 Trying 127.0.0.1... Connected to ma_machine.modem.maison. Escape character is '^]'. 200 news.domain.org InterNetNews NNRP Server INN 1.4 07-Dec-41 ready (posting ok). </verb> Si vous parvenez jusqu'ici, tout ce qu'il vous reste à faire est de configurer votre lecteur de <it>news</it> pour être capable de lire les <it>news</it> via <tt>term</tt>. N.B. : si vous lisez les <it>news</it> de cette façon, soyez certain que dans tous vos envois, vous spécifiez dans la ligne d'en-tête <tt>Reply-To:</tt> une adresse <it>email</it> du réseau à laquelle on peut vous joindre, sinon les gens qui voudront vous contacter enverront leur courrier à l'adresse (fantaisiste) constituée des données quelconques que votre lecteur de <it>news</it> placera dans la ligne d'en-tête <tt>From:</tt>. <sect1><tt>tredir</tt> : Attention, chien méchant ! Le lecteur astucieux, après avoir lu le dernier exemple, se demandera certainement pourquoi le port 2119 a été redirigé vers le port 119. Etant donné que les programmes de lecture de <it>news</it> utilisent par défaut le port 119, pourquoi ne pas faire un <tt>tredir 119 news.domain.org:119</tt> et éviter la configuration du lecteur ? La réponse est que tous les ports de numéro inférieur à 1024 sont des ports <it>réservés</it>, à l'écoute desquels seuls un super-utilisateur peut se mettre. Si vous prenez le risque de <it>suider</it> <tt>tredir</tt> ou si vous le lancez en tant que <it>root</it>, vous pourrez alors rediriger les ports réservés et éviter de vous casser les pieds avec les services restants. Un autre inconvénient de l'utilisation des ports réservés est qu'<tt>inetd</tt> les écoute fréquemment et qu'un port ne peut être écouté que par un seul programme à la fois. Afin d'utiliser un tel port, il vous faut modifier le fichier <tt>inetd.conf</tt> de façon qu'<tt>inetd</tt> ne soit plus à l'écoute du port que vous souhaitez rediriger. Pour ce faire, commentez la ligne du service incriminé, en plaçant un # au début de cette ligne. Le super-utilisateur doit alors envoyer un signal HUP à <tt>inetd</tt> pour qu'il relise son fichier de configuration. <sect1>Quelques astuces <tt>tredir</tt> Dans cette partie, nous allons présenter quelques-unes des utilisations les plus courantes de <tt>tredir</tt>. Nous avons déjà indiqué comment rediriger les services <tt>nntp</tt> et <tt>telnet</tt> et allons maintenant passer à des exemples un peu plus compliqués. <sect2><tt>X Windows</tt> Dans une précédente partie, nous avons expliqué comment permettre à un client s'exécutant sur le réseau d'ouvrir une fenêtre sur la machine locale, grâce à <tt>txconn</tt>. La même technique peut être utilisée sur votre machine locale pour qu'un client envoie son affichage vers l'autre extrémité de la liaison <tt>term</tt>. Mais comment afficher un client <tt>X</tt> sur une machine qui n'est pas l'autre bout de la liaison ? La réponse réside dans la connaissance du fait qu'<tt>X</tt> utilise un service réseau particulier, à l'instar des autres programmes que nous avons évoqués. Un serveur <tt>X</tt> est à l'écoute de requêtes réseau sur un port dont le numéro est donné par la formule : <f>port = 6000 + numero_de_display</f>. Par exemple, un serveur <tt>X</tt> gérant le <it>display</it> 0 sur une machine donnée sera à l'écoute du port 6000. S'il gère le <it>display</it> 2, il écoutera le port 6002. Lorsque vous positionnez votre variable d'environnement <tt>DISPLAY</tt> sur <tt>machine:n</tt>, vos clients <tt>X</tt> tenteront de se connecter au port <f>6000 + n</f> de <tt>machine</tt>. Nous pouvons utiliser cette astuce pour permettre à des clients <tt>X</tt> de votre machine locale d'ouvrir des fenêtres sur des <it>displays</it> distants. Supposons que nous voulons lancer un <tt>xterm</tt> tournant sur la machine locale avec l'affichage sur le <it>display</it> 0 de la machine <tt>xmachine</tt>, qui est quelque part sur le réseau. Premièrement, choisissons un numéro de <tt>display</tt> : 2, par exemple (n'utilisez pas 0, c'est celui que votre serveur <tt>X</tt> local utilise). Faisons-en le <it>display</it> 0 de <tt>xmachine</tt>. En termes de ports, cela signifie qu'il nous faut rediriger le port local 6002 vers le port distant 6000. Les commandes sont les suivantes : <verb> $ tredir 6002 xmachine:6000 $ setenv DISPLAY localhost:2 $ xterm </verb> Ceci devrait ouvrir un <tt>xterm</tt> sur la machine <tt>xmachine</tt>. Notez que nous avons positionné <tt>DISPLAY</tt> sur <tt>localhost:2</tt>. La justification en est que les clients <tt>X</tt> utilisent parfois des <it>sockets unix domain</it> plutôt que des <it>sockets internet domain</it> lorsqu'ils se connectent à un <it>display</it> local (lorsque <tt>DISPLAY</tt> contient <tt>:2</tt>, par exemple). <tt>localhost:2</tt> demande l'utilisation d'une connexion <tt>TCP</tt>. En ce qui concerne <tt>xmachine</tt>, la requête <tt>X</tt> provient de la machine placée à l'extrémité distante de votre liaison <tt>term</tt> (<tt>remotemachine</tt>). C'est pourquoi, si vous voulez autoriser la connexion, vous devez utiliser soit <tt>xhost + remotemachine</tt> sur <tt>xmachine</tt>, soit <tt>xauth</tt> pour mettre à jour le fichier <tt>.Xauthority</tt> de votre machine locale pour le <it>display</it> 2, en utilisant la clé de <tt>xmachine</tt>. Une fois encore, pour accélérer les connexions <tt>X</tt>, vous pouvez utiliser le programme <tt>sxpc</tt> pour établir la liaison. <tt>sxpc</tt> contient des explications sur la façon d'utiliser <tt>tredir</tt> et de l'autoriser, en utilisant <tt>xauth</tt>. <sect2><tt>term</tt> et le <tt>mail</tt> Bien, vous l'aurez voulu ! Le courrier électronique a la réputation justifiée d'être l'un des services les plus difficiles à mettre en place sur les machines <tt>UNIX</tt>. Faire fonctionner <tt>term</tt> avec le courrier électronique implique une bonne compréhension des mécanismes de ce dernier, ce qui déborde largement le cadre de ce document. Pour en savoir plus sur le courrier électronique, procurez-vous un ouvrage sur l'administration de systèmes <tt>UNIX</tt> et/ou le <tt>FAQ</tt> (<it>frequently asked questions</it>) du <it>newsgroup</it> <tt>comp.mail.misc</tt>, disponible par <tt>ftp</tt> anonyme sur <tt>rtfm.mit.edu</tt>, dans le répertoire '<tt>/pub/usenet/comp.mail.misc</tt>'. Il existe actuellement deux paquetages qui vous permettront d'utiliser le courrier électronique avec <tt>term</tt>. Tous deux sont accessibles par <tt>ftp</tt> anonyme sur <tt>sunsite.unc.edu</tt>. Il s'agit de <tt>term.mailerd+mail</tt> de Byron A. Jeff et de <tt>BCRMailHandlerXXX</tt> de Bill C. Riemers. Ceci étant dit, voici une description succinte de la façon dont le courrier électronique fonctionne. Deux parties sont à considérer : l'envoi et la réception de messages. Commençons par envoyer des messages de votre machine locale vers le réseau. Il y a deux sortes de programmes de courrier électronique. Les premiers sont appelés <tt>MUA</tt> (<it>mail user agent</it>) et permettent de lire, composer et envoyer des messages. Parmi les <tt>MUA</tt> les plus connus, on trouve <tt>elm</tt> , <tt>pine</tt>, <tt>Mail</tt> et <tt>vm</tt>. Les <tt>MUA</tt> ne font aucun travail de réseau, ils se contentent d'assembler les messages. Le vrai travail d'envoi des messages est réalisé par le second type de programmes, à savoir les <tt>MTA</tt> (<it>mail transfer agents</it>) qui sont appelés par les <tt>MUA</tt>. Ils prennent les messages, décident de l'endroit où il faut les envoyer (en fonction de l'adresse fournie) et les envoient effectivement sur le réseau. Les deux <tt>MTA</tt> les plus courants sur les systèmes <tt>Linux</tt> sont <tt>sendmail</tt> et <tt>smail</tt>. L'idée de base et de faire se connecter votre <tt>MTA</tt> à un autre <tt>MTA</tt> tournant sur une machine du réseau, laquelle saura quoi faire de vos messages. Pour cela, il faut rediriger un port local sur le port <tt>smtp</tt> de la machine placée sur le réseau. Ensuite, indiquez à votre <tt>MTA</tt> qu'il doit envoyer à celui du réseau tout message qu'il ne sait pas traiter. Celui-ci saura alors comment envoyer le message vers sa destination. Comment cela se passe-t-il avec <tt>smail</tt> ? Tout d'abord, on redirige un port vers le port <tt>smtp</tt> de la machine du réseau (<tt>mailhost</tt>) : <verb> tredir XXXX mailhost:25 </verb> où XXXX est le numéro du port local auquel <tt>smail</tt> va se connecter (notez qu'il est nécessaire de donner un nom à ce port dans le fichier '<tt>/etc/services</tt>' pour que <tt>smail</tt> le reconnaisse). <tt>smail</tt> possède plusieurs fichiers de configuration généralement placés dans '<tt>/usr/local/lib/smail</tt>'. Ceux qui nous intéressent sont '<tt>config</tt>', '<tt>routers</tt>' et '<tt>transports</tt>'. Notez bien que nous supposons que vous avez déjà configuré <tt>smail</tt> correctement pour traiter vos messages locaux. Une fois de plus, consultez la documentation si ça n'est pas le cas. Dans le fichier '<tt>config</tt>', il faut placer la définition suivante : <verb> smart_path=localhost </verb> <tt>localhost</tt> étant la machine à laquelle <tt>smail</tt> se connecte lorsqu'il ne sait pas quoi faire d'un message. Dans le fichier '<tt>routers</tt>', ajoutez : <verb> smart_host: driver=smarthost, transport=termsmtp; path = localhost </verb> Enfin, ajoutez dans '<tt>transports</tt>' : <verb> termsmtp: driver=tcpsmtp, inet, return_path, remove_header="From", append_header="From: VOTRE_ADRESSE_RESEAU", -received, -max_addrs, -max_chars; service=VOTRE_SERVICE_SMTP, </verb> Dans les quelques lignes ci-dessus, les lignes d'en-tête (<it>header</it>) changent tous les en-têtes des messages qui partent de chez vous en l'adresse <tt>VOTRE_ADRESSE_RESEAU</tt>, qui est l'adresse réseau à partir de laquelle vous voulez que les messages semblent être envoyés. Si plusieurs utilisateurs utilisent votre liaison <tt>term</tt>, il vous faudra avoir recours à quelque chose de plus acrobatique, comme maintenir une base de données des adresses réseau des utilisateurs locaux et les insérer dans les en-têtes <tt>From:</tt>. La ligne <tt>service</tt> est le nom du port local que vous avez redirigé vers le port <tt>smtp</tt> de la machine connectée au réseau. Avec la version de <tt>smail</tt> qu'utilise l'auteur, il est impossible d'utiliser juste un nombre. Il est nécessaire de mettre un nom tel que <sq>toto</sq> et de définir <sq>toto</sq> dans le fichier '<tt>/etc/services</tt>' comme étant le numéro du port redirigé. Si vous utilisez un <tt>tredir</tt> <it>suidé</it> et ne faites que rediriger le port <tt>smtp</tt> (25), il n'est nul besoin de définir ce <sq>toto</sq>. Cela devrait suffire pour vous mettre sur la voie. Si vous décidez d'utiliser <tt>sendmail</tt>, les principes sont les mêmes, bien que les détails diffèrent. Ronald Florence (<tt>ron@mlfarm.com</tt>) a affirmé à l'auteur que le <tt>sendmail</tt> de <tt>SUN</tt> ne peut envoyer une file de plusieurs messages vers le port redirigé, mais que le <tt>sendmail BSD 8.6.9</tt> fonctionne correctement. Ronald a appliqué à <tt>sendmail</tt> les modifications suivantes de façon à le faire fonctionner avec <tt>term</tt>. Dans son cas, le port <tt>sendmail</tt> par défaut (25) est utilisé pour le trafic local d'un réseau <it>éthernet</it> et le courrier électronique <it>Internet</it> est donc transmis à un port <tt>TCP</tt> redirigé. <verb> # # Creation du mailer termsmtp qui envoie le courrier via un port TCP redirige # Mtermsmtp,P=[TCP], F=mDFMuCXe, S=22, R=22, A=TCP $h PORTNUMBER </verb> Ici, <tt>PORTNUMBER</tt> est le numéro du port redirigé de la machine locale. Cela doit être un port inutilisé de numéro supérieur à 2000. Il faut ensuite indiquer à <tt>sendmail</tt> à quelle machine se connecter et faire de <tt>termsmtp</tt> le <it>mailer</it> par défaut. <verb> # # Principal mailer de relai # DMtermsmtp # # Principal hote de relai : utilise le mailer $M pour envoyer # le courrier vers d'autres domaines # DR HOSTNAME CR HOSTNAME </verb> Où <tt>HOSTNAME</tt> est le nom de votre machine locale (est-ce que <tt>localhost</tt> fonctionne ?). La dernière ligne suit la règle 0 pour retransmettre le courrier <it>Internet</it>. <verb> # Envoyer les autres noms valides au forwarder R$*<@$*.$+>$* $#$M $@$R $:$1<@$2.$3>$4 user@any.domain </verb> Lorsque la connexion <tt>term</tt> avec l'hôte <it>Internet</it> est établie, lancez les commandes suivantes sur la machine locale. <verb> tredir PORTNUMBER internet.host:25 /usr/lib/sendmail -q </verb> Nous allons maintenant nous préoccuper de recevoir du courrier électronique à l'aide de <tt>term</tt>. Nous supposerons que le courrier est envoyé à votre compte sur la machine <tt>mailhost</tt> connectée au réseau. La solution la plus simple est d'utiliser <tt>trsh</tt> ou <tt>termtelnet</tt> pour se connecter à <tt>mailhost</tt> et d'y lire votre courrier. Il est cependant possible de télécharger automatiquement votre courrier sur la machine locale, grâce à <tt>POP</tt> (<it>post office protocol</it>). <tt>POP</tt> a été précisément conçu dans ce but : envoyer le courrier électronique à des machines n'ayant que des accès intermittents au réseau. Pour utiliser <tt>POP</tt>, il faut qu'il y ait un serveur <tt>POP</tt> installé sur <tt>mailhost</tt>. Si tel est le cas, vous pouvez utiliser un client <tt>POP</tt> pour télécharger votre courrier régulièrement. Comme on pouvait s'y attendre, <tt>tredir</tt> joue un rôle dans la procédure. Le port utilisé par le service <tt>POP</tt> est le 110 (<it>n.b.</it> il existe un ancien protocole <tt>POP-2</tt> qui utilise le port 109. Nous parlons ici de <tt>POP-3</tt> qui est la dernière version de <tt>POP</tt>). Plusieurs clients <tt>POP</tt> sont disponibles. L'un d'eux, écrit en langage <tt>perl</tt> par William Perry et maintenu par l'auteur, est <tt>pop-perl-1.X</tt>. On peut le trouver sur <tt>sunsite</tt> dans <tt>/pub/Linux/system/Mail</tt>. Pour utiliser <tt>POP</tt>, il faut rediriger un port local vers le port 110 de <tt>mailhost</tt> et configurer le client de façon à ce qu'il récupère le courrier sur <tt>localhost</tt> en utilisant le port local. Supposons par exemple qu'il y a un serveur <tt>POP</tt> qui tourne sur <tt>mailhost</tt>. Nous redirigeons le port local 2110 et lançons le client <tt>pop-perl</tt>. <verb> $ tredir 2110 mailhost:110 Redirecting 2110 to mailhost:110 $ pop Username: bill Password: <votre mot de passe pour mailhost> Pop Host: localhost Pop Port: 2110 Starting popmail daemon for bill </verb> Si vous n'avez pas de serveur <tt>POP</tt> à votre disposition, le paquetage <tt>BCRMailHandler</tt> contient un programme permettant de télécharger le courrier électronique vers votre machine locale grâce à <tt>term</tt>. L'auteur ne l'a jamais utilisé, mais quiconque le possède est encouragé à le commenter. Vous pouvez également utiliser le paquetage <tt>term.mailerd+smail</tt>. Malheureusement, aucun de ces deux paquetages ne fonctionne avec les versions 2.0.0 et ultérieures de <tt>term</tt>. <sect><tt>tudpredir</tt> <tt>tudpredir</tt> est très semblable à <tt>tredir</tt> dans ce qu'il fait et dans la façon dont il est exécuté. La grosse différence entre les deux programmes est que l'un (<tt>tredir</tt>) sert à rediriger vers la connexion <tt>term</tt> les services réseau <tt>TCP</tt>, alors que l'autre (<tt>tudpredir</tt>) permet de rediriger les services réseau <tt>UDP</tt> (<it>User Datagram Protocol</it>). Une autre différence importante est que <tt>tredir</tt> se place automatiquement en arrière-plan une fois qu'il a établi la communication avec le port local, alors que <tt>tudpredir</tt> doit être mis en arrière-plan manuellement. La syntaxe classique de la commande <tt>tudpredir</tt> est : <verb> tudpredir [cette_machine_ci:]port [cette_machine_la:]port </verb> <sect>Automatisations Maitenant que vous savez comment obtenir de <tt>term</tt> tous vos services réseau, il peut être agréable de mettre en place une initialisation et une configuration automatiques de votre connexion. Il y a à peu près une infinité de façons d'y parvenir, selon le programme de communication que vous utilisez et la façon dont vous vous connectez au système distant. Il existe un programme que l'auteur n'a pas utilisé, mais dont il a entendu dire le plus grand bien. Il s'agit de <tt>fet</tt>, un frontal pour <tt>term</tt>. Il est conçu pour vous connecter à un système distant et lancer <tt>term</tt> et tous vos <tt>tredir</tt>. Tout commentaire sur <tt>fet</tt> est le bienvenu. Voici maintenant un exemple d'un ensemble de commandes qui utilise <tt>kermit</tt> pour se connecter au système distant et effectuer toutes les initialisations de <tt>term</tt>. Il est clair qu'il vous faudra modifier ces exemples pour les adapter à votre procédure de connexion. La commande qui est effectivement lancée est le script shell 'knet' : <verb> #!/bin/sh /usr/bin/kermit -y $HOME/.kerm_term > $HOME/klog < /dev/null 2>&ero 1 exec $HOME/bin/tstart >> $HOME/klog 2>&ero 1 </verb> Le script '.kerm_term' est le suivant : <verb> pause 2 # Le numero a composer output atdtXXXXXXX \13 # Connexion au serveur de terminal input 145 {name: } output MYNAME \13 input 3 {word: } output MYPASSWORD \13 input 5 {xyplex>} # Rendre la ligne transparente output term telnet-t \13 output term stopb 1 \13 # Connexion au systeme distant. output telnet hotedistant.domainequelconque.org \13 input 10 {ogin: } output MYOTHERNAME \13 input 3 word: output MYOTHERPASSWORD \13 pause 5 # On lance le term distant output exec term -s 38400 -l $HOME/tlog -w 10 -t 150 \13 ! /usr/bin/term -r -l $HOME/tlog -s 38400 -c off -w 10 -t 150 < /dev/modem > /dev/modem & # Lancer les autres clients ici si necessaire suspend !killall -KILL term </verb> Finalement, le script 'tsart' qui lance les clients <tt>term</tt> est le suivant : <verb> #!/bin/sh # # Ceci permet au courrier electronique de sortir. # On peut lire les news ici et recuperer le courrier . # /usr/local/bin/tredir 2025 25 2119 newshost:119 2110 pophost:110 # # On peut lancer X windows ici # /usr/local/bin/trsh -s txconn # # Pour recevoir le courrier electronique... # /usr/local/bin/pop # # On vide la queue... # /usr/bin/runq # # La, c'est fini. # echo ^G^G > /dev/console </verb> Lorsqu'enfin vous souhaitez terminer la connexion, revenez à <tt>kermit</tt> et quittez-le. La dernière ligne du <it>script</it> tue le <tt>term</tt> local et replace le système dans son état initial. (<tt> Note de l'auteur : plutôt que de faire '!killall -KILL term', il devrait être possible de faire un '!tshutdown'. Cela devrait également marcher, non ?</tt>) Comme nous l'avons déjà dit, il y a des zillions de façons de procéder. Ces exemples ne sont fournis que pour vous aider à démarrer. D'autres exemples peuvent être trouvés dans les paquetages <tt>autoterm</tt> et <tt>JoeltermStuff</tt>. <sect>Portage de logiciels pour une utilisation avec <tt>term</tt> En principe, tout programme pouvant être utilisé avec un réseau peut également l'être avec <tt>term</tt>. Certains d'entre eux peuvent être obtenus avec un support <tt>term</tt> intégré. En font partie : <tt>telnet</tt>, <tt>(nc)ftp</tt>, <tt>Mosaic</tt> et nombre d'autres. La plupart de ces programmes ont été compilés pour les versions de <tt>term</tt> 1.17 et antérieures; ils devraient cependant continuer à fonctionner avec les versions de <tt>term</tt> plus récentes. Une autre façon de faire fonctionner des programmes avec <tt>term</tt> est d'en assurer vous-même le portage. C'est le sujet dont traite cette partie. Le dernier moyen de modifier vos programmes pour <tt>term</tt> est de les <tt>termifier</tt>. <sect1>Portage et compilation des sources Le portage pour <tt>term</tt> peut être réalisé selon une procédure relativement simple : Si le programme doit être installé dans '<tt>/usr/local</tt>' par <it>root</it> : <enum> <item> Ajoutez le paramètre de compilation <tt>-include /usr/local/include/termnet.h</tt></item> <item> et ajoutez <tt>-ltermnet</tt> à la liste de bibliothèques.</item> </enum> S'il doit être installé dans votre répertoire utilisateur : <enum> <item> Ajoutez le paramètre de compilation <tt>-include $HOME/term/termnet.h</tt></item> <item> et ajoutez <tt>-L$HOME/term -ltermnet</tt> à la liste de bibliothèques.</item> </enum> Compilez maintenant le logiciel comme l'indique le document '<tt>INSTALL</tt>' ou '<tt>README</tt>' fourni avec. Cela devrait suffire ! Les commandes devraient alors fonctionner à la fois avec et sans <tt>term</tt>. <verb> telnet localhost </verb> n'utilise pas <tt>term</tt> pour effectuer la connexion, mais : <verb> telnet bohr.physics.purdue.edu </verb> utilisera <tt>term</tt>, uniquement si vous n'avez pas d'autre type de connexion réseau. Certaines commandes telles que <tt>rlogin</tt> ne peuvent être lancées que par <it>root</it> et par le propriétaire de la connexion <tt>term</tt> (utilisateurs privilégiés). Certaines commandes <tt>term</tt> seront transparentes et n'utiliseront <tt>term</tt> que s'il n'y a pas d'autre possibilité. C'est en particulier le cas de <tt>telnet</tt> et <tt>ftp</tt>. D'autres ont besoin d'un paramètre qui leur indique qu'elles peuvent utiliser <tt>term</tt>. C'est le cas de <tt>xarchie</tt>, <tt>fsp</tt> et <tt>ytalk</tt>. Vous pouvez paramétrer ces programmes pour qu'ils utilisent <tt>term</tt> en positionnant la variable d'environnement <tt>termMODE</tt> selon les indications du fichier '<tt>README.security</tt>', ou bien en utilisant <tt>make installnet</tt>. En fin de compte, le fichier '<tt>termnet</tt>' créé contiendra des instructions spéciales pour le réseau. Pour l'instant, seule son existence est contrôlée. Si vous ajoutez une connexion <it>éthernet</it> à vote système, il vous suffit d'effacer le fichier '<tt>termnet</tt>' et vous pourrez continuer à utiliser les mêmes exécutables ! <tt>NOTE</tt> : Les programmes dont le portage a été réalisé à l'époque de <tt>client.a</tt> peuvent être recompilés pour être utilisés avec des versions plus récentes de <tt>term</tt> en changeant simplement la référence à <tt>client.a</tt> en <tt>libtermnet.a</tt>. <sect1><tt>termify</tt> Ce paquetage permet de convertir des exécutables <it>linkés</it> de façon dynamique, en vue d'une utilisation avec <tt>term</tt>. Avant de pouvoir utiliser <tt>termify</tt> il vous faut vous assurer que vous avez bien à votre disposition la version 2.2i de <tt>term</tt> (est-ce la version 2.2.8 ?) ou une version plus récente, ainsi que la version 4.5.26 ou une version plus récente de <tt>libc.so</tt>. Il vous faut alors créer le fichier '<tt>libt.so.4</tt>' dans le répertoire '<tt>/lib</tt>' (voir le fichier '<tt>README</tt>' du paquetage). À l'heure actuelle, il vous faut reconstruire le fichier '<tt>libt.so.4</tt>' à chaque fois que vous changez de version de <tt>term</tt>. Une fois cette bibliothèque créée, vous pouvez laisser <tt>termify</tt> digérer le programme que vous voulez rendre utilisable avec <tt>term</tt>, grâce à la commande : <verb> termify <nom du programme> </verb> Si le résultat ne vous plaît pas, l'opération inverse est possible : <verb> termify -u <nom du programme> </verb> Le paquetage contient également un <it>script</it> permettant de <it>termifier</it> complètement <tt>smail</tt>, de telle façon qu'aucune définition de transport particulière ne soit nécessaire. La seule modification que vous aurez éventuellement à apporter est le champ 'From: '. <sect>Clients <tt>term</tt> <sect1>Clients <tt>term</tt> disponibles sur les sites <tt>ftp</tt> Voici une liste des applications capables de fonctionner avec <tt>term</tt>. Elle n'est pas certainement pas exhaustive; toute information complémentaire est donc la bienvenue. Autant que possible, le site et le répertoire dans lequel l'application peut être trouvée (autant que le sache l'auteur) sont fournis. Lorsque le site indiqué est <tt>sunsite.unc.edu</tt>, l'application peut être trouvée dans l'un des répertoires suivants : <enum> <item><tt>/pub/Linux/apps/comm/term/apps</tt></item> <item><tt>/pub/Linux/apps/comm/term/extra</tt></item> </enum> <bf>Le paquetage <tt>term</tt> : </bf> <tscreen><verb> tupload tdownload (versions 2.1.0 et plus recentes) trsh tmon tredir tudpredir (versions 2.0.0 et plus recentes) txconn trdate(d) tshutdown libtermnet </verb></tscreen> <bf>Transfert de fichiers :</bf> <tscreen><verb> ftpd sunsite.unc.edu termncftp sunsite.unc.edu ncftp185 sunsite.unc.edu:/pub/Linux/system/Network/file-transfer fsp sunsite.unc.edu:/pub/Linux/system/Network/file-transfer </verb></tscreen> <bf>Systèmes d'information :</bf> <tscreen><verb> lynx Mosaic sunsite.unc.edu:/pub/Linux/system/Network/info-systems/Mosaic chimera netscape sunsite.unc.edu:/pub/Linux/system/Network/info-systems httpd xgopher gopher sunsite.unc.edu </verb></tscreen> <bf>Connexion à distance :</bf> <tscreen><verb> termtelnet sunsite.unc.edu rlogin physics.purdue.edu:/pub/bcr/term/extra rsh physics.purdue.edu:/pub/bcr/term/extra </verb></tscreen> <bf>Netnews :</bf> <tscreen><verb> tin 1.3 sunsite.unc.edu:/pub/Linux/system/Mail/news news2 sunsite.unc.edu </verb></tscreen> <bf>Courrier électronique :</bf> <tscreen><verb> slurp sunsite.unc.edu smail sunsite.unc.edu term.mailerd+smail sunsite.unc.edu BCRMailHandlerXXX physics.purdue.edu:/pub/bcr/term </verb></tscreen> <bf>Scripts d'automatisation :</bf> <tscreen><verb> JoeltermStuff sunsite.unc.edu autoterm sunsite.unc.edu fet sunsite.unc.edu </verb></tscreen> <bf>Autres programmes :</bf> <tscreen><verb> inetd sunsite.unc.edu rdate sunsite.unc.edu xgospel sunsite.unc.edu:/pub/Linux/games/x11/networked termify physics.purdue.edu:/pub/bcr/term/extra xboard sunsite.unc.edu ircII sunsite.unc.edu:/pub/Linux/system/Network/chat whois xwebster sunsite.unc.edu sxpc ftp.x.org:/R5contrib xztalk sunsite.unc.edu:/pub/Linux/apps/sound/talk </verb></tscreen> <sect1>Le paquetage <tt>termnet</tt> Le paquetage <tt>termnet-2.0.4-Linux-bin.tar.gz</tt> (<tt>sunsite.unc.edu:/pub/Linux/apps/comm/term</tt>) contient un ensemble de clients <tt>term</tt> précompilés ainsi qu'un ensemble de <it>scripts</it>, de pages de manuel et <tt>libtermnet</tt> 2.00.04. Les clients ont été compilés avec cette version de <tt>libtermnet.so</tt>. Le paquetage contient les clients suivants : <tscreen><verb> fet perl sperl4.036 tmon tshutdown xgopher finger perl4.036 suidperl trdate tudpredir ytalk ftp rcp taintperl trdated tupload fwhois rlogin telnet tredir txconn ncftp rsh term trsh xarchie </verb></tscreen> ATTENTION : Le paquetage contient l'ensemble précompilé complet des clients de <tt>term</tt> 2.0.4, ainsi que <tt>term</tt> lui-même. N'installez pas ce paquetage avant d'être sûr de ce que vous faîtes. Lorsque vous commencerez à déplacer les exécutables, vous allez détruire les autres versions de <tt>term</tt> et de ses clients. <sect1>Applications ne fonctionnant pas encore avec <tt>term</tt> <enum> <item> <tt>DOOM</tt> : Le problème avec ce jeu semble être le fait qu'il utilise le port 5039 à la fois en tant que client et en tant que serveur.</item> <item> <tt>NFS</tt> : Le serveur <tt>NFS</tt> est supposé n'accepter des requêtes que si la socket demandant la connexion est attachée à un port inférieur à 1024. Ceci semble poser problème. Cepedant, certains serveurs <tt>NFS</tt> possèdent une option '<tt>insecure</tt>'. Dans ce cas, il se pourrait finalement que <tt>NFS</tt> fonctionne, si la gestion des <tt>RPC</tt> est ajoutée à <tt>term</tt>.</item> </enum> <sect>term et la sécurité Dans cette partie sont évoqués certains des aspects de la sécurité de <tt>term</tt>. Les problèmes y sont évoqués et des moyens d'accroître la sécurité sont donnés. <sect1>trsh <tt>trsh</tt> pose des problèmes de sécurité lorsqu'il est utilisé pour accéder à la machine locale depuis le système distant. Le problème posé par <tt>term</tt> de ses clients est qu'en plus du propriétaire de la connexion <tt>term</tt>, <it>root</it> peut lancer, par l'intermédiaire de la connexion des programmes modifiés pour <tt>term</tt>. Ceci implique en particulier que le <it>root</it> du système distant peut lancer <tt>trsh</tt> et donc se faire passer pour le propriétaire de la connexion <tt>term</tt> assez facilement. Si cet utilisateur sur la machine locale est <it>root</it>, les risques encourus sont considérables. La solution à ce problème est simple : il vous suffit d'ajouter la ligne suivante dans le fichier '<tt>termrc</tt>', sur la machine locale : <verb> denyrsh on </verb> Cette ligne indique que personne ne peut lancer de <tt>trsh</tt> sur votre machine depuis le système distant. L'accès à votre machine est cependant encore possible par l'intermédiaire de la connexion <tt>term</tt>, en utilisant <tt>telnet</tt> et les ports redirigés. <sect1><tt>txconn</tt> et <tt>xauth</tt> <tt>txconn</tt> n'est pas particulièrement sûr. N'importe qui peut se connecter à votre serveur local par l'intermédiaire de <tt>term</tt> et se livrer à toutes sortes d'exactions. Si ce genre de problèmes vous inquiète, il est conseillé d'utiliser <tt>xauth</tt> pour autoriser vos connexions. Un exemple de l'utilisation de <tt>xauth</tt> pour sécuriser vos connexions est donné dans la partie suivante. <sect1><tt>sxpc</tt>, <tt>xhost</tt> et <tt>xauth</tt> L'utilisation de <tt>xauth</tt> est très importante pour assurer la sécurité lorsque vous utilisez <tt>sxpc</tt>. Si vous n'utilisez pas <tt>xauth</tt> en conjonction avec <tt>sxpc</tt>, tous les risques d'un <tt>xhost +</tt> s'appliquent. Entre autres, ils sont les suivants : <itemize> <item>Quelqu'un peut regarder ce qui est affiché à votre écran.</item> <item>Quelqu'un peut savoir ce que vous tapez.</item> <item>Quelqu'un peut entrer des commandes dans vos fenêtres (par exemple une commande pour effacer tous vos fichiers :().</item> </itemize> <tt>xauth</tt> est fourni avec <tt>X</tt> depuis la R4. Nous décrivons ici comment en mettre en place une utilisation de base. Attention, cette configuration est vulnérable au <it>snooping</it>. <bf>NOTE :</bf> lorsque vous utilisez <tt>xauth</tt>, votre variable d'environnement <tt>$DISPLAY</tt> ne doit PAS être positionnée sur <tt>localhost</tt> (ou <tt>localhost:quelquechose</tt>). Si votre variable d'environnement <tt>$DISPLAY</tt> utilise <tt>localhost</tt>, les clients seront incapables de trouver les informations d'autorisation adéquates. La solution est d'utiliser le nom réel de la machine. Si vous suivez les instructions de compilation contenues dans le fichier '<tt>README</tt>' et compilez sans l'option <tt>-DNOGETHOSTNAME</tt>, tout devrait fonctionner correctement. Appelons C la machine sur laquelle vous allez lancer les clients et D celle sur laquelle ils seront affichés. Tout d'abord, choisissez une <it>clé</it> composée d'au plus 16 couples de chiffres hexadécimaux (c'est-à-dire un nombre pair de caractères compris entre 0 et 9 et a et f). Dans l'exemple qui suit, il vous faudra remplacer <clé> par sa valeur. Sur C : <verb> % xauth xauth: creating new authority file $HOME/.Xauthority Using authority file $HOME/.Xauthority xauth> add Chostname:8 MIT-MAGIC-COOKIE-1 <cle> xauth> exit </verb> Sur D : <verb> % xauth xauth: creating new authority file $HOME/.Xauthority Using authority file $HOME/.Xauthority xauth> add Dhostname/unix:0 MIT-MAGIC-COOKIE-1 <cle> xauth> add Dhostname:0 MIT-MAGIC-COOKIE-1 <cle> xauth> exit </verb> Lorsque vous lancez le serveur <tt>X</tt> sur D, il faut alors lui passer le paramètre <tt>-auth $HOME/.Xauthority</tt>. Peut-être vous faudra-t-il créer ou modifier le fichier '<tt>$HOME/.xserverrc</tt>' pour contrôler la façon dont le serveur <tt>X</tt> est lancé. Par exemple : <verb> #!/bin/sh exec X -auth $HOME/.Xauthority $* </verb> Assurez-vous que votre fichier '<tt>.Xauthority</tt>' n'est accessible en lecture que par vous, à la fois sur C et sur D. <sect>Sources d'information Dans cette partie sont indiquées un certain nombres d'adresses <tt>ftp</tt> et d'<tt>URL</tt> utiles auxquelles vous trouverez des logiciels et des informations sur <tt>term</tt>. <bf>ftp :</bf> <verb> sunsite.unc.edu:/pub/Linux/apps/comm/term/<toute l'arborescence> sunsite.unc.edu:/pub/Linux/docs/HOWTO physics.purdue.edu:/pub/bcr/term/<toute l'arborescence> </verb> <bf>URL :</bf> <verb> http://sunsite.unc.edu/mdw/HOWTO/term-HOWTO.html http://zeus.cs.kun.nl:4080/term-howto/term-HOWTO.html http://physics.purdue.edu/~bcr/homepage.html </verb> <bf>netnews :</bf> <verb> comp.os.linux.announce annonces des nouvelles versions de term et du term-HOWTO comp.os.linux.help voici ou poser vos questions sur term comp.os.linux.misc un autre endroit pour les questions comp.protocols.misc on peut trouver ici des reponses aux questions sur term </verb> Lorsque vous posez des questions dans les <it>news</it>, assurez-vous de fournir toutes les informations utiles pour y répondre (version de <tt>term</tt>, comment vous avez installé votre connexion, etc.). Actuellement, de nombreuses versions de <tt>term</tt> sont utilisées et elles ont toutes des problèmes spécifiques ou communs. Ainsi, si vous souhaitez des réponses utiles, précisez au moins la version de <tt>term</tt> que vous utilisez. Dans le cas contraire, certaines suppositions hasardeuses devront être faites pour vous aider à résoudre votre problème. <sect>Stabilité des versions de <tt>term</tt> A l'heure actuelle, de nombreuses versions de <tt>term</tt> ont été répandues. Bill Riemers, qui s'occupe de la maintenance de <tt>term</tt>, nous confie la liste suivante, qui indique quelles en sont les versions stables et celles qu'il est plus prudent d'éviter. <tscreen><verb> term110 --> stabilite inconnue term111 --> stabilite inconnue term112 --> stabilite inconnue term113 --> stabilite inconnue term114 --> version BETA relativement stable term115 --> version BETA instable term116 --> version BETA instable term117 --> version BETA instable term118 --> version BETA moyennement stable term119 --> version GAMMA stable term-2.0.X --> versions BETA relativement stables term-2.1.X --> versions BETA plus stables term-2.2.X --> nouvelles versions BETA term-2.3.X --> </verb></tscreen> <sect>Performances de <tt>term</tt> Grâce à Bill McCarthy, nous avons maintenant à notre disposition un tableau indiquant les performances de <tt>term</tt> obtenues avec différents modems et différents types de connexions. Son but est de donner aux utilisateurs débutants comme expérimentés une idée des configurations utilisées par leurs collègues et des résultats qu'ils obtiennent. <tscreen><verb> LINUX term CHART 8/14/94 |__type/vitesse modem__|_vitesse_ligne_|_cps moyen_|__maxi__|__version__| | 1) USR SP 14.4 | 9600 | 950 | 963 | 1.17 | | 2) USR SP 14.4 | 14400 | 1376 | n/a | 1.18p06 | | 3) Zoom 2400 | 2400 | 220 | 230 | 1.19 | | 4) Boca V.32bis 14 | 57600 | 1400 | n/a | 1.01/09? | | 5) Viva 14.4 | 14400 | 1300 | n/a | 1.16 | | 6) USR SP 14.4 | 14400+ | 1550 | 1680 | 1.19 | | 7) Intel 14.4 Fax | 14400 | 1400 | 1650 | 2.0.4 | | 8) cable tv hookup | 57600 | 1500 | 1800 | 1.18p06 | | 9) Twincom 144/DFi | 57600 | 1500 | 4000? | 2.0.4 | | 10) USR SP 14.4 | 14400 | 1200 | 1500 | 1.08 | | 11) cable tv hookup | 19200 | 1300 | 1800 | 1.19 | |-----------------------------------------------------------------------| + options/parametres du termrc : 1) default escapes 2) window 5 3) baudrate 2400 4) n/a baudrate 9600 timeout 200 window 3 window 10 noise on timeout 150 5) compress off 6) baudrate 19200 7) ignore 19+17 8) compress off window 10 compress on window 4 escape 0, 13, timeout 150 timeout 90 16-19, 255 baudrate 38400 baudrate 0 shift 224 flowcrtl 500 window 10 timeout 70 retrain on breakout 24 9) compress off 10) compress off 11) baudrate 19200 baudrate 57600 baudrate 38400 compress on window 10 escape 17, 19 shift 224 timeout 200 remote escape 0, 13 16-17 noise on 19, 255 share on window 10 remote timeout 40 Eviter des caracteres a une extremite implique qu'il faut les ignorer a l'autre. </verb></tscreen> <sect>Trucs et astuces trouvés sur le Net Dans les <it>newsgroups</it> traitant de <tt>Linux</tt>, de nombreuses questions sur <tt>term</tt> reviennent régulièment, suivies de leurs réponses. Afin de réduire l'encombrement des <it>newsgroups</it>, certaines sont traitées ici, que l'auteur ait ou non personnellement expérimenté les solutions proposées. <itemize> <item>Nombreux sont ceux qui se plaignent d'ennuis avec <tt>vi</tt>, lequel refuse d'afficher 24 lignes dans une fenêtre qui en comporte pourtant bien 24. C'est en particulier le cas des utilisateurs d'<tt>Ultrix</tt>. Pour résoudre ce problème, trois méthodes sont envisageables : <enum> <item>Se connecter au système distant par la commande : <verb> trsh -s telnet <hostname> </verb></item> <item>Ajouter <tt>resize; clear</tt> dans votre fichier '<tt>.login</tt>'. </item> <item>La meilleure solution semble être d'entrer sur le système distant : <verb> stty 38400 </verb></item> </enum></item> <item> Nombreux sont ceux qui ont des problèmes avec des connexion <tt>term</tt> qui s'interrompent, quelles qu'en soient les raisons. C'est pourquoi ils souhaitent connaître l'état de la connexion avant de lancer des applications. Cet état peut être déterminé grâce aux petits <it>scripts shell</it> donnés en exemple ici : Pour ceux qui utilisent <tt>tcsh</tt> : <verb> if ( { trsh -s true } ) then ... endif </verb> et pour ceux qui utilisent <tt>bash</tt> : <verb> if trsh -s true; then ... fi </verb> </item> <item> <tt>Netscape</tt>, le nouveau client <tt>WWW</tt> semble poser des problèmes à ceux qui souhaitent le faire fonctionner avec <tt>term</tt>. Voici comment y parvenir : <verb> 1. Termifiez netscape. 2. Lancez termnetscape. Dans le menu Options | Preferences | Mail/Proxys, laissez vides _toutes_ les boites 'proxy'. Mettez 'remotehost' et 80 dans les boites SOCKS. 3. Ne tenez pas compte de l'erreur qui survient lorsque vous quittez le menu Options. 4. Si termnetscape ne fonctionne pas correctement : dans le menu Options | Preferences | Mail/Proxys, laissez vides _toutes_ les boites 'proxy'. Mettez 'none' et 80 dans les boites SOCKS. 5. Ne tenez pas compte de l'erreur qui survient lorsque vous quittez le menu Options. </verb> </item> </itemize> <sect>Divers Compléments souhaitables à ce document : <itemize> <item>Détailler le traitement des problèmes.</item> <item>Détailler les considérations de sécurité.</item> <item><tt>termwrap</tt>.</item> <item>Suggestions.</item> </itemize> En tout état de cause, si vous avez des suggestions, des critiques ou quelque remarque que ce soit à propos de ce document, n'hésitez pas. Patrick Reijnen est l'auteur actuel du <tt>term-HOWTO</tt> et peut être joint aux adresses suivantes : <tt>patrickr@cs.kun.nl</tt> ou <tt>patrickr@sci.kun.nl</tt>. Cette remarque s'applique également au traducteur, dont l'adresse est : <tt>ruch@labri.u-bordeaux.fr</tt>. <sect>Remerciements Nombreux sont ceux à qui l'auteur souhaite adresser ses remerciements. Avant tout, merci à Michael O'Reilly et à l'ensemble des développeurs de <tt>term</tt>, qui ont mis à notre disposition un si bel outil. L'auteur remercie également tout ceux qui ont fait part de leurs expériences et ont contribué à ce document. En font partie Bill Reynolds, le précédent auteur de ce HOWTO, Ronald Florence, Tom Payerle, Bill C. Riemers, Hugh Secker-Walker, Matt Welsh, Bill McCarthy, Sergio, Weyman Martin et bien d'autres dont il oublie de mentionner les noms. Le traducteur tient à adresser à Xavier Cazin (<tt>xc@itp.itp.fr</tt>), coordinateur des traductions françaises de la documentation <tt>Linux</tt>, ses plus vifs remerciements pour le travail qu'il accomplit et reste à son entière disposition. Il tient également à remercier Olivier Belhomme (le premier cyber-S.D.F., sans domaine fixe :)) pour son travail de relecture, qui a permis à ce document de ne pas arriver jusqu'à vous truffé d'erreurs. </article>