Por un proyecto de mi actual empresa, he estado mirando si era viable aplicar el tema del X forwarding para que un PC que actuara de server se encargara de procesar algunas o todas las peticiones de numerosas workstations.

Los requisitos

Requisitos:

1. Tener unas workstations que pudieran trabajar con aplicaciones de procesado de imágenes 2D/3D y probablemente, a medio/largo plazo, con video.
2. Poder imprimir los trabajos allí realizados o trabajos ya procesados en otro lado, y tener un buen control de las opciones de impresión (color, calidad/tipo del papel, gestión de colas...).
3. No había requerimiento de uso de ningún Sistema Operativo ni aplicación, así que a priori podía elegirse cualquiera.

El abanico de posibilidades en cuanto a infraestructura

1. Usar únicamente workstations que se encargaran de su propio trabajo.
2. Usar workstations que se encargaran de su propio trabajo, y que estuvieran unidas por un clúster que haga balanceo de carga (p.ej. OpenMosix) cuando fuera posible.
3. Usar workstations que mandaran los trabajos a procesar a un server.
4. Usar las opciones 2 y 3 simultáneamente.

La infraestructura elegida

Después de haber estado haciendo alguna prueba para comprobar la reliability del tema del X forwarding y de haber estado meditando el tema de la idoneidad de cada solución (incluso comentándolo por alguna que otra lista de distribución -gracias comandob!-), la opción por la que se ha optado es la más conservadora (la 1).

Por un lado, se ha descartado el tema de que haya un server que procese el trabajo requerido por las terminales por el tamaño de los datos con los que se tienen que trabajar (ficheros demasiado grandes para ser movidos a través de una red, aunque se trate de una LAN). ¿Por qué? Porque si el server debe ser el encargado del procesamiento de los trabajos que le requieren las workstations, habrá una gran carga de red transfiriendo los datos de las estaciones al servidor para ser procesadas, y luego del servidor a las estaciones para guardar los cambios realizados (1 viaje de ida y otro de vuelta de los datos estan asegurados).

Por otro lado, se ha descartado el tema del clúster (OpenMosix) por la misma razón: es un clúster que trabaja sobre la capa de protocolos TCP/IP, y en las pruebas realizadas, el clúster sabiamente tomaba la decisión de no migrar el proceso a otra máquina libre. Su actuar se debe seguramente a que no vale la pena migrar tal cantidad de datos dado el tiempo que se pierde transfiriéndolos por la red, tanto para la ida (procesado por parte del server) como para la vuelta (devolución de los datos caso que se decida almacenarlos/guardarlos).

Caso de haber requerido Xforwarding...

Si hubiéramos querido usar algún tipo de Xforwarding, ¿qué opciones teníamos? Esto lo he sacado y lo puedes encontrar en el Remote X Apps mini-HOWTO:

• Host List Mechanism (aka xhost). Se basa en el comando xhost aceptando o denegando peticiones a las X's a través de nombres de host, de la forma xhost +hostname, xhost -hostname, o simplemente xhost + ó xhost - (para aceptar todos o ningún host, respectivamente). Es un sistema muy sencillo, pero también muy inseguro, por lo que no recomiendan usarlo en Untrusted Networks (p.ej. Internet).
• Magic Cooke Mechanism (aka xauth). Este mecanismo consta de 2 pasos:
1. Hacer la cookie. Modos de hacerla:
• Añadir a /usr/X11R6/bin/startx el comando que fabrica la cookie (mkookie | sed ...), siempre que startx sea ejecutado como root.
• Añadir dicho comando a ~/.xserverrc ejecutándolo como usuario.
• Usando xdm, definiendo el parámetro DisplayManager.authDir en /etc/X11/xdm/xdm-config.
2. Transportar la cookie, ya sea mediante directorios compartidos, usando rsh, telnet...
• Ssh. Se trata de activar el X forwarding a través de ssh, algo para lo cual ssh ya viene preparado. Este es el método que probé y el que brevemente describiré. Agradecido debo estarle a MaD-DoG, quién fue el que me ayudó a sacarlo. Unas notas a tener en cuenta:
• Debemos asegurarnos de inicar el servidor X del PC que vaya a hacer de server sin la opción -nolisten (no es necesario en el PC que vaya a hacer de cliente). Para ello, es mejor no usar un gestor de sesión (o saber cómo configurarlo para que no use esa opción al iniciar el servidor X). Lo mejor es probar a iniciar las X's con startx a mano.
• En los ficheros /etc/ssh/ssh_config y sshd_config debemos descomentar (habilitar) la opción X11Forwarding.
• El puerto 6000 debe estar abierto.
• En el server, deberemos aceptar la IP del PC que haga de cliente (xhost +ip_del_cliente).
Teniendo esto en cuenta, los pasos para conseguir un túnel ssh son:
1. ssh user@server
2. export DISPLAY=ip_cliente:0.0. Esto en realidad no es necesario porque ssh se encarga del X11 forwarding. Para comprobar que se sse lo está haciendo cabe ejecutar desde la sesión ssh lo siguiente: echo $DISPLAY. La respuesta deberá ser localhost:10.0.
3. Ejecutar una aplicación que se halle tanto en el cliente como en el server.

Enlaces de interés

Si estás interesado en el tema, seguramente también te apetezca visitar:

• Configuración y Experiencias con Terminales X
• X-Terminal : cuaderno de bitácora.
• Linux Terminal Server Project - Documentation
• HOWTO X-forwarding
• Remote X Apps mini-HOWTO

Y bueno, esto es tooodo amigooos. Si creéis que me dejo/sobra algo, que hay algún error o simplemente me queréis poner más verde que el nuevo theme del blog... para todo eso tenéis el sistema de comentarios (correctamente moderados :D). Salu2!


Comentarios (2)