Solaris CDE - Guide avancé de l'utilisateur et de l'administrateur système

Gestion des écrans locaux et en réseau

La Figure 1-1 présente un exemple de configuration de serveur de connexion.

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

Graphic

Recherche de l'ID de processus du serveur de connexion

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

Pour indiquer un autre fichier, définissez la ressource Dtlogin.pidFile du fichier Xconfig. Si cette ressource est définie, le répertoire spécifié doit exister lors du 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 de processus du serveur de connexion dans /var/mes_serveurs/Dtpid, définissez le paramètre suivant dans le fichier Xconfig :

Dtlogin.pidFile: /var/mes_serveurs/Dtpid

Au prochain démarrage du serveur de connexion, son ID de processus sera placé dans /var/mes_serveurs/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 démarrage, 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 en réseau.

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_écranclasse_écran type_écrancommande_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_machine:0 est prise en compte. Le nombre 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 en réseau 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 suivant).

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 nombre spécifié dans nom_écran.

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

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

Exécution 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 graphique. Lorsque l'utilisateur s'est connecté puis déconnecté, ou après un délai donné, le serveur de connexion redémarre 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 la variable local@écran est indiquée, le serveur de connexion considère que le serveur X et /dev/écran résident sur la même entité physique et qu'une connexion à partir de la ligne de commande (généralement, getty) s'exécute sur cette unité. Lorsque l'utilisateur sélectionne Connexion à partir de la ligne de commande, le serveur X est arrêté, autorisant ainsi 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 Connexion à partir de la ligne de commande sur un écran, indiquez la valeur none pour écran. La valeur par défaut d'écran est console. Si la variable local est spécifiée, la valeur d'écran devient console. Si vous indiquez foreign, l'option 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 en mode caractère

Si le serveur de connexion est directement connecté à une console de type terminal en mode caractère, 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 en mode caractère (utilisé comme console) et sur l'écran graphique, vous pouvez attribuer à écran la valeur de 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 version 1.0, qui lui permet d'analyser les demandes, puis de les accepter ou de les rejeter. Ce protocole est intégré sur la plupart des terminaux X.

Requêtes XDMCP directes

Lorsque vous configurez un terminal X pour qu'il utilise le protocole XDMCP en mode direct (requête), vous lui indiquez le nom de la machine sur laquelle le serveur de connexion est installé. Lorsque le terminal X s'initialise, il se connecte au serveur de connexion, qui affiche une fenêtre de connexion sur le terminal X. Pour plus de détails sur cette configuration, reportez-vous à la documentation du 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, le serveur de connexion anita affichera un écran de connexion sur le serveur X :

X -query anita

Requêtes XDMCP indirectes

Lorsque vous configurez un terminal X pour qu'il utilise le protocole XDMCP en mode indirect, vous lui indiquez le nom de la machine sur laquelle le serveur de connexion est installé. Lorsque le terminal X s'initialise, il 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 une machine, laquelle affichera une fenêtre de connexion sur son terminal X. Pour plus de détails sur cette configuration, reportez-vous à la documentation du terminal X.

Comme en mode direct, la plupart des serveurs X prennent en charge l'option -indirect, qui leur permet de se connecter au serveur de connexion en mode XDMCP indirect.

Gestion des écrans en réseau non XDMCP

Il se peut que le protocole 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.

L'écran étant sur le réseau, nom_écran comprend également le nom de machine. La valeur classe_écran peut être utilisée pour indiquer des ressources propres à une classe donnée de terminaux X (reportez-vous à la documentation de votre terminal X pour connaître sa classe). La valeur foreign pour type_écran indique au serveur de connexion de se connecter à un serveur X existant plutôt que d'en démarrer un nouveau. Dans ce cas, n'indiquez pas de commande_serveur_X.

Exemple

Les lignes suivantes du fichier Xservers indiquent au serveur de connexion d'afficher un écran 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, toute machine 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 le protocole XDMCP

Lorsqu'une machine tente de se connecter directement au serveur de connexion via le protocole XDMCP, son nom est comparé aux entrées du fichier Xaccess afin de déterminer si elle est autorisée à effectuer cette opération. Chaque entrée Xaccess est un nom d'hôte pouvant inclure des caractères génériques tels que l'astérisque (*) et le point d'interrogation (?). L'astérisque (*) représente zéro, un ou plusieurs caractères et le point d'interrogation (?), un caractère quelconque. Un point d'exclamation (!) précédant un nom de machine empêche l'accès à celle-ci.

Considérons par exemple que le fichier Xaccess contient les entrées suivantes :

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

La première entrée permet l'accès au serveur de connexion à partir de la machine amazon.waterloo.com, la deuxième entrée à partir de toute machine dont le nom de domaine se termine par dept5.waterloo.com, et la troisième entrée interdit l'accès à partir de toutes les autres machines.

Connexion indirecte via le protocole XDMCP

Lorsqu'une machine 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 si elle est autorisée à effectuer cette opération. Les entrées Xaccess sont comparables aux entrées de connexion en mode XDMCP direct, 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 la machine amazon.waterloo.com peut accéder au serveur de connexion, tout comme les machines dont le nom de domaine se termine par dept5.waterloo.com, et la troisième entrée interdit l'accès à partir de toutes les autres machines.

La chaîne CHOOSER peut être suivie de :

BROADCAST indique au serveur de connexion de faire une recherche sur son sous-réseau pour établir la liste des machines serveurs de connexion disponibles. Si vous spécifiez une liste de noms de machine, le serveur de connexion l'utilisera comme liste des machines 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 le protocole XDMCP, il recevra une liste contenant shoal et alum. Si alice.dept5.waterloo.com se connecte, une liste contenant toutes les machines serveurs de connexion disponibles sur le sous-réseau des serveurs de connexion lui est présentée. Les autres requêtes XDMCP indirectes seront rejetées.

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

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