Mi chuleta sobre WSL

Detalles informativos

• el comando wsl parece que funciona desde un cmd normal, no hace falta una consola de power shell
• el hecho de que wsl responda con usage no quiere decir que esté instalado: paise que todo lo que no sea wsl --install es menearsela al mono; parece que mientras no se instala la característica opcional es solo una forma de hacerlo.
• En general, WSL 2 performa mejor que WSL1, excepto en accesos de un filesys a otro, pero a cambio los accesos al propio en linux son mejores en WSL2. Comparación aki ('WSL 2 is running as a Hyper-V virtual machine'): https://learn.microsoft.com/en-us/windows/wsl/compare-versions Pero ATENCION pq parece que acceso via ssh parece mas fácil en WSL1 pq comparte con win los temas de red del kernel, mientras que WSL 2 es una máquina virtual a la que windows asigna una IP que ademas cambia cada arranque
• Lo normal es instalar versiones que hay en la app store de windows, que se mantienen como una variante mas de la distro

Instalando SWL v1

wsl --set-default-version 1

asombrosamente lo hace de manera inmediata ...

wsl --install -d Debian

... te pregunta nombre de usuario, contraseña y parece que ya estas en debian, por el prompt que sale, ademas de obtener un recuadro de bienvenida a wsl con enlaces para configurar y documentación

existen ficheros de configuración

/etc/wsl.conf y tb /mnt/c/Users/chafar/.wslconfig

Primer problema

chafar@lola:~$ ping debian.org
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

sudo setcap 'cap_net_raw+p' /usr/bin/ping arregla eso, peeeeroooo:

Segundo problema

chafar@lola:~$ ping debian.org
ping: debian.org: Temporary failure in name resolution

cat /etc/resolv.conf te dice la solución: còmo evitar que wsl lo regenere, y una vez hecho se reemplazar el enlace, que queda roto, por un fichero que contenga algo como

nameserver 8.8.8.8
nameserver 1.1.1.1

... y listo, sudo apt-get update, sudo apt-get upgrade, sudo apt-get install git ...

Manejo

• wsl --status muestra la versión 1 / 2 que se ejecuta
• wsl --list --running para ver instancias en ejecución; importante para saber cuándo reiniciar tras hacer cambios de configuración wsl
• wsl --shutdown para asegurarse de que todas las instancias se cierran

Importante que el primer usuario que wsl crea al generar la instancia tiene permisos sudo como para sudo -i.

Obstáculos

Es un problema tener servicios corriendo en el lado linux, pq la instancia solo se arranca cuando el usuario accede expresamente ... y se apaga automáticamente pasados unos segundos sin que el usuario acceda interactivamente a ella (no tenga ninguna consola de instancia abierta). Ademas, en v1 los servicios (p.e. BD) no arrancan de forma automática, solo manualmente.

Para info sobre el tema: esto ... y los enlaces que hay ahí. Esta ese del propio msoft y dice que si dejas algo andando en segundo plano una vez que entras a la instancia, aunque cierres la ventana, la instancia sigue andando, y es cierto.

Estos obstáculos se pueden soslayar gracias a ese hecho de que la instancia siga andando si el usuario entra y arranca algo que deja andando:

• autologon de sysinternals, una utilidad de msoft para que al arrancar el sistema se inicie una sesión del usuario indicado. Tb se puede hacer sin descargar nada, ejecutando netplwiz, deshabilitando Users must enter a username and password to use this computer. y aportando usuario y contraseña cuando te los pide. No citan ventajas de este método sobreo autologon de sysinternals.
• Para ese usuario, con [win]+[R] se ejecuta shell:startup para enlazarle la consola wsl a su inicio de sesión
• command = service mariadb start en apartado [boot] de /etc/wsl.conf furrula. El hecho de que en esa misma sección esté systemd=true y eso no lo haga supongo que es por estar el mode wsl v1.
• y en .bashrc se invoca el guión que se encargue de la app que se vaya a utilizar

v1

A nivel de red muy cómodo: instalas mariadb en debian, habilitas el puerto para escucha en /etc/mysql/mariadb.cnf y ya conectas don MySQL Workbench desde windows: comparten localhost.

v2

• CUIDADO que podría no funcionar junto a Virtaual Box.
• Actualmente, al menos en modo NAT parece que conectar desde el host windows a la instancia WSL no es problema: lo encuentra en localhost, pero a la inversa, o entrar desde fuera a la instancia es otro cantar, pq en ese escenario la IP es diferente.
• Con networking en modo mirror la cosa parece mas fácil, pq crea en linux espejos de las ifaces windows; eso sí, con el permiso del firewall de Hiper V, que hay que configurar para que acepte conexiones foráneas (aunque parece que es una única instrucción power shell) y parece que esto está tan reciente que hay problemas akí y allá.

Referencias

• Configuración avanzada
• Debian tiene una página en el wiki
• Existe interoperabilidad entre los dos mundos mas allá de la típica carpeta compartida
• Esta es la doc ténica de WSL y el repositorio github
• También hay una extensión WSL para VS Code