X MODELO CLIENTE - SERVIDOR

En el principio las computadoras eran aparatos enormes, mainframes, hosts o como quieran
llamarlos.
El concepto de red que hoy conocemos no estaba tan difundido, justamente porque esas
computadoras eran carisimas, y solo las tenian los militares, las universidades, las grandes
empresas, etc.
Entonces, como hacian muchas personas para trabajar en conjunto sin tener que estar en la misma
computadora, con 20 teclados a la vez? :) - Se utilizaban terminales 'bobas', justamente por no
tener una gran capacidad de procesamiento. De hecho tenian muy poca. Se las vinculaba mediante
puerto serie (por ejemplo) al HOST central, y alli obtenian un shell Unix, VMS, etc. Por supuesto,
esto era todo muy bueno cuando trabajabamos en modo texto, en la consola simple, tan amada por
los odiadores del mouse (me incluyo).
Luego se dise un sistema grafico, y las terminales bobas necesitaban tener al menos la capacidad
de ejecutar un controlador de modo de video, que no necesitaba tanto procesamiento. Ya eran
menos bobas, pero no tanto. Ustedes se preguntaran: "de que sirve solo tener un controlador
grafico y no tener poder para ejecutar aplicaciones?" - Bueno, este controlador grafico es en verdad
el Servidor X. Un servidor X es un conjunto de controladores de placas de video, y tambien un
conjunto de funciones basicas, como por ejemplo: "dibujar en las coordenadas x1,y1,x2,y2 un
cuadrado".
Claro, tener funciones de dibujo no sirve de nada si no tenemos programas que las utilicen. Estos
programas se llaman "clientes X", ya que acceden a las funciones de un "servidor X". Y si,
adivinaron: los clientes X se ejecutaban en los HOSTS centrales, pero se conectaban al servidor X
de nuestra terminal ya-no-tan-boba. Este es el concepto de XWindow bajo la arquitectura
Cliente/Servidor: Los 'programas' son clientes que se conectan a un servidor, y el servidor hace lo
que le piden. Obviamente el servidor X tambien se encarga de controlar el mouse, teclado, y otros
dispositivos de entrada, asi como tambien varios monitores simultaneamente, etc.
Luego de tener claro este concepto podemos llegar a suponer de forma muy acertada que esta
funcionalidad se mantiene en el actual XWindow, asi que vayamos a la practica:
Imaginen de que no tienen espacio para instalar, por ejemplo, OpenOffice, o que les faltan las
librerias necesarias para hacer anda tal programa para XWindow. Si estan en una red, o via banda
ancha, o incluso modem (aunque tendremos que armarnos de PACIENCIA!), pueden averiguar si
en otra computadora con GNU/Linux se encuentra el programa en cuestion instalado. Entonces,
con solamente conectarnos via SSH, o telnet, o como fuere mientras podamos ejecutar un
programa instalado en dicho sistema, podremos ver y usar en nuestro servidor X el cliente X en
cuestion, o sea el programa que estemos ejecutando.
Ustedes diran: "Claro... y como sabe el cliente X a que servidor X se tiene que conectar?". Simple:
lo sabe a traves de una variable de entorno llamada DISPLAY, o a traves de un parametro en la
linea de comandos del programa.
En principio, la variable DISPLAY debe contener nuestra direccion IP y tambien el numero de
pantalla X que se esta usando. Generalmente por cada PC funciona un solo servidor X por vez, y un
solo monitor, por lo que sera el "Display 0". Intentaron alguna vez ejecutar un programa de
XWindow directamente desde la consola? Habran visto el mensaje de error "Can't open display"
(no se puede abrir la pantalla, digamos). Justamente, los programas X (clientes X) necesitan que
haya un display (servidor X) activo para poder funcionar.

Entonces, ya tenemos lo siguiente: la variable DISPLAY debe contener el par

