<!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>