Viviendo en wayland desde el login

Desde que publiqué la entrada anterior he estado usando la sesión de xfce en wayland en un par de máquinas y la verdad es que estoy muy contento con como va la cosa, así que me ha pillado un poco el tema y he seguido con un run run en la cabeza hasta que haciendo una búsqueda (no en google sino en apt) di con la respuesta.

El run run era una pregunta de si no había ningún "display manager" para wayland, es decir, sabía que el gdm iba nativamente sobre wayland, pero montar gdm con todas las dependencias que tiene para tener sólo un login... no me había molado, por eso comenté en el artículo anterior que podemos arrancar directamente el xfce en wayland desde el login de la consola. Pero claro... eso es un poco "cutre", igual no es esa la palabra pero me entendéis, hoy todo el mundo quiere todo gráfico, por eso tenemos en Debian un instalador gráfico que es igual que el de modo texto pero... es gráfico X-)

La pregunta que le hice a apt debió de ser algo como...

$ apt-cache search wayland display manager greetd - minimal Wayland login manager tan concreta fue su respuesta que no pude evitar instalar greetd y tirar del hilo, me llevó a que va a juego con los "greeters" y entre ellos me quedé con:
nwg-hello - GTK3-based greeter for the greetd daemon
lo que pasa es que los greeters como nwg-hello necesitan por debajo un compositor, uno que me gustó mucho porque es muy sencillo y para un greeter va muy bien es cage, si queremos arrancar nwg-hello desde greetd usando cage tenemos que editar /etc/greetd/config.toml y poner
command = /usr/bin/cage /usr/bin/nwg-hello
sencillo, ¿no?

Si te gusta el look explosivo que trae nwg-hello pues genial, yo lo quería un poco más sobrio y con el look de Debian, así que en /etc/nwg-hello hice lo que dice el README que está allí, copié los default y edité el nwg-hello.css para cambiar la imagen de fondo dejándola tal que así:

background-image: url("/usr/share/desktop-base/active-theme/login/background.svg"); background-size: 140% 140% El cambio del tamaño a 140% es para que al agrandar la imagen el logo de Debian 13 se vaya más a la derecha y quede como al medio de la segunda mitad de la pantalla, donde no está la parte de login.

Puestos a investigar y dado que el compositor que uso luego en xfce es labwc me puse a buscar en la red si podíamos usar labwc para arrancar el nwg-hello y encontré esto donde se explica todo perfectamente, pero que resumiendo sería poner en /etc/greetd/config.toml:
command = "labwc --config-dir /etc/nwg-hello/labwc-config"
y crear ese directorio que configuramos con esa linea, que no existe, y dentro de él creamos el fichero autostart con este contenido:
exec /usr/bin/nwg-hello; /usr/bin/labwc --exit
y listo.

Ahora si que me ha quedado una sesión fully wayland y potita, y el overhead para la sesión es sólo el greetd, no se queda nada más por ahí corriendo, así que lo he puesto hasta en el netbook, aunque ahí hubo que tocar un poco más el css para que entrase todo en la pobre resolución de la pantalla, pero vamos, bajar los paddings de 12 a 5 y descomentar los labels del welcome y clock para que las fuentes sean más pequeñas.

A disfrutarlo.

Wayland en Debian 13 (Trixie) usando xfce

Hace ya tiempo que quería pasar alguna de mis máquinas a Wayland pero nunca me ponía porque los entornos de escritorio que soportan Wayland son muy pesados y sway y sus amigos no me atraían mucho, la verdad.

Sin embargo recientemente, mientras probaba la que será la Debian 13 (Trixie, que todavía no ha salido, pero que ya ando probando), he tenido problemas con mi viejo netbook, y me vi probando algunas de las alternativas sobre Wayland y entre ellas y para mi sorpresa, en Trixie tendremos xfce 4.20, cuyo soporte de Wayland es todavía un poco pobre, pero que combinado con labwc creo que puede dar una buena experiencia sobre Wayland.

Vayamos al tema, tendremos que instalar los paquetes xfce4 labwc, eso está claro, añadimos algunos extras como xfce4-goodies xfce4-power-manager swayidle swaylock swaybg mako-notifier. La sesión de xfce para Wayland viene configurada ya en los paquetes y quedará disponible para su arranque desde los display managers (aunque ahora mismo parece que en lightdm no funciona, si lo hace en sddm y gdm3) o bien podemos arrancarla directamente desde la consola como se hacía antiguamente con las X con startx, como me recordó un viejo profile heredado desde sabe dios que versión de Debian que decía...

case "`tty`" in
    /dev/tty[1-4]) exec startx
