[winswitch] [xpra] Xpra and JupyterHub

[Matteo Ipri]

On Sun, Jul 8, 2018 at 11:32 PM, Troll Berserker via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> A day ago I finally got a working container with Xpra and the
> proxy in front of it running without Jupyter notebook server.
>
> JupyterHub supports a bunch of different Authenticators and Spawners
> (for example, we are using KubeSpawner to spawn single-user
> containers in a Kubernetes cloud)
> I don't know any other remote desktop project which could be
> as flexible as JupyterHub+Xpra combination.
> AFAIK x2go and Apache Guacamole support some sort of load balancing,
> but I don't think they support, for example, Kubernetes.
> The disadvantage is that the only way to access Xpra is its HTML5 client.
>
> I'm attaching the Dockerfile and the entry script I'm using.
> This is the first version which is not ideal and has some workarounds and
> dirty hacks I had to use to make it working.
> I've found that  Xpra became kinda rebellious: it ignores the orders I
> give it
> not to launch dbus and pulseaudio and not to put sockets in an original
> HOME directory
> (which is a network-mounted FS which doesn't seem to support sockets and
> pipes)
> so I had to install nss-sssd connector to map UIDs to usernames so that
> the dbus-launch doesn't refuse to start and I had to override the HOME
> variable.
>

The python script is not attached to the mailing list, only the Dockerfile
has been delivered embedded in the email.
Can you share again the entrypoint script?

I am curious of the solution you found for the home folder and the unix
socket file.
I also run JupyterHub which spwans docker containers running xpra.
I shared my Dockerfile in another thread here on the mailing list (I just
sent it again copy and pasted in an email since the attachment did not get
through).
I just run that Dockerfile with vanilla JupyterHub, without nbserverproxy
and things works, although on the slow side.
The javascript proxy is too slow for websockets and adds too much latency.
At least this is my impression, but I can not be sure that the culprit is
only the javascript reverse proxy contained in JupyterHub.

Thanks