Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container applications running in Browser (without X server on the host) #110

Closed
eine opened this issue Jan 28, 2019 · 18 comments
Closed

Container applications running in Browser (without X server on the host) #110

eine opened this issue Jan 28, 2019 · 18 comments
Labels

Comments

@eine
Copy link
Contributor

eine commented Jan 28, 2019

First, some context. Since I use x11docker for development, I have focused on being able to use the same tools (containers) on different hosts (Win10, Fedora, Arch...). Precisely, I use x11docker to execute some GNU/Linux GUI apps on Win10. So, most of my comments are related to seamlessly adding x11docker to existing docker run commands, with minimum additional dependencies on the host: https://github.com/mviereck/x11docker/issues?utf8=%E2%9C%93&q=commenter%3A1138-4EB+

Today, I was using it on a Fedora 29 host, which I think is using wayland. I installed xpra and nxagent just to try them and I felt no difference. Then, I read https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#attributes-of-x-server-and-wayland-options. It seems that none of them support --gpu, so I need --xpra-xwayland if I want seamless mode and GPU support. This adds a bunch of dependencies (weston, Xwayland, xdotool) on the host. Hence, I am considering if it is worth in my use case. @mviereck, could you explain in very few words which are the advantages of using --xpra-xwayland instead of --hostdisplay?

