Le Gestionnaire d'Affichage X

Introduction

L'objet de cet article est le paramétrage et l'utilisation du Gestionnaire d'Affichage X. Il s"éxecute comme daemon sur une machine hôte et gère plusieurs affichages X (locaux ou à distance) et assure la gestion de session de base de manièreanalogue à init(8), getty(1) et login(1) sur les terminaux texte. De plus, xdm permet de nettoyerles terminaux sur lesquels le serveur X ne s'exécute plus. Une des propriétés les plus appréciables de xdm est sa capacité à générer des informations liées aux autorisations qui peuvent être utilisées par le serveur pour contrôler les accès basés sur les hôtes et les niveaux des comptes. Grâce à sa capacité de gestion des connections de sessions X en utilisant des techniques d'autentification standards, xdm est idéal sur les sites où une machine unique est partagée par de multiplesutilisateurs qui exécutent des sessions X individuelles et personnalisées.

Objet

Bien que ces colonnes abordent les autorisations sous xdm, la sécurité de X Window sera traitée le mois prochain en tant que sujet à part entière. Si vous êtes intéressés par l'utilisation de xdm sur un système unique, vous pouvez laisser de coté la section XDMCP. Une configuration prête à l'emploi vous a surement été livrée avec votre distribution. Si c'est le cas , vous vous en sortirez en vérifiant simplement les sections "personnalisation et exécution de xdm ". Le reste de l'article traite principalement des systèmes en réseaux et de leur interaction avec les terminaux X. De plus, si vous recherchez une approche type recette de cuisine pour paramètrer l'environnement d'un terminal X, je vous suggère de vous référer à Associates " The X WindowSystem Administrators Guide" de O' Reilly & Associates qui couvre les détails de l'administartion des terminaux X beaucoup plus en détail que ne le fait cet article.

gestion de Session sous X

Dans un login traditionnel sur un terminal texte, une session est l'interpréteur de l'utilisateur. Sous xdm une session est controllée par gestionnaire de session arbitraire car dans un environnement graphique le processus de login d'un utilisateur n'a pas forcement une interface de type terminal où se connecter. A titre de gestion de session dans l'environnement X windows, nous utilisons le gestionnaire de fenêtres en tant que " gestionnaire de session ". Quand le gestionnaire de fenêtre se termine, il en est de même pour la session de l'utilisateur.

Concepts de base d'xdm

xdm est un client X qui gère les premieres et dernieres étapes de la connection, le contrôle et la coordination d'une session utilisateur. Xdm trace quels serveurs X sont disponibles pour des connections en lisant les fichiers des serveurs X et en écoutant le port XDMCP à l'écoute d'autres serveurs qui demandent à être gérés. Quand xdm recoit la gestion d'un serveur X, il affiche la boite de login et attend les entrées de l'utilisateur. Quand ce dernier entre son nom et son mot de passe, il est authentifié de la même manière que sur un terminal standard (tty). A ce point, xdm exécute un certain nombre de scripts qui démarrent le clients X de l'utilisateur. Désormais, une session X normale se déroule et quand l'utilisateur la quitte, xdm ferme toutes les connections et ramène le terminal à son état de login, prêt pour une nouvelle session.

Pourquoi utiliser xdm ?

A coté des aspects sécurité, contrôle à distance et agrément, xinit est considéré comme obsolète par le Consortium X ( maintenant The Open Group ) avec toutes les nouvelles fonctions intégrées à xdm. Xdm permet aux administarteurs de configurer des environnements pour tout un système. De plus, xdm est le seul moyen (à ma connaissance) de partager une machine entre plusieurs utilisateurs sans avoir à tuer le serveur X et le redémarrer pour chaque nouvel utilisateur autrement qu'en partageant le même bureau et les mêmes réglages.

Configuration

