Bureau CDE Guide de l'administrateur

Gestion des écrans locaux et éloignés

La Figure 1-1 montre un exemple de configuration du serveur de connexion.

Figure 1-1 Configuration possible d'un serveur de connexion

Graphic

Recherche de l'ID processus du serveur de connexion

Par défaut, l'ID processus du serveur de connexion est stocké dans le fichier /var/dt/Xpid.

Pour modifier son emplacement, utilisez la ressource Dtlogin.pidFile du fichier Xconfig. S'il est modifié, le répertoire spécifié doit exister au lancement du serveur de connexion.

Pour éditer le fichier Xconfig, copiez-le de /usr/dt/config vers /etc/dt/config. Une fois la modification effectuée dans /etc/dt/config/Xconfig, entrez la commande suivante pour que le serveur de connexion relise Xconfig :

/usr/dt/bin/dtconfig -reset

Cette opération lance la commande kill -HUP ID_processus_serveur_connexion.

Par exemple, pour placer l'ID processus du serveur de connexion dans /var/myservers/Dtpid, définissez le paramètre suivant dans le fichier Xconfig :

Dtlogin.pidFile: /var/myservers/Dtpid

Au prochain lancement du serveur de connexion, son ID processus sera placé dans /var/myservers/Dtpid. Le répertoire /var/mes_serveurs doit exister lors du redémarrage du serveur de connexion.

Affichage d'une fenêtre de connexion sur un écran local

Au lancement, le serveur de connexion vérifie dans le fichier Xservers si un serveur X doit être lancé localement. Il détermine également le nombre et le type des fenêtres de connexion à afficher sur des écrans locaux ou éloignés.

Pour modifier le fichier Xservers, copiez-le de /usr/dt/config vers /etc/dt/config. Une fois la modification effectuée dans /etc/dt/config/Xservers, entrez la commande suivante pour que le serveur de connexion relise Xservers :

/usr/dt/bin/dtconfig -reset

Cette opération lance la commande kill -HUP ID_processus_serveur_connexion

Le format des lignes du fichier Xservers est le suivant :

nom_écran classe_écran type_écran commande_serveur_X 

nom_écran--Indique au serveur de connexion le nom à utiliser lors de l'accès au serveur X (dans l'exemple ci-dessous, :0). Si vous entrez un astérisque (*), la valeur nom_hôte:0 est prise en compte. Le numéro indiqué doit correspondre au numéro de connexion de commande_serveur_X.

classe_écran--Identifie les ressources spécifiques de l'écran (Local dans l'exemple qui suit).

type_écran--Indique au serveur de connexion si l'écran est local ou éloigné et définit le mode de traitement de l'option Connexion à partir de la ligne de commande de l'écran de connexion (local@console dans l'exemple ci-dessous).