esac

Pues como la sesión de xfce en wayland se arranca como startxfce4 --wayland podemos poner esto en lugar del startx o bien arrancarlo a mano, con un alias, ...

Uno de los primeros problemas que afronté fue la configuración de teclado, suelo usar teclado español y si bien encontré enseguida que la configuración que usa xfce para labwc está en el directorio .config/xfce4/labwc y en concreto podía poner el teclado en castellano poniendo en el fichero environment la variable XKB_DEFAULT_LAYOUT=es y ejecutando labwc -r para recargar, el problema está en que este fichero se genera automáticamente cada vez que se arranca xfce, así que se sobreescribía todo el rato, me costó bastante dar con este bug en el que se describe como workaround el crear un fichero con nombre lock en dicho directorio para evitar que xfce sobreescriba nuestra configuración.

Una vez conseguido esto empecé a configurar las cosas como a mi me gustan, normalmente haciendo todo ya desde la configuración gráfica de xfce, incluso cuando se trató de añadir el "salvapantallas" que bloquease la sesión al cabo de un rato indicando en la configuración de la sesión que quería ejecutar un nuevo programa con este comando que venía como ejemplo en alguna de las múltiples webs de ayuda de labwc:

swayidle -w timeout 300 'swaylock -f -c 000000' timeout 600 'wlopm --off \*' resume 'wlopm --on \*' before-sleep 'swaylock -f -c 000000'

O lo mismo pero para poner el fondo de pantalla:

swaybg -i /usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg

Una cosa más, que sí tuve que tocar a mano, porque la parte del teclado va todo sobre labwc, fueron los atajos de teclado, los keybindings que se definen en .config/xfce4/labwc/rc.xml y que quería cambiar para añadir un atajo a la ejecución de comandos con control+alt+espacio usando:

    <keybind key="C-A-space">
      <action command="xfce4-appfinder --collapsed" name="Execute">
    </action></keybind>

Básicamente eso fue todo, para estar por así decirlo en pañales esta primera versión de xfce con soporte de wayland... la verdad, todo bastante bien, sobre todo la economía de memoria de todo esto corriendo en mi viejo netbook con 2 gigas de ram ahorrándome display managers y todo tipo de cosas que no necesitaba para nada, mucho mejor que mi viejo setup que ya era minimalista, pero llevaba las X con su display manager, ... ahora no voy a decir aquello de que "es alucinante y vuela" ;-) porque ya sabemos que ese viejo Atom con un navegador moderno nunca va a volar, pero... va mucho mejor :-)

Windows 11 en una máquina vieja vía libvirt en Linux

Entre los requirimientos de Windows 11 están una CPU moderna, arranque EFI seguro y un dispositivo de seguridad TPM versión 2.0. A continuación os comentaré como lo instalé sin trucos en una máquina virtual dentro de una máquina que no tiene ni TPM ni arranque seguro EFI, así que el único requerimiento que cumplía era el tener una CPU algo moderna, con virtualización hardware, claro.

Para poder probar cosas con el Windows 11 en el trabajo he querido instalar Windows 11 como siempre hago con los Windows, es decir, en una máquina virtual dentro del sobremesa, hasta ahora siempre lo he hecho con VirtualBox, es cómodo y cumplía con lo que yo necesito.

Sin embargo en este caso, si queremos instalar Windows 11 sin trucos, necesitaremos un dispositivo de seguridad TPM, que no existe en VirtualBox, así que... he explorado un poco el mundo de libvirt usando por debajo KVM, que sí que nos permite usar un TPM software y el resto de cosas que necesita Windows 11 para funcionar.

He utilizado los paquetes de Bookworm (ahora en testing mientras no se convierte en la nueva estable) para contar con las últimas versiones y no tener que andar haciendo las cosas "a mano" editando los XML y tal, con las versiones de Bookworm se puede hacer todo en plan gráfico sin problema, con versiones anteriores igual también se puede, pero en algunas hay que tocar los XML a mano.

La cosa para mi ha sido instalar por un lado la parte de libvirt, instalé estos paquetes: virt-manager virt-viewer libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-systemd libvirt-daemon-config-nwfilter libvirt-daemon-config-network libvirt-clients gir1.2-spiceclientgtk-3.0

Por otro lado para cumplir con los requerimientos del Windows 11 (TPM y arranque EFI) instalé: swtpm-tools ovmf

En algunas pruebas en alguna máquina muy "barebones" no tenía un polkit adecuado así que le instalé: lxpolkit Esto no será necesario en sistemas normales con interfaz gráfica ya que ya tendrán instalado un polkit, sino... el propio virt-manager os lo indicará con un error, sino... arrancarlo con "--debug"

