Abra una window en una pantalla X remota (¿por qué "No se puede abrir la pantalla")?

Había una vez,

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

después de entrar a mi escritorio desde mi computadora portátil provocaría que totem reproduzca movie.avi en mi escritorio.

Ahora da el error:

 No protocol specified Cannot open display: 

Reinstalé Debian squeeze cuando se volvió estable en ambas computadoras, y creo que rompí la configuration.

He buscado en Google esto, y no puedo imaginar lo que se supone que debo hacer.

(VLC tiene una interfaz HTTP que funciona, pero no es tan conveniente como ssh).

El mismo problema surge cuando bash ejecutar esto desde un trabajo cron.

(Adaptado de Linux: wmctrl no puede abrir la pantalla cuando la session se inicia a través de la pantalla ssh + )

PANTALLA y AUTORIDAD

Un progtwig X necesita dos piezas de información para conectarse a una pantalla X.

  • Necesita la dirección de la pantalla, que normalmente es :0 cuando está conectado localmente o :10 :11 , etc. cuando está conectado de forma remota (pero el número puede cambiar dependiendo de cuántas conexiones X hay activas) ) La dirección de la pantalla normalmente se indica en la variable de entorno DISPLAY .

  • Necesita la contraseña para la pantalla. Las passwords de visualización X se llaman cookies mágicas . Las cookies mágicas no se especifican directamente: siempre se almacenan en files de autoridad X, que son una colección de loggings del formulario "pantalla :42 tiene cookie 123456 ". El file de autorización X normalmente se indica en la variable de entorno XAUTHORITY . Si $XAUTHORITY no está configurado, los progtwigs usan ~/.Xauthority .

Estás tratando de actuar en las windows que se muestran en tu escritorio. Si usted es la única persona que usa su máquina de escritorio, es muy probable que el nombre para mostrar sea :0 . Encontrar la location del file de autorización X es más difícil, porque con gdm como se configuró en Debian squeeze o Ubuntu 10.04, está en un file con un nombre generado aleatoriamente. (No tuvo ningún problema antes porque las versiones anteriores de gdm usaban la configuration pnetworkingeterminada, es decir, las cookies almacenadas en ~/.Xauthority ).

Obteniendo los valores de las variables

Aquí hay algunas maneras de get los valores de DISPLAY y XAUTHORITY :

  • Puede iniciar sistemáticamente una session de pantalla desde su escritorio, tal vez automáticamente en sus scripts de inicio de session (desde ~/.profile ; pero hágalo solo si ~/.profile session en X: pruebe si DISPLAY está configurado en un valor que comience por : (eso debería abarcar todos los casos que es probable que encuentre)). En ~/.profile :

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

    Luego, en la session ssh:

     screen -d -r local 
  • También puede save los valores de DISPLAY y XAUTHORITY en un file y recuperar los valores. En ~/.profile :

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

    En la session ssh:

     . ~/.local-display-setup.sh screen 
  • Puede detectar los valores de DISPLAY y XAUTHORITY desde un process en ejecución. Esto es más difícil de automatizar. Debe averiguar el PID de un process que está conectado a la pantalla en la que desea trabajar, luego obtenga las variables de entorno de /proc/$pid/environ ( eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Copiando las cookies

Otro enfoque (siguiendo una sugerencia de Arrowmaster ) es no tratar de get el valor de $XAUTHORITY en la session ssh, sino hacer que la session X copie sus cookies en ~/.Xauthority . Dado que las cookies se generan cada vez que ~/.Xauthority session, no es un problema si mantiene valores obsoletos en ~/.Xauthority .

Puede haber un problema de security si se puede acceder a su directory de inicio a través de NFS u otro sistema de files de networking que permita a los administradores remotos ver sus contenidos. De todos modos, necesitarían conectarse a su máquina, a less que haya habilitado X conexiones TCP (Debian las tiene desactivadas de manera pnetworkingeterminada). Entonces, para la mayoría de la gente, esto no se aplica (no es NFS) o no es un problema (no hay conexiones X TCP).

Para copyr las cookies cuando ~/.xprofile session en su session X de escritorio, agregue las siguientes líneas a ~/.xprofile o ~/.profile (o alguna otra secuencia de commands que se lee cuando ~/.profile session):

 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 

¹ En principio, esto carece de comillas adecuadas, pero en este caso específico $DISPLAY y $XAUTHORITY no contendrán ningún metacarácter de shell.

Resolví este problema añadiendo

 xhost +si:localuser:$USER 

a ~/.xprofile . No sé si esto es completamente seguro (estaría muy interesado en escuchar lo que piensa la gente más enterada), pero supongo que es mucho mejor que desactivar el control de acceso (con xhost + ) como se sugiere comúnmente. cuando buscas en Google este problema

Necesita export DISPLAY=:0.0

Funciona para mí, debian wheezy -> ubuntu trusty.

Nota: en este caso, el server no está ejecutando un administrador de pantalla, es una máquina virtual "sin cabeza" sin una tarjeta gráfica o monitor conectado.

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

La pantalla X en la computadora portátil muestra la salida de xterm ejecutándose en el server.

Depurar usando:

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

strace dertwigrá una gran cantidad de detalles sangrientos sobre lo que está haciendo, usted debería ser capaz de adivinar dónde se queda atascado, esperando una connection o lo que sea.

En una línea …

 ssh -C -R 6000:127.0.0.1:6000 alice@server "DISPLAY=:0.0 xterm"