COMO: Parte 1 - lo básico para aplicaciones remotas en un servidor X local

Imagen de acl

Introducción

El protocolo X11 es el método de comunicación entre las aplicaciones gráficas (xeyes, xterm, konqueror, firefox, ooffice, skype, etc) y el proceso que controla los detalles de la pantalla donde debe desplegarse (un servidor de X). Éste es esencialmente un esquema cliente servidor que puede trabajar sobre distintos tipos de sockets, entre ellos TCP/IP. Esto significa que una aplicación gráfica que se ejecuta en una máquina (llamémosle susana) puede conectarse por tcp a una máquina remota (llamémosle cristina) que mostrará la interfaz de la aplicación, aunque la aplicación se esté ejecutando en el procesador de susana.

Normalmente, cuando estamos usando nuestra distro favorita, la aplicación gráfica y el servidor X están en la misma máquina, pero no hay nada que impida que nuestras aplicaciones se desplieguen en otra máquina que tenga un servidor de X instalado.

Ahora un paréntesis para un poco de convención en el lenguaje: Normalmente pensamos en un servidor como una máquina a la que nos conectamos y no podemos alcanzar; y pensamos el cliente como la máquina a la que tenemos en frente nuestro. Cuando estamos operando con X y familia, el mundo se pone al revés. El servidor X es la máquina que tenemos en nuestro escritorio y el cliente es una máquina (potencialmente) remota.

Tengan en cuenta esto, sin embargo: el cliente de X es un "servidor de aplicaciones", pues es aquel el que usa su procesador y hace todo el "trabajo" de la aplicación. El servidor de X, en cambio no hace sino tomar lo que le dan y mostrarlo en el monitor y es un cliente de despliegue de gráficos.

Cierro paréntesis.

Existen varias formas de preparar las aplicaciones para este efecto. En su forma más simple, podemos redefinir la variable de ambiente $DISPLAY para que apunte a un servidor X de nuestra preferencia:


susana$ echo $DISPLAY
:0.0
susana$ export DISPLAY=192.168.54.65:1
susana$ echo $DISPLAY
192.168.54.65:1
susana$ xterm
xterm Xt error: Can't open display: 192.168.54.65:1
susana$

Como ven, la aplicación xterm intentó conectarse a la máquina que le dijimos. A pesar de que falló, vemos que podemos controlar quién va a recibir y presentar las imágenes que se generan en susana.

El servidor X

Veamos ahora el otro lado de la conversación: el servidor X. Cualquier distro moderna incluye la implementación Xorg de la especificación X11R6 (desarrollada por el X Consortium). Parte de la implementación de la especificación es proveer un proceso que escuche en un socket dado y reciba los mensajes de las aplicaciones clientes. Estos mensajes son traducidos a píxeles y se muestran en el hardware del computador que corre Xorg.

Podemos arrancar un servidor X simplemente con invocarlo:


cristina$ X
cristina$ X

Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.

Esta invocación falló porque ya tengo Xorg corriendo. Casi todas las distros populares inician una instancia de X durante el proceso de arranque. Esa primera instancia toma posesión del primer "display" gráfico de la máquina y existen potencialmente miles de displays en una máquina, y se los numera desde el 0. Para iniciar un servidor de X en un display distinto, simplemente se le incluye como argumento:


cristina$ X :1
<>

Ahora tengo dos displays corriendo en cristina. La primera en la terminal virtual 7 (ctrl+alt +f7) y la segunda en la terminal virtual 8 (ctrl+alt+f8). La segunda no es gran cosa. Una pantalla gris o negra con un cursor en forma de X que puedes mover con el mouse. Pero con eso podemos continuar.

Ahora veamos los sockets en estado de escucha:


cristina# netstat -ntap | grep LISTEN | grep X
tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN 22309/X

Fíjense que hay un proceso de X escuchando en todas las interfaces en el puerto tcp 6001. ¿No se les hace familiar ese 1? Justamente la relación entre número de display y puerto de escucha es puerto = 6000 + display. En terminología de X, se dice que tenemos un servidor X escuchando en "cristina:1". Comparen esto con el display que tiene por defecto un ambiente gráfico: :0

Intentemos ahora conectarnos desde susana:


susana$ export DISPLAY=ip.de.cristina:1
susana$ xterm

Aquí pueden pasar 2 cosas, dependiendo de la distribución. En mi gentoo, la aplicación xterm se despliega en cristina (ctrl+alt+f8 en cristina nos mostrará lo que queremos). Pero puede no ser el caso: es posible que obtengan el siguiente mensaje de error:


Xlib: connection to "ip.de.cristina:1.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: ip.de.cristina:1

Pueden hacer que funcione haciendo:

cristina$ DISPLAY=localhost:1 xhost +
access control disabled, clients can connect from any host

<>
susana$ xterm

Xterm se está ejecutando en susana pero verán los gráficos desplegados en cristina. Desde esta terminal pueden correr cualquier aplicación gráfica y debería mostrarse en cristina. Aquí una captura:

En las siguientes partes veremos cómo podemos hacer en caso que el servidor de X tenga autenticación activada (lo que pudo pasar aquí y ya vimos como resolver de una manera simple, pero insegura), cómo encriptar la comunicación y finalmente cómo desplegar una ventana que se ejecuta en linux en :barf: window$ con la ayuda de Xming

Comentarios

X -query

Imagen de pepo

Si el equipo remoto está habilitado para recibir las conexiones, desde el servidorX (computadora local) yo ejecuto;


X -query

Claro en ocasiones como nos cuentas hay que configurar el programa de control de acceso: xhost

------------------------------------------------
Linux User Registered #232544
Jabber : pepo@jabberes.org
Ekiga : pepo@ekiga.net
ICQ : 337889406
GnuPG-key : www.keyserver.net

------------------------------------------------
Linux User Registered #232544
Jabber : pepo@jabberes.org
Ekiga : pepo@ekiga.net
GnuPG-key : www.keyserver.net

Este caso es distinto pero

Imagen de acl

Este caso es distinto pero similar. Aquí quien escucha es el display manager (xdm, gdm, kdm, etc) que es un programa un tanto especial y cuando envías el -query, X se conecta como un cliente, pero el display manager se encarga de dar valor a la variable DISPLAY a las aplicaciones que arranques desde ese momento. Se dice que el display manager administra tu sesión.

El protocolo que se usa en este caso se llama XDMCP y funciona sobre UDP, lo cual significa que es más difícil de encriptar y por lo tanto es inseguro. No se lo utiliza mucho a través de internet, pero hay lugares en que aún se usa.

También puedes hacer una pregunta de broadcast para saber qué display managers tienes disponibles en tu red con X -broadcast y podrás ver un menú.

--
haber != a ver
ha != a

Y que diferencia tiene este

Imagen de jcyepez

Y que diferencia tiene este método contra el utilizar ssh?

Yo utilizo el comando:
ssh -CXYZ equipo.remoto.con.X
Luego lanzo la aplicación que requiero y de igual manera la aplicación se ejecuta en el equipo al que me he conectado y lo visualizo en mi equipo.

Si me puedes aclarar la duda por favor?

Saludos

Juan Yépez
093681879

Saludos

Juan Yépez
0993681879
Dj - Discomovil Quito

En este caso, ssh se encarga

Imagen de acl

En este caso, ssh se encarga de todos los detalles de autenticación del cliente (copia del cookie, principalmente), pero ya lo describiré en más detalle más adelante. Especificar la opción -X o -Y en ssh justamente hace esa tareilla que no he escrito todavía que no me meto con cómo funciona la autenticación.

--
haber != a ver
ha != a