Entre los requerimientos de Windows 11 están la CPU, que tiene que ser moderna y que el arranque sea EFI, por ello definiremos una nueva máquina en el virt-manager poniendo de arranque la ISO del Windows descargada de MS, dejaremos que detecte el operativo (detecta Windows 10, por ahora no tienen 11, pero nos sirve) y justo al final, antes de darle a finish, activaremos "Customize configuration before install" y ahí le ponemos en "overview" tendremos que cambiar el apartado "firmware" de BIOS a UEFI con arranque seguro (secboot), además iremos a la ventana "CPUs" y eligiremos en "Configuration" la opción "host-passthrough".

Si le dimos a "apply" en las opciones podemos volver a "overview" y comprobar en el xml que nos queda algo como esto:

machine=pc-q35-7.1 cpu mode='host-passthrough' ... firmware UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.secboot.fd

El otro requerimiento que tiene Windows 11 y que no suelen cumplir las máquinas menos modernas es el TPM, pero al ser una máquina virtual usamos el TPM software que hemos instalado y listo. Para esto añadimos a la máquina un dispositivo nuevo de tipo TPM y modelo TIS, y listo, ya podemos darle a "Begin installation".

Esta configuración de máquina es con la tarjeta gráfica qxl, cuando terminemos la instalación de Windows será conveniente instalar en el Windows 11 las spice guest tools que podemos descargar de spice-space.org para tener un buen soporte del esta y el resto del hardware.

Una vez instalemos eso apagamos la máquina y en el virtual-manager en la ventana de la máquina virtual Windows 11, seleccionamos "view", "scale display" y marcamos "autoresize vm with window"

Listo, con esto Windows debería reconocer todo el hardware y hacer escalado de la pantalla al tamaño de nuestra ventana.

Trabajando en remoto sobre Debian

La situación actual nos ha llevado a muchos a trabajar en remoto, algo para lo que hay muchas opciones, hablemos de alguna de ellas.

SSH

Es el sistema de acceso remoto por excelencia, lo usamos todos desde siempre, o al menos desde que la seguridad en la red importa, aunque no siempre fuera así, los ancianos del lugar usábamos el telnet, pero mejor no hablar de temeridades, no? ;-)

El secure shell como su propio nombre indica está diseñado para acceder a un shell, es decir, para acceso remoto a un entorno modo texto, pero como ya sabréis permite hacer túneles de todo tipo, desde puertos hasta forwarding de clientes X.

Si bien el SSH nos permite acceder a nuestros clientes X y traerlos hasta el servidor local de nuestro ordenador en casa, resulta que las X no están diseñadas para que el cliente y el servidor estén separados por las latencias de una wan por medio, por lo que aunque tengamos 1 giga de ancho de banda, nuestras aplicaciones X en remoto irán muy lentas, por eso... veamos que podemos utilizar para la parte gráfica...

x2go

Seguro que es el sistema más currado y más complejo para acceso remoto, soporta no sólo Linux, pero... si lo probáis veréis que hace muchas cosas por su cuenta sin contárnoslas, así que uno no deja de preguntarse... ¿para qué es todo esto? Lo tenemos soportado en Debian con paquetes tanto para hacer de servidor como para cliente, aunque ya os digo que a mi me pareció demasiado complejo y poco transparente.

Sin embargo si miramos debajo del capó vemos que utiliza la tecnología de NX que me parece más sencilla y entendible.

NX

Se trata de una tecnología que nos permitirá la utilización de aplicaciones nativas X tal cual, se basa en la proxificación de los clientes X de modo que los eventos no tengan tanta latencia y por lo tanto todo vaya mucho más fluido. Además añadiremos un servidor X en el lado remoto que nos permitirá tener una mejor respuesta y sesiones permanentes.

Su uso es sencillo, veamos un ejemplo, la idea es que accedemos al sistema remoto via ssh -L 4008:localhost:4008 host.remoto (forwardeamos el puerto 4008 que usaremos para el proxy de NX que correremos con :8 o sea usando el puerto 4008) y allí ejecutamos un proxy al que nos conectamos desde localhost a través de este puerto que hemos forwardeado. Esa es la parte de proxificado, pero vamos a añadir el agente que lo que hace es añadir un servidor X local sobre que lanzaremos las aplicaciones X y que nos dará también una sesión permanente que nos permite desconectarnos y conectarnos cuando queramos, veamos esto:

Remoto: nxproxy -C :8 & Local: nxproxy -S localhost:8 & Remoto: nxagent -display nx/:8 -geometry 1276x976 :9 & DISPLAY=:9 startlxqt