What about --gpu support on Windows? IIRC (see #70), it is supported for seamless mode with either VcXsrv or Xwin. Should this be added to the wiki? I am not suggesting to do it. I wonder whether all the complexity about xpra, xephyr, wayland, etc. also applies to Win10 or it is somehow specific to GNU/Linux hosts. I found this page in the wiki: https://github.com/mviereck/x11docker/wiki/Wayland-on-MS-Windows. So, once again, is it worth using wayland on Windows instead of --hostdisplay (which defaults to --vcxsrv)?

Overall, I feel that I can either use x11docker without worrying about settings as long as it works; or I need to know quite a lot about window servers and desktop environments. When I read all the available options, I wonder how do they compare according to complexity. I.e., does --xpra-xwayland run X apps on top of wayland with an X compatibility layer, which is connected through xpra to the Xorg server on the host? Does xpra replace the Xorg server on the host? Is it more performant to run wayland than an X server (i don't know, maybe because it handles resizing better) even if you are not using/developing an app that depends on it?

@mviereck, I am not expecting you to answer all these last questions. Please, just drop some thoughts about it. If you have some list of references, I'd be glad to have a look.


Anyway, let's focus on the main topic. I was wondering which would be the approach to use x11docker in environments (clients) where no X server is available. I am thinking about Win10 setups without VcXsrv/Xwin or play-with-docker. This was asked in #80, which points to #40:

@mviereck I also did some attempts to run Weston and Xwayland in a container. Basically it works, but needs some final work.

Does this mean that weston/xwayland running in a container can replace the server on the host? I can somehow imagine such a setup replacing vcxsrv and being able to draw windows on my desktop. But I cannot understand how would it work on play-with-docker, as I believe that the browser should not let me create random windows.

I checked https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#description-of-x-server-options:

--xdummy --xvfb: Invisible X server for custom access e.g. with SSH or HTML5. Output of environment variables on stdout (--showenv). With --gpu a setup with Weston, Xwayland and xdotool is used (instead of Xdummy or Xvfb).

On the one hand, why are these not used with --gpu? I assume that --weston-xwayland is used. I.e., what does (X) mean in https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options#attributes-of-x-server-and-wayland-options? What about --kwin-xwayland, --weston or --kwin, which support both --gpu and console?

On the other hand, if I understand the scheme correctly, those are used in the server, so that applications running there believe that a display exists. Then, some client is connected to the server to actually render the windows. This is the case in the examples with SSH and xpra: https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra. However, this requires xpra to be installed on the client. I assume that xpra connects the server to the X server on the host/client. Hence, this does not really solve my issue.


Therefore, the last option is to use the browser to render the windows. This would work on almost any computer, because there are no dependencies at all besides docker (server) and a browser (client). I read Container applications running in Browser with HTML5. According to HTML5 with GTK3 broadway, I executed the example:

NOTE: I run all these tests on Win10 (MSYS2).

x11docker -t \
          --env BROADWAY_DISPLAY=:5 \
          --env GDK_BACKEND=broadway \
          -- -p 8085:8085 -- \
          x11docker/xfce "broadwayd :5 & sleep 2 && xfce4-terminal"

I get an error: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined. But I browsed localhost:8085 and it works fairly well.

NOTE: the clipboard in the browser is not shared with the client. I.e., you can copy and paste things between the windows in the web desktop. But you cannot copy that content to an application on the host. Neither can you copy content from the host to the windows in the web.

I wonder what's the difference between passing --env options to x11docker or putting them in the section for docker options. The following syntax works well too:

x11docker -t -- \
          -e BROADWAY_DISPLAY=:5 \
          -e GDK_BACKEND=broadway \
          -p 8085:8085 \
          -- x11docker/xfce "broadwayd :5 & sleep 2 && xfce4-terminal"

Then, I tried to install something, but I couldn't. See #111.

So, I wrote a Dockerfile:

FROM x11docker/xfce

RUN apt update -y && apt install -y gtkwave

I built it:

docker build -t broadway/gtkwave .

And I tried:

x11docker -t -- \
          -e BROADWAY_DISPLAY=:5 \
          -e GDK_BACKEND=broadway \
          -p 8085:8085 \
          -- broadway/gtkwave "broadwayd :5 & sleep 2 && xfce4-terminal"

I can start some GUI apps, such as another xfce4-terminal. But gtkwave refuses to start because:

Could not initialize GTK!  Is DISPLAY env var/xhost set?

Usage: gtkwave [OPTION]... [DUMPFILE] [SAVEFILE] [RCFILE]
...

Some others that fail:

  • Because of Cannot open display: .: xfce4-about, xfce4-appfinder, xfce4-notes, xfce4-keyboard-settings, xfce4-panel...
  • startxfce4 fails because exec: xinit: not found.
  • Thunar: Failed to initialize Xfconf: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11.

I get the same result if I try:

NOTE: ghdl/ext:vunit-gtkwave is based on Debian and libgtk-3-bin is already installed.

# ./x11docker -i --tty -- \
              -e BROADWAY_DISPLAY=:5 \
              -e GDK_BACKEND=broadway \
              -p=8085:8085 \
              -- ghdl/ext:vunit-gtkwave "broadwayd :5 & sleep 2 && bash"
x11docker WARNING: Command 'xauth' not found.
  Please install 'xauth' to allow X cookie authentication.
  Fallback: Disabling X authentication protocol. (option --no-auth)

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

x11docker WARNING: Option --no-auth: SECURITY RISK!
  Allowing access to X server for everyone.

x11docker note: Did not find container init system 'tini'.
  This is a bug in your distributions docker package.
  Normally, docker provides init system tini as '/usr/bin/docker-init'.

  x11docker uses tini for clean process handling and fast container shutdown.
  To provide tini yourself, please download tini-static:
    https://github.com/krallin/tini/releases/download/v0.18.0/tini-static
  Store it in one of:
    /home/eine/.local/share/x11docker/
    /usr/local/share/x11docker/

eine@62a5e0674a67:~$ exit
exit
Listening on /tmp/XDG_RUNTIME_DIR/broadway6.socket
eine@62a5e0674a67:~$ gtkwave
Could not initialize GTK!  Is DISPLAY env var/xhost set?
...

Note that I need to exit once, for the service to start.

I tried interactive mode because I wanted to install xterm or xfce4-terminal in the container. But, as reported in #111, I cannot install anything.

Am I missing something? Why does xfce4-terminal work but not any of the other?

@eine eine changed the title Container applications running in Browser without X server on the host Container applications running in Browser (without X server on the host) Jan 28, 2019
@eine
Copy link
Contributor Author

eine commented Jan 29, 2019

Some others that fail:

* Because of `Cannot open display: .`: `xfce4-about`, `xfce4-appfinder`, `xfce4-notes`, `xfce4-keyboard-settings`, `xfce4-panel`...

* `startxfce4` fails because `exec: xinit: not found`.

* `Thunar: Failed to initialize Xfconf: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11`.

I tried docker run --rm -p 8085:8085 chadmoon/gtk3-docker (from the reference in https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5):

  • All of the xfce4-* apps fails too.
  • startxfce4 fails with a different error: parse_vt_settings: Cannot open /dev/tty0 (No such file or directory).
  • Thunar fails with Cannot open display:.

Some of the applications in the launcher provided in gtk3-docker also fail. For example, gnome-tweak-tool and sysprof: GLib.Error: g-io-error-quark: Cannot autolaunch D-BUS without X11 $DISPLAY (0). midori: XDG_RUNTIME_DIR not set in the environment and Nested Wayland compositor could not create display socket. Surprisingly, if I restart the container, some of those that were failing now work ok.

Nevertheless, I cannot find where is broadway in chadmoon/gtk3-docker. Although I can see it running if I start the System Monitor from the launcher. Found it: https://github.com/moondev/gtk3-docker/blob/master/init.sh#L3

@mviereck
Copy link
Owner

mviereck commented Jan 29, 2019

A lot of questions. :-) I'll try to answer them all soon.

At least some points for now:

Why does xfce4-terminal work but not any of the other?

xfce is only partially ported to GTK3 yet, it's work in progress. Applications that still use GTK2 will fail. Many gnome application on the other hand are entirely based on GTK3 and are worth a try.
I myself did only few tests with broadway or html5 in general so I have only few experience.

you can copy and paste things between the windows in the web desktop. But you cannot copy that content to an application on the host.

I assume html5 works like a video stream. The browser does not render the fonts itself and does not know what is text and what is not. However, that is not nice for productive use.

@eine
Copy link
Contributor Author

eine commented Jan 29, 2019

A lot of questions. :-) I'll try to answer them all soon.

