Howto configure SDDM/KDE/PLASMA remote deskop with xpra

[j-landru]

Howto configure SDDM/KDE/PLASMA remote deskop with xpra.

As it took me a while to make all that stuff working, I share here my personal notes here, hoping it can be useful for others or enhanced with probably better X config practice as I'm not an X11 expert.

Context : I'm trying to build containerized Alpine desktop OS image to be run on common container runtime (docker, podman, LXD,...). The goal is to deploy ephemeral VDI (Virtual Desktop Infrastructure) at scale on demand for network or computer science MOOC lab sessions on k8s infrastructure.
_

Disclaimer : I know that containerized os images break the primitive dogma enacted by Docker ("one process per container you'll execute"), that's why Canonical designed LXD as "lightvisor" to containerize full systems. But on k8s clusters LXD runtime is not common.

_

Desktop is KDE/PLASMA with its display manager i.e. SDDM. This note is about that latter configuration for clientless remote desktop on common HTML5 able browser. One key feature of that config is dynamic resolution adjustment of the remote virtual display to the browser window size. Googling, I didn't find lot of guidelines about SDDM on xpra, that's the goal of this note.

In such execution context (containers or pods) no graphic card (hardware nor paravirtualized), so Xorg is run with Xdummy driver, which offert the dynamic resolution capability. From xpra Xdummy doc, set Xorg parms to those values :

/usr/bin/Xorg -noreset +extension GLX +extension RANDR +extension RENDER -config /etc/xpra/xorg.conf -dpi 96

One key point to consider with display manager is the X server is driven by the DM, and with SDDM renewed at each session with its own extra Xorg parms, including a dynamic xauth config file named. So SDDM appends -background none -seat seat0 vt2 -auth /var/run/sddm/xauth_Xwxyz -noreset -displayfd 18 to the previous command with random Xwxyz file suffix. Xorg call config is located in the [X11] stanza of the sddm.conf file. In my case located in the /etc/sddm.conf.d/10-sddm-xpra-xdummy.conf splitted conf file.

/etc/sddm.conf.d/10-sddm-xpra-xdummy.conf file :

[X11]
# for xpra Start Xorg with Xdummy
# and set DPI 96 for dynamic resolution adjustment with client window size
ServerPath=/usr/bin/Xorg
ServerArguments= -noreset +extension GLX +extension RANDR +extension RENDER -config /etc/xpra/xorg.conf -dpi 96

So SDDM and its KDE/PLASMA session now run on an Xdummy xorg server. As told earlier this X server is respawned at each session with new xauth token file, so xpra in desktop mode has to be upgraded at each session. Xpra launch and its parms were placed inside a /etc/xpra/scrpits/xpra-remote-desktop.sh script to be restarted at each session by a call from the /usr/share/sddm/scripts/Xsetup SDDM hook script.

/etc/xpra/scrpits/xpra-remote-desktop.sh file :

#!/bin/bash

# At each session, sddm restarts Xorg and renews  xauth file  under /var/run/sddm to display greeter so need to adjust XAUTHORITY env before launching xpra upgrade
#  xpra always launched in upgrade-destop mode
#  bind-tcp localhost in dual stack IPv6/IPv4 on single 8080 port --bind-tcp=[::1]:8080 and --bind-tcp=[::ffff:127.0.0.1]:8080
# - remote access through ssh tunnel -L 8080:[::1]:8080 or ancient IPV4 -L 8080:127.0.0.1:8080 

# adjust XAUTHORITY before xpra upgrade-desktop
## for test and debug
##echo "before xpra launch /var/run/sddm dir  : "/var/run/sddm/$(ls -t /var/run/sddm) " --XAUTHORITY="$XAUTHORITY > /var/log/xauthority-env.txt
#  when launched inside /usr/share/sddm/scripts/Xsetup at Xorg startup several xauth files (previous and new) are present
#      under /var/run/sddm so set XAUTHORITY env to the newest one using "ls -t" and filter the first with "head -n 1" 

export XAUTHORITY=/var/run/sddm/$(ls -t /var/run/sddm | head -n 1) && \
                     /usr/bin/xpra upgrade-desktop :0 \
                    --bind-tcp=[::1]:8080 --bind-tcp=[::ffff:127.0.0.1]:8080 --readonly=no --sharing=yes  \
                    2>&1 > /var/log/xpra-remote-desktop-sh.log

## for test and debug
##echo "after  xpra launch /var/run/sddm dir  : "/var/run/sddm/$(ls -t /var/run/sddm) " -- XAUTHORITY="$XAUTHORITY >> /var/log/xauthority-env.txt

Then add xpra-remote-desktop.sh call at the bottom of /usr/share/sddm/scripts/Xsetup SDDM hook script.

cat <<EOF >> /usr/share/sddm/scripts/Xsetup
#
# launch xpra upgrade-desktop for html5 remote desktop
/etc/xpra/scripts/xpra-remote-desktop.sh
#
EOF

Nota : That xpra-remote-desktop.sh script could also be used on legacy baremetal or HVM VM systems to remote display classical X on graphic card server.

Nota : --bind-tcp is bound on localhost lo interface in dual stack IPv6/IPv4 mode to ssh tunneled access through IPv6 as well IPv4 in dual stack mode as well as IPv6 or IPv4 only mode.

