Ponte en esta situación no muy difícil de imaginar: tienes un Windows Server 2019 con determinados roles y software para Windows, pero además quieres instalarle la versión 2.0.x de Deluge, un cliente de BitTorrent con una interesante arquitectura desacoplada entre servidor y cliente.
Aunque Deluge ha acostumbrado a tener versiones para Windows, desde la versión 2.0.x no hay paquete de instalación sobre todo por el movimiento a GTK 3 y Python 3. Hay un issue donde se explican los pasos para hacer una instalación manual en Windows con la que muchos usuarios han informado tener éxito. El problema que le veo, es que además del engorroso proceso, mantener al día las versiones de cada componente va a ser muy manual y doloroso, y un cliente de BitTorrent no es algo que quieras tener con vulnerabilidades, ¿verdad?
La mejor práctica sería probablemente poner a punto una máquina virtual con GNU/Linux e instalar ahí todo el stack o bien hacernos un contenedor Docker; sin embargo, en este artículo vamos a optar por una aproximación curiosa: ejecutar la versión Linux de forma nativa en nuestro Windows Server 2019, gracias a Windows Subsystem for Linux.
¿Y cuál es el plan? Ejecutar el demonio de Deluge en nuestro Windows Server permitiendo que nos podamos conectar desde otro ordenador que se encuentre en la LAN que ejecute la interfaz GTK.
IMPORTANTE: el proceso aquí descrito es para la versión 1 de WSL. WSL 2 requiere una build de Windows 10 o Server superior a la 18917, lo cual quiere decir que no lo veremos aterrizar en la rama LTSC de Windows Server hasta... ¿2022? No hay de qué preocuparse, ya que WSL 1 da mucho juego.
IMPORTANTE II: este artículo no es un tutorial para instalar Deluge 2.0.x en Windows Server, sino un ejemplo de cómo podemos utilizar los WSL para instalar demonios (servicios) de GNU/Linux en nuestra máquina Windows.
IMPORTANTE III: por si alguien se lo preguntaba, queremos Deluge para descargar y ayudar a distribuir imágenes de CD de instalación de Debian GNU/Linux.
¡Vamos a paso a paso!
Habilitando WSL en Windows Server
Microsoft nos lo ha puesto aquí insultántemente fácil. Abrimos una PowerShell en modo administrador e introducimos:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Acto seguido reiniciamos y es el momento de instalar una distribución. Como en Windows Server no acostumbra a haber Marketplace, deberemos hacer la descarga a mano, tal como ser explica aquí. Imaginemos que queremos utilizar Ubuntu 18.04, la descargamos desde línea de comandos con el genial curl, que ya viene de serie en Windows Server 2019 y que podemos lanzar desde PowerShell:
curl -L -o ubuntu-1804.appx https://aka.ms/wsl-ubuntu-1804
¿Por qué usar curl.exe y no Invoke-WebRequest de PowerShell? Porque el primero es notablemente más rápido.
Una vez descargado, instalamos la distribución con:
Add-AppxPackage .\ubuntu-1804.appx
Una vez se complete la instalación deberíamos poder ver el icono de la distribución en nuestro Windows Server.
Hacemos clic en él para hacer la inicialización.
Y acto seguido iniciamos un sudo apt update && sudo apt upgrade -y.
Instalando Deluge en WSL
¡No podía ser más fácil! Abrimos el bash de nuestro GNU/Linux bajo Windows Server y escribimos:
$ sudo add-apt-repository -u ppa:deluge-team/stable
$ sudo apt install deluged
Y con esto instalaremos automáticamente el demonio de Deluge y todas sus dependencias. Acto segudo podemos hacer un $ deluged -V y obtendremos algo parecido a esto:
$ deluged -V
deluged 2.0.3-2-201906121747-ubuntu18.04.1
libtorrent: 1.1.5.0
Python: 3.6.8
OS: Linux 4.4.0-17763-Microsoft
No pinta mal, ¿verdad? Ahora bien, ¿cómo hacemos que esto se ejecute como el resto de servicios de nuestro Windows?
Background Tasks y arranque de demonios en WSL
Windows Server 2019 soporta background tasks en WSL, lo cual significa que podemos ejecutar procesos de fondo sin necesidad de que haya una ventana de terminal abierta.
Sin embargo, todavía tenemos un escollo que saltar: WSL 1 no soporta ningún gestor de arranque de GNU/Linux, lo cual quiere decir que no tenemos nada para arrancar nuestros programas cuando se incia el sistema, es decir, nada de SysV Init o de systemd.
Aquí ya entran en juego soluciones no excesivamente glamurosas, pero imaginativas y que funcionan bien, como wsl-autostart que podemos encontrar en Github, que no son más que un conjunto de script bastante sencillos para gestionar el arranque y parada de nuestros servicios WSL desde Windows Server.
En mi caso decidí utilizar las instrucciones del repositorio de Github, pero sin seguir las instrucciones que hablan de modificar el registro de Windows. El motivo es que siguiendo esas instrucciones nuestra aplicación se ejecutará sólo cuando tengamos la sesión iniciada, y eso no es lo que queremos. En su lugar hice lo siguiente:
Lo primero es un git clone https://github.com/troytse/wsl-autostart.git desde PowerShell o cmd.exe. Acto seguido desde la misma línea de comandos editamos el commands.txt para que contenga:
/etc/init.d/cron
/etc/init.d/deluge-daemon
Después volvemos al bash.exe y editamos /etc/sudoers para que contuviera lo siguiente:
%sudo ALL=NOPASSWD: /etc/init.d/cron
%sudo ALL=NOPASSWD: /etc/init.d/deluge-daemon
Ahora sólo nos queda ir al Task Scheduler de Windows y crear una nueva tarea programada que se ejecute al arranque del sistema, sin necesidad de que iniciemos sesión. El programa a ejecutar será C:\wsl-autostart\start.vbs.
¿Y dónde podemos ver las tareas en ejecución de WSL si no hay terminal abierto? Pues en el Task Manager junto con las de Windows.
¿Y ver en qué puertos escucha? Desde luego, con un netstat -a | findstr LISTENING.
Un último detalle, Windows Defender Firewall
No tendremos mucho éxito conectándonos al demonio de Deluge, o cualquier servicio que publiquemos si no configuramos el firewall de Windows para aceptar conexiones entrantes en el puerto o puertos indicados. ¡No olvides este detalle!
Conectándonos desde el cliente
¡Ha llegado el momento de probar a conectarnos! Para ello he utilizado el WSL de mi Windows 10 e instalado Deluge por el mismo método descrito en este artículo. Como ahora sí que voy a ejecutar una aplicación gráfica, necesitaré un servidor X, que en mi caso es el genial X410.
¡Hay conexión y podemos conectarnos!
Una última nota de seguridad
WSL siempre ha causado controversia en terreno de la seguridad por bypassear muchos de los sistemas de Windows. Debido a esto, antes de instalar algún servicio en producción por este mecanismo recomiendo encarecidamente tener un buen conocimiento de cómo funciona WSL a bajo nivel para comprender los riesgos de que un posible atacante aproveche una vulnerabilidad de seguridad.
Como mejor práctica general, pon tu servicio GNU/Linux a ejecutarse en una máquina virtual donde sea el sistema operativo real.
A este respecto, os dejo con este hilo de Stackoverflow sobre el tema.
Conclusiones
Con el soporte oficial de WSL en Windows Server 2019 terminamos de hacer difusa la línea que separa ambos sistemas operativos, hasta el punto que podemos llegar a obtener mejor soporte de una aplicación ejecutando su versión Linux aunque nos encontremos bajo Windows.
Sin embargo, si nos planteamos esto en escenarios productivos es muy conveniente conocer todas las implicaciones de seguridad y controlar como funciona WSL a bajo nivel.
Happy WSLing!
