<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Remote X Apps mini-HOWTO</TITLE>
</HEAD>
<BODY>
<H1>Remote X Apps mini-HOWTO</H1>
<H2>
<A HREF="http://www.xs4all.nl/~zweije/">Vincent Zweije</A>,
<A HREF="mailto:zweije@xs4all.nl">zweije@xs4all.nl</A></H2>v, 14 luglio 1998
<P><HR>
<EM>Questo mini-HOWTO descrive come eseguire applicazioni X in remoto. Ovvero, come avere un programma X che scrive su un computer diverso da quello su cui sta girando. O viceversa: come far sí che un programma X giri su un computer diverso da quello a cui uno è seduto. L'accento in questo mini-HOWTO è sulla sicurezza. </EM>
<HR>
<H2><A NAME="s1">1. Introduzione</A></H2>
<P>Questo mini-HOWTO è una guida a come far andare
le applicazioni X in remoto. È stato scritto
per parecchie ragioni.
<OL>
<LI> Sono apparse su usenet molte domande su come far andare
applicazioni X in remoto. </LI>
<LI> Vedo molti, molti suggerimenti di ``usare
<CODE>xhost +hostname</CODE>'' o perfino ``<CODE>xhost +</CODE>''
per permettere le connessioni X. <B>Questo è
ridicolmente insicuro</B>, e ci sono metodi migliori. </LI>
<LI> Non conosco un documento semplice che descriva le opzioni
che uno <EM>davvero</EM> ha. Per favore informatemi
<A HREF="mailto:zweije@xs4all.nl">zweije@xs4all.nl</A> se ne sapete di più.</LI>
</OL>
<P>Questo documento è stato scritto avendo in mente
sistemi di tipo unix. Se il vostro sistema locale o remoto è
di un altro tipo, potrete trovare qua come vanno le cose.
Nonostante ciò, dovrete tradurre da soli gli esempi
per adattarli al vostro sistema/i.
<P>La versione [inglese] più recente di questo documento
è sempre disponibile sul WWW all'indirizzo
<A HREF="http://www.xs4all.nl/~zweije/xauth.html">http://www.xs4all.nl/~zweije/xauth.html</A>. È
anche disponibile come il Linux Remote X Apps mini-HOWTO
all'indirizzo
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps</A>. I Linux
(mini-)HOWTO sono disponibili via http o ftp da
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html">sunsite.unc.edu</A>. La traduzione italiana può
essere trovata sul sito
<A HREF="http://pluto.linux.it">http://pluto.linux.it</A> e mirror.
<P>Questa è la versione 0.5.1. Non ci sono garanzie,
solo buone intenzioni. Sono disponibile a suggerimenti, idee,
aggiunte, indicazioni utili, correzioni tipografiche, ecc...
Tuttavia vorrei che questo rimanesse un documento semplice
e leggibile, nello stile HOWTO inteso al meglio. I flame
finiscono in <CODE>/dev/null</CODE>.
<P>Contenuto aggiornato l'ultima volta il 14 Luglio 1998 da
<A HREF="http://www.xs4all.nl/~zweije/index.html">Vincent Zweije</A>.
Traduzione italiana a cura di
<A HREF="mailto:n.pero@mi.flashnet.it">Nicola Pero</A>.
<P>
<H2><A NAME="s2">2. Letture Scelte</A></H2>
<P>Un documento correlato sul WWW è
``Che cosa fare quando Tk dice che il tuo display è
insicuro'' [in inglese],
<A HREF="http://ce-toolkit.crd.ge.com/tkxauth/">http://ce-toolkit.crd.ge.com/tkxauth/</A>. È stato
scritto da
<A HREF="http://ce-toolkit.crd.ge.com/people/kennykb.html">Kevin Kenny</A>. Suggerisce una soluzione all'autenticazione X simile
a quella suggerita in questo documento (xauth). Tuttavia, Kevin
ha più come obiettivo di usare xdm per guidare xauth per voi.
<P>
<P>X System Window System Vol. 8,
``Guida dell'Amministratore di X Window System'' [in inglese]
da
<A HREF="http://www.ora.com/">O'Reilly and Associates</A> è stato anche portato alla mia attenzione
come una buona fonte di informazione. Sfortunatamente, non ho potuto
provarla.
<P>Tuttavia un altro documento molto simile a quello che state
leggendo, intitolato ``Rendere X Windows Sicuro'' [in inglese],
è disponibile presso
<A HREF="http://ciac.llnl.gov/ciac/documents/ciac2316.html">http://ciac.llnl.gov/ciac/documents/ciac2316.html</A>.
<P>Potete anche provare usenet newsgroup, come <CODE>comp.windows.x</CODE>,
<CODE>comp.os.linux.x</CODE>, e <CODE>comp.os.linux.networking</CODE>.
<P>
<H2><A NAME="s3">3. Lo Scenario</A></H2>
<P>State usando due computer. State usando l'X window system del primo
per scrivere e guardare. State usando il secondo per fare qualche
importante lavoro grafico. Volete far sí che il secondo
mostri il suo output sul display del primo. X window system lo rende
possibile.
<P>Naturalmente, avete bisogno di una connessione di rete per fare
ciò. Preferibilmente una connessione veloce; il protocollo X
mangia molte risorse di rete. Ma con un poco di pazienza
e un protocollo di compressione adatto, potete eseguire applicazioni
perfino attraverso un modem. Per la compressione del protocollo X,
potreste voler provare dxpc
<A HREF="http://ccwf.cc.utexas.edu/~zvonler/dxpc/">http://ccwf.cc.utexas.edu/~zvonler/dxpc/</A> o LBX
<A HREF="http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html">http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html</A>
(anche noto come
<A HREF="http://suncite.unc.edu/LDP/HOWTO/mini/LBX">LBX mini-HOWTO</A>).
<P>Dovete fare due cose per ottenere tutto ciò
<P>
<OL>
<LI> Dire al display locale (il server) di accettare connessioni
dal computer remoto.
</LI>
<LI> Dire all'applicazione (il client) di redirigere il suo output
verso il display locale.
</LI>
</OL>
<P>
<H2><A NAME="s4">4. Un Poco di Teoria</A></H2>
<P>La parola magica è <CODE>DISPLAY</CODE>.
Nell'X window system, un display consiste (semplificando)
di una tastiera, un mouse e uno schermo. Un display
è gestito da un programma server, conosciuto come server X.
Il server mette a disposizione le capacità di visualizzazione
agli altri programmi che si connettono a lui.
<P>Un display è indicato con un nome, per esempio:
<P>
<UL>
<LI> <CODE>DISPLAY=light.uni.verse:0</CODE>
</LI>
<LI> <CODE>DISPLAY=localhost:4</CODE>
</LI>
<LI> <CODE>DISPLAY=:0</CODE>
</LI>
</UL>
<P>Il display consiste di uno hostname (come <CODE>light.uni.verse</CODE> e
<CODE>localhost</CODE>), due punti (<CODE>:</CODE>), e un numero di sequenza (come <CODE>0</CODE>
e <CODE>4</CODE>). L'hostname del display è il nome del computer
dove gira il server X. Se l'hostname è omesso si intende
il local host [computer locale]. Il numero di sequenza è
solitamente 0 -- può variare se ci sono più di un display
connessi ad un solo computer.
<P>Se mai vi capita di incontrare una indicazione di display con un <CODE>.n</CODE>
in più attaccato, si tratta del numero dello schermo. Un display
può in realtà avere più di uno schermo. Di solito
tuttavia c'è un solo schermo, che ha numero <CODE>n=0</CODE>, per cui
questo è il default.
<P>Esistono altre forme di <CODE>DISPLAY</CODE>, ma le precedenti sono sufficienti
per i nostri scopi.
<P>
<H2><A NAME="s5">5. Dirlo al Client</A></H2>
<P>Il programma client (per esempio, la vostra applicazione grafica) sa
a quale display deve connettersi da un esame della variabile di
ambiente <CODE>DISPLAY</CODE>. Tuttavia questo settaggio può essere
cambiato, dando al client l'argomento di linea di comando
<CODE>-display hostname:0</CODE> quando viene fatto partire. Alcuni esempi
potrebbero rendere le cose più chiare.
<P>Il nostro computer è noto al mondo esterno come light, e
siamo nel dominio uni.verse. Se stiamo facendo andare un server X normale,
il display è conosciuto come <CODE>light.uni.verse:0</CODE>. Vogliamo
far partire il programma di disegno xfig su un computer remoto,
chiamato <CODE>dark.matt.er</CODE>, e stampare il suo output qua su light.
<P>Supponete di avere già fatto un telnet dentro al computer
remoto, <CODE>dark.matt.er</CODE>.
<P>Se avete csh che sta andando sul computer remoto:
<P>
<BLOCKQUOTE><CODE>
<PRE>
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
</PRE>
</CODE></BLOCKQUOTE>
<P>o alternativamente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
dark% xfig -display light.uni.verse:0 &
</PRE>
</CODE></BLOCKQUOTE>
<P>Se avete sh che sta andando sul computer remoto:
<P>
<BLOCKQUOTE><CODE>
<PRE>
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
</PRE>
</CODE></BLOCKQUOTE>
<P>o, alternativamente,
<P>
<BLOCKQUOTE><CODE>
<PRE>
dark$ DISPLAY=light.uni.verse:0 xfig &
</PRE>
</CODE></BLOCKQUOTE>
<P>o, naturalmente, anche:
<P>
<BLOCKQUOTE><CODE>
<PRE>
dark$ xfig -display light.uni.verse:0 &
</PRE>
</CODE></BLOCKQUOTE>
<P>Sembra che alcune versioni di telnet trasportino automaticamente
la variabile <CODE>DISPLAY</CODE> all'host remoto. Se avete una di queste,
siete fortunati, e non dovete settarlo a mano. Altrimenti,
la maggior parte delle versioni di telnet trasportano la variabile
d'ambiente <CODE>TERM</CODE>; con qualche hacking giudizioso è
possibile "piggyback" [lett., portare indietro a maialino]
la variabile <CODE>DISPLAY</CODE> sulla variabile <CODE>TERM</CODE>.
<P>La idea con il piggybacking è di prepare degli script
per ottenere le cose seguenti: prima di fare il telnet, si attacca
il valore di <CODE>DISPLAY</CODE> a <CODE>TERM</CODE>. Quindi si fa il telnet.
All'estremità remota, nel file <CODE>.*shrc</CODE> appropriato,
si legge il valore di <CODE>DISPLAY</CODE> da <CODE>TERM</CODE>.
<P>
<H2><A NAME="s6">6. Dirlo al Server</A></H2>
<P>Il server non accetterà connessioni da dovunque come niente fosse.
Non volete che tutti possano visualizzare finestre sul vostro schermo.
O leggere quello che state scrivendo -- ricordate che la tastiera
è parte del vostro display!
<P>Troppa poca gente sembra realizzare che permette di accedere al proprio
display pone a rischio la sicurezza. Qualcuno che ha accesso al vostro
display può leggere e scrivere sui vostri schermi, leggere
che tasti premete, e leggere quello che fa il vostro mouse.
<P>La maggior parte dei server conosce due modi di autenticare
le connessioni verso di lui: con la lista di host (xhost) e
con i magic cookie (xauth). Infine c'è ssh, la shell sicura,
che può trasportare le connessioni X.
<P>
<H2>6.1 Xhost</H2>
<P>Xhost permette l'accesso sulla base degli hostname. Il server mantiene
una lista di host che hanno il permesso di connettersi a lui.
Può anche disabilitare completamente il controllo degli host.
Attenzione: questo significa che non viene fatto nessun controllo,
per cui <EM>qualunque</EM> host può connettersi!
<P>Potete controllare la lista di host del server con il programma xhost.
Per usare questo meccanismo nell'esempio precedente, fate:
<P>
<BLOCKQUOTE><CODE>
<PRE>
light$ xhost +dark.matt.er
</PRE>
</CODE></BLOCKQUOTE>
<P>Questo permette tutte le connessioni dall'host <CODE>dark.matt.er</CODE>.
Non appena il vostro client X ha fatto la sua connessione e ha
visualizzato una finestra, per sicurezza, revocate i permessi
di altre connessioni con:
<P>
<BLOCKQUOTE><CODE>
<PRE>
light$ xhost -dark.matt.er
</PRE>
</CODE></BLOCKQUOTE>
<P>Potete disabilitare il controllo degli host con:
<P>
<BLOCKQUOTE><CODE>
<PRE>
light$ xhost +
</PRE>
</CODE></BLOCKQUOTE>
<P>Questo disabilita il controllo di accesso degli host e perciò
permette a <EM>chiunque</EM> di connettersi. Non dovete <EM>mai</EM> fare
questo in una rete in cui non vi fidate di <EM>tutti</EM> gli utenti
(come nel caso di Internet). Potete ri-abilitare il controllo degli host con:
<P>
<BLOCKQUOTE><CODE>
<PRE>
light$ xhost -
</PRE>
</CODE></BLOCKQUOTE>
<P>xhost - da solo <EM>non</EM> rimuove tutti gli host dalla lista di accesso
(il che sarebbe abbastanza inutile - non potreste connettervi da
nessun host, nemmeno dal vostro host locale).
<P><EM>Xhost è un meccanismo molto insicuro.</EM> Non distingue
fra utenti diversi sull'host remoto. Ancora, gli hostname (in realtà
gli indirizzi) possono essere spoofati [=falsificati].
Questo è male se vi trovate in una rete di cui non fidarsi
(per esempio già con un accesso ad Internet con PPP,
via rete telefonica).
<P>
<H2>6.2 Xauth</H2>
<P>Xauth permette l'accesso a chiunque conosca il segreto giusto.
Un tale segreto è chiamato codice di autorizzazione,
o magic cookie [lett, biscottino magico]. Questo schema
di autorizzazione è formalmente chiamato MIT-MAGIC-COOKIE-1.
<P>I cookie per display differenti sono memorizzati insieme nel file
<CODE>~/.Xauthority</CODE>. Il vostro <CODE>~/.Xauthority</CODE>
deve essere inaccessibile al gruppo/ad altri utenti. Il programma
xauth amministra questi cookies, da cui il nomignolo xauth per questo schema
di autorizzazione.
<P>Iniziando una sessione, il server legge un cookie dal file che
è indicato dall'argomento <CODE>-auth</CODE>. Fatto questo,
il server permette connessioni solo da client che conoscono
questo stesso cookie. Quando il cookie in <CODE>~/.Xauthority</CODE>
cambia, <EM>il server non si accorgerà del cambiamento</EM>.
<P>Server più recenti possono generare al volo cookies per i client
che lo richiedono. Tuttavia i cookie sono ancora mantenuti dentro il server;
non finiscono in <CODE>~/.Xauthority</CODE> a meno che un client
non li metta là. Secondo David Wiggins:
<P>
<BLOCKQUOTE>
Un ulteriore espediente che vi potrebbe interessare è
stato aggiunto in X11R6.3. Attraverso la nuova estensione SECURITY,
il server X stesso può generare e restituire nuovi cookie
al volo. Per di più, i cookie possono essere designati
come ``untrusted'' [di cui non fidarsi] in modo che applicazioni
che fanno connessioni con tali cookie avranno delle restrizioni
nelle operazioni. Per esempio, non potranno rubare input di tastiera/mouse,
o contenuti di finestre, da altri client di cui ci si fida.
C'è ora un sottocomando ``genera'' di xauth per rendere questa
funzionalità almeno possibile da usare, se non semplice.
</BLOCKQUOTE>
<P>Xauth ha un chiaro vantaggio di sicurezza sopra xhost. Potete limitare
l'accesso a utenti specifici su computer specifici. Non soffre per
lo spoofing [falsificazione] di indirizzi come fa xhost. E se volete,
potete ancora usare xhost insieme a xauth per permettere connessioni.
<P>
<H3>Costruire i Cookie</H3>
<P>Se volete usare xauth, dovete far partire il server X con l'argomento
<CODE>-auth authfile</CODE>. Se usate lo script startx, è il posto
giusto per farlo. Create una registrazione di autorizzazione, come
mostrato sotto, nel vostro script startx.
<P>Passi scelti da <CODE>/usr/X11R6/bin/startx</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</PRE>
</CODE></BLOCKQUOTE>
<P>Mcookie è un programma minuscolo del pacchetto util-linux,
sito primario
<A HREF="ftp://ftp.math.uio.no/pub/linux/">ftp://ftp.math.uio.no/pub/linux/</A>. In alternativa,
potete usare md5sum per rielaborare dei dati casuali
(per esempio, presi da <CODE>/dev/urandom</CODE> o <CODE>ps -axl</CODE>)
in formato cookie:
<P>
<BLOCKQUOTE><CODE>
<PRE>
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</PRE>
</CODE></BLOCKQUOTE>
<P>Se non potete editare il file startx (perché non siete root),
fate sistemare per bene startx al vostro amministratore di sistema,
o fategli invece mettere su xdm. Se non può o non vuole,
potete fare uno script <CODE>~/.xserverrc</CODE>.
Se avete questo script, xinit lo esegue al posto del vero server X.
Poi potete far partire il vero server X da questo script con gli
argomenti adeguati. Per fare questo, fate usare al vostro
<CODE>~/.xserverrc</CODE> la linea per i magic cookie vista prima
per creare un cookie e quindi eseguire il vero server X:
<P>
<BLOCKQUOTE><CODE>
<PRE>
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</PRE>
</CODE></BLOCKQUOTE>
<P>Se usate xdm per controllare le vostre sessioni X, potete usare xauth
facilmente. Definite la risorsa .authDir del DisplayManager in
<CODE>/etc/X11/xdm/xdm-config</CODE>. Xdm passerà l'argomento
<CODE>-auth</CODE> al server X server quando parte. Quando poi voi fate
un log in sotto xdm, xdm mette il cookie
nel vostro <CODE>~/.Xauthority</CODE> per voi.
Si veda xdm(1) per maggiori informazioni. Per esempio,
il mio <CODE>/etc/X11/xdm/xdm-config</CODE>
contiene la seguente linea:
<P>
<BLOCKQUOTE><CODE>
<PRE>
DisplayManager.authDir: /var/lib/xdm
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>Transportare il Cookie</H3>
<P>Ora che avete incominciato la vostra sessione X sull'host server
<CODE>light.uni.verse</CODE> e che avete il vostro cookie in
<CODE>~/.Xauthority</CODE>, dovrete trasferire il cookie
all'host client, <CODE>dark.matt.er</CODE>.
<P>La cosa più semplice è quando le vostre directory
su light e dark sono condivise. I file <CODE>~/.Xauthority</CODE>
sono gli stessi, per cui il cookie è trasportato simultaneamente.
Tuttavia, c'è un inganno: quando mettete un cookie per
<CODE>:0</CODE> in <CODE>~/.Xauthority</CODE>, dark penserà che sia
un cookie per sé stesso invece che per light. Dovete
usare un host name esplicito quando create un cookie; non potete
tralasciarlo. Potete installare lo stesso cookie sia per
<CODE>:0</CODE> che per <CODE>light:0</CODE> con:
<P>
<BLOCKQUOTE><CODE>
<PRE>
#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</PRE>
</CODE></BLOCKQUOTE>
<P>Se le home directory non sono condivise, potete trasportare il cookie
per mezzo di rsh, la shell remota:
<P>
<BLOCKQUOTE><CODE>
<PRE>
light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -
</PRE>
</CODE></BLOCKQUOTE>
<P>
<OL>
<LI> Estrae il cookie dal vostro <CODE>~/.Xauthority</CODE> locale
(<CODE>xauth nlist :0</CODE>).
</LI>
<LI> Lo trasferisce a dark.matt.er (<CODE>| rsh dark.matt.er</CODE>).
</LI>
<LI> Lo mette nel <CODE>~/.Xauthority</CODE> là
(<CODE>xauth nmerge -</CODE>).
</LI>
</OL>
<P>È possibile che rsh non vada bene per voi. A parte questo, rsh
ha anche un incoveniente per quanto rigurda la sicurezza (host spoofati
[falsificati] di nuovo, se non ricordo male). Se non potete o non volete
usare rsh, potete anche trasferire il cookie manualmente, tipo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
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$
</PRE>
</CODE></BLOCKQUOTE>
<P>Si vedano anche rsh(1) e xauth(1x) per maggiori informazioni.
<P>Potrebbe essere possibile fare un ``piggyback'' del cookie
nella variabile <CODE>TERM</CODE> o <CODE>DISPLAY</CODE> quando fate un telnet
all'host remoto. Questo funzionerebbe nello stesso modo in cui
si fa il piggyback della variabile <CODE>DISPLAY</CODE> sulla variabile
<CODE>TERM</CODE>. Si veda la sezione 5: Dirlo al Client. Dal mio punto
di vista qua sono fatti vostri, ma sono interessato se qualcuno
potesse confermarlo o negarlo.
<P>
<H3>Usare il Cookie</H3>
<P>Una applicazione X su dark.matt.er, come la xfig di prima, guarderà
automaticamente in <CODE>~/.Xauthority</CODE> là per il cookie
con cui autenticarsi.
<P>
<H2>6.3 Ssh</H2>
<P>Le registrazioni di autorità sono trasmesse senza crittografia.
Se siete anche solo impensieriti dall'idea che qualcuno possa snoopare
[annusare] le vostre connessioni, usate ssh, la shell sicura.
Andrà bene per trasportare X sopra connessioni crittate.
E inoltre, è grande anche per molti altri motivi. È
un buon miglioramento strutturale del vostro sistema. Visitate
semplicemente
<A HREF="http://www.cs.hut.fi/ssh/">http://www.cs.hut.fi/ssh/</A>, la home page di ssh.
<P>Chi conosce qualcosa d'altra sugli schemi di autenticazione o di
crittografia delle connessioni X? Forse kerberos?
<P>
<H2><A NAME="s7">7. Risoluzione dei Problemi</A></H2>
<P>La prima volta che cercate di lanciare una applicazione X remota,
di solito non funziona. Ecco qua qualche comune messaggio di errore,
le sue probabili cause, e soluzioni per aiutarvi.
<P>
<BLOCKQUOTE><CODE>
<PRE>
xterm Xt error: Can't open display:
</PRE>
</CODE></BLOCKQUOTE>
<P>Non c'è una variabile <CODE>DISPLAY</CODE> nell'ambiente, e non avete
neanche parlato all'applicazione con il flag <CODE>-display</CODE>. L'applicazione
assume una stringa vuota, ma questa è sintatticamente invalida.
Per risolvere questo problema, assicuratevi di aver settato correttamente
la variabile <CODE>DISPLAY</CODE> nell'ambiente (con <CODE>setenv</CODE> o <CODE>export</CODE>
a seconda della vostra shell).
<P>
<BLOCKQUOTE><CODE>
<PRE>
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</PRE>
</CODE></BLOCKQUOTE>
<P>L'Errno 101 è ``Network is unreachable'' [rete irraggiungibile].
L'applicazione non ha potuto fare una connessione
di rete al server. Controllate di avere settato correttamente
<CODE>DISPLAY</CODE>, e che la macchina server sia raggiungibile dal vostro
client (lo deve essere, dopotutto siete probabilmente loggati
nel server e state facendo un telnet al client).
<P>
<BLOCKQUOTE><CODE>
<PRE>
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</PRE>
</CODE></BLOCKQUOTE>
<P>L'Errno 111 è ``Connection refused'' [Connessione rifiutata].
La macchina server a cui state cercando di connettervi è
raggiungibile, ma là il server indicato non esiste.
Controllate di stare usando l'host name giusto e il numero di display
giusto.
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>Il client ha potuto fare una connessione al server, ma il server
non permette al client di usarlo (non è autorizzato).
Assicuratevi di avere trasportato il magic cookie corretto al client,
e che non sia espirato (il server usa un nuovo cookie quando incomincia
una nuova sessione).
<P>
</BODY>
</HTML>
