Discussion:
[winswitch] [xpra] Xpra and JupyterHub
Troll Berserker via shifter-users
2018-07-08 21:32:52 UTC
Permalink
Hi,

I was working on a local JupyterHub deployment
(if you don't know what Jupyter and JupyterHub is,
you may get a rough idea what is it from the first
8 minutes of this
video)
and once thought that it would be great to run X11 displays
in Jupyter signle-user notebook server about the same way
it is possible to start terminal emulators inside it.

While googling I've found the project named nbserverproxy
and the issue about proxying noVNC with it
(https://github.com/jupyterhub/nbserverproxy/issues/24)

nbserverproxy is a Jupyter notebook extension which
enables one to access a HTTP service running inside
Jupyter single-user server, see example in the readme
https://github.com/jupyterhub/nbserverproxy/blob/master/README.md#example

I've tried to run Xpra and discovered a bug in the nbserverproxy
websocket proxying logic, the fix will be merged sooner or later.

There is also a request to make nbserverproxy a standalone service
(https://github.com/jupyterhub/nbserverproxy/issues/1)
Having websocket issue solved, I've tried to use nbserverproxy
without the Jupyter Notebook app running and it was possible,
the JupyterHub package provides classes which make it easy
to authenticate against the Hub.

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.
Matteo Ipri via shifter-users
2018-07-09 08:33:16 UTC
Permalink
On Sun, Jul 8, 2018 at 11:32 PM, Troll Berserker via shifter-users <
Post by Troll Berserker via shifter-users
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
Troll Berserker via shifter-users
2018-07-09 14:05:00 UTC
Permalink
Post by Matteo Ipri via shifter-users
On Sun, Jul 8, 2018 at 11:32 PM, Troll Berserker via shifter-users <
Post by Troll Berserker via shifter-users
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?
Trying to attach to this message. If it fails see
https://gist.github.com/BerserkerTroll/4f579ada6429dc4b576b996bc786d898
Post by Matteo Ipri via shifter-users
I am curious of the solution you found for the home folder and the unix
socket file.
I mount an empty volume at /scratch and point HOME to this directory.
Xpra seem to ignore --socket-dir[s] options...
Post by Matteo Ipri via shifter-users
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).
BTW, you don't have to run `apt-get clean` each time, see
/etc/apt/apt.conf.d/docker-clean in the Ubuntu Docker images.
Post by Matteo Ipri via shifter-users
I just run that Dockerfile with vanilla JupyterHub, without nbserverproxy
and things works, although on the slow side.
So you are just running Xpra without anything in front of it
and you don't require authentication to access it?

Loading...