mini-HOWTO : Comment ex�cuter des applications X � distance
Vincent Zweije,
[email protected]
V 0.6.1, 19 Novembre 1999
Ce mini-HOWTO d�crit comment ex�cuter des applications X � distance.
C'est-�-dire, comment faire pour qu'un programme X s'affiche sur un
�cran d'ordinateur diff�rent de celui sur lequel il s'ex�cute. Ou,
autrement dit, comment faire tourner un programme X sur un ordinateur
diff�rent de celui devant lequel vous �tes assis. L'accent de ce mini-
HOWTO sera mis sur les questions de s�curit�. Ce mini-HOWTO contient
�galement des informations sur la mani�re de faire tourner des appli�
cations X en local, mais avec un identificateur d'utilisateur (user-
id) diff�rent. Adaptation fran�aise : Albert-Paul Bouillot apb@club-
internet.fr
______________________________________________________________________
Table des mati�res
1. Introduction
2. Lectures compl�mentaires
3. Le contexte
4. Un peu de th�orie
5. Dire au client ...
6. Dire au serveur ...
6.1 Xhost
6.2 Xauth
6.2.1 Fabrication du Cookie
6.2.2 Transfert du Cookie
6.2.3 Utilisation du Cookie
6.3 Ssh
7. Les applications X avec un identificateur d'utilisateur (User-id) diff�rent
7.1 Plusieurs utilisateurs sur le m�me h�te
7.2 Root est l'utilisateur client
8. Faire tourner un gestionnaire de fen�tres distant
9. Maintenance
______________________________________________________________________
11.. IInnttrroodduuccttiioonn
Ce mini-HOWTO constitue un guide sur la mani�re de faire tourner des
applications X � distance. J'ai r�dig� ce document pour plusieurs
raisons :
1. Il y a eu de nombreuses questions, sur Usenet, sur la mani�re de
faire tourner des applications X � distance;
2. J'ai vu beaucoup, beaucoup, de conseils d'utilisation de �des
connexions X. CC''eesstt dd''uunnee iinnss��ccuurriitt�� ttoottaallee, et il existe de bien
meilleures m�thodes;
3. Je n'ai pas connaissance d'un document simple d�crivant les options
dont _o_n _p_e_u_t disposer. Si vous avez des informations
compl�mentaires, s'il vous pla�t, faites-le moi savoir :
<
[email protected]>.
Ce document a �t� �crit en pensant � des syst�mes de type Unix. Si le
syst�me d'exploitation de votre ordinateur local ou de celui qui est �
distance est de type diff�rent, vous devriez trouver ici des
informations sur la mani�re dont les choses se passent. Cependant, il
vous faudra modifier les exemples par vous-m�me pour les utiliser sur
votre (vos) propre(s) syst�mes(s).
La version (anglaise) la plus r�cente de ce document est toujours
disponible sur le WWW �
http://www.xs4all.nl/~zweije/xauth.html. Il
est �galement disponible en tant que mini-HOWTO Linux Applications X �
distance (Remote X Apps) � :
http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps. Les (mini-)HOWTOs
Linux sont disponibles par http ou ftp sur sunsite.unc.edu.
Ceci constitue la version 0.6.1. Aucunes garanties, seulement de
bonnes intentions. Je suis ouvert aux suggestions, id�es, ajouts,
pointeurs utiles, corrections (typo), etc... Je veux que cela reste un
document simple et lisible, dans la bonne moyenne du style HOWTO. Les
querelles seront redirig�es vers /dev/null.
Le contenu de ce mini-HOWTO a �t� mis � jour le 19 Novembre 1999 par
Vincent Zweije
22.. LLeeccttuurreess ccoommppll��mmeennttaaiirreess
Un document, en rapport avec cela, sur le WWW traite de ''Quoi faire
quand Tk dit que votre �cran n'est pas s�r'',
http://ce-
toolkit.crd.ge.com/tkxauth/. Il a �t� �crit par Kevin Kenny. Il
sugg�re une solution similaire � celle de ce document pour
l'authentification X (xauth). Cependant, Kevin vise plus �
l'utilisation de xdm pour diriger xauth � votre place.
On m'a indiqu� que le volume 8 du ``Guide de l'administrateur du
syst�me X Window'' (X Window System Administrator's Guide Vol. 8) de
chez O'Reilly and Associates �tait une bonne source d'informations.
Malheureusement, je n'ai pas pu le v�rifier.
Il y a �galement un autre document qui ressemble beaucoup � celui que
vous �tes en train de lire, dont le titre est ''Securing X Windows'',
et qui est disponible �
http://ciac.llnl.gov/ciac/documents/ciac2316.html.
Consultez �galement les listes de diffusion usenet, telles que :
comp.windows.x, comp.os.linux.x, et comp.os.linux.networking.
33.. LLee ccoonntteexxttee
Vous utilisez deux ordinateurs. Sur le premier, vous �tes dans
l'environnement X Window pour taper au clavier et regarder l'�cran.
Sur le second vous effectuez un important traitement graphique. Vous
voulez que les sorties du second soient affich�es sur l'�cran du
premier. Le syst�me X window rend cela possible.
Naturellement, vous devez disposez de connexions � un r�seau pour
pouvoir le r�aliser. De pr�f�rence rapides, car le protocole X est un
d�voreur de ressources r�seau. Mais, avec un peu de patience et un
protocole de compression de donn�es adapt�, vous pouvez m�me faire
tourner des applications par l'interm�diaire d'un modem. Pour un
protocole de compression pour X, vous pouvez aller consulter les sites
: dxpc <
http://ccwf.cc.utexas.edu/~zvonler/dxpc/> ou LBX
<
http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html> (�galement connu
comme �tant le LBX mini-HOWTO).
Vous avez deux choses � faire pour r�aliser tout cela :
1. Indiquer � l'unit� d'affichage locale (le serveur) qu'elle doit
accepter les connexions venant de l'ordinateur � distance.
2. Dire � l'application � distance (le client) de rediriger ses
sorties vers votre unit� d'affichage locale.
44.. UUnn ppeeuu ddee tthh��oorriiee
Le mot magique est DISPLAY (unit� d'affichage). Dans le syst�me X
window, une unit� d'affichage est constitu�e (en simplifiant) d'un
clavier, d'un mulot et d'un �cran. Une unit� d'affichage est g�r�e par
un programme serveur, plus connu sous le nom de serveur X. Le serveur
fourni des fonctionnalit�s d'affichage aux autres programmes qui se
connectent � lui.
Une unit� d'affichage est identifi�e par un nom, de type, par exemple
:
� DISPLAY=light.uni.verse:0
� DISPLAY=localhost:4
� DISPLAY=:0
Un nom d'unit� d'affichage est constitu� d'un nom d'h�te (par exemple
: light.uni.verse et localhost), du signe deux point (:), et d'un
num�ro de s�quence (tels que 0 et 4). Le nom d'h�te de l'unit�
d'affichage est le nom de l'ordinateur sur lequel tourne le serveur X.
Si le nom de l'h�te est omis, cela signifie qu'il s'agit de
l'ordinateur local. D'habitude, le num�ro de s�quence est 0 -- cela
peut changer s'il y a plusieurs unit�s d'affichage connect�es sur le
m�me ordinateur.
Si jamais il vous arrive de voir le nom d'une unit� d'affichage avec
un .n suppl�mentaire accol� � son nom, c'est qu'il s'agit d'un num�ro
d'�cran. Une unit� d'affichage peut, en th�orie, avoir plusieurs
�crans. Cependant, d'habitude, il n'y en a qu'un, qui porte le num�ro
n=0, et c'est le num�ro par d�faut.
D'autres formes de DISPLAY existent, mais celle-ci suffira pour notre
propos.
Pour celui qui est curieux de technique :
� hostname:D.S signifie �cran S sur unit� d'affichage D de l'h�te
hostname; le serveur X de cette unit� d'affichage est � l'�coute du
port TCP 6000+D.
� host/unix:D.S signifie �cran S sur unit� d'affichage D de l'h�te
host; le serveur X de cette unit� d'affichage est � l'�coute du
socket de domaine UNIX /tmp/.X11-unix/XD (et donc, seul host peut
l'atteindre).
� :D.S est �quivalent � host/unix:D.S, o� host est le nom de l'h�te
local.
55.. DDiirree aauu cclliieenntt ......
Le programme client (par exemple, votre application graphique) sait �
quelle unit� d'affichage il doit se connecter en consultant la
variable d'environnement DISPLAY. Cependant ce param�trage peut �tre
modifi�, en lan�ant le client avec l'argument -display hostname:0
dans la ligne de commande. Quelques exemples peuvent clarifier les
choses.
Notre ordinateur est connu du monde ext�rieur sous le nom light, et
nous sommes dans le domaine uni.verse. Si nous fonctionnons avec un
serveur X normal, l'unit� d'affichage est connue comme �tant
light.uni.verse:0. Nous voulons faire tourner le programme de dessin
xfig sur un ordinateur � distance, appel� dark.matt.er, et afficher sa
sortie ici, sur light.
Supposons que vous vous soyez d�j� connect� par telnet � l'ordinateur
distant, dark.matt.er.
Si l'interpr�teur de commande de l'ordinateur �loign� est csh :
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
Ou, d'une autre mani�re :
dark% xfig -display light.uni.verse:0 &
Si c'est sh qui tourne sur l'ordinateur � distance :
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
Ou, autrement :
dark$ DISPLAY=light.uni.verse:0 xfig &
Ou, bien s�r, �galement :
dark$ xfig -display light.uni.verse:0 &
Il para�t que certaines versions de telnet transmettent
automatiquement la variable DISPLAY � l'ordinateur h�te �loign�. Si
vous avez l'une ce celles-ci, vous avez de la chance, et c'est
effectivement automatique. Si ce n'est pas le cas, la plupart des
versions de telnet _d_o_i_v_e_n_t transmettre la variable d'environnement
TERM, et avec un bidouillage judicieux, il est possible de superposer
la variable DISPLAY sur la variable TERM.
L'id�e, sous-jacente � cette superposition, est de r�aliser une sorte
de script pour effectuer ceci : avant la connexion par telnet, donner
la valeur de DISPLAY � TERM. Puis de lancer telnet. Du c�t� de
l'ordinateur distant, dans le fichier .*shrc concern�, lire la valeur
de DISPLAY � partir de TERM.
66.. DDiirree aauu sseerrvveeuurr ......
Le serveur n'acceptera pas de connexions venant de n'importe o�. Vous
ne voulez pas que n'importe qui puisse afficher des fen�tres sur votre
�cran. Ou lire ce vous tapez -- souvenez-vous que votre clavier fait
partie de votre unit� d'affichage!
Trop peu de gens semble r�aliser que permettre l'acc�s � leur unit�
d'affichage pose des probl�mes de s�curit�. Quelqu'un qui dispose d'un
acc�s � votre unit� d'affichage peut lire et �crire sur vos �crans,
lire vos frappes au clavier, et suivre les d�placements de votre
mulot.
La plupart des serveurs disposent de deux mani�res d'authentifier les
demandes de connexions qui arrivent : le m�canisme de la liste d'h�tes
(xhost) et le m�canisme du mot de passe secret (magic cookie) (xauth).
De plus, il y a ssh, l'interpr�teur de commande s�curis�, qui peut
acheminer les connexions X.
66..11.. XXhhoosstt
Xhost permet les acc�s bas�s sur les nom d'h�tes. Le serveur
entretient une liste des h�tes qui sont autoris�s � se connecter �
lui. Il peut aussi d�sactiver compl�tement la v�rification des h�tes.
Attention : cela signifie que plus aucun contr�le n'est effectu�, et
donc, que _n_'_i_m_p_o_r_t_e _q_u_e_l h�te peut se connecter!
Vous pouvez contr�ler la liste des h�tes du serveur avec le programme
xhost. Pour utiliser ce m�canisme dans l'exemple pr�c�dent, faites :
light$ xhost +dark.matt.er
Ceci permet toutes les connexions � partir de l'h�te dark.matt.er.
D�s que votre client X a r�alis� sa connexion et affiche une fen�tre,
par s�curit�, supprimez les permissions pour d'autres connexions avec
:
light$ xhost -dark.matt.er
Vous pouvez d�sactiver la v�rification des h�tes avec :
light$ xhost +
Ceci d�sactive la v�rification des acc�s des h�tes et donc permet �
_t_o_u_t _l_e _m_o_n_d_e de se connecter. Vous ne devriez _j_a_m_a_i_s faire cela sur
un r�seau o� vous n'avez pas confiance dans _t_o_u_s les utilisateurs (tel
internet). Vous pouvez r�activer la v�rification des h�tes avec :
light$ xhost -
xhost - par lui-m�me _n_e _s_u_p_p_r_i_m_e _p_a_s tous les h�tes de la liste
d'acc�s (ce qui serait tout � fait inutile - vous ne pourriez plus
vous connecter de n'importe o�, pas m�me de votre h�te local).
_X_h_o_s_t _e_s_t _u_n _m_�_c_a_n_i_s_m_e _v_r_a_i_m_e_n_t _t_r_�_s _p_e_u _s_�_r_. Il ne fait pas de
distinction entre les diff�rents utilisateurs sur l'h�te � distance.
De plus, les noms d'h�tes (en r�alit� des adresses) peuvent �tre
manipul�s. C'est mauvais si vous vous trouvez sur un r�seau douteux
(d�j�, par exemple, avec un acc�s PPP t�l�phonique � Internet).
66..22.. XXaauutthh
Xauth autorise l'acc�s � tous ceux qui connaissent le bon secret. On
appelle un tel secret un enregistrement d'autorisation ou cookie. Ce
m�canisme d'autorisation est d�sign� c�r�monieusement comme �tant le
MIT-MAGIC-COOKIE-1.
Les cookies pour les diff�rentes unit�s d'affichage sont stock�s
ensembles dans ~/.Xauthority.Votre fichier ~/.Xauthority doit �tre
inaccessible pour les utilisateurs groupe/autres. Le programme xauth
g�re ces cookies, donc le surnom xauth dans ce sch�ma.
Au d�marrage d'une session, le serveur lit un cookie dans le fichier
qui est indiqu� par l'argument -auth. Ensuite, le serveur ne permet la
connexion que des clients qui connaissent le m�me cookie. Quand le
cookie dans ~/.Xauthority change, _l_e _s_e_r_v_e_u_r _n_e _r_�_c_u_p_�_r_e_r_a _p_a_s _l_a
_m_o_d_i_f_i_c_a_t_i_o_n.
Les serveurs les plus r�cents peuvent g�n�rer des cookies � la vol�e
pour des clients qui le demandent. les cookies sont cependant encore
conserv�s dans le serveur; ils ne finissent pas dans ~/.Xauthority �
moins qu'un client ne les y mettent. Selon David Wiggins :
Une possibilit� suppl�mentaire , qui peut vous int�resser, a
�t� ajout�e dans X11R6.3. Par l'interm�diaire de la nou�
velle extension SECURITY, le serveur X lui-m�me peut g�n�rer
et renvoyer de nouveaux cookies � la vol�e. De plus on peut
d�signer les cookies comme �tant ``douteux'' de sorte que
les applications qui se connectent avec de tels cookies
auront une capacit� op�ratoire restreinte. Par exemple, ils
ne pourront pas regarder les entr�es au clavier/mulot, ou le
contenu des fen�tres, d'autres clients ``fiables''. Il y a
une nouvelle sous-commande ``generate'' de xauth pour rendre
cette fonctionnalit�, pas forc�ment facile, mais au moins
possible � utiliser.
Xauth poss�de un avantage clair, au niveau de la s�curit�, sur xhost.
Vous pouvez limiter l'acc�s � des utilisateurs sp�cifiques sur des
ordinateurs sp�cifiques. Il ne permet pas l'usurpation d'adresse comme
le permet xhost. Et, si vous le d�sirez, vous pouvez encore utiliser
xhost en parall�le pour permettre des connexions.
66..22..11.. FFaabbrriiccaattiioonn dduu CCooookkiiee
Si vous voulez utiliser xauth, vous devez lancer le serveur X avec
l'argument -auth authfile. Si vous utilisez le script ssttaarrttxx pour
lancer le serveur X, c'est le bon endroit pour le faire. Cr�ez
l'enregistrement d'autorisation comme indiqu� ci-dessous dans votre
script startx.
Extrait de /usr/X11R6/bin/startx:
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Mcookie est un petit programme du paquetage util-linux, site primaire
ftp://ftp.math.uio.no/pub/linux/. Autrement, vous pouvez utiliser
md5sum pour cr�er quelques donn�es al�atoires (de, par exemple,
/dev/urandom ou ps -axl) au format cookie :
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Si vous ne pouvez pas �diter le script startx (parce que vous n'�tes
pas root), demandez � votre administrateur de syst�me de configurer
startx correctement, ou, � la place, laissez-le configurer xdm. S'il
ne peut, ou ne veut, pas, vous pouvez �crire un script ~/.xserverrc.
Si vous avez ce script, il sera ex�cut� par xinit au lieu du v�ritable
serveur X. Alors, vous pourrez lancer le serveur X v�ritable � partir
de ce script avec les arguments adapt�s. Pour faire cela, faites
utiliser par votre ~/.xserverrc le mcookie de la ligne ci-dessus pour
cr�er un cookie puis lancer le v�ritable serveur X :
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Si vous utilisez xdm pour g�rer vos sessions X, vous pouvez utiliser
xauth facilement. D�finissez les ressources du DisplayManager.authDir
dans /etc/X11/xdm/xdm-config. Xdm passera l'argument -auth au serveur
X � son d�marrage. Au moment de la connexion sous xdm, xdm place le
cookie dans ~/.Xauthority pour vous. Consultez xdm(1) pour de plus
amples information. Par exemple, mon /etc/X11/xdm/xdm-config contient
la ligne suivante :
DisplayManager.authDir: /var/lib/xdm
66..22..22.. TTrraannssffeerrtt dduu CCooookkiiee
Maintenant que vous avez lanc� votre session X sur le serveur h�te
light.uni.verse et que vous avez votre cookie dans ~/.Xauthority, il
vous faut transf�rer le cookie sur le client, dark.matt.er.
Le plus simple est que vos r�pertoires sur light et dark soient
partag�s. Les fichiers ~/.Xauthority sont les m�mes, donc le cookie
est transf�r� instantan�ment. Cependant, il y a un pi�ge : lorsque
vous mettez un cookie pour :0 dans ~/.Xauthority, dark va croire que
c'est un cookie pour lui au lieu de light. Il faut que vous utilisiez
un nom d'h�te explicite � la cr�ation du cookie; on ne peut pas faire
autrement. Vous pouvez installer le m�me cookie pour, � la fois, :0 et
light:0 avec :
#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
Si les r�pertoires _h_o_m_e ne sont pas partag�s, vous pouvez transf�rer
le cookie au moyen de rsh, le shell � distance :
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
1. Extraire le cookie de votre fichier local ~/.Xauthority (xauth
nlist :0).
2. Le transf�rer vers dark.matt.er (| rsh dark.matt.er).
3. >Le mettre dans ~/.Xauthority l� (xauth nmerge -).
Notez l'utilisation de ${HOST}. Vous devez transf�rer le cookie qui
est explicitement associ� � l'h�te local. Une application X distante
interpr�terait une valeur d'unit� d'affichage �gale � :0 comme �tant
une r�f�rence � la machine distante, ce qui ne correspond pas � ce que
l'on veut !
Il est possible que rsh ne fonctionne pas chez vous. En plus de cela,
rsh a un inconv�nient en ce qui concerne la s�curit� (noms d'h�tes
parodi�s, si je me souviens bien). Si vous ne pouvez, ou ne voulez,
pas utiliser rsh, vous pouvez �galement transf�rer le cookie
manuellement, comme ceci :
light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
dark% xfig &
[15332]
dark% logout
light$
Consultez �galement rsh(1) et xauth(1x) pour de plus amples
informations.
Il doit �tre possible de superposer le cookie sur la variable TERM ou
DISPLAY quand vous utilisez telnet sur l'h�te �loign�. Cela doit
fonctionner de la m�me mani�re que de superposer la variable DISPLAY
sur la variable TERM. Regardez la section 5 : Dire au Client. De mon
point de vue, sur ce sujet, vous prenez vos responsabilit�s, mais cela
m'int�resse si quelqu'un peut me confirmer ou m'infirmer cela.
66..22..33.. UUttiilliissaattiioonn dduu CCooookkiiee
Une application X, telle que xfig ci-dessus, sur dark.matt.er, ira
automatiquement voir le cookie dans ~/.Xauthority pour s'authentifier.
L'utilisation de localhost:D entra�ne une petite difficult�.
L'application X cliente peut traduire localhost:D en host/unix:D pour
les besoins de recherche du cookie. Effectivement, cela signifie
qu'un cookie pour localhost:D dans votre ~/.Xauthority n'a _a_u_c_u_n
effet.
66..33.. SSsshh
Les enregistrements d'autorisation sont transmis sans codage. Si vous
vous souciez de ce que l'on puisse espionner vos connexions, utilisez
ssh, le shell s�curis�. Il effectuera des transmissions X s�curis�es
au moyen de connexions crypt�es. De plus, il est g�nial pour d'autres
choses aussi. C'est une bonne am�lioration structurelle de votre
syst�me. Allez voir simplement
http://www.cs.hut.fi/ssh/, la page
d'accueil de ssh.
Qui poss�de d'autres informations sur les m�thodes d'authentification
ou de cryptage des connexions X ? Peut-�tre Kerberos ?
77.. LLeess aapppplliiccaattiioonnss XX aavveecc uunn iiddeennttiiffiiccaatteeuurr dd''uuttiilliissaatteeuurr ((UUsseerr--iidd))
ddiiffff��rreenntt
Supposez que vous vouliez faire tourner un outil graphique de
configuration qui n�cessite d'avoir les privil�ges du compte _r_o_o_t
alors que la session X actuelle se d�roule sous votre compte. Cela
peut sembler �trange au premier abord, mais le serveur X _n_e permettra
_p_a_s � cet outil d'acc�der � votre unit� d'affichage. Comment cela est-
il possible alors que _r_o_o_t peut normalement tout faire ? Et comment
contourner ce probl�me ?
�largissons le propos au cas o� l'on veut faire tourner une
application X, sous un identificateur d'utilisateur clientuser, alors
que la session X a �t� lanc�e par serveruser. Si vous avez lu le
paragraphe sur les _c_o_o_k_i_e_s, il est �vident que clientuser ne peut pas
acc�der � votre unit� d'affichage : ~clientuser/.Xauthority ne
contient le cookie magique qui permet d'acc�der � l'unit� d'affichage.
Le cookie correct se trouve dans ~serveruser/.Xauthority.
77..11.. PPlluussiieeuurrss uuttiilliissaatteeuurrss ssuurr llee mm��mmee hh��ttee
Naturellement, tout ce qui marche pour un X distant marchera aussi
pour un X � partir d'un identificateur d'utilisateur diff�rent
(particuli�rement slogin localhost -l clientuser). Et ici l'h�te
client et l'h�te serveur sont pr�cis�ment les m�mes. Cependant, quand
les deux h�tes sont les m�mes, il y a quelques raccourcis pour
transf�rer le _c_o_o_k_i_e _m_a_g_i_q_u_e.
On supposera que l'on utilise su pour passer d'un identificateur
utilisateur � l'autre. Essentiellement, il faut �crire un script qui
appelle su, mais enveloppe la commande que su ex�cute d'un peu de code
qui effectue les t�ches n�cessaires pour le X distant. Ces t�ches
n�cessaires sont l'initialisation de la variable DISPLAY et le
transfert du _c_o_o_k_i_e _m_a_g_i_q_u_e.
L'initialisation de DISPLAY est relativement facile ; il faut
simplement d�finir DISPLAY="$DISPLAY" avant d'ex�cuter l'argument de
la commande su. Donc, il faut simplement faire :
su - clientuser -c "env DISPLAY="$DISPLAY" clientprogram &"
Ce n'est pas tout, il faut encore transf�rer le cookie. On peut le
retrouver en utilisant xauth list "$DISPLAY". Cette commande renvoie
le cookie dans un format qui convient pour le mettre dans xauth; ce
dont nous avons justement besoin ! Donc, on met le cookie obtenu dans
xauth dans le commande su, on initialise DISPLAY ici, et on lance la
commande d�sir�e
su - clientuser -c "xauth add `xauth list $DISPLAY`; \
exec env DISPLAY=$DISPLAY clientprogram"
On peut �crire un script pour r�aliser tout cela, en le param�trant
avec clientuser et clientprogram. Am�liorons un peu le script pendant
que nous y sommes, �a va le rendre un peu moins compr�hensible mais un
peu plus robuste. Le tout ressemble � cela :
#!/bin/sh
if [ $# -lt 2 ]
then echo "usage: `basename $0` clientuser command" >&2
exit 2
fi
CLIENTUSER="$1"; shift
exec su - "$CLIENTUSER" -c "xauth add `xauth list \"$DISPLAY\"`; \
exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*'"
Je pense que c'est portable et que cela fonctionne suffisamment
correctement dans la plupart des circonstances. Le seul d�faut auquel
je pense en ce moment est d� � l'utilisation de '$*', les guillemets
simples dans command vont perturber les guillemets de l'argument('$*')
de la commande su. Si cela entra�ne quelque chose de vraiment g�nant,
envoyez-moi un courrier �lectronique.
Nommez le script /usr/local/bin/xsu, et vous pouvez faire :
xsu clientuser 'command &'
Facile, non ?
77..22.. RRoooott eesstt ll''uuttiilliissaatteeuurr cclliieenntt
�videmment, tout ce qui marche pour un client non root doit
fonctionner pour root. Cependant, avec root vous pouvez faire cela
encore plus facilement, car celui-ci peut lire le fichier
~/.Xauthority de tout le monde. Il n'y a pas besoin de transf�rer le
cookie. Tout ce qu'il y a � faire consiste � initialiser DISPLAY, et �
faire pointer XAUTHORITY sur ~serveruser/.Xauthority. Donc, vous
pouvez �crire :
su - -c "exec env DISPLAY='$DISPLAY' \
XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
command"
Et, en mettant cela dans un script, cela donne quelque chose comme
#!/bin/sh
if [ $# -lt 1 ]
then echo "usage: `basename $0` command" >&2
exit 2
fi
su - -c "exec env DISPLAY='$DISPLAY' \
XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
"'"$SHELL"'" -c '$*'"
Nommez le script /usr/local/bin/xroot, et vous pouvez faire :
xroot 'control-panel &'
Encore plus facile, non ??
88.. FFaaiirree ttoouurrnneerr uunn ggeessttiioonnnnaaiirree ddee ffeenn��ttrreess ddiissttaanntt
Un gestionnaire de fen�tres (comme twm, wmaker, ou fvwm95) est une
application comme n'importe quelle autre. La proc�dure normale devrait
fonctionner.
Enfin, presque. Il ne peut tourner, au plus, qu'un seul gestionnaire
de fen�tres � un instant donn� dans une unit� d'affichage. Si vous
faites d�j� tourner un gestionnaire de fen�tre local, vous ne pouvez
pas lancer le gestionnaire distant (il le dira et s'arr�tera). Il faut
tuer (ou simplement quitter) le gestionnaire local en premier.
Par manque de chance, beaucoup de scripts de sessions X se terminent
par un
exec le-gestionnaire-de-fenetre-de-votre-choix
et cela signifie que quand le gestionnaire de fen�tre (local) se
termine, votre session se termine, et le syst�me (xdm ou xinit)
consid�re que votre session est termin�e, et effectivement, vous
d�connecte.
Vous aurez encore � faire quelques contorsions, mais vous devez y
arriver et ce n'est pas trop difficile. Amusez-vous un peu avec votre
script de session (normalement ~/.xsession ou ~/.xinitrc) pour arriver
� vos fins.
Attention, un gestionnaire de fen�tres permet souvent de faire tourner
de nouveaux programmes qui s'ex�cuteront sur la machine locale.
C'est-�-dire locale � la machine sur lequel tourne le gestionnaire de
fen�tres. Si vous faites tourner un gestionnaire de fen�tres distant,
il lancera des applications distantes, et ce n'est peut-�tre pas ce
que vous voulez. Naturellement, elles continueront � s'afficher sur
l'unit� d'affichage qui est locale pour vous.
99.. MMaaiinntteennaannccee
D'ordinaire, la premi�re fois que vous allez essayer de faire tourner
une application X � distance, �a ne marchera pas. Voici quelques-uns
des messages d'erreur habituels, leur cause probable et des solutions
pour vous aider � progresser.
xterm Xt error: Can't open display:
Il n'y a pas de variable DISPLAY renseign�e dans votre environnement
et vous n'avez pas non plus lanc� l'application avec le drapeau
-display. L'application assume que la variable display contient une
cha�ne de caract�res vide, ce qui est syntaxiquement incorrect. La
solution � cela consiste � s'assurer que la variable DISPLAY est
correctement renseign�e dans l'environnement (avec setenv ou export
selon votre shell).
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
Erreur 101 signifie ``R�seau inaccessible''. L'application n'arrive
pas � se connecter au serveur � travers le r�seau. V�rifiez que la
variable DISPLAY est correctement renseign�e et que la machine
serveur est accessible � partir de votre client (ce qui devrait �tre
le cas, car apr�s tout vous �tes probablement connect� au serveur en
ayant une session telnet avec votre client).
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
Erreur 111 signifie ``Connexion refus�e''. La machine � laquelle vous
�tes en train d'essayer de vous connecter peut �tre atteinte, mais le
serveur indiqu� n'existe pas � cet endroit. V�rifiez que vous
utilisez le nom d'h�te correct et le num�ro d'unit� d'affichage
ad�quat.
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0
Le client pourrait r�aliser une connexion avec le serveur, mais celui-
ci ne permet pas au client de l'utiliser (pas autoris�). Assurez-vous
que vous avez transf�r� le bon cookie au client, et qu'il n'est pas
p�rim� (le serveur utilise un nouveau cookie au d�marrage d'une
nouvelle session).