Nota : On that conf test, xpra is tcp bound on localhost lo interface in clear HTTP protocol and acceded only through ssh tunnel. I am aware that it would also be necessary to consider more classical conf with usual secure web access protocols such https, wss, quic... also IPv6 only or dual stack mode.

For local test

In the container : note ip address of the container - launch sddm - on the docker host open tunneled ssh session to container on local source tunnel port xxxx and remote target tunnel port 8080 - then point your browser to http://[::1]:xxxx for IPv6 or http://127.0.0.1:xxxx for ancient IPv4

For example on default docker bridge docker0 if LLA IPv6 address on eth0 inside the container is fe80::42:acff:fe11:2/64
Set up ssh tunnel using

# ssh -L 8080:[::1]:8080 yourlogin@fe80::42:acff:fe11:2%docker0

command and then point your usual recent (html5 compliant) browser to http://[::1]:8080 or http://127.0.0.1:8080

Nota : on host, docker has to have IPv6 enabled (see : enable IPv6 support), otherwise the loopback lo interface inside the container does not have standard ::1 IPv6 localhost address set and dual stack xpra-remote-desktop.sh will fail.

Nota : If you want to stay in ancient world you can open your tunnel on IPv4. Assuming that IPv4 eth0 container address is 172.17.0.2 then ssh command could be :

# ssh -L 8080:127.0.0.1:8080 yourlogin@172.17.0.2

Nota : When changing the browser window size, sometimes you may need to reload the xpra html5 page, with the browser command, to trigger the resolution adjustment (strangely, the reload command from xpra status bar not working, maybe because of ssh tunnel redirection ?). - need further investigation...

[totaam]

/usr/bin/Xorg -noreset +extension GLX +extension RANDR +extension RENDER -config /etc/xpra/xorg.conf -dpi 96

Don't use -dpi 96, recent versions of the dummy driver should be able to give you virtualized dpi.

and dual stack xpra-remote-desktop.sh will fail

Have you tried using --bind-tcp=*:8080?
You should not even need IPv6 since you can use an IPv4 address with your tunnel.

[j-landru]

Don't use -dpi 96, recent versions of the dummy driver should be able to give you virtualized dpi.

Thank you for your comment, it was left over from trial and error fine-tuning. The automatic and dynamic resolution adaptation does indeed work very well without this parameter.

Have you tried using --bind-tcp=*:8080 ?

I didn't know this parameter could be used with wildcards. I tested it and it works as expected: "all interfaces, IPv6 protocol as well as IPv4". At this stage, instantiating the idea of a complete desktop in a container, I limit access to the loopback device only. Wildcards will be useful when considering more conventional secure access such https, wss or quic.

You should not even need IPv6 since you can use an IPv4 address with your tunnel.

I know, but as a network teacher, in 2023 (and since 2015), I consider that all howto or tutorials should show IPv6 only and eventually in dual-stack. IPv4 should be considered as dead language just like Latin or ancient Greek, venerable but unsuitable. ;o)

[totaam]

all howto or tutorials should show IPv6 only
IPv4 should be considered as dead language

Hell no!
You're jumping through hoops to enable an IPv6 address which doesn't even need to be used.
IPv6 is much more complex than IPv4, it has its place, but using it between a host and a container is not it.

[j-landru]

You're jumping through hoops to enable an IPv6 address which doesn't even need to be used.

It's your point of view...

IPv6 is much more complex than IPv4, it has its place, but using it between a host and a container is not it.

I think the exact opposite is true: the structuring, type and scope of addresses ensures much better direct readability. Native auto-configuration and IID size is much better suited to the dynamics and scale of ephemeral cloud containers. For the latter, whether it's k8s or Openstack, the complexity of the network level is exorbitant due to the multi-level implementation of dynamic NAPT, the result of an initial development choice that was IPv4-only rather than IPv6-compliant dual stack.
I think the false impression of IPv6 complexity is strongly linked to a natural reluctance to change. Comfortably ensconced in the habits of IPv4's dotted decimal notation, many developers are reluctant to embrace the new hexadecimal notation needed for IPv6.

I don't think this is the right place for that kind of debate. Xpra is an excellent tool for my needs and the script described above has shown me that multiprotocol compliance is there. That's the most important thing to me.

[totaam]

You're jumping through hoops to enable an IPv6 address which doesn't even need to be used.

It's your point of view...

Err. It's plain facts.
You're spending effort enabling IPv6 (multiple steps are needed), without which - in your own words: IPv6 localhost address set and dual stack xpra-remote-desktop.sh will fail
So you've made your script brittle and gained no benefits since IPv6 is not actually used. (hidden behind a tunnel)

I think the false impression of IPv6 complexity ..

"False" - it's your point of view. 😉

[j-landru]

"False" - it's your point of view.

Ahah, yes after more than 20 years of teaching IPv6 and feeling like "preaching in the desert"...

So you've made your script brittle and gained no benefits since IPv6 is not actually used. (hidden behind a tunnel)

Of course my ssh tunnel is IPv6 only (between IPv6 LLA endpoints) and inside that tunnel flows are also IPv6 only, the applicative dest endpoint is [::1]:8080. But works as well on with endpoint 127.0.0.1:8080 inside IPv6 only ssh tunnel and reverse. That's the "magic" of fully dual stack compliance. I can furnish some wireshark capture if you are not convinced...