Page suivante - Page précédente - Table des matières

9. Mettre en place un terminal X

Trouvez une utilisation à votre vieux PC ! Faites-en un endroit supplémentaire pour pouvoir travailler ! Pas besoin d'acheter un nouveau matériel coûteux ! Vous avez déjà tout ce qu'il faut !

Sérieusement, vous pouvez mettre en place un vieux PC comme terminal X. Un terminal X est un ordinateur qui fondamentalement n'exécute rien d'autre qu'un serveur X. Vous pouvez vous connecter dessus et obtenir une session X, avec des xterms, xbiff, xclock et tout autre client X concevable. Cependant, les clients X s'exécuteront sur l'hôte distant et ils utiliseront le serveur X distant pour afficher leur sortie sur votre terminal X local. Même le gestionnaire de fenêtre s'exécutera à distance.

Un terminal X consomme peu de ressources en comparaison d'une machine Unix complète. J'ai ici un terminal X constitué par un processeur 486, 16 Mo de RAM et 250 Mo d'espace disque. Oh et une connexion réseau, naturellement. Il n'a même pas besoin d'avoir des répertoires utilisateurs.

Pour trouver des lectures liées à ce sujet, jetez un coup d'oeil aux documents suivants :

À la différence des documents ci-dessus, le document que vous êtes en train de lire se limite à une courte description de XDMCP, mais il insiste plus sur les problèmes de sécurité impliqués.

9.1 Une fois de plus, un peu de théorie en premier