En el ejemplo arrancamos el lxqt, pero se puede arrancar lo que sea. Esta sesión sera permanente, ya que como dijimos estamos arrancando un servidor X en el equipo remoto, en este caso el DISPLAY será :9, contra el que irán las aplicaciones X. Aunque apaguemos el equipo local, se corten las comunicaciones o lo que sea, podremos reconectar. Para esto sólo hay que rearrancar las partes del proxy remoto y local y luego avisar al nxagent de que queremos que nos vuelva a mandar el display utilizando por ejemplo:

killall nxagent -HUP

VNC

Que decir de VNC, ha estado ahí desde hace muchos años.

Tenemos el servidor al estilo windows, en el paquete x11vnc que podemos arrancar así:

x11vnc -rfbport 5900 -bg -o %HOME/.vnc/x11vnc.log.%VNCDISPLAY -rfbauth ~/.vnc/passwd -display :0 o el tigervnc-scraping-server que al igual que el anterior nos permitirá acceder vía cliente VNC a unas X que estén corriendo, aunque ahora tenemos también la extensión de X tigervnc-xorg-extension que nos dará la misma funcionalidad pero de una manera mucho más eficiente. Estos están bien para ver lo que hay en ejecución en la pantalla de un equipo y por ejemplo ofrecer ayuda remota.

Además tenemos el tigervnc-standalone-server y el tightvncserver que lo que nos permiten es tener todas las sesiones X que queramos (ya que no van atadas a nuestra gráfica ni nada) y accederlas en remoto vía VNC, y por supuesto varios clientes específicos de vnc como tigervnc-viewer y xtightvncviewer además de otros que soportan VNC y otros protocolos.

El handicap de siempre del VNC es que todo va en claro, nada va cifrado, así que necesita sí o sí de SSH o similar para cifrar los datos.

RDP

Este protocolo diseñado por Microsoft tiene ahora tanto servidores como clientes para Linux, requiere mucho menos ancho de banda que VNC y soporta diversos tipos de cifrado, tanto cifrado propio como incluso una capa de TLS.

Al igual que en el caso de VNC tenemos también servidores para acceso a un servidor X ya existente, como el freerdp-shadow-cli en el paquete freerdp2-shadow-x11. Lo podemos lanzar con esta orden para acceder a las X corriendo en :0:

DISPLAY=:0 freerdp-shadow-cli /port:12345

Ya sabéis, como en el caso del VNC, es muy útil para ayuda remota. Si bien es conveniente tener en cuenta este bug ya que hace que nofuncione la autenticación mientras que no lo arreglemos, así que o bien recompilamos o bien añadimos el parámetro -auth, pero entonces cualquiera que tenga acceso al puerto podrá tomar control de la sesión X.

También tenemos clientes como el clásico rdesktop o el xfreerdp del paquete freerdp2-x11 y otros clientes que soportan VNC, RDP y más, como vinagre, de GNOME o remmina.

Pero si lo que queremos es un acceso remoto a un entorno de trabajo Linux persistente tendremos que fijarnos en xrdp, todo un servidor rdp para dar acceso a tantas sesiones de escritorios Linux como queramos, estas sesiones serán permanentes y podremos conectarnos y desconectarnos de las mismas cuando queramos, además soporta sonido, aunque eso requerirá que compilemos los módulos siguiendo estas instrucciones, la reproducción de sonido es estándar, por lo que funcionará en cualquier cliente, pero si queremos mandar nuestro micro al server deberemos utilizar por ejemplo el paquete de rdesktop de buster (lo he probado y funciona) o algún otro compatible, ya que han hecho una implementación no estándar :-(

No voy a hablar de más protocolos (que los hay) pero si quería hablar de algo que me parece muy interesante, un potente cliente web de todos estos protocolos y más...

Guacamole

Esto si que no lo tenemos en Debian, aunque hubo algún intento de paquetización antiguo y probablemente os podáis encontrar todavía por ahí los paquetes viejos, no os los aconsejo porque tienen varios bugs de seguridad. Este cliente es bastante complejo, con diversas partes, basado en java, requiere al menos un tomcat para mover el servidor, ... pero a cambio tendremos acceso a servidores RDP, VNC, ssh, ... con seguridad de dos factores en varios estilos y colores y el cliente no necesitará nada más que un navegador web, algo que nos puede aligerar los requisitos para los trabajadores que tengan que acceder en remoto.

Bueno, eso es todo lo que se ocurre ahora mismo, podéis sugerir otras ideas en los comentarios.

Saludos.