Cette section détaille la procédure de configuration d'un terminal X avec XDMCP. Comme pré-requis, vous devez avoir n'importe quelle distribution Linux installée, ainsi que X.
Avant de commencer, il vaut mieux comprendre globalement le fonctionnement. (Vous trouverez plus de détails Ressources ci-dessous et sur le site de Traduc.org)
D'habitude, le serveur X est lancé à partir d'un gestionnaire
d'affichage X. Presque toutes les distributions Linux embarquent
xdm, kdm et gdm. Le choix de l'un d'entre eux est libre. (Ce
document se servira de gdm et kdm comme exemples). Le gestionnaire
d'affichage constitue une interface agréable et uniforme pour les
utilisateurs lambda (ouverture de session graphique, démarrage
d'un gestionnaire de fenêtre, horloge, et cætera). Un gestionnaire
d'affichage contrôle une série d'affichages X, qui peuvent être
situés sur l'hôte local ou sur des serveurs distants. Il est bon
de noter que ce qu'exécute votre environnement est le fichier
Xsession
.
Quand xdm s'exécute, il propose deux manières différentes de gérer
l'affichage. Il peut gérer un serveur X qui s'exécute sur la
machine locale (indiqué dans Xservers
) et des
serveurs X distants (en général des terminaux X) en utilisant
XDMCP (en fonction de ce qui est indiqué dans le fichier
Xaccess
— voir les pages de manuel de
xdm).
Quant à kdm (qui fait partie de l'environnement graphique KDE),
c'est un remplaçant de xdm qui se configure de façon identique, à
ceci près que ses fichiers sont /etc/X11/kdm
pour Caldera, dans /etc/kde/kdm
pour Red Hat,
et dans /usr/share/config/kdm
pour Mandrake.
Le gdm (Gestionnaire d'affichage Gnome) est une réécriture du
fameux xdm. Les fonctions de gdm sont similaires à celles de xdm
et kdm. Gdm (gdm) est le gestionnaire d'affichage de Gnome, et ses
fichiers de configuration sont situés dans
/etc/X11/gdm/gdm.conf
. Le fichier
gdm.conf
contient un ensemble de variables et
un grand nombre d'options pour gdm. Le répertoire Sessions
contient un script pour chaque option de session ; chaque script
appelle /etc/X11/xdm/Xsession
avec l'option
appropriée. Gdm offre des fonctions similaires à xdm et kdm, mais
a été écrit à partir de zéro et ne contient aucun code originaire de XDM
ou du consortium X.
Avec RH 8.0, une nouvelle interface graphique appelée « Bluecurve » apparaît. Son objectif est d'imiter l'apparence de XP. Dans ce cas, il n'y a aucune différence de configuration !
On peut trouver d'autres bonnes références pour une configuration similaire dans les documents suivants :
Le petit guide XDM et les terminaux X, écrit par Kevin Taylor.
Le Petit guide d'exécution à distance des applications X, une excellente référence d'approche pratique et théorique d'exécution de X à distance. Écrit par Vincent Zweije.
Le petit guide Xterminal, écrit par Scot W. Stevenson.
L'utilisation de XDMCP est par définition dangereuse, ce qui fait que la plupart des distributions ont désactivé son utilisation par défaut. Si vous devez utiliser XDMCP, ne le faîtes qu'au sein de réseaux sécurisés, tels que des réseaux d'entreprises protégées par un pare-feu. Malheureusement, XDMCP utilise le port UDP 177 et TCP le port 6000 ; il n'est donc pas possible de l'utiliser nativement avec SSH. Actuellement, SSH1 et SSH2 ne permettent pas de transmettre les communications UDP de manière sécurisée.
La technique de sécurisation des connexions via SSH est appelée transfert de port X11 TCP/IP (X11 TCP/IP Port Forwarding). Rendez-vous sur Why Port Forwarding? et dans la section Ressources pour des informations complémentaires (en anglais). Au cas où vous voudriez l'expérimenter, j'ai ajouté une petite section plus bas pour vous montrer son fonctionnement. Je vous décrirai sommairement son fonctionnement ; je laisse les autres experts et/ou les guides pratiques vous expliquer son utilisation avancée.
J'ai testé les configurations de GNOME (gdm) et de KDE (kdm) sur Red Hat 6.0, 6.2 et Red Hat 7.x et 8.0. J'ai eu aussi la chance de les tester sur Mandrake 7.2, 8.0, 8.2 et 9.0. Les configurations de SuSE 7.2 and Slakware 8.0 ont été testées par les utilisateurs ; merci à Peter Van Aerten et à tous ceux qui m'ont aidé à la préparation de ce guide pratique. Je désire remercier tous les utilisateurs qui m'ont aidé à réaliser ce projet. J'ai aussi essayé sur Caldera eDesktop 2.4, dont la configuration est similaire à celle de RH, à la différence qu'il utilise KDE. Je n'ai pas eu l'occasion de tester sur d'autres variantes telles que Debian ou Slackware (les utilisateurs de Slackware m'ont rapporté que le fonctionnement est identique à celui décrit dans ce document). Cependant, la configuration devrait être similaire et devrait bien fonctionner. Si vous avez réussi à configurer sur d'autres distributions que Red Hat, Caldera et Mandrake, faites-moi partager votre expérience. Je l'ajouterai à ce document.
Le PC que j'utilise est un compatible IBM, équipé d'un AMD Athlon XP 1800+, de 384 Mo de mémoire et d'un disque dur de 60 Go ATA-100. Cette machine a été mise à jour à partir d'un PC équipé d'un Intel Pentium II 500 MHz (je me suis aperçu que mon vieux PC Pentium 100 MHz marche très bien). J'utilise une carte Fast Ethernet intégrée dans ma nouvelle carte mère AMD. Sur mon vieux PC, j'utilise l'adaptateur 3Com 10/100 (3C509B), un cédérom 48X et un disque ZIP IOMEGA. J'ai aussi effectué des tests avec mon portable Toshiba Tecra 8100 connecté par carte sans fil Agere.
J'utilise Exceed 7.0 (Exceed 6.x fonctionne aussi correctement) sur mon PC, et je les ai testé sous Windows 98 SE, Windows NT 4.0 et Windows 2000 Pro. J'ai aussi constaté que X-Win32 et X-ThinPro sont d'autres choix répandus. Il existe également beaucoup d'applications, libres ou commerciales.
Sous RH 7.x, il faut configurer la recherche des DNS, pour
permettre à certaines fonctions de réseau de fonctionner
correctement (comme telnet qui sera utilisée
pour tester la configuration). Vous pouvez saisir
netstat -r
ou
arp -a
pour vérifier la configuration
des DNS ou les temps de réponse. Si vous êtes dans un petit
environnement (comme à la maison ou un petit réseau d'entreprise)
qui n'a pas son propre serveur DNS et qui utilise le serveur DNS
du FAI, ajoutez l(es) adresse(s) des serveurs de noms dans le
fichier resolv.conf
. Si vous l'utilisez
uniquement à la maison ou au labo, vous pouvez alors ajouter dans
votre fichier local les noms d'hôte de toutes les stations de
travail host
.
Pour que votre serveur X accepte une session XDMCP, assurez-vous que les éléments suivants sont bien installés :
Installez votre OS Linux. Dans mon cas, j'ai installé Red Hat 7.3 (installation personnalisée). Si vous projetez d'utiliser SSH pour faire du transfert de port, il vous faudra installer le paquetage OpenSSH ou compiler SSH dans le kernel. De plus, RH 7.x est fourni avec un pare-feu installé par défaut (à moins que vous ne fassiez pas ce choix). Vous pourrez rencontrer des problèmes si vous n'ajoutez pas des règles à votre pare-feu ou si vous ne le neutralisez pas temporairement le temps de configurer XDMCP. Je ne détaillerai pas les règles du pare-feu dans la mesure où ce n'est pas l'objet de ce document. Je montrerai seulement comment le faire fonctionner, à charge pour vous de le régler finement.
Avec le noyau 2.2x, vous afficherez les règles de votre
pare-feu en saisissant la commande
ipchains -L
. Pour le désactiver
temporairement, utilisez la commande
ipchains -F
pour effacer les
règles (pas de panique, elles seront restaurées en les
rechargeant ou au redémarrage). Avec le noyau 2.4x, remplacez
la commande ipchains par
iptables. Un utilisateur m'a indiqué qu'en
ajoutant cette règle, vous n'aurez pas besoin de désactiver
votre pare-feu et que vous pourrez accéder au serveur X (vous
pouvez le vérifier par vous-même).
ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT
Vous devriez pouvoir utiliser la commande iptables de manière identique. (Vous trouverez des références à iptables dans les Ressources).
Pour plus de détails sur les pare-feu, rendez-vous sur la page du Guide pratique de masquage IP.
Il est aussi possible d'ajouter des règles pour qu'il accepte uniquement les adresses IP des stations de travail de confiance. Vous pouvez utiliser la commande iptables à votre gré. Je rappelle que sa description n'est pas l'objet de ce document. J'ai de la chance dans le sens où j'utilise le pare-feu de ma société.
Configuration du réseau. Vous pouvez utiliser les commandes ping, ftp et telnet pour tester le fonctionnement de votre réseau. Pour des raisons de sécurité, le démon de la commande telnet est désactivé sur RH 7.x et versions ultérieures. Pensez à l'activer si vous désirez l'utiliser pour effectuer vos tests. Vous pourrez toujours le désactiver (avec la commande ntsysv) lorsque vous en aurez terminé. Il est aussi bon de se souvenir que les règles du pare-feu sont actives. Ajoutez vos propres règles ou désactivez les temporairement (comme mentionné plus haut) pour permettre l'exécution de ces commandes.
Configuration de X
Ne configurez pas X avec une résolution plus haute que celle dont les utilisateurs distants pourront disposer. Testez le serveur X en saisissant soit startx soit telinit 5. Assurez-vous que X fonctionne correctement.
Créez les comptes indispensables (et les groupes associés) pour les utilisateurs devant accéder par le terminal X.
J'ai utilisé les étapes suivantes pour configurer le serveur X afin qu'il accepte les requêtes XDMCP :
Dans un environnement grahique Linux, les polices utilisées
sont soit celles du serveur X (xfs), soit celles dont le chemin est
spécifié dans les fichiers de configuration XF86Config ou
XF86Config-4. .Si vous prévoyez d'utiliser le serveur de polices
xfs (cliquez ici pour voir les
avantages de xfs), pour RH 6.2 et Mandrake 8.x et 9.0,
modifiez le fichier
/etc/rc.d/init.d/xfs
et
apportez-y les modifications suivantes. Changez tout ce qui suit
(cela concerne le port du serveur de polices) :
daemon xfs -droppriv -daemon -port -1
en:
daemon xfs -droppriv -daemon -port 7100
Dans la Mandrake 7.2, le port est déjà 7100. De plus, sur la RH 7.x, l'écoute sur un port TCP est à présent désactivée par défaut pour des raisons de sécurité ! Si vous désirez paramétrer le serveur de polices de X, suivez les étapes
Changez la ligne suivante du fichier
/etc/rc.d/init.d/xfs
:
daemon xfs -droppriv -daemon
en :
daemon xfs -droppriv -daemon -port 7100
Puis, dans /etc/X11/fs/config
, mettez
cette ligne en commentaires :
# Ne pas écouter sur les ports TCP (pour des raisons de sécurité) #no-listen = tcp
Si vous changez ou ajoutez le port, utilisez cette commande pour redémarrer votre serveur de polices X (nécessite les droits de root) :
service xfs restart
Le port 7100 n'est pas obligatoire. Vous pouvez choisir un autre port, dans la mesure où vous aurez vérifié soigneusement que ce port n'occasionne pas de conflit. Il est de bon ton de consulter votre administrateur Linux avant de le faire, afin qu'il sache que le port est utilisé ! Les différentes distributions Linux peuvent placer xfs dans différents répertoires sous /etc/rc.d. Si c'est le cas, vous pouvez le rechercher.
Modifiez /etc/X11/xdm/xdm-config
en
effectuant les modifications suivantes : Par défaut dans
la plupart des distributions Linux, cette ligne est active, ce
qui fait qu'il n'écoute pas les connexions XDMCP. Ceci pour
des raisons de sécurité. Pour Caldera et en utilisant kdm, le
fichier est situé en /etc/X11/kdm
.
Trouvez cette ligne :
DisplayManager.requestPort: 0
et mettez la en commentaire comme ceci :
! DisplayManager.requestPort: 0
Rappelez vous que ceci n'affecte pas gdm. La configuration de gdm se trouve dans la section suivante.
Dans le fichier /etc/X11/xdm/Xaccess
modifiez ce qui suit. (cela permet à tous les hôtes de se
connecter). Pour Caldera, et en utilisant kdm, le fichier est
situé en /etc/X11/kdm
. Changez les droits
d'accès en 644 (chmod 644) :
#* # any host can get a login window
en :
* # any host can get a login window
La configuration ci-dessus est en mode Diffusion (Broadcast), qui permet d'établir la liste de tous les serveurs X écoutant les demandes de prise en charge de connexion X et en mesure de l'effectuer. Si vous désirez n'autoriser que certaines connexions, utilisez la section CHOOSER du même fichier. Vous trouverez un exemple dans les Ressources.
J'utilise gdm par défaut ainsi que l'invite de connexion gdm
pour permuter KDE et GNOME. Pour gdm, éditez le fichier
/etc/X11/gdm/gdm.conf
. Ce qui suit active
XDMCP, en le faisant écouter les requêtes. Pour kdm (si vous
avez choisi KDE comme gestionnaire d'affichage lors de
l'installation), éditez le fichier
/usr/share/config/kdm/kdmrc
pour Mandrake et
/etc/kde/kdm/kdmrc
pour Red Hat ou
/opt/kde2/share/config/kdm/kdmrc
pour
Slackware version (KDE2). Modifiez cette ligne :
[xdmcp] # false peut être remplacé par 0 dans certaines distributions Enable=false
en :
# true peut être remplacé par 1 dans certaines distributions Enable=true
Assurez-vous que Port=177
est présent à la
fin de ce bloc.
À présent, éditez le fichier /etc/inittab
et modifiez la ligne suivante :
id:3:initdefault:
en:
id:5:initdefault:
Dans la Slackware, le mode graphique (X11) est
4
et non 5
.
Ceci fait passer la connexion du mode ligne de commande en mode graphique. Vous pouvez utiliser la commande telinit pour effectuer un test avant de modifier cette ligne. Utilisez soit telinit 3 pour passer au niveau 3, ou telinit 5 pour passer au niveau 5 en mode graphique (vous pouvez essayer cette commande sur la deuxième machine reliée par telnet à votre serveur).
Assurez-vous que les attributs de sécurité du fichier
/etc/X11/xdm/Xservers
sont
fixés à 444 (chmod 444).
Localisez
/etc/X11/xdm/Xsetup_0
et
exécutez
chmod 755 sur ce fichier.
Éditez le fichier XF86Config
(si vous
utilisez Xfree86 4.x, le fichier se nomme
XF86Config-4
) situé en
/etc/X11
et modifiez la ligne :
FontPath "unix/:-1"
en :
FontPath "unix/:7100"
Si vous décidez d'utiliser un port différent du traditionnel
port 7100, assurez-vous de le modifier à la fois dans le
fichier /etc/rc.d/init.d/xfs
et
ici !
Afin de vous économiser du temps et de l'énergie, je vous recommande d'ajouter le chemin des polices (FontPath) dans les fichiers de configuration XF86Config et XF86Config-4. Si vous n'êtes pas certain de la disponibilité des polices, vous pouvez utiliser cette commande pour le vérifier (avec les droits de root) :
chkfontpath --list
Les polices suivantes constituent quelques exemples de référence. Assurez-vous de disposer de ces polices avant d'éditer ces chemins.
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
(Il n'est pas nécessaire d'effectuer
cette modification. Vous pouvez laisser les paramètres par
défaut, cependant je préfère ce réglage. En cas de doute,
laissez-les tels quels). Modifiez cette ligne à la fin du
fichier /etc/inittab
:
x:5:respawn:/usr/bin/gdm
Si vous décidez de ne pas modifier cette ligne, tant mieux ! Ce n'est pas une étape nécessaire, mais une préférence personnelle !
À présent, vous allez pouvoir effectuer un test.
Un autre point à connaître (qui a été demandé par certains), est
la manière d'afficher le message au chargement avec
Willing to manage. D'après ce que je sais,
cette opération est possible dans xdm en ajoutant ce qui suit au
fichier /etc/X11/xdm/xdm-config
.
DisplayManager.willing: su noboby -c /etc/X11/xdm/Xwilling
Le script Xwilling devant être présent sur votre système.
Pour gdm, ajoutez cette ligne au fichier
/etc/X11/gdm/gdm.conf
dans la section
[security]
:
Willing=/etc/X11/gdm/Xwilling
Vous trouverez ici un exemple du script Xwilling à titre de référence. La décision d'ajouter ou non ce script vous appartient. Ce n'est pas une étape nécessaire ici !
Pour tester si votre XDMCP fonctionnant avec le serveur X est prêt à accepter les connexions, suivez ces étapes. Je trouve qu'il est plus aisé d'utiliser le serveur X et un autre poste pour effectuer les tests.
(Re)lancez X (situé dans le niveau d'exécution n°5). Si vous ne savez pas trop comment le faire, redémarrez simplement votre système (ce n'est cependant pas nécessaire si vous savez comment le redémarrer en ligne de commande. C'est toute la beauté de Linux, comparée à Windows).
Si vous n'avez pas procédé à la modification des règles de
votre pare-feu, il vous faut le désactiver temporairement par
le commande iptables -F
(ou
ipchains -F
).
Vérifiez que l'invite de connexion apparaît. Vérifiez que la résolution d'affichage et que la souris fonctionnent. Connectez-vous depuis la console pour voir si l'accès en local est possible. Si oui, ne vous déconnectez pas.
Paramétrez Exceed (ou tout autre logiciel de client graphique (X)) pour soit appeler cette machine (par son adresse IP ou son nom DSN totalement qualifié), soit pour utiliser le paramètre de diffusion de XDMCP (XDMCP-Broadcast) et essayez de vous connecter au serveur X. Vous devriez voir apparaître l'écran de la session X et l'invite de connexion.