No need to answer any of them fast ;).

xfce is only partially ported to GTK3 yet, it's work in progress. Applications that still use GTK2 will fail. Many gnome application on the other hand are entirely based on GTK3 and are worth a try.

I checked the repo of gtkwave and I found that there is a gtk3 branch indeed: https://sourceforge.net/p/gtkwave/code/HEAD/tree/. So, I built it again (https://github.com/ghdl/docker/blob/master/dockerfiles/ext/vunit#L36-L57) using that branch (I had to add a single new dependency: libbz2-dev). However, it still complains about DISPLAY being empty.

I myself did only few tests with broadway or html5 in general so I have only few experience.

Did you use the other option (with xpra)? Or none of them?

I assume html5 works like a video stream. The browser does not render the fonts itself and does not know what is text and what is not. However, that is not nice for productive use.

I am not completely sure. Because you can copy text from a terminal and paste it to gedit. But only if both of them are in the html page. So there is some clipboard that is shared between all the apps connected to broadway.

@mviereck
Copy link
Owner

However, it still complains about DISPLAY being empty.

It could be an issue in gtkwave. Maybe it checks only DISPLAY but not BROADWAY_DISPLAY and GDK_BACKEND. It might be worth a bug report.

Did you use the other option (with xpra)? Or none of them?

I only checked out the possibilities how to get it work, but did not use them.
You can also run xpra server in container with or without x11docker.

Note that xpra server on itself does not support GPU. It uses invisible X servers Xvfb or Xdummy to create a display. x11docker does some setup in background with hidden Weston and Xwayland and connects xpra to Xwayland.

For the main purpose I think xpra is the most efficient way to run on a headless server.
Connecting with xpra client on the clients is probably the most performant and best integrated way, better than HTML5 or VNC. It has clients for Linux, Mac and Windows.

Because you can copy text from a terminal and paste it to gedit. But only if both of them are in the html page.

GTK_BROADWAY is some sort of X server and clients within can share a clipboard. However, a clever integration could communicate with the browser and tell it to exchange data with the host clipboard. But that might as well be forbidden for security/privacy reasons. Arbitrary internet sites should not be able to read your clipboard.

I wonder what's the difference between passing --env options to x11docker or putting them in the section for docker options.

For most setups it makes no difference. It takes effect e.g. with option --systemd. systemd deletes all environment variables and x11docker has to set them afterwards.

@eine
Copy link
Contributor Author

eine commented Jan 29, 2019