commande_serveur_X--Définit la ligne de commande, le numéro de connexion et les autres options utilisées par le serveur de connexion pour le lancement du serveur X (/usr/bin/X11/X: 0 dans l'exemple ci-dessous). Le numéro de connexion indiqué doit correspondre au numéro spécifié dans nom_écran.

La ligne Xservers par défaut a le format suivant :

:0 Local local@console /usr/bin/X11/X :0 

Lancement du serveur de connexion sans écran local

Si le système sur lequel s'exécute le serveur de connexion ne dispose pas d'un écran graphique, lancez le serveur de connexion sans écran local. Pour ce faire, mettez en commentaire la ligne du fichier Xservers associée à l'écran local, en la faisant précéder du signe dièse (#). Par exemple :

# :0 Local local@console /usr/bin/X11/X :0

Une fois lancé, le serveur de connexion s'exécute en arrière-plan, attendant les requêtes émises par les écrans du réseau.

Connexion à partir de la ligne de commande sur un écran local

Lorsque l'utilisateur sélectionne "Connexion à partir de la ligne de commande" dans l'écran de connexion, le serveur de connexion arrête provisoirement le serveur X, permettant l'accès à la connexion traditionnelle à partir de la ligne de commande en cours sur l'écran en mode point. Après que l'utilisateur se soit connecté puis déconnecté, ou après un délai donné, le serveur de connexion redémarrera le serveur X.


Remarque :

L'option "Connexion à partir de la ligne de commande" n'est pas disponible sur les écrans en réseau.


Le paramètre type_écran contrôle le comportement de la connexion à partir de la ligne de commande. Le format de type_écran est le suivant :

Lorsque local@écran est indiqué, le serveur de connexion considère que le serveur X et /dev/écran résident sur la même unité physique, sur laquelle une connexion à partir de la ligne de commande (généralement, getty) s'exécute. Lorsque l'utilisateur sélectionne Connexion à partir de la ligne de commande, le serveur X est arrêté, ce qui autorise l'accès à la procédure de connexion à partir de la ligne de commande (getty) en cours sur /dev/écran.

Pour désactiver l'option de connexion à partir de la ligne de commande sur un écran, indiquez la valeur none pour écran. La valeur par défaut de écran est console. Si vous indiquez local, la valeur par défaut devient console. Si vous indiquez foreign, l'option de connexion à partir de la ligne de commande est désactivée.


Remarque :

La désactivation sera effective sur l'écran local au prochain lancement du serveur de connexion à partir de la ligne de commande.


Prise en charge d'une console à caractères

Si le système sur lequel s'exécute le serveur de connexion dispose d'une console de type terminal à caractères, connectée directement au système, vous pouvez également attribuer la valeur none au paramètre écran pour désactiver la connexion à partir de la ligne de commande sur l'écran graphique.

Si une connexion à partir de la ligne de commande (getty) est en cours à la fois sur le terminal à caractères (utilisé comme console) et sur l'écran graphique, vous pouvez attribuer à écran la valeur correspondant au terminal à caractères utilisé comme console, pour l'associer à l'écran graphique lors de la connexion à partir de la ligne de commande (getty).

Par exemple, si la connexion à partir de la ligne de commande (getty) est en cours sur l'écran /dev/tty01, attribuez la valeur local@tty01 à type_écran.

Affichage d'un écran de connexion sur un écran du réseau

Le serveur de connexion peut afficher un écran de connexion sur tout écran du réseau (terminal X ou station de travail) qui en fait la demande.

Pour gérer ce type de requête, le serveur de connexion utilise le protocole XDMCP (X Display Manager Protocol) version 1.0, qui lui permet d'analyser les demandes, puis de les accepter ou de les rejeter. Sur la plupart des terminaux X, ce protocole est installé en standard.

Requêtes XDMCP directes

Lorsque vous configurez un terminal X pour qu'il utilise XDMCP en mode direct (requête), vous lui indiquez le nom hôte du système sur lequel le serveur de connexion est installé. À l'amorçage, le terminal X se connecte au serveur, qui affiche une fenêtre de connexion sur le terminal X. Pour plus de détails sur cette configuration, reportez-vous à la documentation relative au terminal X.

La plupart des serveurs X prennent également en charge l'option -query. Dans ce mode, le serveur X se comporte comme un terminal X : il se connecte directement au serveur de connexion et demande l'affichage d'une fenêtre de connexion. Par exemple, si vous lancez le serveur X sur un écran graphique sur la station de travail bridget et souhaitez que le serveur de connexion anita affiche un écran de connexion sur le serveur X, tapez la commande suivante :

X -query anita

Requêtes XDMCP indirectes

Lorsque vous configurez un terminal X pour qu'il utilise XDMCP en mode indirect, vous lui indiquez le nom hôte du système sur lequel le serveur de connexion est installé. À l'amorçage, le terminal X se connecte au serveur de connexion, qui affiche un écran de sélection contenant une liste des autres serveurs de connexion du réseau. L'utilisateur peut alors choisir un hôte qui affiche une fenêtre de connexion sur son terminal X. Pour plus de détails sur cette configuration, reportez-vous à la documentation relative au terminal X.

La plupart des serveurs X prennent en charge le mode -indirect, qui leur permet de se connecter au serveur de connexion en mode XDMCP indirect.

Gestion des écrans en réseau non XDMCP

Il est possible que XDMCP ne soit pas pris en charge sur les modèles de terminaux X les plus anciens. Pour que le serveur affiche un écran de connexion sur un terminal de ce type, indiquez son nom dans le fichier Xservers.

Étant donné que l'écran est relié au réseau, nom_écran comprend également le nom hôte. La valeur classe_écran peut être utilisée pour indiquer des ressources propres à une classe donnée de terminaux X (pour plus de détails, reportez-vous à la documentation relative à votre terminal X). La valeur foreign pour type_écran indique au serveur de connexion de se connecter à un serveur X existant plutôt que d'en lancer un nouveau. Dans ce cas, il est inutile d'indiquer une commande de type commande_serveur_X.

Exemple

Les lignes suivantes du fichier Xservers permettent au serveur de connexion d'afficher une fenêtre de connexion sur deux terminaux X non XDMCP, ruby et wolfie :

ruby.blackdog.com:0 AcmeXsta foreign 
wolfie:0 PandaCo foreign

Contrôle de l'accès au serveur de connexion

Par défaut, tout hôte du réseau ayant accès à votre serveur de connexion peut demander l'affichage d'un écran de connexion. Pour limiter l'accès à votre serveur de connexion, modifiez le fichier Xaccess.

Pour ce faire, copiez-le de /usr/dt/config vers /etc/dt/config. Une fois la modification effectuée dans /etc/dt/config/Xaccess, entrez la commande suivante pour que le serveur de connexion relise Xaccess :

/usr/dt/bin/dtconfig -reset

Cette opération lance la commande kill -HUP ID_processus_serveur_connexion.

Connexion directe via XDMCP

Lorsqu'un système hôte ou un terminal X tente de se connecter directement au serveur de connexion via XDMCP, son nom est comparé aux entrées du fichier Xaccess, afin de déterminer s'il est autorisé à effectuer cette opération. Les entrées de ce fichier sont des noms hôtes, dans lesquels les caractères génériques * (astérisque) et ? (point d'interrogation) sont autorisés. L'astérique représente zéro, un ou plusieurs caractères et le point d'interrogation, un caractère quelconque. Un nom hôte précédé d'un point d'exclamation (!) est inaccessible.

Par exemple, si le fichier Xaccess contient les entrées suivantes :

amazon.waterloo.com
 *.dept5.waterloo.com
 !*

La première entrée autorise le système hôte amazon.waterloo.com à accéder au serveur de connexion, la deuxième entrée autorise l'accès de n'importe quel système hôte dont le nom de domaine entier se termine par dept5.waterloo.com et la troisième entrée signifie que l'accès est interdit à tous les autres hôtes.

Connexion indirecte via XDMCP

Lorsqu'un système hôte tente de se connecter indirectement au serveur de connexion via XDMCP, son nom est comparé aux entrées du fichier Xaccess, afin de déterminer s'il est autorisé à effectuer cette opération. Les entrées Xaccess sont comparables aux entrées de connexion directe via XDMCP, caractères génériques compris, si ce n'est qu'elles sont associées à une chaîne CHOOSER. Par exemple :

amazon.waterloo.com   CHOOSER BROADCAST
 *.dept5.waterloo.com  CHOOSER BROADCAST
 !*		CHOOSER BROADCAST

Comme indiqué précédemment, la première entrée signifie que le système hôte amazon.waterloo.com a accès au serveur de connexion, tout comme les hôtes dont le nom de domaine se termine par dept5.waterloo.com (deuxième entrée) et la troisième entrée signifie que l'accès est interdit à tous les autres hôtes.

L'une des valeurs suivantes peut être indiquée après la chaîne CHOOSER.

BROADCAST indique au serveur de connexion qu'une liste des hôtes serveurs de connexion disponibles sur le sous-réseau doit être établie. Cette liste doit être utilisée par le serveur de connexion pour désigner les hôtes de connexion disponibles. Par exemple :

amazon.waterloo.com   CHOOSER shoal.waterloo.com alum.waterloo.com
 *.dept5.waterloo.com  CHOOSER BROADCAST
 !*		CHOOSER BROADCAST

Si amazon.waterloo.com se connecte indirectement via XDMCP, une liste contenant shoal et alum lui est proposée. Si alice.dept5.waterloo.com se connecte, une liste contenant tous les hôtes serveurs de connexion disponibles sur le sous-réseau du serveur de connexion lui est présentée. Les autres requêtes indirectes XDMCP seront rejetées.

Vous avez également la possibilité de définir une ou plusieurs macros contenant la liste de noms hôtes. Par exemple :

%list1			shoal.waterloo.com alum.waterloo.com
 amazon.waterloo.com  CHOOSER %list1