Después de mucho tiempo utilizando para desarrollar maquinas virtuales con Linux en VirtualBox e Hyper-V, hace algún tiempo me propuse utilizar ese mismo tipo de VMs pero en Azure. Esto me permitía no tener que preocuparme por el destino de esas VMs cuando formateaba o migraba de laptop o maquina física (host machine). Para mi, que trabajo mucho tiempo dando charlas/demos y viajando de un cliente para otro, era importante no tener que depender de que mi portátil estuviera al día. Ademas, me gusta mucho «cacharrear» y no puedo estar «atado» a una maquina física con un SO y una version del mismo concreta durante mucho tiempo, sobre todo cuando desarrollo.

Creando la máquina en Azure (Ubuntu 16.04 LTS Xenial Xerus)

Dicho lo cual, me fuí a Azure y me puse a crear una VM con Ubuntu Server 16.04 LTS. No tiene mucho misterio, pero si queréis conocer en detalle como crearla os sugiero visitar el siguiente link: https://docs.microsoft.com/es-es/azure/virtual-machines/virtual-machines-linux-quick-create-portal

Una vez creada la VM, tendremos una instalación estupenda de Ubuntu Server (16.04 o Xenial Xerus en mi caso). No tiene demasiado misterio. Pero lo divertido empieza ahora. Como imaginaréis, las versiones Server de Ubuntu vienen de serie sin desktop gráfico (sin ventanas vamos). La razón (supuestamente) es que los servers no son accedidos por personas humanas directamente por lo que no tiene sentido instalar un desktop gráfico que les consumirá preciosos recursos (CPU, disco, etc.) Pero para el caso de querer utilizar dicha máquina como puesto de desarrollo, por mucho que algunos «hipster» se escandalicen, no hay nada como un buen entorno gráfico.

Instalando el entorno gráfico (Xfce4)

Dicho lo cual, pasamos a instalar en dicha máquina un entorno gráfico que la «humanice» un poco. Primer cambio de paso para alguien como yo que estaba acostumbrado a GNOME y Unity en Ubuntu. Desde la versión 12.04 Ubuntu decidió que no soportaba GNOME como entorno gráfico directamente. Es decir, en nuestro Xenial Xerus ( o Cordial Ardilla Terrestre de El Cabo por si alguien se pregunta la traducción al castellano) no vamos a poder instalar de una manera sencilla GNOME. Además, como no está la casa para dispendios, tampoco podemos utilizar entornos gráficos que requieran aceleración gráfica mas que nada porque las VMs de la serie NV de Azure cuestan una pasta (en mi caso, y haciendo un alarde de poderío, he creado una máquina D3_V2 con 4 cores y 14Gb. de RAM). Esto nos deja con algunas opciones en cuanto a qué entorno gráfico instalar:

• Xfce4
• Mate desktop

Personalmente, he probado las dos y para este post me centraré en Xfce4 (version 4.12) por ser el «lightweight desktop» más conocido, aunque he de decir que para los «Unity-lovers» Mate sería la opción que más se acerca. Entonces, después de abrir una sesión SSH contra nuestra máquina en Azure con nuestro viejo amigo PuTTy, teclearemos lo siguiente:

sudo apt-get install xfce4 xfce4-goodies

Después de algunos minutos tendremos todos los paquetes instalados sin problemas. Ahora, ¿cómo accedemos a nuestro entorno gráfico desde otra máquina (en mi caso Windows 10)? En este caso, XRDP es nuestra solución. Procedemos a su instalación y configuración (SPOILER: aquí la cosa empieza a ponerse divertida). En nuestra consola tecleamos lo siguiente:

sudo apt-get install xrdp 
echo xfce4-session >~/.xsession

Después de este último comando, tendremos que modificar ligeramente el script de arranque de XRDP para que sepa arrancar el nuevo gestor del desktop. Para ello editamos el fichero /etc/xrdp/startwm.sh mediante el comando:

sudo nano /etc/xrdp/startwm.sh

Y dentro añadimos el siguiente texto:

#!/bin/sh
if [ -r /etc/default/locale ]; then
. /etc/default/locale
export LANG LANGUAGE
fi
startxfce4

Una vez grabado el fichero, y después de abandonar el editor de texto Nano, reiniciamos el servicio de XRDP para que tenga en cuenta los cambios:

sudo service xrdp restart

Si todo va bien, en un par de minutos, tendremos un servidor de XRDP corriendo en nuestro puesto de desarrollo en Azure. Ahora, tendremos que pedirle a Azure que nos permita conectar con el puerto utilizado por XRDP (TCP-3389). Tampoco esto tiene mucho misterio, y en el siguiente enlace os enseñan como hacerlo: https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-troubleshoot-rdp-connection#using-the-azure-portal

Ya estamos en disposición de conectarnos a nuestra máquina desde Windows. Abrimos nuestro cliente de Remote Desktop y en el desplegable introducimos la IP o el nombre DNS de nuestra máquina de Azure.

Veremos la pantalla de login proporcionada por XRDP. Solo tenemos que introducir el usuario y contraseña para entrar.

Uppps, si habéis creado la VM utilizando certificados SSH como mecanismo de acceso, tendréis que volver a vuestro PuTTY y asignar una password a vuestro usuario

No puedo hacer login en la máquina ¿Qué pasa?

Primer problema: Azure os pide contraseñas de usuario con cierto nivel de complejidad y estoy seguro de que en el 99,99% de los casos acabaréis usando algún símbolo ortográfico dentro de dicha contraseña. Pues en este momento os partiréis la cabeza preguntándoos porque XRDP no os deja entrar en la VM. Repuesta: El teclado que se ha configurado por defecto en la VM (si no habéis tocado nada de la configuración por defecto) está con el layout US. Es decir, vuestros guiones («-«)  están justo donde no estáis acostumbrados. Sugiero hacer la prueba de teclear vuestra contraseña dentro del campo de texto del nombre de usuario para que comprobéis si estoy equivocado.

Vamos a tener que volver a nuestro terminal de texto, y a tener que cacharrear un poco para que XRDP nos ponga un layout es-ES (o mejor dicho Spanish Traditional Sort). En mi caso, quería mantener la máquina con el locale en-US (todos tenemos nuestros defectillos y a mi me gusta tener todo en inglés, menos el teclado lógicamente) y solo cambiar el layout del teclado a es-ES. Para ello, nos vamos al directorio /etc/xrdp y hacemos un backup del fichero km-0409.ini

cd /etc/xrdp
sudo cp km-0409.ini km-0409.ini.orig

Ahora procedemos a editar el fichero km-0409.ini y lo modificaremos para que tenga el layout de teclado que nos interesa (en este caso el 0C0A como muestra el código del siguiente listado). Lo más sencillo, es acceder al fichero en cuestión (os dejo otro enlace a los ficheros de diversos códigos de layout) para que seleccionéis el que más os guste.

sudo vim km-0409.ini

Dentro borramos el contenido y pegamos el que hayamos seleccionado en el enlace que os he dejado más arriba. Salvamos el fichero, y solo nos queda reiniciar el servicio de XRDP.

sudo service xrdp restart

Ahora ya solo nos queda volver a intentar conectarnos desde Windows por RDP con nuestro puesto de desarrollo en Azure, y si todo va bien, veremos que hemos solucionado el problema del teclado al menos en primera instancia.

En un siguiente post, hablaremos de cómo configurar la máquina con aquellos «goodies» que nos gustan a los desarrolladores (en especial si queréis trabajar con .NET Core, NodeJS, Blockchain, etc.)

¡A disfrutar!