direccion_IP:numero_de_display. Por ejemplo, "200.45.23.111:0". Al ejecutar el programa X
teniendo esa variable de entorno 'seteada', el cliente X se conectara al servidor X que esta
funcionando en 200.45.23.111, y si la coneccion es aceptada (ya veremos por que), enviara datos al
display 0.
Entonces, iniciemos XWindow ('startx'). Abramos una xterm o algun equivalente que nos de un
shell. Ahora ingresemos por ssh (o como fuere) a algun sistema GNU/Linux donde tengamos una
cuenta shell. Para poder setear la variable DISPLAY necesitamos saber nuestra direccion IP. Eso lo
podemos hacer con el /sbin/ifconfig. Abramos OTRA xterm, y en dicha xterm ejecutemos ifconfig.
Busquemos la interfaz por la que estamos conectados al otro sistema GNU/Linux (por ejemplo,
ppp0 o eth0), y tomemos la direccion IP que aparece en "Inet addr:". Llamaremos a este valor
"server_ip". Ahora tenemos los elementos necesarios: IP y numero de display (usaremos el 0).
Ingresemos el siguiente comando en la sesion remota (la otra cuenta shell): " export
DISPLAY=server_ip:0". Por ejemplo, si nuestra direccion IP fuera 200.20.2.22 ingresariamos
"export DISPLAY=200.20.2.22:0" en la xterm de la sesion remota, para asi informarle a los clientes
X a que servidor y display X deben conectarse para enviar sus graficos, y recibir sus respuestas.
Ahora intentemos ejecutar algun programa de X, por ejemplo otra 'xterm' o el 'gimp' o el que
quieran, incluso el KDE (aunque hay que tomar una consideracion especial para esto). Claro,
ejecutemoslo desde la sesion remota!.
Si todo sale bien, veremos la xterm remota en nuestra pantalla. Pero no, no va a salir bien, porque
no le dimos PERMISO a ese cliente X de que se conecte a nuestro servidor X!
Como le damos permiso? Con el comando 'xhost'. Este comando se utiliza de la siguiente manera:

"xhost +": elimina toda restriccion, cualquier cliente puede conectarse

"xhost -": activa las restricciones, solo los clientes autorizados pueden
conectarse.
"xhost +IP": permite que la IP indicada se conecte. "xhost -IP":
elimina el permiso de coneccion a la direccion IP indicada.

Entonces, necesitamos saber la direccion IP de la maquina donde se encuentran los clientes X que
queremos ejecutar, o sea, donde nosotros ahora estamos via ssh o telnet. Recuerdan como hicimos
para obtener la IP de nuestro sistema? Si, con el ifconfig. Hagamos lo mismo en el sistema remoto:
"/sbin/ifconfig". Debemos indicar el path completo ya que lo mas probable es que no seamos
'root' en ese sistema, y el /sbin no se incluye en el PATH para usuarios comunes. Una vez obtenida
la IP... solo hagamos "xhost +esa_ip" y listo. Volvamos a ejecutar el xterm, y esta vez SI lo
veremos aparecer en nuestro display, de a no ser que tengamos iptables o ipchains filtrando los
puertos del 6000 al 6063, que son los que XWindow utiliza para recibir conecciones de clientes.
Esto lo podemos obtener haciendo "grep x11 /etc/services".
Ahora ustedes piensen: cuando ponen XWindow, no solo aparece el servidor X (el cual pueden
cargar con el comando 'X', en vez de 'startx'), sino que aparecen una serie de programas:
Administrador de ventanas o de escritorio, alguna que otra xterm o similar, etc. En este caso, el
servidor X y los clientes X se conectan mediante la interfaz 'loopback', la famosa direccion IP
'127.0.0.1', la que siempre que hagamos 'ifconfig' va a estar, de a no ser que la desactivemos (algo
para nada aconsejable).
Claro, en este caso no usamos xhost, ni nada. Somos nosotros mismos ejecutando tanto el server
como los clientes, en el mismo teclado, misma PC, mismo usuario, etc.
Entonces, en resumen, todo el tiempo X esta funcionando como servidor y recibe permanentes
conecciones de clientes X, y generalmente estos son 'locales', y no 'remotos'.