xdm est configuré au moyen de fichiers texte standard. Les fichiers globaux sons généralement situés dans /usr/lib/X11/xdmoru/etc/xdm tandis que les fichiers locaux sont situé (où d'autre ?) dans le répertoire de chaque utilisateur. Notons que le fichier xmd-config peut définir des chemins différents pour tous les autres fichiers, et le sien peut être précisé au moyen du paramètre -config, ainsi les système avec avec un paramètrage prédéfinis peuvent facilement être modifiés sans toucher à l'original. Ci-dessous figure une brève description de chaque fichier ainsi qu'un exemple commenté (si nécessaire).

Fichiers globaux

xdm-config

Ce fichier précise les chemins de tous les autres fichiers de configuration (si des réglages autres que ceux par défaut doivent être utilisés) et définit les commandes pour xdm setup, startup, reset et le script initial. Dans l'exemple ci dessous tous les fichiers additionnels sont dans /etc/X11/xdm de telle sorte que les fichiers par défaut reste dans /usr/lib/X11/xdm sans être modifiés.

DisplayManager.errorLogFile: /var/log/xdm-error.log

DisplayManager.pidFile: /var/run/xdm.pid

DisplayManager.keyFile: /etc/X11/xdm/xdm-keys

DisplayManager.servers: /etc/X11/xdm/Xservers

DisplayManager.accessFile: /etc/X11/xdm/Xaccess

DisplayManager._0.authorize: true

DisplayManager._1.authorize: true

DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0

DisplayManager._0.startup: /etc/X11/xdm/GiveConsole

DisplayManager._0.reset: /etc/X11/xdm/TakeConsole

DisplayManager*resources: /etc/X11/xdm/Xresources

DisplayManager*session: /etc/X11/xdm/Xsession

DisplayManager*authComplain: false

Xservers

Une liste de serveurs à gérer par xdm. Au minimum, ce fichier doit contenir le serveur pour l'affichage local. NOTA - ce fichier est seulement relu à la fin d'une session ou si xdm reçoit un signal SIGHUP. Pour envoyer un signal SIGHUP à xdm, trouvez son pid et tuez ce processus. C'est à dire

# ps -a | grep xdm

2639 ? R 0:09 /usr/bin/X11/xdm

# kill -9 2639

Voici un exemple de fichier Xserver destiné à être utilisé sur une machine seule...

# La première ligne doit être l'affichage local

:0 local /usr/X11R6/bin/X

# :0 définit la console

# local précise que le serveur X est exécuté locallement

# /usr/X11R6/bin/X executable lancé au démarrage

# la syntax pour les terminaux X terminals est légèrement différente

# puisqu'ils exécutent un serveur X depuis une autre machine

# entrer SEULEMENT les terminaux X s'ils NE supportent PAS XDMCP

eng1:0 foreign NCD xterminal

# eng1 est le nom du terminal

# :0 est l'affichage à utiliser sur le terminal

# foreign signifie que le serveur the X s'exécute sur une machinedifférente

# NCD xterminal est une classe de ressources d'affichage spécifiques à ce terminal

# et ne sont pas absolument necessaire

eng2:0 foreign NCD xterminal

eng3:0 foreign Visual xterminal

Xsession

Script initial de démarrage utilisé par chaque session X.

#!/bin/sh

# la section suivante active le mode sans echec si necessaire

# l'utilisation de <CTRL><RETURN> après password active le mode sans echecs (failsafe)

case $# in

1)

case $1 in

failsafe)

exec xterm -geometry 80x24-0-0

;;

esac

esac

# rediriger les erreurs vers un fichier dans le répertoire utilisateur

for errfile in "$HOME/.xsession-errors" "${TMPDIR-/tmp}/xses-$USER" "/tmp/xses-$USER"

do

if ( cp /dev/null "$errfile" 2> /dev/null )

then

chmod 600 "$errfile"

exec > "$errfile" 2>&1

break

fi

done

# utiliser les fichiers locaux de l'utilisateur .xsession et .Xresources s'ils existent

startup=$HOME/.xsession

resources=$HOME/.Xresources

if [ -x "$startup" ]; then

exec "$startup"

elif [ -x "$HOME/.Xclients" ]; then

exec "$HOME/.Xclients"

elif [ -x /etc/X11/xinit/Xclients ]; then

exec /etc/X11/xinit/Xclients

else

if [ -f "$resources" ]; then

xrdb -load "$resources"

fi

exec xsm

fi

Xresources

Definit les ressources à charger via xrdb(1) pour tous les serveurs gérés par xdm.

# accélérateurs claviers utilisé par le widget Xlogin

xlogin*login.translations: #override\

# Ctrl R empèche xdm de gérer l'affichage

Ctrl<Key>R: abort-display()\n\

# F1 ou Ctrl Return execute un mode sans echecs session

# qui consiste en une simple fenêtre xterm

<Key>F1: set-session-argument(failsafe) finish-field()\n\

Ctrl<Key>Return: set-session-argument(failsafe) finish-field()\n\

<Key>Return: set-session-argument() finish-field()

# paramètres d'affichage du widget Xlogin affichés par xdm

xlogin*borderWidth: 3

xlogin*greeting: CLIENTHOST

xlogin*namePrompt: login:\040

xlogin*fail: Sorry Try Again

#ifdef COLOR

xlogin*greetColor: CadetBlue

xlogin*failColor: red

*Foreground: black

*Background: #fffff0

#else

xlogin*Foreground: black

xlogin*Background: white

#endif

# réglages pour le client xconsole qui est utilisé lors

# de l'initialisation de la connection au serveur xdm. Ceci

# empêche les messages envoyés entre les logins de traverser l'écran

XConsole.text.geometry: 480x130

XConsole.verbose: true

XConsole*iconic: true

XConsole*font: fixed

Chooser*geometry: 700x500+300+200

