it-swarm.it

Aprire una finestra su un display X remoto (perché "Impossibile aprire il display")?

C'era una volta,

DISPLAY=:0.0 totem /path/to/movie.avi

dopo averlo inviato sul mio desktop dal mio laptop, il totem sarebbe riprodotto movie.avi sul mio desktop.

Ora dà l'errore:

No protocol specified
Cannot open display:

Ho reinstallato Debian Squeeze quando è diventato stabile su entrambi i computer e credo di aver rotto la configurazione.

Ho cercato su Google su questo, e non posso per la mia vita capire cosa dovrei fare.

(VLC ha un'interfaccia HTTP che funziona, ma non è conveniente come ssh.)

Lo stesso problema si presenta quando provo ad eseguirlo da un cron job.

83
justin cress

(Adattato da Linux: wmctrl non può aprire il display quando la sessione è iniziata tramite ssh + screen )

DISPLAY e AUTORITÀ

Un programma X richiede due informazioni per connettersi a un display X.

  • Richiede l'indirizzo del display, che in genere è :0 Quando si effettua l'accesso localmente o :10, :11, Ecc. Quando si effettua l'accesso in remoto (ma il numero può cambiare a seconda di quante connessioni X sono attive). L'indirizzo del display è normalmente indicato nella variabile d'ambiente DISPLAY.

  • Ha bisogno della password per il display. Le password di visualizzazione X sono chiamate cookie magici . I cookie magici non vengono specificati direttamente: sono sempre memorizzati in file di autorità X, che sono una raccolta di record del modulo "display :42 Ha cookie 123456". Il file di autorità X viene normalmente indicato nella variabile di ambiente XAUTHORITY. Se $XAUTHORITY Non è impostato, i programmi usano ~/.Xauthority.

Stai tentando di agire sulle finestre visualizzate sul desktop. Se sei l'unica persona che utilizza la tua macchina desktop, è molto probabile che il nome visualizzato sia :0. Trovare la posizione del file di autorità X è più difficile, perché con gdm come impostato in Debian squeeze o Ubuntu 10.04, si trova in un file con un nome generato casualmente. (Non hai mai avuto problemi prima perché le versioni precedenti di gdm utilizzavano l'impostazione predefinita, ovvero i cookie memorizzati in ~/.Xauthority.)

Ottenere i valori delle variabili

Ecco alcuni modi per ottenere i valori di DISPLAY e XAUTHORITY:

  • È possibile avviare sistematicamente una sessione dello schermo dal desktop, magari automaticamente negli script di accesso (da ~/.profile; Ma farlo solo se si accede in X: verifica se DISPLAY è impostato su un valore che inizia con : (che dovrebbe coprire tutti i casi che potresti incontrare)). In ~/.profile:

    case $DISPLAY in
      :*) screen -S local -d -m;;
    esac
    

    Quindi, nella sessione ssh:

    screen -d -r local
    
  • È inoltre possibile salvare i valori di DISPLAY e XAUTHORITY in un file e richiamare i valori. In ~/.profile:

    case $DISPLAY in
      :*) export | grep -E '(^| )(DISPLAY|XAUTHORITY)=' >~/.local-display-setup.sh;;
    esac
    

    Nella sessione ssh:

    . ~/.local-display-setup.sh
    screen
    
  • È possibile rilevare i valori di DISPLAY e XAUTHORITY da un processo in esecuzione. Questo è più difficile da automatizzare. Devi capire il PID di un processo collegato al display su cui vuoi lavorare, quindi ottenere le variabili di ambiente da /proc/$pid/environ (eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Copia dei cookie

Un altro approccio (seguendo un suggerimento di Arrowmaster ) è quello di non cercare di ottenere il valore di $XAUTHORITY Nella sessione ssh, ma invece di fare in modo che la sessione X copi i suoi cookie in ~/.Xauthority. Poiché i cookie vengono generati ogni volta che accedi, non è un problema se mantieni i valori non aggiornati in ~/.Xauthority.

Può esserci un problema di sicurezza se la tua home directory è accessibile tramite NFS o altri file system di rete che consente agli amministratori remoti di visualizzarne i contenuti. Dovrebbero comunque connettersi al tuo computer in qualche modo, a meno che tu non abbia abilitato X TCP (Debian li ha disattivati ​​di default). Quindi per la maggior parte delle persone, questo non si applica (no NFS) o non è un problema (nessuna X TCP).

Per copiare i cookie quando si accede alla sessione X del desktop, aggiungere le seguenti righe a ~/.xprofile O ~/.profile (O qualche altro script letto al momento dell'accesso):

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ In linea di principio, questo non ha una quotazione corretta, ma in questa specifica istanza $DISPLAY E $XAUTHORITY Non conterranno alcun metacarattere Shell.

Ho risolto questo problema aggiungendo

xhost +si:localuser:$USER

per ~/.xprofile. Non so se sia del tutto sicuro (sarei molto interessato a sapere cosa pensano le persone più informate), ma suppongo che sia molto meglio che disattivare il controllo degli accessi (con xhost +) come è comunemente suggerito quando vai su Google per questo problema.

20
edam

Devi export DISPLAY=:0.0

7
asoundmove

Funziona per me, Debian Wheezy -> Ubuntu Trust.

Nota: in questo caso il server non esegue un display-manager, è una macchina virtuale "senza testa" senza scheda grafica o monitor collegati.

[email protected]:~$ grep -iB 1 tcp /etc/gdm3/daemon.conf
[security]
DisallowTCP = false
[email protected]:~$ ssh -C -R 6000:127.0.0.1:6000 [email protected]
X11 forwarding request failed on channel 0
[email protected]:~$ export DISPLAY=:0.0
[email protected]:~$ xterm

Il display X sul laptop mostra l'output di xterm in esecuzione sul server.

Debug usando:

[email protected]:~/tmp$ nc -v 127.0.0.1 6001
localhost [127.0.0.1] 6001 (x11-1) : Connection refused
[email protected]:~/tmp$ nc -v 127.0.0.1 6000
localhost [127.0.0.1] 6000 (x11) open
[email protected]:~$ nc -v 127.0.0.1 6000
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded!*
[email protected]:~$ strace xterm

strace riverserà un sacco di dettagli cruenti su ciò che sta facendo, dovresti essere in grado di indovinare dove si blocca - in attesa di una connessione o altro.

In una riga ..

ssh -C -R 6000:127.0.0.1:6000 [email protected] "DISPLAY=:0.0 xterm"
3
jmullee