Veamos entonces, para que un cliente X remoto se ejecute en nuestro display, el resumen de los
comandos o pasos necesarios es el siguiente:
1. Iniciar XWindow por el metodo elegido (X o startx).
2. Obtener nuestra direccion IP utilizando ifconfig. Este sera el valor que
usaremos para la variable DISPLAY en el sistema remoto.
3. desde un shell (sea de otra consola, o desde una xterm en el XWindow
recien cargado) conectarnos por ssh, telnet o el metodo que sea a otro
sistema GNU/Linux o U*nix, tambien, ya que el protocolo X es comun a
todos.
4. Obtener la IP del sistema remoto (otra vez ifconfig).
5. Localmente, habilitar dicha IP con xhost +IP.
6. Remotamente, ejecutar "export DISPLAY=ip_nuestra:0". ip_nuestra es
el valor obtenido en el paso (2).
7. Ultimo paso, ejecutar el cliente X en cuestion, claro esta desde el
sistema remoto.
Y si todo anda bien, o sea, no hay firewalls molestando en ningun lado, veremos el cliente X en
nuestra pantalla.
Ahora, utilizar la variable de entorno DISPLAY es la mejor opcion, creo yo, ya que aunque
podemos indicar mediante parametros al cliente X a que servidor X conectarse, no siempre este
parametro es exactamente igual en todo cliente. En cambio el uso de la variable de entorno
DISPLAY esta 'estandarizado'. Aparte nos ahorra el hecho de tener que indicarle mas parametros a
los programas!
De todas formas, el parametro que los clientes X aceptan es generalmente "-display" o "--display" y
en algunos casos no tiene nada que ver. Tendremos que ver la documentacion o modo de uso (-help si se encuentra disponible, o -h) del cliente en cuestion. Entonces, para ejecutar la xterm
mediante parametros o no mediante la variable de entorno, hariamos lo siguiente:
xterm -display 200.20.2.22:0

Otros programas quiza necesiten --display, o incluso un parametro o formato totalmente

diferente. Ah! Y en caso de que necesiten eliminar el valor de la variable de entorno DISPLAY,
pueden hacerlo con "export DISPLAY=" (con el = al final). Con ello tendra un valor vacio.
De esta forma me despido hasta la proxima, y no olviden que yo armo esta seccion en base a las
consultas de los lectores. Escribanme a linux@tectimes.com, que me haran llegar sus consultas e
inquietudes.

$ xinit

Obtendremos una sesin X en la primera tty libre (si no tenemos otra sesin grfica abierta
ser la terminal tty7) con un xterm abierto. En ese xterm ejecutaremos el comando:
$ xhost +nombre_de_host

Atencin
Nunca usaremos el comando xhost +, ya que permite a cualquier cliente conectarse y
tomar el control de las X. Siempre especificaremos un host.

A continuacin, abriremos una sesin SSH en el servidor desde cualquier terminal del host
cliente, ejecutando en el host cliente el comando:
$ ssh <IP_servidor>

Por ejemplo:
$ ssh 192.168.1.3

En la terminal SSH, estableceremos el valor de la variable DISPLAY, ejecutando el

comando:
$ export DISPLAY=<IP_host_cliente>:0

Por ejemplo:
$ export DISPLAY=192.168.1.2:0

Por ltimo, ejecutaremos en la terminal SSH el comando que lanza el window manager
(por ejemplo, icewm-session):
$ icewm-session

De esta manera obtendremos en la terminal tty7 la sesin X remota.

En el host cliente tendremos activos los procesos servidor X (Xorg) y xterm, que cuelgan
de xinit, y ssh:
$ pstree
init-+|-login---bash-+-xinit-+-Xorg
|

|-xterm---bash

|-ssh

Y en el servidor tendremos activo el proceso window manager (por ejemplo, icewmsession), que cuelga del demonio sshd:
$ pstree
init-+|-sshd---sshd---bash---icewm-session

Si ya tenamos en el host cliente una sesin X local abierta, para iniciar una sesin X
remota tendremos que especificar el DISPLAY tanto al lanzar xinit:

$ xinit -- :1
$ xhost +

como al exportar la variable DISPLAY en la terminal SSH:

$ export DISPLAY=192.168.1.2:1
$ icewm-session

Obtendremos una sesin X en la primera tty libre (por ejemplo la terminal tty8).

De la misma manera, si queremos abrir otra sesin X remota en el host cliente tendremos
que especificar el DISPLAY tanto al lanzar xinit:

$ xinit -- :2 &
$ xhost +

como al exportar la variable DISPLAY en la terminal SSH:

$ export DISPLAY=192.168.1.2:2
$ icewm-session

Obtendremos una sesin X en la primera tty libre (por ejemplo la terminal tty9).
En el host cliente tendremos activos los procesos:
$ pstree
init-+|-login---bash-+-xinit-+-Xorg
|