Chooser*allowShellResize: false

Chooser*viewport.forceBars: true

Chooser*label.font: *-new century schoolbook-bold-i-normal-*-240-*

Chooser*label.label: XDMCP Host Menu from CLIENTHOST

Chooser*list.font: -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1

Chooser*Command.font: *-new century schoolbook-bold-r-normal-*-180-*

xdm-pid

Fichier contenant le pid de xdm (pour information seulement, ne pas éditer)

xdm-errors

Fichier d'enregistrement des erreurs pour xdm.

Xaccess

Configure le contrôle d'accès pour XDMCP (X11R5 et plus). Ce fichier définit seulement les permissions d'accès pour les requêtes XDMCP. Il permet aussi de définir des macros pour grouper logiquement des ensembles d'hôtes liés. Le contôle d'accès au serveur est activé en utilisant la ressource DisplayManager*authorize dans le fichier xdm-config. Pour plus d'informations sur le paramètrage de XDMCP et des exemples, voir la section sur le CHOOSER ci-dessous.

GiveConsole

Un script utilisé pour attribuer la console à l'utilisateur. Sans raisons valables, laisser ce script et take console à leurs valeurs par défaut comme ci-dessous

#!/bin/sh

# Attibue la console à l'utilisateur entrant

# $XConsortium: GiveConsole,v 1.2 93/09/28 14:29:20 gildea Exp $

#

# Par convention, à la fois xconsole et xterm-C vérifient que

# la console appartient à l'utilisateur et est lisible avant d'y lier

# la sortie de la console. De cette façon, l'utilisateur peut appeler xterm -C sans

# causer de dommages sérieux.

#

chown $USER /dev/console

Take Console

Un script utilisé pour ré-attribuer la console à root (X11R5 et plus). Ici encore, laisser ce script en l'état

#!/bin/sh

# Reassigne la console à root, ceci devrait désactiver

# la redirection des sorties console vers n'importe quel utilisateur xterm

# $XConsortium: TakeConsole,v 1.2 93/09/28 14:30:29

#

chmod 622 /dev/console

chown root /dev/console

Xsetup_0

Un sript pour paramètrer l'affichage local du serveur. (X11R5 et plus) Prépare xconsole qui est une fenêtre terminal qui affiche les messages générés par le système entre les logins.

#!/bin/sh

# $XConsortium: Xsetup_0,v 1.3 93/09/28 14:30:31

/usr/X11R6/bin/xconsole -geometry480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail

Local Files

~/.xsession

Script de démarrage spécifique à l'utilisateur et appelé depuis le script global Xsession. Contrairement à ~/.xinit il peut être éxécuté par n'importe quel interpréteur. (~/.xinit doit être un script pour Bourne shell ou Bash)

~/.Xresources

Ressources spécifiques à l'utilisateur et lues par le script global Xsession.

~/.xsession-errors

Fichier d'erreur pour les sessions X individuelles.

~/.Xauthority

Contients les informations d'autorisation pour le serveur de l'utilisateur.

XDMCP

Le protocol de contrôle du gestionnaire d'affichage (X Display Manager Control Protocol) fut introduit pour la première fois dans la version 4 de X11 pour résoudre divers problèmes entre xdm et les terminaus X. Avant XDMCP le moyen pour xdm de connaître les serveurs prêts à être gérés était de lire le fichier Xservers. Comme ce fichier n'est lu qu'au démarrage de xdm, des problèmes survenaient quand des terminaux X étaient éteints puis réallumés. Chaque fois qu'un terminal X était réallumé il était nécessaire qu'un administrateur système force xdm à relire le fichier Xservers en envoyant un signal SIGHUP à xdm via sons pid.

XDMCP permet aux serveurs de dialoguer avec xdm sans que celui ci n'ait de connaissance explicite préalable du serveur. Sous XDMCP les hôtes attendent des requêtes (dans n'importe lequel des 3 modes de communications supportés) sur le port XDMCP. Quand il reçoit une requête, il relance une copie de lui même et transmet l'écran de login au terminal.

Les Modes de Communication

XDMCP autorise trois modes de communication aux serveurs qui requièrent une gestion et qui ne figurent pas explicitement dans le fichiers Xservers ; ce sont DIRECT, INDIRECT, ou BROADCAST.

Avec le mode DIRECT, un serveur fait une demande non spécifique de gestion sur le réseau. Le premier processus xdm qui répond à une requête DIRECT devient le gestionnaire du serveur. Une requête INDIRECT génère une boite de dialogue vers le terminal X qui liste tous les hôtes disponibles pour des connections et laisse l'utilisateur décider lequel assurera la gestion. Le mode INDIRECT est particulièrement utile dans les environnements multi-hôtes. Pour implanter le mode INDIRECT, il faut utiliser le mot clé CHOOSER lors de l'établissement des ressources dans le fichiers Xaccess. Une autre façon de mettre en œuvre le chooser, est d'utiliser le mode BROADCAST en conjonction avec la ressource CHOOSER qui envoit un message diffusé à tous les hôtes sur le réseau et permet à l'utilisateur d'en choisir un.

