Pistachio Brainstorming

¿Te ha pasado alguna vez el tener que ejecutar una aplicación que se encuentra en el ordenador del trabajo?

Con un poco de suerte, te basta con abrir una terminal, hacer una conexión SSH, ejecutar la aplicación y esperar el resultado. Sin embargo, en otras ocasiones necesitas que el programa se siga ejecutando cuando te desconectes del ordenador, o, peor aún, que quieras manipular la interfaz gráfica de la aplicación.

Como estoy harto de buscar en Google cómo hacer cada cosa, me voy a hacer una pequeña receta con los tres casos, a ver si te sirve a ti también.

Ejecutar aplicación en consola

En este caso lo que se quiere hacer es:

1. Conectarse al ordenador remoto vía SSH.
2. Ejecutar una aplicación.
3. Esperar que finalice la aplicación.
4. Desconectarse del ordenador remoto.

Esto es bastante sencillo y buscando por Internet (y leyendo las páginas del manual del comando “ssh”) es fácil encontrar la solución.

Para conectarte al ordenador remoto basta con hacer una llamada del estilo:

localhost$ ssh usuario@servidor.es

donde ‘usuario’ es el nombre de usuario que quieres utilizar en el ordenador identificado por su nombre de dominio ‘servidor.es’. Después de introducir tu password cuando te lo pida, te mostrará un terminal en el ordenador remoto. Ahí podrás ejecutar la aplicación que desees:

servidor.es$ uname -srv
Linux 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 25 07:53:43 CET 2011

Una vez terminada la ejecución del programa podemos introducir ‘exit’ o pulsar control+D para salir.

Ejecutar una aplicación persistente en consola

Este caso es muy parecido al anterior. Sólo se diferencia en que ahora no existe el paso 3., es decir, queremos que la aplicación se siga ejecutando después de habernos desconectado del ordenador remoto. Para ello utilizamos el comando POSIX “nohup” en el ordenador remoto.

servidor.es$ nohup make &
servidor.es$ ^D

Eso nos garantiza que la aplicación se seguirá ejecutando aún cuando le llegue la señal hangup (HUP), que indica que el usuario que ejecutó la orden se ha desconectado de la máquina. Este comando es especialmente útil para compartir ficheros por redes P2P (con un programa torrent por consola) o para hacer grandes actualizaciones remotamente.

Ejecutar una aplicación X

El último caso es cuando queremos ejecutar un comando en el ordenador remoto que cree una ventana en nuestro ordenador local. Por tanto, tendremos que iniciar una sesión X en el ordenador local, lo que en la mayoría de casos significa que debes haber iniciado sesión en Gnome, KDE, PekWM o el entorno de escritorio que utilices.

Los pasos a seguir son muy similares. Primero habrá que conectarse por SSH como en el primer caso, pero añadiendo la opción ‘-X’:

localhost$ ssh -X usuario@servidor.es

El resultado será el mismo, tendremos una terminal remota en el servidor ‘servidor.es’. Todo igual, salvo que al ejecutar una aplicación gráfica todas las llamadas al servidor X se hacen a la máquina local (donde estás tú) no a la máquina remota (donde ejecutas la aplicación).

Por ejemplo, si ejecuto la aplicación ‘kcalc’ (la calculadora del escritorio KDE) en mi máquina wigner (ordenador del trabajo):

[alejandro@wigner ~]$ kcalc

en maxwell (mi ordenador personal) aparece la siguiente ventanita:

Las tres recetas las he obtenido de diferentes sitios en Internet que ya no recuerdo. El último caso lo aprendí aquí, en un tutorial de Van Emery.

Después de un rato buscando por Internet he conseguido arreglar este error bobo que ocurre al cambiar el prompt (¿cómo lo traduces?) de tu terminal de GNU/Linux.

Os pongo en situación. En mi archivo ~/.bashrc exporto la variable PS1 para modificar la “moñiga” que aparece en la línea de comandos y que indica dónde puedo empezar a introducir órdenes. Hasta ahí en muchos tutoriales te explican de forma muy clara lo que hay que hacer y qué diferentes opciones tienes (ejemplo). Lo que se me pasó (por leer en diagonal) es que los caracteres de escape (que no se verán en la terminal) también cuentan en ciertas ocasiones. Por ejemplo, utilizó el PS1:

export PS1='\e[32;1m\w\e[0m$ '

que básicamente te indica el directorio actual en verde negrita:

~/Documentos$ 

cuando vuelvo para atrás en el historial de bash y escribo un comando que supera los 17 caracteres de la variable PS1, el prompt se va al carajo. Si fuera a ejecutar el comando 'apt-get install power-to-me' y luego el comando 'nano ~/.me' en la terminal vería:

~$ apt-get install power-to-me
~$ apt-get instalnano ~/.me

Fíjate que los 17 primeros caracteres pertenecen al comando anterior y el resto es el comando de nano.

Esto ocurre porque para calcular la distancia del prompt cuenta todos los caracteres de la variable PS1, incluidos los caracteres de escape de colores. La solución estaba todo el tiempo delante de mis narices, porque en todos los tutoriales sobre la modificación del PS1 te indican cómo hacerlo. Tan simple como utilizar las secuencias de escape especiales '\[' y '\]' (que indican que no hay que contar los caracteres que encierran) alrededor de los caracteres de cambio de color. Así, el prompt quedaría:

export PS1='\[\e[32;1m\]\w\[\e[0m\]$ '

y tan amigos todos.

Desde hace tiempo utilizo software de virtualización de máquinas para acceder a esos programas que son necesarios y en GNU/Linux no existe una alternativa de suficiente calidad. Básicamente lo uso para dos cosas: 1) Adobe Illustrator porque las alternativas libres (Inkscape y compañía) no funcionan tan bien y para la publicación en revistas es necesario que las figuras sean de la máxima calidad, y 2) Microsoft Office para cuando me mandad algún archivo .DOCX y similares. Para el resto de aplicaciones me basta y me sobra con GNU/Linux.

Hasta ahora he utilizado el VirtualBox de Oracle para la virtualización. Sin embargo, recientemente he probado KVM (Kernel-based Virtual Machine) que lo ponían como bueno y me ha gustado. Para completar la lista tengo que decir que también existe el software de VMware que es gratis pero no libre, y por tanto no me convence. Tanto VirtualBox como KVM son de código abierto. Del que voy a hablar aquí es de KVM, que es el que uso actualmente. En concreto explicaré los pasos seguidos para la instalación de kvm en Debian «Squeeze» en arquitectura de 64 bits y la creación de un sistema virtual con Windows 7 y Abode Creative Suite 4.

Según lo entiendo yo (que no necesariamente es cierto) KVM carga unos módulos del kernel de Linux que sirven para compartir los recursos de hardware entre la máquina virtual (la que crearemos ahora) y el sistema huésped (el sistema operativo donde se ejecuta esto). Cuando ejecutas KVM lo que hace es cargar una BIOS básica y emular una máquina (ordenador) que realmente no existe. Es realmente como The Matrix: el mundo real es tu ordenador y ahí cargas un programa como Matrix que permite instalar otro sistema operativo como si Matrix fuera el mundo real. El sistema operativo virtual no es consciente de que realmente es un subprograma en otro sistema operativo, para él sólo existe Matrix

La instalación de KVM sigue el procedimiento típico de cualquier distribución con administrador de paquetes. En mi caso simplemente ejecuté el siguiente comando como superusuario:

# apt-get install kvm

Esto funciona en Debian testing (squeeze) y probablemente en *Ubuntu 10.04. Si utilizas Fedora tendrás que usar yum y si usas openSuse zypper. Esto te instala todos los paquetes necesarios para usar KVM, incluyendo los módulos del kernel. Nótese que la explicación de esta entrada es para la versión 0.12.5 de kvm. Otras versiones pueden tener diferente sintaxis o características.

Una vez termina la instalación, lo primero es crear el disco duro de la máquina virtual. Para ello podemos utilizar las herramientas que proporciona KVM, en concreto, el comando:

$ kvm-img create -f qcow2 MyVirtualHDD.qcow 30G

Éste crea en el directorio actual una imagen en formato qcow2 con tamaño de 30 gygabytes: lo que será el disco duro virtual. Podemos cambiar el tamaño modificando el último parámetro del comando anterior. Para más información lee el manual ejecutando `info kvm-img`.

Con eso ya tenemos todo lo necesario para que arranque nuestra máquina virtual. Con el siguiente comando se arranca usando un gygabyte de memoria RAM y el disco duro recién creado:

$ kvm -m 1G -hda MyVirtualHDD.qcow

Si lo ejecutamos lo que obtenemos es un bonito error del tipo: No Bootable Devices Found.

Esto es porque nuestro ordenador no tiene sistema operativo (en concreto lo que no tiene es medio de arranque). Por lo tanto, el siguiente paso es introducir un dvd virtual para la instalación del sistema operativo.

Existen dos formas de hacerlo: 1) o bien tenemos el dvd físico del sistema operativo o 2) tenemos una imagen .iso del mismo. En ambos casos es lo mismo y lo único que cambia es un parámetro. En mi caso tengo el dvd de instalación de Windows 7 64 bits. Identificando el dispositivo del lector de dvd, éste se encuentra en /dev/dvd. En otros casos puede variar. Ahora, el comando de ejecución incluye un parámetro para que cargué el dvd en el arranque:

$ kvm -m 1G -hda MyVirtualHDD.qcow -cdrom /dev/dvd -boot d

El parámetro ‘-cdrom’ indica dónde está el lector de dvd y ‘-boot’ indica que debe arrancar desde dicho lector. Si tenemos una imagen .iso podemos usarla como imagen del dvd cambiando ‘/dev/dvd’ por ‘/ruta/dvd.iso’.

Si ejecutamos el anterior comando con el dvd de Windows 7 en la unidad, se iniciará el instalador en la máquina virtual. La instalación es exactamente igual que como sería en tu ordenador real. Al final de la misma tendremos Windows 7 instalado en el disco duro virtual, por lo que el arranque por dvd ya no es necesario. Iniciar tu sistema virtual recién instalado es tan sencillo como ejecutar:

$ kvm -m 1G -hda MyVirtualHDD.qcow -cdrom /dev/dvd -boot c

Ahora es el turno de instalar el Adobe Create Suite 4, que viene en 3 dvds. La pregunta es, ¿cómo lo instalo a partir de tres dvds si sólo puedo especificar un dvd cada vez que arranca el sistema virtual? Afortunadamente KVM tiene depende en algunos aspectos de qemu, y qemu tiene un “monitor” del sistema (una sala de control en la analogía con Matrix) donde podemos cambiar algunas propiedades de la máquina virtual de forma dinámica. En concreto tiene una opción para expulsar un dispositivo de bloques (dvd) y cambiarlo por otro (enlace).

Para entrar en el modo monitor hay que pulsar la combinación de teclas control+alt+2. Eso nos llevará a una consola de comandos. Para obtener información de los dispositivos de bloque que hay en la máquina virtual tenemos que ejecutar:

(qemu-monitor) info blocks

Esto producirá una salida parecida a la siguiente:

Ahí podemos ver que el identificador del dvd es ‘ide1-cd0′. Sobre él podremos ahora hacer dos operaciones básicas: expulsar su contenido y cambiar la ruta a su imagen. La primera hace en Matrix el equivalente a extraer el dvd de la unidad lectora. La segunda es el equivalente a cambiar el dvd por otro. Así, los pasos a seguir para cambiar el dvd en la máquina virtual utilizando el lector de dvd (/dev/dvd) de la máquina huésped son los siguientes:

1. Extrae en Windows el medio: botón derecho en la unidad de dvd y pulsa expulsar.
2. Ejecutar un `info blocks` en el kvm monitor para comprobar si la unidad ha sido extraída.
3. (opcional) Si la unidad no ha sido extraída ejecutar:

(qemu) eject ide1-cd0

4. Extraer el dvd del lector físico y cambiarlo por el otro que queramos.
5. Recargar el medio virtual ejecutando:

(qemu) change ide1-cd0 /dev/dvd

Siguiendo esos pasos es inmediato instalar el Adobe CS4 y cualquier otro software que necesite ser instalado a partir de varios dvds.

Y ya está, el sistema virtual completamente instalado y listo para usarse. Sólo para recordar, el comando para ejecutarlo es:

kvm -m 1G -hda MyVirtualHDD.qcow -cdrom /dev/dvd -boot c

Por último he de reconocer que todo esta información viene de Internet en general y en concreto de estas fuentes:

• La página oficial de KVM (enlace).
• La documentación oficial de qemu (enlace).
• El wiki de Debian.org (enlace).
• Los maravillosos tutoriales de Sean Kenefick (tutorial 1, tutorial 2).