En ce qui concerne X, le terminal X va n'exécuter rien d'autre qu'un serveur X. Ce serveur X sera configuré pour dialoguer avec l'hôte distant en utilisant XDMCP (le protocole de contrôle de gestion d'affichage X, « X Display Manager Control Protocol »). Il va demander à l'hôte distant une session X. L'hôte distant fournira une fenêtre de connexion dans le terminal X et après la connexion, il exécutera une session X avec tout l'habillage y compris le gestionnaire de fenêtres, tout cela utilisant X distant pour l'affichage sur le terminal X.

Vous aurez probablement remarqué que l'hôte distant agit comme un serveur, bien que pas comme un serveur X. L'hôte distant fournit les sessions X aux serveurs X qui les demandent. Ainsi, selon XDMCP, l'hôte distant est en fait un serveur, fournissant des sessions X, également connu sous le nom de serveur XDMCP. Le serveur X joue le rôle d'un client XDMCP ! Vous me suivez ?

Le programme qui fournit le service XDMCP sur le serveur XDMCP est xdm. Donc, pour exécuter un terminal X, vous devez configurer deux programmes : X (le client XDMCP) sur le terminal X et xdm (le serveur XDMCP) sur l'hôte distant.

Vous devez toujours vous rappeler que le protocole X (et le protocole XDMCP) n'est pas chiffré. Si vous devez utiliser X à distance, tout ce qui transite sur le réseau peut être espionné par d'autres hôtes du réseau. Ceci est particulièrement néfaste avec les sessions X distantes car la première chose qui se passe est la connexion en donnant l'utilisateur et le mot de passe. Vous ne devez donc exécuter X à distance que sur un réseau sécurisé !

9.2 Configurer X comme client XDMCP

Si vous désirez mettre en place une machine Linux comme terminal X, vous avez besoin de très peu de ressources. Fondamentalement, vous avez besoin de ce qu'il est nécessaire d'avoir pour faire fonctionner une machine Linux dépouillée plus un serveur X. Spécifiquement, vous n'avez pas besoin des clients et bibliothèques X. Il peut être utile d'installer certaines polices X, mais vous pouvez également utiliser un serveur de polices situé quelque part sur le réseau.

Il existe plusieurs moyens pour un serveur X d'obtenir une session X d'un serveur XDMCP. La plus simple est d'aller directement à un serveur XDMCP connu et de lui en demander une. Le serveur peut également émettre en multi-diffusion une requête et utiliser le premier serveur XDMCP qui répond. Enfin, le serveur X peut demander à un serveur XDMCP de lui fournir une liste des hôtes qui acceptent de fournir une session et laisser l'utilisateur choisir l'hôte de session.

  1. Si vous connaissez l'hôte qui va vous fournir une session, utilisez-le directement. Exécutez 
    X -query sessionhost
    et, en supposant que xdm fonctionne sur sessionhost, vous obtiendrez une fenêtre de connexion et, après connexion, une session X.
  2. Si l'hôte duquel vous obtiendrez la session vous importe peu, utilisez la méthode d'émission de multi-diffusion. Exécutez 
    X -broadcast
    et, en supposant que xdm fonctionne sur un hôte quelque part sur le réseau, vous obtiendrez une fenêtre de connexion du premier (et, on l'espère, du plus rapide) xdm qui répond et, après connexion, une session X.
  3. Si vous désirez choisir l'hôte où vous voulez avoir votre session, demandez au serveur XDMCP une liste des hôtes. Exécutez 
    X -indirect xdmcpserver
    et, en supposant que xdm est bien configuré sur ce serveur, une liste des hôtes vous sera présentée parmi lesquels vous pourrez choisir. Choisissez-en un ; vous obtiendrez la fenêtre de connexion pour cet hôte et, après connexion, la session que vous avez demandée.

Il se peut que vous ayez remarqué l'absence de l'option -auth. Le serveur X utilisera XDMCP pour négocier le mot de passe secret (« magic cookie ») avec le serveur XDMCP. Le serveur XDMCP placera le cookie dans votre ~/.Xauthority après la connexion.

Après la fermeture d'une session, le serveur X va boucler, il reviendra au serveur XDMCP d'origine et lui demandera une nouvelle session (ou une liste de choix). Si vous ne désirez pas cela, vous pouvez utiliser l'option -once. Notez que ceci ne semble pas fonctionner avec l'option -indirect à cause de l'implémentation du « chooser ».

Quand vous avez déterminé la façon dont vous allez exécuter le serveur X, vous pouvez alors le placer dans un script de démarrage ou même l'exécuter directement à partir de /etc/inittab. Veuillez consulter la documentation de votre propre distribution pour savoir comment modifier vos scripts d'amorçage ou /etc/inittab.

N'exécutez pas un serveur X ainsi depuis le fichier de configuration Xservers. xdm s'attend à pouvoir se connecter à de tels serveurs et il pourrait les tuer s'il ne peut pas se connecter.

9.3 Configurer xdm comme serveur XDMCP

Le programme qui fournit le service XDMCP (le service de session) est généralement xdm. Il existe des variantes de celui-ci, comme wdm ou gdm sur Linux, mais ceux-ci fonctionnent fondamentalement de la même façon. Assurez-vous donc que xdm ou une variante est installé sur l'hôte où vous désirez exécuter vos sessions X. Si vous disposez d'une connexion graphique locale depuis l'hôte de session X, xdm est déjà installé ; la plupart des distributions Linux sont ainsi fournis de nos jours.

En plus de xdm, vous aurez besoin des programmes que vous désirez exécuter dans une session X. C'est-à-dire, tous les clients X comme xterm, xfig, xclock, des gestionnaires de fenêtre et ainsi de suite. Cependant, pour un serveur XDMCP, vous n'avez pas besoin d'installer de serveur X ; le serveur X fonctionnera à la place sur le terminal X.

À partir de l'histoire sur le serveur X ci-dessus, vous pouvez en conclure qu'il y a fondamentalement deux types de services XDMCP. Il y a le service direct qui consiste à permettre la connexion d'un client XDMCP et à lui fournir une session X. Il y a également le service indirect dans lequel le serveur fournit une liste d'hôtes fournissant un service direct, au choix pour le client XDMCP.

Tous les services xdm sont configurés dans le fichier d'accès, généralement situé à /etc/X11/xdm/Xaccess ou un emplacement semblable. Cet emplacement est en fait défini dans le fichier de configuration général de xdm /etc/X11/xdm/xdm-config par la ressource accessFile. Veuillez voir votre manuel xdm pour l'emplacement par défaut.

  1. Si vous désirez autoriser xdm à fournir des sessions X aux clients XDMCP, que ce soit par multi-diffusion ou non, placez le nom d'hôte du client XDMCP (le serveur X, vous vous souvenez ?) seul sur une ligne dans le fichier Xaccess. En fait, vous pouvez placer un expression rationnelle correspondant à plusieurs hôtes. Voici quelques expressions valides : 

    xterm023.my.domain      # xterm023.my.domain peut obtenir une session X
*.my.domain             # tout hôte dans my.domain peut obtenir une session X
*                       # tout hôte sur Internet peut obtenir une session X (non sécurisé)

    Vouloir fournir une session X à tout hôte sur Internet est discutable. De façon évidente, tout service que vous fournissez est une faille de sécurité potentielle dans la sécurité de votre serveur. D'un autre côté, le serveur devrait être sécurisé lui-même et un client XDMCP demandant une session X doit fournir une authentification valide avant que la session X ne soit accordée.

    De plus, la session X utilise une connexion X distante qui n'est pas chiffrée. La paire nom d'utilisateur/mot de passe de connexion sera transportée sur cette connexion. Toute personne pourrait alors espionner des combinaisons valides d'utilisateur/mot de passe tout comme sur des connexions telnet simple. Ceci est même pire que d'avoir son mot de passe secret (« magic cookie ») espionné.

    Prenez vos propres décisions ici, mais je recommande de ne pas activer ce service au monde entier à moins d'avoir une bonne raison.

  2. Si vous désirez fournir aux clients XDMCP (X -indirect xdmcpserver) une liste de choix (une liste d'hôtes pour choisir duquel ils obtiendront une session X), faite suivre l'expression rationnelle du client par le mot-clé CHOOSER et la liste des hôtes que le client peut choisir. À la place de la liste des hôtes, vous pouvez également spécifier BROADCAST ; avec ceci, xdm émet en multi-diffusion sur le réseau pour interroger les serveurs désirant fournir une session. Des exemples valides : 

    xterm023.my.domain      CHOOSER seshost1 seshost2
*.my.domain             CHOOSER BROADCAST
*                       CHOOSER extseshost1 extseshost2
    Le premier exemple permet à xterm023 de choisir entre des sessions sur seshost1 et sur seshost2. Le deuxième exemple permet à tout hôte dans my.domain de choisir n'importe quel hôte fournissant une session X. Le troisième exemple permet à tout hôte de choisir une session entre extseshost1 et extseshost2.

    Ce n'est probablement pas une bonne idée de faire * CHOOSER BROADCAST. Ceci permettrait à tout hôte en dehors de votre réseau d'obtenir des informations sur les hôtes dans votre réseau. Vous ne voulez probablement pas communiquer une telle information. En fait, autoriser un choix pour tout hôte extérieur n'est probablement pas très utile de toute façon, car vous ne devriez pas autoriser des connexions arbitraires directes non plus.

Quand vous avez reconfiguré xdm, envoyez-lui le signal HUP pour le forcer à relire ses fichiers de configuration. 

# kill -HUP pid-of-xdm
#

9.4 XDMCP techniquement

Techniquement, pour autant que je puisse le voir, XDMCP n'est pas tout à fait ce à quoi vous pouvez vous attendre d'après la description ci-dessus. xdm peut rediriger des serveurs X se connectant, vers un autre endroit et il utilise cette astuce pour implémenter la liste de choix. Ainsi, le choix se produit dans xdm et non dans le serveur X bien que la liste de choix soit représentée dans l'affichage du serveur X. C'est également pour cela que l'option -once du serveur X ne se combine pas avec -indirect.

Page suivante - Page précédente - Table des matières