Chooser

Quand on utilise des terminaux X qui n'offrent pas de menu d'hôtes au démarrage, le programme chooser peut être utilisé en conjonction avec les modes BROADCAST ou INDIRECT. Pour activer le programme chooser on utilise CHOOSER comme première entrée de la liste indirecte des hôtes dans le fichier Xaccess.

eng*.odhs.dsd.com CHOOSER BROADCAST

permet à tous les terminaux " engineering " à odhs.dsd.com de choisir tous les hôtes diponibles dans une liste. Un scénario plus probable consisterait à prédéfinir une liste donnée d'hôtes auxquels tous les terminaux du département d'engineering seraient autorisés à se connecter, le mode indirect serait le meilleur moyen d'accomplir cela.

eng*.odhs.dsd.com CHOOSER dsdapps.odhs.dsd.com dbsrv.odhs.dsd.com test.odhs.dsd.com

Le paramètrage ci dessus autorisera tous les terminaux du département d'engineering à accèder aux applications, bases de données et serveurs de test via le menu.

Le fichier Xaccess permet de définir des macros pour regrouper logiquement les hôtes en relations. Voici un exemple qui utilise des macros avec le paramètrage précédent du département d'engineering.

%ENGHOSTS dsdapps.odhs.dsd.com dbsrv.odhs.dsd.com test.odhs.dsd.com

eng*.odhs.dsd.com CHOOSER %ENGHOSTS

Les attributs visuels du chooser peuvent être ajustés en modifiant les défauts dans le(s) fichier(s) Xresources.

Exécuter xdm

Pour essayer un paramètrage de xdm sans rebooter, faire depuis la console

$ init 5

cela devrait reinitialiser le système au niveau d'exécution 5. Si le niveau 5 ne démarre pas xdm, vérifiez /etc/inittab qui devrait préciser à quel niveau démarre xdm (Certaines distributions Slackware utilisent le niveau 4 pour xdm, mais la plupart des autres distributions que j'ai utilisées se réfèrent au 5.). On doit maintenant voir le widget xlogin qui demande le nom de l'utilisateur et son mot de passe et être capable de se connecter et d'essayer divers paramètres. Si vous êtes certain d'être au bon niveau d'exécution système et que xdm ne se comporte toujours pas comme prévu, consulter le chapitre dépannage ci-dessous. Sinon, à partir de ce point vous pouvez ajuster les différent paramètres individuels (voir le chapitre individualisation ci-dessous). Une fois que xdm est configuré, vous pouvez changer le niveaud'exécution par défaut au démarrage pour 5 (ou l'équivalent sur votre système). La modification sur ma machine est aussi simple que de changer

#/etc/inittab

id:3:initdefault:

en

id:5:initdefault:

Ceci démarre Linux au niveau 5 par défaut ce qui à son tour démarre automatiquement xdm à chaque démarrage du système (boot).

Dépannage de xdm

Si xdm ne fonctionne pas comme prévu, le premier endroit où regarder est ~/.xsession-errors. Ce fichier local d'enregistrement des erreurs contient uniquement celles générées avec votre compte et est par conséquent plus spécifique que celui du système. Ci dessous j'ai souligné quelques erreurs et pièges potentiels ainsi que les solutions adaptées.

La boite de Login n'apparaît pas à l'écran

C'est très probablement une erreur dans les fichiers de configuration, vous testez bien cela avant de changer votre niveau d'exécution par défaut n'est ce pas ?

Vous vous connectez avec succès et la boite de dialogue de login réapparait

Votre fichier .xsession peut ne pas être exécutable. Essayez de vous connecter et de presserCTRL-RETURN après votre mot de passeau lieu de " entrée ". Ceci court circuitera le script .xsession et vous donnera une seule fenêtre de terminal à partir de laquelle vous pourrez

# chmod +x .xsession

et réessayer.

Après connection, l'écran clignote et la boite de dialogue de login réapparaît

Utilisez la méthode décrite ci-dessus pour cour-circuiter votre fichier .xsession pendant la connection et assurez vous que la dernière commande de votre fichier .xsession démarre en arrière plan.

Conclusion

J'espère que cet article vous a convaincu de la puissance et de la souplesse du gestionnaire d'affichage X ( X Display Manager). Si vous souhaitez des informations plus détaillées sur xdm, consultez les liens ci-dessous pour en savoir plus. Dans le prochain numéro, nous plongerons dans la très brulante question de la sécurité de X Window. N'hésitez pas à m'envoyer vos questions et commentaires à [email protected]

Traduit par John Perr