It could be an issue in gtkwave. Maybe it checks only DISPLAY but not BROADWAY_DISPLAY and GDK_BACKEND. It might be worth a bug report.

Actually, gtkwave does it properly. It uses gdk_init_check, so it does not check DISPLAY manually. However, I did not build it properly. Now I fixed it and it is working great!

./x11docker -t -- \
  -p=8080:8085 \
  -e BROADWAY_DISPLAY=:5 \
  -e GDK_BACKEND=broadway \
  -- ghdl/ext:vunit-gtkwave "broadwayd :5 & sleep 2 && gtkwave"

NOTE: I did need to change the base image from stretch to buster, because gtkwave won't compile with libgtk-3-dev version 3.22.11-1 available in the former. But it does with version 3.24.4-1 available in the latter.


For the main purpose I think xpra is the most efficient way to run on a headless server.
Connecting with xpra client on the clients is probably the most performant and best integrated way, better than HTML5 or VNC. It has clients for Linux, Mac and Windows.

That would be an option if I run the xpra client on Windows, because it will use the existing window server. Alternatively, xpra can be executed in a container, and connect it to vcxsrv I believe. However, this does not meet the requirement to not install anything besides docker.

Earlier, I did execute xpra natively in a GNU/Linux host in order to try the HTML5 client. It worked. I haven't used it with x11docker tho. But, if the app works with broadway, it seems to be a better solution. Anyway, since python is already installed in the image, i'll give it a try.

GTK_BROADWAY is some sort of X server and clients within can share a clipboard. However, a clever integration could communicate with the browser and tell it to exchange data with the host clipboard. But that might as well be forbidden for security/privacy reasons. Arbitrary internet sites should not be able to read your clipboard.

Agree. Nevertheless, since docker shares a directory between the host and the container, a file can be opened at the same time in both of them. This allows to work around the issue.

For most setups it makes no difference. It takes effect e.g. with option --systemd. systemd deletes all environment variables and x11docker has to set them afterwards.

Can x11docker parse docker variables (-e or --env) and save them as if they where provided before --? Other options, such as -i, -t or --user are functionally quite different, so it is easy to tell where to put them. However, it is not so clear with -e.

@mviereck
Copy link
Owner

./x11docker -t -- \
  -p=8080:8085 \
  -e BROADWAY_DISPLAY=:5 \
  -e GDK_BACKEND=broadway \
  -- ghdl/ext:vunit-gtkwave "broadwayd :5 & sleep 2 && gtkwave"

The command "broadwayd :5 & sleep 2 && gtkwave" works, but is ugly. It has the advantage not to change the image.
However, if you want to support it in general, I'd recommend an ENTRYPOINT script that sets up broadwayd in container depending on environment variables DISPLAY and/or GDK_BACKEND.
Maybe it is possible to check whether broadwayd is ready other than waiting with a stupid sleep.
Maybe it is possible to detect the open port and to configure broadwayd/BROADWAY_DISPLAY accordingly.

However, this does not meet the requirement to not install anything besides docker.

You will need some helper anyway to provide a display. It can be VcXsrv or an xpra client or a VNC viewer or a browser.
xpra provides the best performance across networks. VcXsrv provides the best performance for local setups. HTML5 and VNC are slow in all setups.

Can x11docker parse docker variables (-e or --env) and save them as if they where provided before --?

I don't want to parse DOCKER_RUN_OPTIONS. It has only few possible use cases but would need a bunch of code to cover all possible (and changing) docker run options.

@eine
Copy link
Contributor Author

eine commented Jan 30, 2019

The command in the comment above fails after the fix for #112: /x11docker/container.CMD.sh: 89: exec: broadwayd :5 & sleep 2 && gtkwave: not found. The correct syntax is:

./x11docker -t -- \
  -p=8080:8085 \
  -e BROADWAY_DISPLAY=:5 \
  -e GDK_BACKEND=broadway \
  -- ghdl/ext:vunit-gtkwave bash -c "broadwayd :5 & sleep 2 && gtkwave"

Also, if I add -i and replace gtkwave with bash. The behaviour is now correct. This comment above does not apply anymore:

Note that I need to exit once, for the service to start.