|-ssh

|-xterm---bash

|-login---bash-+-xinit-+-Xorg
|

|-xterm---bash

|-ssh

Y en el servidor tendremos activos los procesos:

$ pstree
init-+|-sshd-+-sshd---bash---icewm-session
|-sshd---bash---icewm-session

Cmo configurar el sistema para sesiones grficas remotas

Por Joel Barrios Dueas
mailto:jbarrios@-QUITAR-ESTO-linuxparatodos.com
http://www.linuxparatodos.com/
Copyright 1999-2003 Joel Barrios Dueas.
Se otorga el permiso para copiar, distribuir y modificar este documento bajo los trminos de la
Licencia de Documentacin Libre del GNU, versin 1.1 o cualquier otra posterior publicada por Free
Software Foundation; este documento no consta de secciones invariantes ni con portadas o
contraportadas. Una copia de la licencia se incluye en la documentacin del sitio.
Linux es una marca registrada de Linus Torvalds, LinuxPPP es una marca registrada de Jos Neif
Jury Fabre, RedHat Linux, RPM y GLINT son marcas registradas de RedHat Software, Unix es
marca registrada de X/Open. Apache es una marca registrada de The Apache Group. Otras marcas
registradas son propiedad intelectual de sus autores o propietarios.
La informacin contenida en este documento se proporciona tal cual es y el autor no asumir
responsabilidad alguna por el mal uso que se haga de esta.

Introduccin.
Cuando se tienen distintas mquinas en una LAN y se desea aprovechar el poder y recursos de una de estas y
ahorrar trabaj, una sesin grfica remota ser de gran utilidad. Lograr esto es muy fcil. Se puede hacer de
dos formas, una accediendo va SSH, RHS o Telnet, y la otra utilizando alguna de las pantallas de acceso
grfico, como GDM.

Sesin grfica remota con RHS, SSH o Telnet.

Aunque es un tanto ms complejo que utilizar GDM, es un mtodo muy popular y utilizado con mayor
frecuencia en distintos tipos de sistemas basados sobre UNIX.

Procedimiento.
1. Abrase una sesin X de la mquina cliente, pero sin utilizar startx, y utilcese en cambio el comando
xinit para que se abra slo una consola grfica.
2. En la consola grfica de la mquina cliente, debe ejecutarse el siguiente comando:
xhost +

3. Tmese nota de la direccin IP de la mquina cliente y hgase ssh, telnet, rsh, o lo que se prefiera,
al servidor.
4. En terminal del telnet, modifquese la direccin del DISPLAY. Suponiendo que la direccin IP de la
mquina cliente es 192.168.0.3, entonces debe ejecutarse:
export DISPLAY=192.168.0.3:0

5. En la terminal de ssh, rsh o telnet, debe ejecutarse el comando que lanza entorno grfico de su
preferencia, como sera gnome-session o startkde. No debe utilizarse startx porque no funcionar.
6. Disfrute de su sesin X remota.

Sesin grfica remota con GDM.

GDM tiene una caracterstica poco usada, pero muy til. El mtodo ser de mucha utilidad suponiendo que
se tiene un servidor central con buena cantidad de memoria y un buen microprocesador y lo ms nuevo en
software, y en la red de rea local (LAN) se tienen una o varias mquinas con muy poco espacio en disco y/o

poco poder en el microprocesador, o resulta mucho trabajo instalarles todo un sistema optimizado y
personalizado.
El objetivo ser entonces querrs que los usuarios puedan utilizar el servidor con mayor poder y recursos
para que se ejecuten ah las sesiones grficas y as tener un mayor control en toda la red.
Las pruebas realizadas para la redaccin de este manual se hicieron en los siguientes equipos:

Servidores:
o Mandrake 7.2 + actualizaciones disponibles a la fecha + XFree86-4.0.3 + Ximian GNOME1.4 + kernel-2.4.5, en un equipo Pentium III 550 MHz, 256 MB RAM. Bogomips: 1101.
o LinuxPPP 6.4 + actualizaciones disponibles a la fecha + XFree86-4.0.3 + Ximian GNOME1.4 + kernel-2.2.19, en un equipo Pentium III 700 MHz, 512 MB RAM. Bogomips: 1399.19
Clientes: utilizaron un rudimentario Mandrake 7 o LinuxPPP 6.4 con XFree86-3.3.6 instalado.
Concentrador: Encore ENH705-TX base 100 TX.

