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.
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é !
X comme client XDMCPSi 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.
X -query sessionhost
xdm fonctionne sur sessionhost, vous
obtiendrez une fenêtre de connexion et, après connexion, une session X.
X -broadcast
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.
X -indirect xdmcpserver
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.
xdm comme serveur XDMCPLe 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.
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.
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
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
#
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.