Last, note that these examples don't work with x11docker/xfce because of the bug described in #112.


The command "broadwayd :5 & sleep 2 && gtkwave" works, but is ugly. It has the advantage not to change the image.
However, if you want to support it in general, I'd recommend an ENTRYPOINT script that sets up broadwayd in container depending on environment variables DISPLAY and/or GDK_BACKEND.

Agree. Rather than changing the entrypoint, I would add the script to /etc/profile.d/. However, when I did this earlier (on Alpine) I did need to use sh -l, because sh did not source scripts in /etc/profile.d. See https://github.com/1138-4EB/elide/blob/master/docker/Dockerfile-alpine-run#L21-L24. BTW, as you see there, the script will contain gtk theme and icon theme setups too.

Maybe it is possible to check whether broadwayd is ready other than waiting with a stupid sleep.
Maybe it is possible to detect the open port and to configure broadwayd/BROADWAY_DISPLAY accordingly.

Sure. I will try with curl.

You will need some helper anyway to provide a display. It can be VcXsrv or an xpra client or a VNC viewer or a browser.

Even if performance is not the best, broadway works fairly well with gtkwave. That's what I wanted to test. Since libgtk-3-bin is already installed in the image, the benefit of this approach is that nothing but a browser is required. So, it allows to provide the demo of a environment for users that don't want or cannot spend time installing/configuring it. For example, currently this works:

 curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- -t -- -p=8080:8085 -e BROADWAY_DISPLAY=:5 -e GDK_BACKEND=broadway -- ghdl/ext:vunit-gtkwave bash -c "broadwayd :5 & sleep 2 && gtkwave"

And it can/will be improved to:

 curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- -t -- -p=8085:8085 -e GDK_BACKEND=broadway -- ghdl/ext:vunit-gtkwave bash -c "gtkwave"

Since x11docker shares a folder, this allows any user to try gtkwave with their own files. Just with a shell, docker and a browser. That's cool!

xpra provides the best performance across networks. VcXsrv provides the best performance for local setups. HTML5 and VNC are slow in all setups.

I will of course try xpra. I saw that there are lots of clients, as you commented. And I think that they can be used without admin privileges. However, unless the HTML option is used, SSH is required, isn't it? If so, I think that it is an interesting option for remote setups, but the effort might not be worth if/when VcXsrv is available.

Personally, I don't like the VNC approach, nor installing SSH in the container. Hence, it'd be great if xpra could be used locally (i.e., exposing the ports to the host only) without requiring SSH. I'll investigate.

I don't want to parse DOCKER_RUN_OPTIONS. It has only few possible use cases but would need a bunch of code to cover all possible (and changing) docker run options.

Understood.

@eine
Copy link
Contributor Author

eine commented Jan 30, 2019

This is the script I am using to start broadway automatically:

#!/bin/sh

# Example execution command:
#   x11docker -it -- -e BROADWAY=5 -p 8085:8085 -- ghdl/ext:broadway bash

set -e

if [ "$BROADWAY" != "" ]; then
  export BROADWAY_DISPLAY=":$BROADWAY"
  if [ "$GDK_BACKEND" = "" ]; then
    export GDK_BACKEND="broadway"
  else
    if [ "$(echo "$GDK_BACKEND" | grep "broadway")" == "" ]; then
      export GDK_BACKEND="$GDK_BACKEND,broadway"
    fi
  fi
  set +e; curl localhost:$((8080 + $BROADWAY)) > /dev/null 2>&1; err="$?"; set -e
  if [ "$err" != "0" ]; then
    echo "BROADWAY_DISPLAY: $BROADWAY_DISPLAY"
    echo "GDK_BACKEND: $GDK_BACKEND"
    # Start broadway server
    broadwayd "$BROADWAY_DISPLAY" &
  fi
fi

set +e

It can be added to any existing image with libgtk-3-bin:

FROM <image>

COPY broadway.sh /etc/x11docker/broadway.sh

RUN printf "\nsource /etc/x11docker/broadway.sh\n" >> /etc/bash.bashrc

