Consulta Técnica: View y Thin Clients

Nos pasan la siguiente consulta:

"Hola JL,

Estoy leyendo tu blog con mucho interés y tengo unas dudas sobre VDI.

Estoy viendo la posibilidad de implantar thin clients en mi empresa y me surge la siguiente duda:

Si pongo thin clients con windows embedded con el view client de vmware, necesitaré un antivirus para proteger los thin clients, ya que no dejan de ser unos mini-pcs con windows?

También he pensado en poner thin clients con linux, que suponemos que tienen el vmware-view-open-client, pero he visto que no soportan la redirección de USB, lo cual es un problema. Sabes si esto es así en estos clientes?

También he pensado en reutilizar los pcs actuales, quitandoles el HD y arrancando por PXE y ejecutando el cliente vmware-view-open-client desde una sesión de LTSP. ( https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall http://www.jaimebalmes.org/php/mod/resource/view.php?id=409 )

Por otra parte, qué platafoma de gestión nos recomiendas para gestionar los thin clients sena linux o windows?


Muchas gracias por tu tiempo.

Saludos."

Efectivamente. Si utilizas Thin clients basados en Windows XP (sea o no embedded) sigue siendo un Windows XP, eso sí, con menos "superficie" de exposición a virus y demás, lo que no implica que debamos prescindir del Antivirus, ya que en un entorno mixto, como dice el maestro Ros, la podemos liar parda. Por otro lado, un entorno de thin clients Linux nos obligará a prescindir de la redirección USB de View, olbligándonos a ir a productos de terceros, salvo que el fabricante disponga de licencia de VMware para la redirección de USB.

Mi recomendación sobre la plataforma de gestión de los Thin Clients es clara: Ninguna. Nunca he terminado de entender eso de migrar a Virtual Desktop para sustituir SMS o System Center por un Thin client management. El uso de clientes basados en linux o Windows obliga, en mayor o menor medida, a disponer de una plataforma de gestión de los mismos, y mi recomendación es que la gestión tire a inexistente. Es un hecho que la plataforma del Thin Client variará substancialmente su precio dependiendo de si el cliente corre o no Windows (Normalmente la gestión de clientes basados en Windows suele ser más cara e implica mayor nivel de gestión).

Tanto en un caso como en otro, el Thin Client puede convertirse en un punto de fallo dentro de la infraestructura View, ya que su propia "inteligencia" lo hace - eso sí, bastante menos - susceptible a fallos en los procesos de actualización y configuración.

Respecto a la opción de convertir PC's en Thin Clients, además de la que comentas (LSTP), dispones de Thin Station, una minidistribución altamente configurable, que incluso dispone de configuradores Web donde "montarte" tu cliente ligero desde ella (los TS-O-MATIC). En el mirror de Dinamarca (DK) incluso te permite integrar el cliente View de VMware. Estos ts-o-matic te permiten crear desde imágenes ISO a imágenes PXE para el arranque. Recomiendo fervientemente esta distribución como iniciación de bajo o nulo coste al mundo del Virtual Desktop.

Si lo que buscas es una solución robusta, sin intervención en el thin client del usuario, que permita redirección USB, compatibilidad con VMware View, en la que despreocuparte ABSOLUTAMENTE del dispositivo y a un coste unitario realmente interesante, te recomiendo los SUN Ray de SUN Microsystems. En mi compañía (y en varios clientes) tenemos la solución funcionando en menos de dos horas. Es realmente elegante y ciertamente potente. Las características incorporadas en la versión 5 (aceleración multimedia, aceleración flash, USB Mapping) junto con las ventajas de siempre (hot desking, multiple monitors - hasta 8, creo recordar) hacen de SUN Ray, al menos para mí, la solución Thin client perfecta. Por no necesitar, no necesitan IP del entorno corporativo. El terminal SUN Ray (DTU para los amigos) es simplemente eso: Un terminal del servidor SUN Ray. Las conexiones con los virtual desktop se realizan desde este, y no desde el terminal, es decir, el SUN Ray client no es más que una pantalla y un teclado extra del servidor SUN Ray (que puede correr tanto en Solaris como en Linux). Te invito a verlo cuando quieras.

Un cordial saludo.

Nota Técnica: VMware View Open Client

Como supongo que sabéis, VMware ha "liberado" hace ya un tiempo el cliente View (o VDM) para Linux, lo que permite tanto a los forofos y/o usuarios de este sistema operativo como a los fabricantes de Thin Clients acceder a los entornos View desde este sistema operativo.

Entrecomillo "liberar" ya que el cliente en cuestión tiene ciertas peculiaridades, que destaco:

• No soporta redirección USB. En la distribución estándar del cliente "faltan" los componentes de la redirección de dispositivos USB, que entiendo que requerirán de licencia OEM al efecto.
• Es pelín exclusivo: No tenemos control sobre la ventana del desktop virtual, ya sea para cambiar el tamaño o alternarla con el deskop físico.
• Presenta algunos "problemillas" con el teclado: Tiene como buena "costumbre" obligarnos a usar el teclado US en lugar del que tengamos configurado.

Dado que de último uso Ubuntu en mi flamante Sony Vaio VGN-P11z (el vista que trae de serie hace desesperadamente lento al cacharro en cuestión, y Windows 7 no mejoró mucho las expectativas de rendimiento me decidí a "Ubuntear" el portátil, ya que todo mi entorno de trabajo se encuentra en el desktop virtual) el uso del cliente View se volvió necesario, así que me decidí a intentar superar las limitaciones antes expuestas, al menos las concernientes al desktop.

El VMware View Open Client, al igual que su contrapartida en Windows, requiere de un cliente de terminal server previamente instalado en el equipo, en el caso de Linux, rdesktop, así que me dediqué a investigar cómo el cliente View interacciona con rdesktop. Para ello, procedí a realizar lo siguiente:

1. Renombré el binario de rdesktop, localizado en /usr/bin/rdesktop a /usr/bin/rdesktop.bin:

# mv /usr/bin/rdesktop /usr/bin/rdesktop.bin

2. Creé un archivo /usr/bin/rdesktop.wrapper con el siguiente contenido:

#!/bin/bash
echo $* > $HOME/rdesktop.parms
/usr/bin/rdesktop.bin $*

en $* el shell nos suministrará la línea de comandos que View Client le pasa a rdesktop

3. Hice un link simbólico entre el archivo rdesktop.wrapper y rdesktop:

# ln -s /usr/bin/rdesktop.wrapper /usr/bin/rdesktop

Tras lo cual, ejecuté el cliente de vmware view (vmware-view).

Tras conectarme, procedí a examinar el contenido del fichero $HOME/rdesktop.parms, encontrando lo siguiente:

-z -K -g 1280x1024 -X 65012445 -u jlmedina -d bato-its -p - -a 24 -r sound:local :3389 10.0.10.18

Si consultamos las opciones de rdesktop (via man rdesktop) observamos lo siguiente:

-z: Activar compresión RDP

-K: No anular las asignaciones de teclas del Window Manager. Por defecto (es decir, sin esta opción activada) rdesktop intercepta todas las pulsaciones. Esta opción es la que nos impide minimizar la ventana del virtual desktop mediante la pulsación de ctrl+alt+enter

-g: Resolución de la ventana de virtual desktop. Por defecto, VDM ocupa toda la pantalla disponible.

-X: Ejecuta rdesktop dentro de una ventana existente. El comportamiento por defecto de VDM es ejecutar la ventana de rdesktop sobre una ventana invisible que no es minimizable.

-u : Usuario con el que conectarse

-d: Dominio al que pertenece el usuario

-p: password suministrada al cliente VDM

-a: Profundidad de color. Por defecto, VDM utiliza el máximo soportado por VDM, que es 24 bits.

-r: Dispositivos redirigidos. Por defecto, sólo el sonido

el resto corresponde a la IP y puerto del desktop a conectarse.

Por lo pronto, las opciones que parecen "molestarnos", es decir, la de no poder salir de la ventana del Virtual Desktop, son las siguientes:

-K, es decir, la que nos desactiva el ctrl+alt+enter

-X, que ejecuta el rdesktop en una ventana no "resizable".

Si nos limitamos a eliminar estas dos opciones, nos encontraremos con los siguientes "problemillas":

• El teclado seguirá estando en inglés EEUU
• El virtual desktop se presentará por defecto en modo ventana
  

Para solucionarlo, deberíamos pasar a rdesktop los siguientes parámetros:

-f: Activa el modo full sreen
-k es: configura el teclado por defecto a español.

Ahora bien... ¿Cómo eliminar opciones y añadirlas a los parámetros que el cliente view pasa a rdesktop?

Como antes dijimos, la variable $* almacena los parámetros que vmware-view pasa a rdesktop, así que aprovecharemos esto para eliminar los parámetros que nos molestan y añadir los que nos faltan. Para ello, volvamos a mi fichero rdesktop.wrapper:

#!/bin/bash

echo $* > $HOME/rdesktop.parms

/usr/bin/rdesktop.bin $*

lo modificaremos para que quede como sigue:

#!/bin/sh

parms=`echo $* awk '{print $1,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17}'`

/usr/bin/rdesktop.bin -k es -f $parms

Básicamente lo que he hecho es, mediante el comando awk, eliminar de la línea de parámetros los que me molestan, y después añadir "a pelo" los que necesito. En este caso, eliminaría los que destaco en rojo:

-z -K -g 1280x1024 -X 65012445 -u -d -p - -a 24 -r sound:local:3389

De esta manera conseguiremos un cliente view funcionando en pantalla completa, que nos permite volver al desktop pulsando ctrl+alt+enter y con teclado en castellano(*)

Espero que os sea útil.

(*) Es posible pasar a rdesktop el código de teclado mediante variable de entorno, pero lamento reconocer que no lo conseguí.