Procedimiento.
1. Actualice gdm al menos a la versin 2.2.x o, de ser posible, ms reciente.
2. En el servidor, debe abrirse una terminal como superusuario y debe ejecutarse el comando
gdmconfig, vaya a la seccin de Expert y de all a la pestaa XDMCP, deben habilitarse las casillas
de "Activar XDMCP" y "Honrar peticiones indirectas" y despus re-iniciar gdm.

3. Debe determinarse la localizacin de X con el comando which:

which X

4. En los clientes, debe respaldarse y editarse el archivo /etc/X11/prefdm y debe hacerse que contenga
nicamente lo siguiente, considerando que se debe poner la ruta completa de X:

#!/bin/sh
/usr/X11R6/bin/X -query direccin_IP_del_Servidor

Ejemplo:
#!/bin/sh
/usr/X11R6/bin/X -query 192.168.1.254

5. En todas las mquinas, ya sea que si se utiliza linuxconf o alguna otra herramienta, hgase que el
modo de ejecucin sea grfico y con red, es decir que arranque en modo de ejecucin 5 (o nivel de
corrida 5).
6. Deben re-iniciarse los servidores X de las mquinas clientes.
7. Las mquinas clientes vern a GDM ejecutndose como si se estuviese en el mismo servidor, y
permitir iniciar GNOME o KDE o cualquier otro entorno grfico utilizado. Si cuenta con buenos
adaptadores de red, ni siquiera se notar si se est en un cliente o en el servidor.

9. Ms formas de uso de ssh

El protocolo ssh adems de permitirle conectarse a servidores en modo texto (ver Seccin 2.3, Conexin
con ssh) le permite iniciar aplicaciones grficas que se ejecuten en el servidor, hacer redireccionamiento de
puertos y conectarse sin necesidad de dar clave (dando una clave slo una vez en su computador).

9.1. Abrir programas con interfaz grfica

Es posible ejecutar aplicaciones grficas en el servidor y ver las ventanas grficas en otro computador. Para
esto es necesario:
1. Que en el archivo de configuracin /etc/ssh/sshd_config del servidor est habilitada la opcin:
2. X11Forwarding yes