Alternatively, lsof can be used instead of curl in order to detect if the service in the port is broadway. However, this requires lsof to be installed in the image.

  # Check if an instance of broadwayd is already running in the same port
  lsof -Pi :$((8080 + $BROADWAY)) -sTCP:LISTEN -Fc | grep broadwayd

Note that I did not need to work around sleep 2. It is just not required at all. If GDK_BACKEND and BROADWAY_DISPLAY are properly set, applications wait on their own.

EDIT

I added the script above to some images (ghdl/ext:broadway, ghdl/ext:gtk and ghdl/ext:gtk-ide). For example:

x11docker -it --user=RETAIN -- -p 8086:8080 -e BROADWAY=5 -p 8085:8085 -- ghdl/ext:gtk-ide

Then browse localhost:8086 and login with hwd (pass admin).

NOTE: Due to a bug, go to Settings > Global Settings and click UPDATE. See filebrowser/filebrowser#655.

Click the Toggle shell button on the top-right corner, and execute bash -c ". /etc/broadway.sh". From there on, every GUI application that is executed in the shell will be shown at localhost:8085.

@eine eine mentioned this issue Jan 31, 2019
9 tasks
@mviereck
Copy link
Owner

Today, I was using it on a Fedora 29 host, which I think is using wayland.

You can check WAYLAND_DISPLAY to see if a Wayland server is running. However, Gnome-Wayland also runs Xwayland to support X clients.

@mviereck, could you explain in very few words which are the advantages of using --xpra-xwayland instead of --hostdisplay?

It avoids the issues shown in warnings of x11docker if using --hostdisplay. With --hostdisplay container applications can access and control the host with X features like keylogging, remote window control and virtual keypresses and mouse clicks.