3. Que en el computador donde se desea ver la informacin est instalado un servidor de X-Window.
En el caso de sistemas tipo Unix basta con tener X-Window instalado (si ve el modo grfico es porque ya
est instalado). Para otros sistemas operativos puede ser posible encontrar un servidor de X-Window, por
ejemplo para Windows, puede emplear Cygwin-X (http://x.cygwin.com) o Xming
(http://www.straightrunning.com/XmingNotes/).
Una vez est ejecutndo el servidor de X-Window en su computador entre al servidor usando ssh con opcin
para hacer reenvo de X11. De esta manera toda la informacin grfica enviada por el servidor viajar por el
canal seguro que ssh establece cuando se conecta al servidor. En el caso de OpenSSH esto se indica con la
opcin -X, i.e se debe conectar con:
ssh -X juan@pasosdeJesus.org

En el caso de putty en el dialogo de configuracin que aparece antes de iniciar la conexin, en el men
Connection->SSH->X11 marque 'Enable X11 forwarding'.

Una vez haga esto, las aplicaciones grficas que inicie en la sesin ssh que inici, se vern en su
computador. Pruebe por ejemplo con:
xeyes

9.2. Tuneles con SSH

Puede usar ssh tambin para crear un tnel entre un puerto local y un puerto accequible desde el servidor al
cual se conecta. Por ejemplo si en una organizacin tienen un cortafuegos conectado a Internet (digamos que
es pasosdeJesus.org) y en la red interna cuentan con un servidor web SSL (por ejemplo base), podra
establecerse un tnel desde un computador fuera de la organizacin y el servidor privado, ingresando al
cortafuegos con:
ssh -L10443:base:443 juan@pasosdeJesus.org

donde base es el nombre del servidor al interior de la organizacin y 443 es el nmero de puerto de HTTPS
(protocolo HTTP sobre SSL, es decir conexiones web encriptadas).
Si emplea putty debe especificar esta informacin en el dilogo de configuracin Connection->SSH>Tunnels como se presenta a continuacin presionando el botn Add para adicionar el tnel a la regin
`Forwarded ports'.

Una vez inicie la conexin debe digitar la clave del usuario en el cortafuegos. Con lo cual quedar
establecido un tnel entre el puerto 10443 del computador local y el puerto 443 del servidor base. Este tnel
puede usarse ingresando en un navegador la direccin:
https://127.0.0.1:10443

Conexiones X y Tunneling
El uso de las X bajo encapsulado dentro de la conexin ssh es un ejemplo de tunneling. Tunneling o
redireccionamiento de puertos (port forwarding) es una tcnica que permite redireccionar trfico TCP inseguro a
travs de SSH.

Para establecer una conexin grfica use la opcin -X.

$ ssh -X loginname@machine1
lhp@nereida:~$ ssh -X orion
Linux machine1 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux
$ echo $DISPLAY
localhost:10.0

En el sistema de ventanas X un display consiste en un teclado, un ratn y una pantalla. Cuando se invoca un
cliente X este necesita saber que DISPLAY utilizar. Un display queda determinado por una cadena de la
forma HOST:n.v, donde:

HOST es el nombre de la mquina que ejecuta el X server que controla el display

n es el nmero de display, un entero. X permite que hayan mltiples displays conectados a un servidor
v Es el nmero de pantalla. Un display puede tener mltiples pantallas. X soporta mltiples displays virtuales

en un mismo display fsico.

El hecho de que $DISPLAY valga localhost:10.0 se traduce en la instruccin: 'conctate con TCP al
puerto 10+6000 = 6010'. La aplicacin ejecutndose en orion, por ejemplo xclock se conectar al puerto
6010 de localhost (orion). El daemon de ssh en orion esta ya escuchando en ese puerto y redirige la salida
grfica en ese puerto atravs del puerto 22 de orion hacia el cliente. El mensaje est cifrado. El mensaje
cifrado es recibido por el cliente el cul lo descifra y lo enva descifrado al servidor X local. Obsrvese que
el puerto 6010 de orion slo es accedido desde orion. No hay por tanto necesidad de dejar los puertos del
servicio X 6000 en adelante abiertos al exterior.

Figura: Redireccin de las X via SSH

Comprobemos lo dicho con un ejemplo. Primero nos conectamos a una mquina solicitando
redireccionamiento de las X y comprobamos donde esta puesto el DISPLAY:
lusasoft@LusaSoft:~$ ssh -X pp2@europa.deioc.ull.es
pp2@europa:~$ env | grep -i displa
DISPLAY=localhost:21.0
pp2@europa:~$

Ahora arrancamos una segunda sesin SSH, pero no solicitamos redireccin de las X. Establecemos la
variable DISPLAY al valor que tenemos en la otra sesin y reutilizamos el servicio de redireccin:
lusasoft@LusaSoft:~$ ssh pp2@europa.deioc.ull.es
pp2@europa:~$ export DISPLAY=localhost:21.0
pp2@europa:~$ xclock & # Aparece un reloj en nuestro escritorio
[1] 5904

pp2@europa:~$
pp2@europa:~$ konsole & # Aparece una consola KDE en el escritorio
[2] 5906
pp2@europa:~$ kbuildsycoca running...
Reusing existing ksycoca
kdecore (KProcess): WARNING: _attachPty() 10

Es posible especificar tambin el redireccionamiento de las X con la opcin ForwardX11 yes en el fichero
de configuracin.
Si no funciona el tunneling de las X puede ser debido a la configuracin de ssh. Habra que comprobar los
ficheros de configuracin del cliente ssh_config y del servicio sshd_config. Habitualmente la
configuracin por defecto desabilita el redireccionamiento de las X. Para permitirlo hay que poner:
X11Forwarding yes

y las siguientes lneas en el fichero de configuracin del cliente /etc/ssh/ssh_config:

ForwardAgent yes
ForwardX11 yes

Por ejemplo:
$ grep X11 /etc/ssh/ssh*fig
/etc/ssh/ssh_config:#
ForwardX11 no
/etc/ssh/ssh_config:#
ForwardX11Trusted yes
/etc/ssh/sshd_config:X11Forwarding yes
/etc/ssh/sshd_config:X11DisplayOffset 10

El servicio ssh modifica automticamente la variable de entorno DISPLAY a un valor de la forma

hostname:n donde hostname es el nombre de la mquina en la que se ejecuta la shell y n es un entero. El
usuario no debera establecer el valor de esta variable manualmente.
Un Desktop Environment Remoto va SSH: Gnome

Supongamos que tenemos KDE en la mquina local. Nos conectamos a la mquina remota con redireccin
de las X:
pp2@nereida:~/pp2bin$ ssh -X -v beowulf

Ahora podemos establecer un escritorio Gnome sin mas que invocarlo en la mquina remota:
casiano@beowulf:~$ gnome-session &

Ejercicio 2.1.18 Abrimos un navegador (mozilla o equivalente). Abra otra aplicacin grfica (un juego). Cierre el
desktop remoto. Se cierra el navegador?. Se cierra el juego?

Observe que procesos suyos se estn ejecutando en la mquina remota despus de cerrado el desktop
grfico:
casiano@beowulf:~$ ps
casiano
302
1
casiano
900
1
casiano
953 32648
casiano
954 32648

-fA | grep casiano

0 13:34 ?
00:00:00
0 13:45 pts/2
00:00:01
0 13:48 pts/2
00:00:00
0 13:48 pts/2
00:00:00

xscreensaver -nosplash
/usr/lib/iceape/iceape-bin -browser
ps -fA
grep casiano

Es posible que tenga que matar alguno:

casiano@beowulf:~$ kill -9 302
debug1: channel 11: FORCE input drain
casiano@beowulf:~$ debug1: channel 11: free: x11, nchannels 5

Ejercicio 2.1.19 Conecte de nuevo con redireccin de las X a la mquina remota:

pp2@nereida:~/pp2bin$ ssh -X -v beowulf

Inicie el escritorio de KDE:

$ startkde

Que ocurre?
Desktop Remoto desde una de las Consolas Alternativas
1. Entre en una de las terminales alternativas pulsando CTRL-ALT-F2 (o cualquier otra TTY alternativa). Ahora
podemos conmutar entre las terminales desde ALT-F1 hasta ALT-F6. Para volver a la sesin grfica actual
pulsamos ALT-F7.
2. Entre en la primera terminal con ALT-F1. Introduzca un login y una password. No tiene por que ser el
mismo usuario que tiene en la otra sesin.
3. Ahora desde la nueva terminal en la que hemos entrado tecleamos
4. $ xinit -- :1 vt12

El programa xinit inicia las X. Tambin puede usarse startx, que es un front-end para xinit.

Por defecto xinit y startx arrancan las X en el display :0 y a continuacin una xterm. Cuando la
xterm termina se elimina el servicio X. Tambin suele ser posible terminar las X presionando la
combinacin Control-Alt-Backspace. En general, xinit arranca un servidor X y ejecuta un cierto
script. Lo normal es que este script corra un cierto nmero de programas y finalmente un gestor de
ventanas.
La sintxis de xinit es:
xinit [ [ client ] options ] [ -- [ server ] [ display ] options ]
o

La opcin :1 hace que usemos un display alternativo al que se est usando (probablemente el :0). Si
se quieren ejecutar mltiples servicios X en la misma mquina, cada uno debe tener un nmero de
display distinto.
o El argumento vt12 es opcional, y asocia la sesin grfica con la tecla ALT-F12 en vez de asociarla
con la primera que est disponible. Si no especificamos esta opcin continuara en F8, etc. Si
queremos iniciar mas sesiones deberemos especificar DISPLAYs alternativos :2, :3, etc.
5. Ahora nos conectamos via SSH a la mquina remota y comenzamos startkde u otro entorno grfico.
6. Podemos conmutar entre las dos sesiones pulsando CTRL-ALT-F7 y CTRL-ALT-F12
CygWin

Con una instalacin de Cygwin en su mquina Windows (Vase http://www.cygwin.com) arranque una
xterm. Haga una conexin con X forwarding a la mquina UNIX:
$ ssh -X user@beowulf

Ahora puede arrancar un desktop (o cualquier otro programa grfico) contra la mquina windows sin mas que hacer
$startkde

Vase una captura de pantalla (screenshot) en http://x.cygwin.com/screenshots/cygx-xdmcp-kde3.1-200312240010.png.