What about --gpu support on Windows? IIRC (see #70), it is supported for seamless mode with either VcXsrv or Xwin. Should this be added to the wiki?

I've added them to the wiki.

I wonder whether all the complexity about xpra, xephyr, wayland, etc. also applies to Win10 or it is somehow specific to GNU/Linux hosts. I found this page in the wiki: https://github.com/mviereck/x11docker/wiki/Wayland-on-MS-Windows. So, once again, is it worth using wayland on Windows instead of --hostdisplay (which defaults to --vcxsrv)?

Wayland does not run natively on MS Windows. The wiki describes a nested setup within VcXsrv.
As you have no choice on Windows, you needn't to worry about the different possibilities on Linux.
--hostdisplay does not work on Windows, x11docker falls back to --vcxsrv.

Overall, I feel that I can either use x11docker without worrying about settings as long as it works; or I need to know quite a lot about window servers and desktop environments. When I read all the available options, I wonder how do they compare according to complexity. I.e., does --xpra-xwayland run X apps on top of wayland with an X compatibility layer, which is connected through xpra to the Xorg server on the host? Does xpra replace the Xorg server on the host?

--xpra-xwayland does the following:

  • Run Weston as an host X client
  • Run Xwayland in Weston
  • Hide Weston window with xdotool
  • Attach xpra server to Xwayland
  • Run xpra client on host X.

Xwayland is not officially supported by xpra, but works well. It supports GPU acceleration while Xvfb and Xdummy don't.

Is it more performant to run wayland than an X server (i don't know, maybe because it handles resizing better) even if you are not using/developing an app that depends on it?

I did not compare it. Current Wayland desktops also run Xwayland for X clients, so there is still an X server.

@eine
Copy link
Contributor Author

eine commented Feb 1, 2019

Thanks a lot, once again. I think we can close this.

@totaam
Copy link

totaam commented Feb 1, 2019

I will of course try xpra. I saw that there are lots of clients, as you commented. And I think that they can be used without admin privileges.

Correct.

However, unless the HTML option is used, SSH is required, isn't it?

I'm not sure I understand the context of this statement, but generally speaking no, see https://xpra.org/trac/wiki/Network
In particular, if you care about performance, try to enable mmap. You may have to fiddle with the mmap file path.

@eine
Copy link
Contributor Author

eine commented Feb 1, 2019

@totaam, thanks for your comments. I just tried it today. Please, see a proof of concept in #117.

I'm not sure I understand the context of this statement, but generally speaking no, see xpra.org/trac/wiki/Network

As you say, no, it is not. Since xpra is running in a docker container, I can bind it to a TCP port that is exposed on the host.

In particular, if you care about performance, try to enable mmap. You may have to fiddle with the mmap file path.

I tried --mmap=yes and --mmap=no when starting the xpra server, but I feel no difference. There is no reference to mmap in the log. So, I don't really know whether it is being used. Do I need to set anything in the Windows client?

@totaam
Copy link

totaam commented Feb 1, 2019

Do I need to set anything in the Windows client?
The windows client normally connects to a windows shadow server, then mmap "just works".

I have zero experience trying to get mmap to work from a windows client to a container.
Try to enable -d mmap debug output. See also the mmap=ABSOLUTEFILENAME man page entry.

Here I assume that windows and the container both have access to a filesystem that supports shared memory where you can create the mmap backing file. But that may not be the case... I don't know.

@eine
Copy link
Contributor Author

eine commented Feb 1, 2019

Try to enable -d mmap debug output. See also the mmap=ABSOLUTEFILENAME man page entry.

Here I assume that windows and the container both have access to a filesystem that supports shared memory where you can create the mmap backing file. But that may not be the case... I don't know.

At first, I thought that two files where required, one for the server and another one for the client. After these comments, I understand that it needs to be the same file. That can be a little more tricky because:

#117 (comment)
Probably that won't work with a shared folder on Windows host but would have to be shared within docker because ntfs does not support unix socket

We are not using a socket for mmap. But the underlying idea is that making some features work on NTFS is not easy.

Moreover, I tried to use the Xpra.exe executable from the portable tarball in MSYS2, and it has no CLI interface. So I don't know if I can set --mmap=ABSOLUTEFILENAME, unless I build xpra for MSYS2 (as suggested in #117).

@totaam
Copy link

totaam commented Feb 1, 2019

Moreover, I tried to use the Xpra.exe executable from the portable tarball in MSYS2, and it has no CLI interface.

Try xpra_cmd.exe which is the command line version.

So I don't know if I can set --mmap=ABSOLUTEFILENAME, unless I build xpra for MSYS2 (as suggested in #117).

According to the xpra code, the mswindows code path should honour whatever mmap filename you tell it to use. (so I must have tested that at some point)

@mviereck
Copy link
Owner

mviereck commented Feb 1, 2019

Re: mmap file

xpra server runs in a container in a Linux VM. xpra client runs on Windows.
It is possible to share the same file located on the Windows ntfs file system with x11docker option --sharedir or docker run option --volume.
But I doubt that this allows to share memory. Though, it is worth a try.

@totaam
Copy link

totaam commented Feb 1, 2019

But I doubt that this allows to share memory.

You're right. I was thinking of WSL, and shared-memory doesn't even work there yet:
Add support for semaphores and shared memory

@eine
Copy link
Contributor Author

eine commented Feb 2, 2019

I think that all the questions in this issue have already being answered and we are moving slightly off-topic. I opened a new issue, #118, to continue the discussion about --mmap. We can keep talking about xpra on Windows in #117.

Some concluding remarks or summary:

@mviereck wrote:
Connecting with xpra client is probably the most performant and best integrated way, better than HTML5 or VNC. It has clients for Linux, Mac and Windows.

xpra provides the best performance across networks. VcXsrv provides the best performance for local setups. HTML5 and VNC are slow in all setups.


NOTE: x11docker is not required in order to use these setups, because no X server is executed on the host (see #80). However, it can still be useful in order to benefit from it's security enhancements.

NOTE: AFAIK, no example has been reported about how to share a single broadwayd server between multiple containers.


NOTE: The status and future of GTK+ Broadway are uncertain. As reported above, the clipboard is not shared with the host (see Bug 775680 - Implement copy+paste between broadwayd and client). Also, it does not work in play-with-docker (see play-with-docker/play-with-docker#319). The author commented about two years ago that it is likely to be removed in GTK4 (see gtk-devel-list: Gtk+4.x and broadway ( and other remote options )). So, although docs for both GTK3 and GTK4 exist, no one is looking after it.

@mviereck, it might worth adding a note to https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5 about the status of Broadway.

@eine eine closed this as completed Feb 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants