search

mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.66k stars 377 forks source link

Usage of xpra on windows #117

Closed eine closed 5 years ago

eine commented 5 years ago

Coming from #110, I tried the following on MSYS2:

First, start a GUI app on top of a xpra server inside a container and bind it to a TCP port:

# ./x11docker -it --user=root -- -p 127.0.0.1:8086:8080 -- ghdl/ext:gtk-ide bash
...
root@f7909b85975c:~# apt install -y xpra
...
root@f7909b85975c:~# pip3 install websockify
...
root@f7909b85975c:~# xpra start --start=gtkwave --bind-tcp=0.0.0.0:8080

Warning: running as root
root@f7909b85975c:~# Entering daemon mode; any further errors will be reported to:
  /tmp/XDG_RUNTIME_DIR/xpra/S2138.log
Actual display used: :0
Actual log file name is now: /tmp/XDG_RUNTIME_DIR/xpra/:0.log

Then, download an xpra client for windows (https://xpra.org/dists/windows/Xpra-Client-x86_64_2.4.3-r21365.zip). Either by opening Xpra-Launcher.exe and clicking Connect or opening Xpra.exe directly, I can connet to root@localhost:8086 (without passowrd). The GUI shows as a new window in my desktop. Cool!

This is the log of the server:

root@f7909b85975c:/tmp# cat  /tmp/XDG_RUNTIME_DIR/xpra/:0.log
2019-01-31 17:48:19,252 cannot access python uinput module:
2019-01-31 17:48:19,252  No module named uinput

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
Current Operating System: Linux f7909b85975c 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 25 October 2018  06:15:23PM
xorg-server 2:1.20.3-1 (https://www.debian.org/support)
Current version of pixman: 0.36.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.S2138.log", Time: Thu Jan 31 17:48:20 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-01-31 17:48:23,959 Warning: failed to create socket directory '/run/user/0/xpra'
2019-01-31 17:48:23,959  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-01-31 17:48:23,959 Warning: cannot create socket '/run/user/0/xpra/f7909b85975c-0':
2019-01-31 17:48:23,959  [Errno 2] No such file or directory
2019-01-31 17:48:23,960  /run/user does not exist
2019-01-31 17:48:23,960 created unix domain socket: /run/xpra/f7909b85975c-0
/bin/sh: 1: dbus-launch: not found
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is 127

2019-01-31 17:48:24,963 Warning: menu forwarding is disabled:
2019-01-31 17:48:24,963  cannot load dbus helper: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnorma
lly without any error message
2019-01-31 17:48:24,993 pointer device emulation using XTest
2019-01-31 17:48:25,514  OpenGL is supported on this display
2019-01-31 17:48:25,555 html server unavailable, cannot find websockify module
2019-01-31 17:48:25,567 dbus server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap
    v = fn()
  File "/usr/lib/python2.7/dist-packages/xpra/x11/server.py", line 1302, in make_dbus_server
    return X11_DBUS_Server(self, os.environ.get("DISPLAY", "").lstrip(":"))
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_server.py", line 38, in __init__
    bus = init_session_bus()
  File "/usr/lib/python2.7/dist-packages/xpra/dbus/common.py", line 22, in init_session_bus
    _session_bus = dbus.SessionBus(private=private)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:48:25,568 Error setting up server dbus instance:
2019-01-31 17:48:25,568   org.freedesktop.DBus.Error.Spawn.ExecFailed
2019-01-31 17:48:25,568   /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:48:25,571 Warning: failed to load or register our dbus notifications forwarder:
2019-01-31 17:48:25,571  org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error mes
sage
2019-01-31 17:48:25,571  if you do not have a dedicated dbus session for this xpra instance,
2019-01-31 17:48:25,571  use the 'notifications=no' option
2019-01-31 17:48:25,590 Warning: webcam forwarding is disabled
2019-01-31 17:48:25,590  the virtual video directory '/sys/devices/virtual/video4linux' was not found
2019-01-31 17:48:25,590  make sure that the 'v4l2loopback' kernel module is installed and loaded
2019-01-31 17:48:25,590 found 0 virtual video devices for webcam forwarding
2019-01-31 17:48:25,596 Warning: cannot load dbus helper:
2019-01-31 17:48:25,596  org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error mes
sage
2019-01-31 17:48:25,670 Warning: failed to load the mdns publisher
2019-01-31 17:48:25,670  No module named avahi
2019-01-31 17:48:25,670  either fix your installation or use the 'mdns=no' option
2019-01-31 17:48:25,670 xpra X11 version 2.4.3-r21350M 64-bit
2019-01-31 17:48:25,670  uid=0 (root), gid=0 (root)
2019-01-31 17:48:25,670  running with pid 2142 on Linux debian buster/sid
2019-01-31 17:48:25,671  connected to X11 display :0 with 24 bit colors
2019-01-31 17:48:25,776 xpra is ready.
2019-01-31 17:48:26,306 7.8GB of system memory

GTKWave Analyzer v3.3.99 (w)1999-2019 BSI

GTKWAVE | Use the -h, --help command line flags to display help.
2019-01-31 17:57:12,378 New tcp connection received from 172.17.0.1:33068 on 0.0.0.0:8080
2019-01-31 17:57:12,381 Handshake complete; enabling connection
2019-01-31 17:57:12,391 dbus server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap
    v = fn()
  File "/usr/lib/python2.7/dist-packages/xpra/server/source/dbus_mixin.py", line 29, in make_dbus_server
    return DBUS_Source(self, os.environ.get("DISPLAY", "").lstrip(":"))
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_source.py", line 36, in __init__
    session_bus = init_session_bus()
  File "/usr/lib/python2.7/dist-packages/xpra/dbus/common.py", line 22, in init_session_bus
    _session_bus = dbus.SessionBus(private=private)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:57:12,392 Error setting up client dbus instance:
2019-01-31 17:57:12,392   org.freedesktop.DBus.Error.Spawn.ExecFailed
2019-01-31 17:57:12,392   /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:57:12,392  automatic picture encoding enabled, also available:
2019-01-31 17:57:12,392   h264, vp9, vp8, png, png/P, png/L, webp, rgb24, rgb32, jpeg, h265, mpeg1, mpeg2
2019-01-31 17:57:12,393 Warning: the python netifaces package is missing
2019-01-31 17:57:12,394 Python/Gtk2 Microsoft Windows 10 aero client version 2.4.3-r21365 64-bit
2019-01-31 17:57:12,394  connected from 'DESKTOP-E1ER43H' as 'root' - 'eine'
2019-01-31 17:57:12,468 setting key repeat rate from client: 500ms delay / 33ms interval
2019-01-31 17:57:12,469 setting keyboard layout to 'gb'
2019-01-31 17:57:12,492  client root window size is 3840x1080 with 1 display:
2019-01-31 17:57:12,492   Default (1016x285 mm - DPI: 96x96) workarea: 3840x1040
2019-01-31 17:57:12,492     DISPLAY1 1920x1080 (480x270 mm - DPI: 101x101) workarea: 1920x1040
2019-01-31 17:57:12,492     DISPLAY2 1920x1080 at 1920x0 (480x270 mm - DPI: 101x101) workarea: 1920x1040
2019-01-31 17:57:12,525 server virtual display now set to 3840x1080
2019-01-31 17:57:12,543 client @01.422 Xpra X11 server version 2.4.3-r21350 64-bit
2019-01-31 17:57:12,544 client @01.437  running on Linux debian buster/sid
2019-01-31 17:57:12,554 DPI set to 45 x 25 (wanted 96 x 96)
2019-01-31 17:57:12,554  you may experience scaling problems, such as huge or small fonts, etc
2019-01-31 17:57:12,555  to fix this issue, try the dpi switch, or use a patched Xorg dummy driver
2019-01-31 17:57:14,391 Warning: sanitizing invalid gtk selection
2019-01-31 17:57:14,391  format=-0x2d6a69e0, type=0x55e72be9e6a0, length=-0x1

Bugs/issues:

The server can be stopped with:

xpra stop :0

This will close the GUI app, xpra and the xorg server.

NOTE: Since no display number was specified, and because no other xorg server was running in the container, :0 was used automatically.

However, if the GUI app is closed graphically, both xpra and xorg will keep running.

Open questions:

How does this fit with x11docker? As explained in the context of #110, I do not have a clear understanding about how is xpra used. According to https://xpra.org/trac/wiki/Usage/Docker and after the test above, I assume that:

So:

If the assumptions above are correct, the following example is not valid for my use case: https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra. It is not valid because it is assumed that the host OS in the server is GNU/Linux. So, command x11docker --xvfb --display=30 --showenv x11docker/lxde pcmanfm will try to create a dummy X server with xvfb, and connect a container to it. Unfortunately, xvfb is not available on MSYS2.

I see two alternatives here:

- User command: x11docker --xvfb --display=30 --showenv x11docker/lxde pcmanfm
- If on windows:
  - read Xenv < <(x11docker -t -p <HOST_PORT>:<CONTAINER_PORT> x11docker/xvfb sh -c "x11docker --xvfb --display=30 --showenv <no_container>")
  - env $Xenv x11docker x11docker/lxde pcmanfm
- Show info for the user to connect with an xpra client: <user>@localhost:<HOST_PORT>

The second option is based on how x11docker-gui behaves when kaptain is not installed on the host. I find it to be a really neat solution.

EDIT

I think that the comments above also apply to example https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5#html5-with-xpra. I.e., xvfb is required on the host.

Furthermore, I think that these pages describe a similar procedure:

mviereck commented 5 years ago

Many issues are specific to xpra. man xpra is quite long, but helps in many cases.

cannot access python uinput module python netifaces package is missing

I am not sure yet.

html server unavailable, cannot find websockify module. This is surprising because I did install it explicitly. Does xpra user python2 instead of python3?

xpra uses python2. Rather install the debian package websockify with apt-get instead of using pip.

Multiple dbus related errors.

Use --dbus-proxy=no

Warning: webcam forwarding is disabled,

--webcam=no

failed to load the mdns publisher

--mdns=no

However, if the GUI app is closed graphically, both xpra and xorg will keep running.

Use --start-child gtkwave --exit-with-children. From man xpra:

       --start=CMD
              After starting the server, runs the command CMD using the default shell.  The command is run with its $DISPLAY set to point to the newly-started server.  This option  may  be  given  multiple
              times to start multiple commands.

       --start-child=CMD
              Identical to --start, except that the commands are taken into account by --exit-with-children.

       --start-after-connect=CMD
              Wait for the first client to connect before starting the command.

       --start-child-after-connect=CMD
              Wait for the first client to connect before starting the child command.  See start-child.

       --start-on-connect=CMD
              Execute this command every time a client connects.

       --start-child-on-connect=CMD
              Execute this child command every time a client connects.  See start-child.

       --start-on-last-client-exit=CMD
              Execute this command every time a client disconnects and there are no other clients left.

       --start-child-on-last-client-exit=CMD
              Execute this child command every time a client disconnects and there are no other clients left.  See start-child.

       --terminate-children=yes|no
              On  server  stop,  terminate  all  the child commands that have been started by the server. This does not affect server exit.  Most child commands are tied to the display so they are normally
              forced to shutdown anyway, but this gives them more time to cleanup properly and can be used to stop background commands that aren't tied to a display.

       --exit-with-children=yes|no
              This option may only be used if --start-child is also given.  If it is given, then the xpra server will monitor the status of the children started by  --start-child,  and  will  automatically
              terminate itself when the last of them has exited.

       --exit-with-client=yes|no
              The server will terminate when the last client disconnects.

How can the GUI app be started again and attached to the running server?

DISPLAY=:0 gtkwave

Is it possible to start multiple apps (windows) with a single xpra/xorg server without desktop mode?

Use --start-child multiple times.

Is it possible to optionally close xpra/xorg automatically if all the windows are closed?

--exit-with-children

How does this fit with x11docker?

x11docker does the following:

If the assumptions above are correct, the following example is not valid for my use case: https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra. It is not valid because it is assumed that the host OS in the server is GNU/Linux.

xpra server is not available on Windows. So this setup won't work. Same goes for HTML5. However, you can create a similar setup with xpra in container.

I can also image a setup with a dedicated xpra server container that serves as "display" for other containers. Basically you would need to share the same /tmp/.X11-unix with all containers and set DISPLAY for all clients. IIRC subuser does this on Linux. 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 sockets.

eine commented 5 years ago

Many issues are specific to xpra. man xpra is quite long, but helps in many cases.

I searched for some options there, but I didn't find the proper sections. Thanks a lot for pointing me to them. Start/exit options are specially useful.

cannot access python uinput module

I found that this is reported in lots of logs and no one worries about it, so it is probably not relevant.

python netifaces package is missing

I am not sure yet.

I just installed it for python2. It doesn't complain anymore.

xpra uses python2. Rather install the debian package websockify with apt-get instead of using pip.

I used pip instead of pip3 and it worked. I want to know which tools require python2 and which are ported to python3 already and this helps me.

I used the options you suggested plus --notifications=no:

xpra start --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no

This is the log now:

2019-01-31 22:34:20,667 cannot access python uinput module:
2019-01-31 22:34:20,667  No module named uinput

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
Current Operating System: Linux 64c1899ac7f6 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 25 October 2018  06:15:23PM
xorg-server 2:1.20.3-1 (https://www.debian.org/support)
Current version of pixman: 0.36.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.S2392.log", Time: Thu Jan 31 22:34:21 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-01-31 22:34:25,593 Warning: failed to create socket directory '/run/user/0/xpra'
2019-01-31 22:34:25,593  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-01-31 22:34:25,593 Warning: cannot create socket '/run/user/0/xpra/64c1899ac7f6-0':
2019-01-31 22:34:25,593  [Errno 2] No such file or directory
2019-01-31 22:34:25,593  /run/user does not exist
2019-01-31 22:34:25,594 created unix domain socket: /run/xpra/64c1899ac7f6-0
/bin/sh: 1: dbus-launch: not found
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is 127

2019-01-31 22:34:26,556 Warning: menu forwarding is disabled:
2019-01-31 22:34:26,556  cannot load dbus helper: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnorma
lly without any error message
2019-01-31 22:34:26,587 pointer device emulation using XTest
2019-01-31 22:34:27,143  OpenGL is supported on this display
WARNING: no 'numpy' module, HyBi protocol will be slower
2019-01-31 22:34:27,191 serving html content from: /usr/share/xpra/www
2019-01-31 22:34:27,203 dbus server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap
    v = fn()
  File "/usr/lib/python2.7/dist-packages/xpra/x11/server.py", line 1302, in make_dbus_server
    return X11_DBUS_Server(self, os.environ.get("DISPLAY", "").lstrip(":"))
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_server.py", line 38, in __init__
    bus = init_session_bus()
  File "/usr/lib/python2.7/dist-packages/xpra/dbus/common.py", line 22, in init_session_bus
    _session_bus = dbus.SessionBus(private=private)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 22:34:27,203 Error setting up server dbus instance:
2019-01-31 22:34:27,203   org.freedesktop.DBus.Error.Spawn.ExecFailed
2019-01-31 22:34:27,204   /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 22:34:27,300 xpra X11 version 2.4.3-r21350M 64-bit
2019-01-31 22:34:27,300  uid=0 (root), gid=0 (root)
2019-01-31 22:34:27,301  running with pid 2396 on Linux debian buster/sid
2019-01-31 22:34:27,301  connected to X11 display :0 with 24 bit colors
2019-01-31 22:34:27,418 xpra is ready.
2019-01-31 22:34:27,979 started command 'gtkwave' with pid 2440
2019-01-31 22:34:27,980 7.8GB of system memory

GTKWave Analyzer v3.3.99 (w)1999-2019 BSI

GTKWAVE | Use the -h, --help command line flags to display help.

Most of the erros are gone (I updated the first comment accordingly). However, some of the dbus errors remain, and this new one is shown now: WARNING: no 'numpy' module, HyBi protocol will be slower. Which is surprising, because numpy is installed.

Anyway, the system works great!

How can the GUI app be started again and attached to the running server?

DISPLAY=:0 gtkwave

This is great, and it helps me understand the scheme. I thought that all the applications would need to be started with xpra. It is cool to see how it can be transparent to the user if initialized properly.

Is it possible to start multiple apps (windows) with a single xpra/xorg server without desktop mode?

Use --start-child multiple times.

I believe that --start-child allows to start multiple apps at the same time. If so, I didn't make the question properly. What I meant was to open multiple apps sequentialy, when the user wants, and connect them to an existing server. The answer is easier then: export DISPLAY=:0; all the apps are now shown in the xpra client.

* Run Xvfb or Xdummy on host.

Since the host of Xvfb or Xdummy is now going to be a container, can I execute x11docker inside it (i.e. without docker client available)? Or do I need to do it manually?

* Run xpra server on host, connecting it to Xvfb with `--use-display`.

By looking at the description of this flag:

--use-display=yes|no Use an existing display rather than starting one with the xvfb command. Default: no

Does this mean that I should skip explicitly creating the X server in the previous step? Or is it still preferred to use x11docker to create it, instead of letting xpra do it?

Related to this, I don't see the difference between xpra start :0 --use-display --bind-tcp=0.0.0.0:10000 and xpra shadow :0 --bind-tcp=0.0.0.0:10000. Do you know if there is any?

* Run xpra client on host connected to xpra server.

It is not possible to connect an xpra client to an existing X server without an intermediate xpra server, is it?

* Run docker, providing X socket, `DISPLAY` and `XAUTHORITY`.

This is the step I am more unsure about. I used to provide the X socket and DISPLAY manually before using x11docker. But I have never used XAUTHORITY. Can I retrieve it from Xenv if I use x11docker to start xvfb?

I can also image a setup with a dedicated xpra server container that serves as "display" for other containers. Basically you would need to share the same /tmp/.X11-unix with all containers and set DISPLAY for all clients.

That's what I'm going to try.

IIRC subuser does this on Linux. 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 sockets.

Unless I misunderstood it, this should not be a problem because /tmp does not lie on Windows. It is inside the root virtual machine where all the containers are executed.

eine commented 5 years ago

Working proof of concept:

FROM debian:buster

RUN apt update -y \
 && apt install -y python-pip \
 && pip install websockify netifaces \
 && apt install -y xpra
docker build -t x11docker/xpra .
...
XPRA_DISPLAY=:0
XPRA_PORT=8080
XPRA_CONTAINER="$(docker run --rm -d -v //tmp/.X11-unix://tmp/.X11-unix -p "$XPRA_PORT:$XPRA_PORT" x11docker/xpra bash -c "\
  xpra start "$XPRA_DISPLAY" --bind-tcp=0.0.0.0:$XPRA_PORT --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no")"

# Open an xpra client on windows and connect to root@localhost:8080

# Now, any GUI app can be shown by providing the X socket and setting `DISPLAY`:

docker run --rm -v //tmp/.X11-unix://tmp/.X11-unix -- ghdl/ext:gtk-ide bash -c "\
  export DISPLAY="$XPRA_DISPLAY" && gtkwave"

# It can be closed (the container will be removed), but the xpra server will keep running. Also, many apps can be opened at the same time, either in the same or in different container.

# In order to kill the container with the xpra server (note that all the apps will be closed):
docker rm -f "$XPRA_CONTAINER"

Now I need to make it more secure by integrating it with x11docker, because ATM any process with access to //tmp/.X11-unix can connect to the display server.

mviereck commented 5 years ago

some of the dbus errors remain,

Install dbus-x11. It contains dbus-launch and depends on dbus. Maybe it helps.

Since the host of Xvfb or Xdummy is now going to be a container, can I execute x11docker inside it (i.e. without docker client available)? Or do I need to do it manually?

x11docker won't help you much in container. Though, it can set up an X server for you, but to reduce complexitiy, I recommend to do it yourself. Xpra wiki provides examples for --xvfb=.... You can also run x11docker with --debug --xvfb and compare the created X command.

Related to this, I don't see the difference between xpra start :0 --use-display --bind-tcp=0.0.0.0:10000 and xpra shadow :0 --bind-tcp=0.0.0.0:10000. Do you know if there is any?

Look at man xpra for xpra shadow. It works like VNC. xpra start works like a window manager and takes more control over the X server and uses this power for better performance.

It is not possible to connect an xpra client to an existing X server without an intermediate xpra server, is it?

It is not possible.

But I have never used XAUTHORITY.

x11docker creates a cookie provided in XAUTHORITY that is provided to X clients. This way only authenticated clients can access X. You can also run X without cookie authentication.

&& tail -f /dev/null

Use --daemon=no instead.

eine commented 5 years ago

x11docker won't help you much in container. Though, it can set up an X server for you, but to reduce complexitiy, I recommend to do it yourself.

I am concerned about security. x11docker sets the user, limits some capabilities, it generates XAUTHORITY, etc. I would like to benefit from all those features. For example, x11docker can automatically set XPRA_DISPLAY to an unused number, in case some other server is already running.

Look at man xpra for xpra shadow. It works like VNC.

Found it:

Note that this mode of operation uses screenscraping which is far less efficient. Using a video encoder (h264 or vp8) is highly recommended for this mode of operation.

Thanks!

This way only authenticated clients can access X. You can also run X without cookie authentication.

Is the cookie just a file that must be shared/copied?

Use --daemon=no instead.

Thanks again!

mviereck commented 5 years ago

I am concerned about security. x11docker sets the user, limits some capabilities, it generates XAUTHORITY, etc. I would like to benefit from all those features. For example, x11docker can automatically set XPRA_DISPLAY to an unused number, in case some other server is already running.

I thought you want to run x11docker inside the container. There it only can set up Xvfb, but nothing more. You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

Is the cookie just a file that must be shared/copied?

Yes.

Now I need to make it more secure by integrating it with x11docker, because ATM any process with access to //tmp/.X11-unix can connect to the display server.

Assess yourself if that is an issue, i.e. whether the X server and its clients need protection. Cookies are created with xauth. You can run x11docker with --verbose or have a look at the cache while it is running. The cookie is created in xinitrc.

Cygwin provides Xvfb: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fxorg-server-extra%2Fxorg-server-extra-1.18.4-1&grep=xvfb

eine commented 5 years ago

I thought you want to run x11docker inside the container. There it only can set up Xvfb, but nothing more.

I thought that I did need to run x11docker where the X server is created, which is inside the container. But, if I can use x11docker to run the container without needing to execute it inside, that's even better.

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

But that will start a instance of vcxsrv, which is what I want to avoid in this use case. I want to have three options:

So, I'd like to rewrite the example above to:

# Set user
# Check if some X server is already running. Otherwise, check is vcxsrv/xwin are installed (suggest it). Otherwise, select a display number.
# Share X socket with container.
# Run the container in the background, so that the shell can be used
# Collect in Xenv the parameters needed to start sibling containers: DISPLAY and XAUTHORY
# Print parameters required to connect from a client: user and port
read Xenv < <(x11docker -t --daemon [--port 127.0.0.1:8080] x11docker/xpra) &

# Allow to start containers which use the xpra server
# Share X socket, DISPLAY, XAUTHORITY...
env $Xenv x11docker ghdl/ext:gtk-ide bash -c "gtkwave"

Does it make sense to you?

Assess yourself if that is an issue, i.e. whether the X server and its clients need protection.

If the TCP port of the xpra server is open, they don't. But they should otherwise, isn't it?

Cookies are created with xauth. You can run x11docker with --verbose or have a look at the cache while it is running. The cookie is created in xinitrc.

Thanks.

eine commented 5 years ago

I tried with alpine as the base image:

FROM python:2-alpine

RUN apk update \
 && apk add dbus-x11 lz4-dev lzo-dev pulseaudio-utils gcc musl-dev linux-headers \
 && pip install lz4 python-lzo websockify netifaces \
 && apk add xpra

# https://bugs.alpinelinux.org/issues/8741
RUN sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf \
  && rm /etc/xpra/conf.d/55_server_x11.conf.bak

It is half the size of the one based on buster (460MB vs 1GB). The xpra server works, and applications started in the same container can be used with a client on the host. However, other containers cannot use the X server. I think this is because some default settings (see xorg.conf and 55_server_x11.conf above) might be different from those on Debian. Alpine is security-oriented, indeed.

EDIT

I added -ac to the last line in 55_server_x11.conf, and it now works. So, it seems that the default on Debian might include -ac. But it must be somewhere else, because the commands in this file are almost the same:

# Debian
xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf
# Alpine
xvfb = xpra_Xdummy -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -ac -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf

Note that -ac was added by me in the second one.

EDIT

A better workaround is to use xhost:

DISPLAY=:0 xhost +local:
totaam commented 5 years ago

/bin/sh: 1: dbus-launch: not found

If you don't want to have a dbus server, try: --dbus-launch=no (I've added this to the FAQ)

cannot access python uinput module

Harmless, only used for virtualizing specialized input devices: See https://xpra.org/trac/wiki/FAQ

xvfb is not available on MSYS2

Since you are using MSYS2, you may be interested in installing xpra as an MSYS2 package rather than an EXE installer, this should be available upstream soon - download the PKGBUILD for now: https://xpra.org/trac/ticket/1883 (and be aware of the caveats in this ticket: some of the MSYS2 packages need fixing)

If --xvfb is used on windows, create the dummy X server in a sibling container. This would not require an X server on the host, since an xpra client would suffice (see xpra shadow at https://xpra.org/trac/wiki/Usage).

Related to this, I don't see the difference between xpra start :0 --use-display --bind-tcp=0.0.0.0:10000 and xpra shadow :0 --bind-tcp=0.0.0.0:10000. Do you know if there is any?

The difference is huge. xpra start will give you seamless mode and it is efficient. xpra shadow will export one window for each monitor, and it is not efficient.

If you have an X11 server available, use xpra start --use-display, not shadow.

WARNING: no 'numpy' module, HyBi protocol will be slower.

Also in FAQ. In the next release (2.5), we're completely getting rid of websockify: https://xpra.org/trac/ticket/2121 So things will work better / faster, and without warnings.

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

DISPLAY=:0 gtkwave

Always try to avoid doing things this way. The environment will not include the various things xpra sets up when starting applications. Either use xpra start --start=gtkwave, or after the xpra server is started ask it to start new commands with: xpra control :0 start gtkwave (you can also do the same thing via the server's dbus control channel) Note: you may need to configure your xpra server to allow new commands to be started with --start-new-commands=yes, this option was added later so it defaults to false.

eine commented 5 years ago

@totaam, first off, thanks and congratulations. I had not realized that you are a maintainer/developer of xpra. That's such a great tool.

If you don't want to have a dbus server, try: --dbus-launch=no (I've added this to the FAQ)

Frankly, I don't really know if I want it or not. I'd rather support it, in case it makes sense. I see that it can be useful for multiple applications running in the same container. But the use case here is xpra in a container and multiple applications in one or many different containers. Therefore, dbus might only make sense if I can actually share it. Hope @mviereck can provide some thoughts.

Anyway, on the alpine based image, where I added dbus-x11, no error is shown because of dbus-launch. This error is shown instead:

cannot load dbus helper: No module named dbus
...
Error setting up server dbus instance:
  No module named dbus

I tried --dbus-launch=no but it makes no difference. I'll need to have a better look at it.

Since you are using MSYS2, you may be interested in installing xpra as an MSYS2 package rather than an EXE installer, this should be available upstream soon - download the PKGBUILD for now: xpra.org/trac/ticket/1883 (and be aware of the caveats in this ticket: some of the MSYS2 packages need fixing)

I'm not sure about it being the best alternative for my use case. I want to avoid installing dependencies on the host (besides docker and a shell). Hence, the portable client provided (which is 200MB) is a quite good solution. It is twice the size of vcxsrv, but it is ok, considering xpra does encoding/decoding.

I had a look at the MSYS2 package and it relies on gtk3, which requires 355MB to be installed. The python2 variant requires python2-pygtk (400MB). I don't want to install those on the host. I use docker containers for that. Indeed, the alpine container with xpra is 466MB.

However, I see that it might be useful in different contexts to have xpra available through MSYS2. E.g., to launch an xpra server on the windows host (without docker). So, if you want the package to be tested, I can give it a try.

The difference is huge. xpra start will give you seamless mode and it is efficient. xpra shadow will export one window for each monitor, and it is not efficient.

If you have an X11 server available, use xpra start --use-display, not shadow.

I thought that shadow might be an alias for start --use-display. But after your comment and (@mviereck's), I am using xpra start. Certainly, I am not using --use-display for now, until I guess how to integrate the PoC with x11docker.

In the next release (2.5), we're completely getting rid of websockify: xpra.org/trac/ticket/2121 So things will work better / faster, and without warnings.

That's good news. On alpine, the error about HyBi is not shown, but the module is not found:

html server unavailable, cannot find websockify module

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

I'll give it a try.

Always try to avoid doing things this way. The environment will not include the various things xpra sets up when starting applications. Either use xpra start --start=gtkwave, or after the xpra server is started ask it to start new commands with: xpra control :0 start gtkwave

That was just an example, but I do need to start the applications without xpra. That's because xpra is not available in the containers where the apps are executed. This is a strong requirements in order to support any image which can be used with vcxsrv (without additional dependenies). The scheme is the following:

                                              (xvfb/xorg server)
                                                (xpra server)               (portable win)
docker-for-win    <-> /tmp/.X11-unix <-> :0 <-> x11docker/xpra  <-> 8080 <-> xpra client                                    |
(alpine vm on hv)                         |
                                          |<-> app/container_1
                                          |<-> app/container_2
                                          |<-> app/container_3

Only x11docker/xpra contains xpra. Neither the host nor any of the other containers have xpra installed. The client can be used on the host, or on any other machine with access to it. So, there is a single connection between xpra and the apps: the X socket.

Is it possible to print those parameters that xpra sets, so that the environment in the app containers can be generated properly and it behaves as close to what xpra expects as possible?

eine commented 5 years ago

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

It seems that xpra accepts :DISPLAY and ssh:HOST:DISPLAY as valid formats. But not HOST:DISPLAY, which is the one set by x11docker.

# ./x11docker -i --user=root -- -p "8080:8080" -- x11docker/xpra sh
x11docker note: Failed to check for sshd. ps -p not supported.

x11docker note: Using X server option --vcxsrv

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 note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

x11docker WARNING: Found custom DOCKER_RUN_OPTIONS.
  x11docker will add them to 'docker run' command
  without a check for validity or security. Found options:
   '-p' '8080:8080'

x11docker WARNING: Option --user=root: Adding some capabilities to allow
  some root privileges in container that x11docker would drop otherwise.

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/

~ # echo $DISPLAY
10.0.75.1:100
~ # ls -la /tmp/.X11-unix/
total 8
drwxrwxrwt    2 root     0             4096 Feb  1 07:31 .
drwxrwxrwt    1 root     0             4096 Feb  1 07:31 ..
lrwxrwxrwx    1 root     0                5 Feb  1 07:31 X100 -> /X100
~ # xpra start $DISPLAY --use-display --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no

Warning: running as root
error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory

** (process:83): WARNING **: 07:33:19.917: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:83): WARNING **: 07:33:19.917: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:83): WARNING **: 07:33:19.918: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 07:33:19,978 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 07:33:19,978  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 07:33:19,978 Warning: cannot create socket '/run/user/0/xpra/50daeaa16548-10.0.75.1:100':
2019-02-01 07:33:19,978  [Errno 2] No such file or directory
2019-02-01 07:33:19,978  /run/user does not exist
2019-02-01 07:33:19,979 created unix domain socket: /root/.xpra/50daeaa16548-10.0.75.1:100
2019-02-01 07:33:19,979 created unix domain socket: /run/xpra/50daeaa16548-10.0.75.1:100
2019-02-01 07:33:19,986 X11 extension Composite not available
2019-02-01 07:33:19,986 Xpra 'start' subcommand runs as a compositing manager
2019-02-01 07:33:19,986  it cannot use a display which lacks the XComposite extension!
2019-02-01 07:33:19,987 closing tcp socket 0.0.0.0:8080
2019-02-01 07:33:19,987 removing socket /root/.xpra/50daeaa16548-10.0.75.1:100
2019-02-01 07:33:19,987 removing socket /run/xpra/50daeaa16548-10.0.75.1:100
totaam commented 5 years ago

I see that it can be useful for multiple applications running in the same container.

Nowadays, many desktop applications expect a dbus server to be available. They may or may not always handle the missing dbus server well..

cannot load dbus helper: No module named dbus

For this one, you need python-dbus since xpra is written in python.

Hence, the portable client provided (which is 200MB) is a quite good solution. It is twice the size of vcxsrv, but it is ok, considering xpra does encoding/decoding

For the record, you can probably trim it down to less than 100MB by removing features you may not need: printing, audio, nvenc + numpy, opengl, etc

I had a look at the MSYS2 package and it relies on gtk3, which requires 355MB to be installed. The python2 variant requires python2-pygtk (400MB). I don't want to install those on the host. I use docker containers for that. Indeed, the alpine container with xpra is 466MB.

FYI: the mswindows EXE you downloaded is made using those same MSYS2 packages, we just trim it down and remove all the bits we don't actually need.

html server unavailable, cannot find websockify module

For more debug logging, try: -d websocket,http. It's likely that python-websockify is not installed, or not correctly installed, or is the wrong version (too old, or unreleased).

This is a strong requirements in order to support any image which can be used with vcxsrv (without additional dependenies)

Gotcha.

Is it possible to print those parameters that xpra sets, so that the environment in the app containers can be generated properly and it behaves as close to what xpra expects as possible?

You can execute env from an xterm running within xpra. Most, but not all, settings can be found in /etc/xpra/conf.d/60_server.conf. (ie: some input method stuff is configured at runtime)

eine commented 5 years ago

Nowadays, many desktop applications expect a dbus server to be available. They may or may not always handle the missing dbus server well..

Will look further into it, then.

For this one, you need python-dbus since xpra is written in python.

Indeed. The package is named py-dbus on alpine. However, if installed, a different error is shown. I need to execute dbus-uuidgen. See logs below.

For the record, you can probably trim it down to less than 100MB by removing features you may not need: printing, audio, nvenc + numpy, opengl, etc

Do you mean by building the binaries myself or by removing dlls and executables from the portable tarball?

FYI: the mswindows EXE you downloaded is made using those same MSYS2 packages, we just trim it down and remove all the bits we don't actually need.

Is there any reference about how do you trim it down? It would be very interesting to have a 100MB client package which does not need all those deps. It is ok if those are just build dependencies, tho.

You can execute env from an xterm running within xpra. Most, but not all, settings can be found in /etc/xpra/conf.d/60_server.conf. (ie: some input method stuff is configured at runtime)

Thanks.

html server unavailable, cannot find websockify module

For more debug logging, try: -d websocket,http. It's likely that python-websockify is not installed, or not correctly installed, or is the wrong version (too old, or unreleased).

xpra start :0 --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no -d websocket,http produces the same output as without -d websocket,http. See log below:

NOTE: Docker image python:2-alpine

~ # apk update && apk add xpra musl-dev gcc dbus-x11 py2-netifaces && pip install websockify
...
~ # sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf && rm /etc/xpra/conf.d/55_server_x11.conf.bak
~ # xpra start :0 --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no
Warning: running as root
WARNING: low display number: 0
 You are attempting to run the xpra server against a low X11 display number: ':0'.
 This is generally not what you want.
 You should probably use a higher display number just to avoid any confusion (and also this warning message).
2019-02-01 08:39:03,625 cannot access python uinput module:
2019-02-01 08:39:03,625  No module named uinput

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux ab7891869bd7 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 29 October 2018  06:33:45PM

Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.:0.log", Time: Fri Feb  1 08:39:03 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 08:39:06,452 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 08:39:06,453  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 08:39:06,453 Warning: cannot create socket '/run/user/0/xpra/ab7891869bd7-0':
2019-02-01 08:39:06,453  [Errno 2] No such file or directory
2019-02-01 08:39:06,454  /run/user does not exist
2019-02-01 08:39:06,454 created unix domain socket: /root/.xpra/ab7891869bd7-0
2019-02-01 08:39:06,455 created unix domain socket: /run/xpra/ab7891869bd7-0
process 115: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is -6

2019-02-01 08:39:08,231 Warning: menu forwarding is disabled:
2019-02-01 08:39:08,231  cannot load dbus helper: No module named dbus
2019-02-01 08:39:08,245 Warning: zlib is the only compressor enabled
2019-02-01 08:39:08,245  install and enable lzo or lz4 support for better performance
2019-02-01 08:39:08,367 pointer device emulation using XTest
2019-02-01 08:39:08,746 html server unavailable, cannot find websockify module
2019-02-01 08:39:08,747 Error setting up server dbus instance:
2019-02-01 08:39:08,747  No module named dbus
2019-02-01 08:39:08,751 pulseaudio not started: 'pulseaudio' command not found

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-01 08:39:09,050 Error: failed to query sound subsystem:
2019-02-01 08:39:09,051  query did not return any data
2019-02-01 08:39:09,055 xpra X11 version 2.2.6-r18970 64-bit
2019-02-01 08:39:09,056  uid=0, gid=0
2019-02-01 08:39:09,056  running with pid 104 on Linux
2019-02-01 08:39:09,056  connected to X11 display :0 with 24 bit colors
2019-02-01 08:39:09,168 xpra is ready.
2019-02-01 08:39:09,169 7.8GB of system memory
~ # apk add py-dbus
(1/2) Installing dbus-glib (0.108-r1)
(2/2) Installing py-dbus (1.2.0-r2)
~ # xpra start :0 --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no
Warning: running as root
WARNING: low display number: 0
 You are attempting to run the xpra server against a low X11 display number: ':0'.
 This is generally not what you want.
 You should probably use a higher display number just to avoid any confusion (and also this warning message).
2019-02-01 08:42:21,049 cannot access python uinput module:
2019-02-01 08:42:21,049  No module named uinput

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux ab7891869bd7 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 29 October 2018  06:33:45PM

Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.:0.log", Time: Fri Feb  1 08:42:21 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 08:42:23,832 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 08:42:23,832  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 08:42:23,833 Warning: cannot create socket '/run/user/0/xpra/ab7891869bd7-0':
2019-02-01 08:42:23,833  [Errno 2] No such file or directory
2019-02-01 08:42:23,833  /run/user does not exist
2019-02-01 08:42:23,835 created unix domain socket: /root/.xpra/ab7891869bd7-0
2019-02-01 08:42:23,835 created unix domain socket: /run/xpra/ab7891869bd7-0
process 149: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is -6

process 138: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted
~ # dbus-uuidgen > /var/lib/dbus/machine-id
~ # xpra start :0 --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no

Warning: running as root
WARNING: low display number: 0
 You are attempting to run the xpra server against a low X11 display number: ':0'.
 This is generally not what you want.
 You should probably use a higher display number just to avoid any confusion (and also this warning message).
2019-02-01 09:05:21,279 cannot access python uinput module:
2019-02-01 09:05:21,280  No module named uinput

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux 41e532dba25d 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 29 October 2018  06:33:45PM

Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.:0.log", Time: Fri Feb  1 09:05:21 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

** (process:1028): WARNING **: 09:05:23.830: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:1028): WARNING **: 09:05:23.830: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:1028): WARNING **: 09:05:23.831: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 09:05:23,870 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 09:05:23,870  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 09:05:23,872 Warning: cannot create socket '/run/user/0/xpra/41e532dba25d-0':
2019-02-01 09:05:23,872  [Errno 2] No such file or directory
2019-02-01 09:05:23,873  /run/user does not exist
2019-02-01 09:05:23,875 created unix domain socket: /root/.xpra/41e532dba25d-0
2019-02-01 09:05:23,875 created unix domain socket: /run/xpra/41e532dba25d-0
2019-02-01 09:05:25,688 Warning: zlib is the only compressor enabled
2019-02-01 09:05:25,688  install and enable lzo or lz4 support for better performance
2019-02-01 09:05:25,797 pointer device emulation using XTest
2019-02-01 09:05:26,178 html server unavailable, cannot find websockify module
2019-02-01 09:05:26,182 pulseaudio not started: 'pulseaudio' command not found

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-01 09:05:26,483 Error: failed to query sound subsystem:
2019-02-01 09:05:26,483  query did not return any data
2019-02-01 09:05:26,487 xpra X11 version 2.2.6-r18970 64-bit
2019-02-01 09:05:26,487  uid=0, gid=0
2019-02-01 09:05:26,487  running with pid 1028 on Linux
2019-02-01 09:05:26,487  connected to X11 display :0 with 24 bit colors
2019-02-01 09:05:26,604 7.8GB of system memory
2019-02-01 09:05:26,605 xpra is ready.
totaam commented 5 years ago

Do you mean by building the binaries myself or by removing dlls and executables from the portable tarball?

Either would work. Building yourself might be easier. Note: the windows installer is not a tarball, so you would have to re-pack the installer afterwards.

Is there any reference about how do you trim it down?

There is a bit of information scattered in various tickets. The key thing is to turn things off during the build: ./setup.py --without-webcam --without-printing --without-nvenc etc.. Then some further trimming may be needed.

I need to execute dbus-uuidgen

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue. IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Warning: zlib is the only compressor enabled install and enable lzo or lz4 support for better performance

Performance will be absolutely dreadful unless you also use --compress=0.

produces the same output as without -d websocket,http

That's odd, but:

xpra X11 version 2.2.6-r18970 64-bit

Since you're running an outdated / unsupported version, that's possible.

eine commented 5 years ago

Note: the windows installer is not a tarball, so you would have to re-pack the installer afterwards.

Sorry, I did mean the zipfile, not tarball. I have not used the installer.

The key thing is to turn things off during the build: ./setup.py --without-webcam --without-printing --without-nvenc etc..

Thanks.

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue. IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Well, since alpine is not really designed for desktop apps, dbus might not be the most loved package...

Performance will be absolutely dreadful unless you also use --compress=0.

It happens the same as with websockify. The packages are installed. You can see in https://github.com/alpinelinux/aports/blob/master/community/xpra/APKBUILD#L12 that both py2-lz4 and py2-numpy are installed with xpra. However, numpy is compiled again when pip install websockify is executed, and lz4 is ignored (not found).

Since you're running an outdated / unsupported version, that's possible.

That's because the base image is still based on alpine3.8. They might update soon: https://github.com/docker-library/python/pull/375

Meanwhile, I'll update the package.

totaam commented 5 years ago

It happens the same as with websockify. The packages are installed.

They might just be too old:

eine commented 5 years ago

@totaam, I think you might have skipped this comment: https://github.com/mviereck/x11docker/issues/117#issuecomment-459622186

They might just be too old:

With this dockerfile:

FROM python:2-alpine

# Use alpine version 3.9 instead of 3.8
RUN sed -i.bak 's#3\.8#3\.9#g' /etc/apk/repositories \
 && rm /etc/apk/repositories.bak

RUN apk update \
 && apk add xpra musl-dev py-dbus gcc dbus-x11 py2-netifaces pulseaudio pulseaudio-utils \
 && pip install websockify \
 && dbus-uuidgen --ensure

# https://bugs.alpinelinux.org/issues/8741
RUN sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf \
 && rm /etc/xpra/conf.d/55_server_x11.conf.bak

these are the versions:

and this is the output:

~ # xpra start :0 --bind-tcp=0.0.0.0:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no
...
2019-02-01 12:28:48,555 Error: cannot enable SSH socket upgrades:
2019-02-01 12:28:48,555  No module named paramiko
2019-02-01 12:28:48,556 cannot access python uinput module:
2019-02-01 12:28:48,556  No module named uinput
...
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-02-01 12:28:51,528 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 12:28:51,528  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 12:28:51,529 Warning: cannot create socket '/run/user/0/xpra/b510efa3b625-0':
2019-02-01 12:28:51,529  [Errno 2] No such file or directory
2019-02-01 12:28:51,529  /run/user does not exist
2019-02-01 12:28:51,530 created unix domain socket: /run/xpra/b510efa3b625-0
2019-02-01 12:28:53,463 pointer device emulation using XTest
2019-02-01 12:28:53,807 Warning: OpenGL support check failed:
2019-02-01 12:28:53,807  OpenGL is not supported
2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module
2019-02-01 12:28:54,119 pulseaudio server started with pid 105
2019-02-01 12:28:54,119  private server socket path:
2019-02-01 12:28:54,119  '/tmp/XDG_RUNTIME_DIR/xpra/pulse-0/pulse/native'
W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/root/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/root/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/root/.pulse-cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/root/.pulse-cookie': No such file or directory
E: [pulseaudio] ltdl-bind-now.c: Failed to open module module-x11-publish.so: Error loading shared library module-x11-publish.so: No s
uch file or directory
E: [pulseaudio] module.c: Failed to open module "module-x11-publish".

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-01 12:28:54,450 Error: failed to query sound subsystem:
2019-02-01 12:28:54,450  query did not return any data
2019-02-01 12:28:54,546 xpra X11 version 2.4.2-r21077 64-bit
2019-02-01 12:28:54,546  uid=0, gid=0
2019-02-01 12:28:54,546  running with pid 85 on Linux
2019-02-01 12:28:54,546  connected to X11 display :0 with 24 bit colors
2019-02-01 12:28:54,666 7.8GB of system memory
2019-02-01 12:28:54,667 xpra is ready.

So, the problem with lz4 is gone. However, it still cannot find websockify. Also, now it complains about OpeGL, which it did not before.

The errors about pulseaudio were not shown earlier because it was not installed. Anyway, those are not relevant ATM.

If I run xpra start -d websocket,http now, I get some debug output:

2019-02-01 12:44:14,053 init_html_proxy(..) options: tcp_proxy=, html='auto'
2019-02-01 12:44:14,053 init_html_proxy(..) html=None
2019-02-01 12:44:14,057 WEBSOCKIFY_NUMPY=False
2019-02-01 12:44:14,058 importing WebSocketConnection
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/server/server_core.py", line 450, in init_html_proxy
    from xpra.server.websocket import WebSocketConnection
  File "/usr/lib/python2.7/site-packages/xpra/server/websocket.py", line 28, in <module>
    from websockify.websocket import WebSocketRequestHandler    #@Reimport
ImportError: No module named websockify.websocket
2019-02-01 12:44:14,063 html server unavailable, cannot find websockify module
2019-02-01 12:44:14,063 found html5 client in '/usr/share/xpra/www'

About the fix after installing dbus. It should not be required, because it is done twice:

However, for some reason post-install and pre-install script fail. So, dbus is installed, but not properly configured. Furthermore, dbus.initd is copied to /etc/init.d/dbus (https://github.com/alpinelinux/aports/blob/master/main/dbus/APKBUILD#L55), but it seems not to be executed. Interesting...

mviereck commented 5 years ago

@totaam Thank you for looking at this!

Re: DBus: x11docker supports dbus in container with some additional setup. However, unless it is a must-have, I would not use it. For the record:

The errors about pulseaudio were not shown earlier because it was not installed.

You can add --pulseaudio=no.

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

It seems that xpra accepts :DISPLAY and ssh:HOST:DISPLAY as valid formats. But not HOST:DISPLAY, which is the one set by x11docker.

VcXsrv is accessable only over IP but not with a unix socket. So DISPLAY has the format IP:DISPLAYNUMBER. It seems xpra server does not support X over IP yet. Regular X setups on Linux always provide a unix socket. Maybe xpra server could handle this special case if it regards this unusual way to access X.

Edit: Re: X server setup, finding free display number and creating a cookie: Have a look at wiki: Extended Xephyr script. It covers all this topics in a small script.

totaam commented 5 years ago

2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module websockify: 0.8.0

That should have worked:

$ rpm -q python2-websockify
python2-websockify-0.8.0-10.fc29.noarch
$ python -c "from websockify.websocket import \
WebSocketRequestHandler;print(WebSocketRequestHandler)"
websockify.websocket.WebSocketRequestHandler

Also, now it complains about OpenGL, which it did not before.

That's because it probably didn't check before and now it does. You can ignore that if your X11 applications don't need OpenGL.

So DISPLAY has the format IP:DISPLAYNUMBER. It seems xpra server does not support X over IP yet. Regular X setups on Linux always provide a unix socket. Maybe xpra server could handle this special case if it regards this unusual way to access X.

This is unusual, but it should work. In fact, I'm pretty sure that it used to work. Let me fix that.

mviereck commented 5 years ago

Re: xpra using VcXsrv

Maybe the format IP:DISPLAY is not the issue. Looking closer at the log in https://github.com/mviereck/x11docker/issues/117#issuecomment-459622186 I see two errors:

error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such file or directory

This xprop error might or might not be important.

2019-02-01 07:33:19,986 X11 extension Composite not available
2019-02-01 07:33:19,986 Xpra 'start' subcommand runs as a compositing manager
2019-02-01 07:33:19,986  it cannot use a display which lacks the XComposite extension!

The missing (or not recognized?) Composite extension is probably the reason why xpra fails. @1138-4EB Please try the following: Run x11docker with --vcxsrv --gpu. That adds VcXsrv options -wgl +iglx.

-[no]wgl    Enable the GLX extension to use the native Windows WGL interface for hardware-accelerated OpenGL
+iglx           Allow creating indirect GLX contexts (default)

With --gpu x11docker sets LIBGL_ALWAYS_INDIRECT=1. That might or might not be important for xpra. VcXsrv also has an option for Composite extension. It should be enabled per default:

-[no]compositewm
    Enable [Disable] Composite extension. Default is enabled.
    Used in -multiwindow mode.
    Use Composite extension redirection to maintain a bitmap
    image of each top-level X window, so window contents which
    are occluded show correctly in Taskbar and Task Switcher
    previews.

x11docker could also add +extension Composite. I am not sure if VcXsrv handles that well.

For the record: All VcXsrv options

eine commented 5 years ago

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue. IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Well, since alpine is not really designed for desktop apps, dbus might not be the most loved package...

However, for some reason post-install and pre-install script fail. So, dbus is installed, but not properly configured. Furthermore, dbus.initd is copied to /etc/init.d/dbus (alpinelinux/aports:main/dbus/APKBUILD@master#L55), but it seems not to be executed. Interesting...

Some of the issues were actually my fault. I did not docker build all the tests. Sometimes I executed x11docker -i --user=root -- -p "$XPRA_PORT:$XPRA_PORT" -- python:2-alpine sh and then installed and executed commands interactively. The problem is that I was not using --cap-default, and that's why some pre-install and post-install scripts failed. So @totaam, there is nothing wrong with the dbus package on alpine.

I now installed everything with docker build. If I start x11docker -it --user=root -- -p 8080:8080 -- x11docker/xpra sh, /var/lib/dbus/machine-id exits, because it was created in the post-install script. But /etc/machine-id does not exist. This one should be set if /etc/init.d/dbus was executed. Since the shebang in the script is openrc-run I assume I need to install openrc.

I built the image again, including openrc. However, the script seems not to be started. I.e., nothing is triggering it. According to https://github.com/mviereck/x11docker/wiki/Init-systems-in-docker:-tini,-systemd,-SysVinit,-runit,-OpenRC-and-elogind#systemd-sysvinit-runit-openrc, I think that this is only useful if xpra is the first command executed in the container. E.g.:

x11docker -it \
  --user=root \
  --cap-default \
  --openrc \
  -- \
  -p 8080:8080 \
  -- \
  x11docker/xpra xpra \
    start \
    :0 \
    --bind-tcp=0.0.0.0:8080 \
    --webcam=no \
    --mdns=no \
    --notifications=no \
    --dbus-proxy=no \
    --dbus-launch=no \
    --pulseaudio=no \
    --daemon=no

x11docker supports dbus in container with some additional setup. However, unless it is a must-have, I would not use it.

I think I won't in the end, because in my use case apps will be executed in different containers. However, I think it can be useful in other contexts where applications are installed on top of x11docker/xpra.

DBus will run well if installing an init system in container like OpenRC or runit. x11docker supports them with --openrc and --runit

Even if dbus is not used in the end, does having the init system inside the container provide any benefit to x11docker?

Re: X server setup, finding free display number and creating a cookie: Have a look at wiki: Extended Xephyr script. It covers all this topics in a small script.

I will. Thanks.

@totaam wrote: That's because it probably didn't check before and now it does. You can ignore that if your X11 applications don't need OpenGL.

It did check it. However, I was using debian, not alpine: https://github.com/mviereck/x11docker/issues/117#issuecomment-459533597

I fixed it now by installing py-opengl and mesa-dri-swrast.

@totaam wrote:

2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module websockify: 0.8.0

That should have worked:

The test command does work, indeed. See below:

~ # xpra start :0 --bind-tcp=0.0.0.0:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=no --pulseaudio=no --daemon=no
...
2019-02-02 10:56:06,469 Error: cannot enable SSH socket upgrades:
2019-02-02 10:56:06,469  No module named paramiko
...
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-02-02 10:56:09,199 created unix domain socket: /run/xpra/0d41f56470c2-0
2019-02-02 10:56:09,255 pointer device emulation using XTest
2019-02-02 10:56:09,572   OpenGL is supported on this display
2019-02-02 10:56:09,621 html server unavailable, cannot find websockify module

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-02 10:56:09,931 Error: failed to query sound subsystem:
2019-02-02 10:56:09,931  query did not return any data
2019-02-02 10:56:10,020 xpra X11 version 2.4.2-r21077 64-bit
2019-02-02 10:56:10,021  uid=0, gid=0
2019-02-02 10:56:10,021  running with pid 80 on Linux
2019-02-02 10:56:10,021  connected to X11 display :0 with 24 bit colors
2019-02-02 10:56:10,132 xpra is ready.
...
~ # python -c "from websockify.websocket import \
> WebSocketRequestHandler;print(WebSocketRequestHandler)"
websockify.websocket.WebSocketRequestHandler

Nevertheless, I don't know if it is worth spending effort on this issue, since it is going to be dropped. You said it will be done in the next release (2.5). I see that last releases have been published every 4-5 months, so I expect that it won't be out until Q2. Is there any schedule? I see december in https://xpra.org/trac/roadmap, but I believe that it is wrong.

Moreover, websockify depends on numy. Although I install 1.15.4 through the package manager, pip insists in building it again (1.16.1). Building it requires gcc and musl-dev. Will xpra get rid of numpy too? Or will it still be required?

The missing (or not recognized?) Composite extension is probably the reason why xpra fails. @1138-4EB Please try the following: Run x11docker with --vcxsrv --gpu. That adds VcXsrv options -wgl +iglx.

I get the same result:

# ./x11docker -i --vcxsrv --gpu --user=root --cap-default -- -p "8080:8080" -- x11docker/xpra sh
...
# xpra start $DISPLAY --use-display --bind-tcp=0.0.0.0:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=no --pulseaudio=no --daemon=no
Warning: running as root
2019-02-02 12:22:16,014 Error: cannot enable SSH socket upgrades:
2019-02-02 12:22:16,014  No module named paramiko
error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
2019-02-02 12:22:16,107 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-02 12:22:16,107  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-02 12:22:16,108 Warning: cannot create socket '/run/user/0/xpra/1855ae177797-10.0.75.1:100':
2019-02-02 12:22:16,108  [Errno 2] No such file or directory
2019-02-02 12:22:16,108  /run/user does not exist
2019-02-02 12:22:16,109 created unix domain socket: /run/xpra/1855ae177797-10.0.75.1:100
2019-02-02 12:22:16,114 X11 extension Composite not available
2019-02-02 12:22:16,115 Xpra 'start' subcommand runs as a compositing manager
2019-02-02 12:22:16,115  it cannot use a display which lacks the XComposite extension!

I tried after unset LIBGL_ALWAYS_INDIRECT too. No difference.

x11docker could also add +extension Composite. I am not sure if VcXsrv handles that well.

I tried adding it to line x11docker#L2977: yes) Xcommand="$Xcommand -wgl +iglx +extension Composite". But it does not change.

Is it possible that xpra fails to detect the extension, but it could use it because VcXsrv does implement it? I.e., we can modify xpra to skip the check, as a test.

EDIT

I checked the log of the vcxsrv:

[mi] Extension "Composite" is not recognized
[mi] Only the following extensions can be run-time disabled:
[mi]    Generic Event Extension
[mi]    XTEST
[mi]    SECURITY
[mi]    XINERAMA
[mi]    XFIXES
[mi]    XFree86-Bigfont
[mi]    RENDER
[mi]    RANDR
[mi]    COMPOSITE
[mi]    DAMAGE
[mi]    MIT-SCREEN-SAVER
[mi]    DOUBLE-BUFFER
[mi]    RECORD
[mi]    DPMS
[mi]    X-Resource
[mi]    GLX

These were also shown:

[mi] Extension "XVideo" is not recognized
...
[mi] Extension "MIT-SHM" is not recognized
...

It seems that the problem with Composite might be a case-sensitiveness issue. After changing 2977 to: yes) Xcommand="$Xcommand -wgl +iglx +extension COMPOSITE", the output is different:

~ # xpra start $DISPLAY --use-display --bind-tcp=0.0.0.0:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=n
o --pulseaudio=no --daemon=no

Warning: running as root
2019-02-02 13:00:34,760 Error: cannot enable SSH socket upgrades:
2019-02-02 13:00:34,760  No module named paramiko
error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MA
GIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 k
eyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-
MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 key2019-02-02 13:00:37,827 Error: failed to connect to display 10.0.75.1:100
2019-02-02 13:00:37,827  could not connect to X server on display '10.0.75.1:100' after 3 seconds
Error in sys.exitfunc:

EDIT 2

I tried to run xterm, just to check if the X server is ok:

~ # xterm
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

So, I closed the container (x11docker closed the instance of vcxsrv), and I started it again:

# x11docker -i --vcxsrv --gpu --user=root --cap-default -- -p "8080:8080" -- x11docker/xpra sh
...
~ # xpra start $DISPLAY --use-display --bind-tcp=0.0.0.0:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=n
o --pulseaudio=no --daemon=no

Warning: running as root
2019-02-02 13:14:24,929 Error: cannot enable SSH socket upgrades:
2019-02-02 13:14:24,929  No module named paramiko
error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
2019-02-02 13:14:25,023 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-02 13:14:25,023  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-02 13:14:25,024 Warning: cannot create socket '/run/user/0/xpra/a29709bec3bc-10.0.75.1:100':
2019-02-02 13:14:25,024  [Errno 2] No such file or directory
2019-02-02 13:14:25,024  /run/user does not exist
2019-02-02 13:14:25,024 created unix domain socket: /run/xpra/a29709bec3bc-10.0.75.1:100
2019-02-02 13:14:25,033 Warning: no XShm support on display 10.0.75.1:100
2019-02-02 13:14:25,081 pointer device emulation using XTest
2019-02-02 13:14:25,082 Warning: XTest extension is missing
2019-02-02 13:14:25,082 Error: keyboard and mouse disabled
mviereck commented 5 years ago

Even if dbus is not used in the end, does having the init system inside the container provide any benefit to x11docker?

As being said in the wiki:

Init in container solves the zombie reaping issue.

Without zombie reaping the container can crash at some point, after hours or after month. As default x11docker uses tini / docker-init, but unfortunately it is not available everywhere. --openrc is a good alternative for alpine images. Let's discuss further upcoming init questions in a separate ticket as they are not related to xpra.

It seems that the problem with Composite might be a case-sensitiveness issue. After changing 2977 to: yes) Xcommand="$Xcommand -wgl +iglx +extension COMPOSITE", the output is different:

Yes, sorry, I should have said it. In recent X versions the name changed from Composite to COMPOSITE. As a workaround x11docker sets for other X options +extension Composite +extension COMPOSITE. One succeeds, one fails. It is ok for X to fail loading an extension, it is not fatal, so don't worry about failing MIT-SHM and XVideo.

Invalid MIT-MAGIC-COOKIE-1

That is odd because the cookie works otherwise. Try disabling cookie authentication with --no-auth.

eine commented 5 years ago

@mviereck, the problem with the cookie was exceptional I think. See second edit above. I think that I might be missing some packages, such as xf86-input-mouse.

Let's discuss further upcoming init questions in a separate ticket as they are not related to xpra.

Agree.

mviereck commented 5 years ago

It looks like xpra server succeeds now to take over VcXsrv. Could you try to run something and connect with xpra client? It might succeed with xpra client but could show damaged content in VcXsrv windows.

xpra can preserve the content in VcXsrv windows:


       --sync-xvfb=DELAY
              The  windows  are  normally only displayed on the client(s), they are not painted on the virtual display.  Some applications like screen recorders may want to capture the window contents, you
              can use this option to enable painting with a configurable delay (in milliseconds).  Warning: this extra painting is expensive and quite slow, which is why it is not enabled by default.
eine commented 5 years ago

It looks like xpra server succeeds now to take over VcXsrv.

No really sure about it. When xpra server starts xpra X11 version 2.4.2-r21077 64-bit and xpra is ready. are printed to the log. None of them is shown here.

Moreover, I can see that some processes are running in the background, but I cannot stop xpra:

~ # xpra stop $DISPLAY
xpra initialization error:
 unknown format for display name: 10.0.75.1:100
~ # xpra list
Found the following xpra sessions:
/run/xpra:
        UNKNOWN session at :10.0.75.1:100
Re-probing unknown sessions in: /run/xpra
        UNKNOWN session at :10.0.75.1:100 (cleaned up)
~ # xpra list
No xpra sessions found
~ # top
Mem: 5036060K used, 3109780K free, 1156K shrd, 134348K buff, 4025876K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.00 0.00 2/434 114
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   95    88 root     S    63064   1%   2   0% {xpra} /usr/bin/python2 /usr/bin/xpra opengl
   88     1 root     S    52632   1%   0   0% {xpra} /usr/bin/python2 /usr/bin/xpra start 10.0.75.1:100 --use-display --bind-tcp=0.0.0
   93     1 root     S     2632   0%   0   0% dbus-launch --autolaunch 4f1001ca5507811c0deb1fd85c556f5c --binary-syntax --close-stderr
    1     0 root     S     1592   0%   0   0% sh
  114     1 root     R     1524   0%   2   0% top
   94     1 root     S     1372   0%   2   0% /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

Could you try to run something and connect with xpra client? It might succeed with xpra client but could show damaged content in VcXsrv windows.

It does not work. Vcxsrv is taking 30% of the CPU. And the icon in the task bar does not respond to the right-click (which provides a contextual menu shown the number of clients, allowing to open the log, etc.).

When I exit, the container is properly closed (I can see it with docker ps -a from another terminal), but the X server needs some time to close.

I also tried to start the container, start xterm to check that vcxsrv is working as expected, and run xpra start while xterm is open. As soon as xpra starts, xterm freezes: (Not Responding). At some point xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X server "10.0.75.1:100".

xpra can preserve the content in VcXsrv windows:

I restarted the container and tried xpra with --sync-xvfb=500. No difference.

mviereck commented 5 years ago

ok, at this point I have no idea. Maybe VcXsrv is just not compatible to xpra. Maybe it cannot handle +extension COMPOSITE well. @totaam might have an idea, though. As you can successfully use Xvfb/Xdummy in container, it might not be worth to debug this further. It could have been a possibility to add some GPU support, though.

totaam commented 5 years ago

Maybe VcXsrv is just not compatible to xpra.

All xpra needs is an X11 server with the composite and damage extensions. Try running xpra with -d x11 or even -d all.

eine commented 5 years ago

Try running xpra with -d x11 or even -d all.

~ # xpra start $DISPLAY --use-display --bind-tcp=0.0.0.0:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=n
o --pulseaudio=no -d all

Warning: running as root
2019-02-02 18:01:45,368 get_enabled_encoders(['rencode', 'bencode', 'yaml']) enabled=['rencode', 'bencode']
~ # Entering daemon mode; any further errors will be reported to:
  /tmp/XDG_RUNTIME_DIR/xpra/10.0.75.1:100.log
cat /tmp/XDG_RUNTIME_DIR/xpra/10.0.75.1:100.log
2019-02-02 18:01:45,373 import paramiko
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/scripts/server.py", line 467, in create_sockets
    import paramiko
ImportError: No module named paramiko
2019-02-02 18:01:45,375 Error: cannot enable SSH socket upgrades:
2019-02-02 18:01:45,375  No module named paramiko
2019-02-02 18:01:45,375 setting up SSL sockets:
2019-02-02 18:01:45,375 setting up SSH sockets:
2019-02-02 18:01:45,375 setting up https / wss (secure websockets):
2019-02-02 18:01:45,375 setting up TCP sockets: ('0.0.0.0', 8080)
2019-02-02 18:01:45,376 <socket._socketobject object at 0x7fa494650980>.bind(('0.0.0.0', 8080))
2019-02-02 18:01:45,376 tcp: 0.0.0.0:8080 : <module 'socket' from '/usr/lib/python2.7/socket.pyc'>
2019-02-02 18:01:45,376 setting up UDP sockets:
2019-02-02 18:01:45,376 setting up http / ws (websockets):
2019-02-02 18:01:45,376 setting up rfb sockets:
2019-02-02 18:01:45,376 setting up vsock sockets:
2019-02-02 18:01:45,376 env={'PYTHONIOENCODING': 'UTF-8', 'MWNO_RIT': 'true', 'XDG_CURRENT_DESKTOP': 'Xpra', 'XDG_SESSION_TYPE': 'x11'
, 'QT_IM_MODULE': 'xim', 'USER': 'root', 'HOME': '/root', 'LIBGL_ALWAYS_INDIRECT': '1', 'PATH': '/usr/local/bin:/usr/local/sbin:/usr/l
ocal/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'MWWM': 'allwm', 'DISPLAY': '10.0.75.1:100', 'LANG': 'C.UTF-8', 'TERM': 'xterm', 'SHELL': '/b
in/sh', 'container': 'docker', 'XAUTHORITY': '/x11docker/Xclientcookie', 'SHLVL': '2', 'PYTHON_PIP_VERSION': '19.0.1', 'XPRA_XSHM': '0
', 'MWNOCAPTURE': 'true', 'XMODIFIERS': '@im=none', 'XPRA_LOG_DIR': '/tmp/XDG_RUNTIME_DIR/xpra', 'IMSETTINGS_MODULE': 'none', 'GPG_KEY
': 'C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF', 'XDG_RUNTIME_DIR': '/tmp/XDG_RUNTIME_DIR', 'DISABLE_IMSETTINGS': '1', 'NO_AT_BRIDGE': '
1', 'QT_X11_NO_NATIVE_MENUBAR': '1', 'TZ': 'UTC-01', 'PYTHON_VERSION': '2.7.15', 'GTK_IM_MODULE': 'xim', 'UBUNTU_MENUPROXY': '', 'OLDP
WD': '/tmp', 'HOSTNAME': '50baea70a402', 'PWD': '/root', 'CKCON_X11_DISPLAY': '10.0.75.1:100'}
2019-02-02 18:01:45,378 looking for '_XPRA_UINPUT_ID' on display '10.0.75.1:100' with XAUTHORITY='/x11docker/Xclientcookie'
error running (['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
2019-02-02 18:01:45,380 Popen(['xprop', '-display', '10.0.75.1:100', '-root', '_XPRA_UINPUT_ID'])=(-1, '', '')
2019-02-02 18:01:45,467 setup_local_sockets: bind=['auto']
2019-02-02 18:01:45,467 sockpaths(10.0.75.1:100)=['/run/user/0/xpra/50baea70a402-10.0.75.1:100', '/run/xpra/50baea70a402-10.0.75.1:100
'] (uid=0, gid=0)
2019-02-02 18:01:45,467 state(/run/user/0/xpra/50baea70a402-10.0.75.1:100)=DEAD
2019-02-02 18:01:45,468 creating sockdir=/run/user/0/xpra, kwargs={}
2019-02-02 18:01:45,468 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-02 18:01:45,468  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-02 18:01:45,468 state(/run/xpra/50baea70a402-10.0.75.1:100)=DEAD
2019-02-02 18:01:45,468 creating sockdir=/run/xpra, kwargs={'mode': 509}
2019-02-02 18:01:45,468 sockets in unknown state: []
2019-02-02 18:01:45,468 state(/run/user/0/xpra/50baea70a402-10.0.75.1:100)=DEAD
2019-02-02 18:01:45,468 state(/run/xpra/50baea70a402-10.0.75.1:100)=DEAD
2019-02-02 18:01:45,468 socket creation error
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/server/socket_util.py", line 377, in setup_local_sockets
    sock, cleanup_socket = create_unix_domain_socket(sockpath, sperms)
  File "/usr/lib/python2.7/site-packages/xpra/server/socket_util.py", line 41, in create_unix_domain_socket
    listener.bind(sockpath)
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 2] No such file or directory
2019-02-02 18:01:45,470 Warning: cannot create socket '/run/user/0/xpra/50baea70a402-10.0.75.1:100':
2019-02-02 18:01:45,470  [Errno 2] No such file or directory
2019-02-02 18:01:45,471  /run/user does not exist
2019-02-02 18:01:45,471 created unix domain socket: /run/xpra/50baea70a402-10.0.75.1:100
2019-02-02 18:01:45,471 setting up local sockets: [(('unix-domain', <socket._socketobject object at 0x7fa4930b5050>, '/run/xpra/50baea
70a402-10.0.75.1:100'), <function cleanup_socket at 0x7fa4931c18c0>)]
2019-02-02 18:01:45,471 unix-domain /run/xpra/50baea70a402-10.0.75.1:100 : <socket._socketobject object at 0x7fa4930b5050>
2019-02-02 18:01:45,475 Missing property _XPRA_DBUS_PID (u32)
2019-02-02 18:01:45,475 Missing property DBUS_SESSION_BUS_ADDRESS (latin1)
2019-02-02 18:01:45,476 Missing property DBUS_SESSION_BUS_PID (u32)
2019-02-02 18:01:45,477 Missing property DBUS_SESSION_BUS_WINDOW_ID (u32)
2019-02-02 18:01:45,477 retrieved existing dbus attributes
2019-02-02 18:01:45,477 dbus attributes: pid=None, env={}
2019-02-02 18:01:45,477 env={'PYTHONIOENCODING': 'UTF-8', 'MWNO_RIT': 'true', 'XPRA_XDG_OPEN_SERVER_SOCKET': '/run/xpra/50baea70a402-1
0.0.75.1:100', 'XDG_CURRENT_DESKTOP': 'Xpra', 'XDG_SESSION_TYPE': 'x11', 'QT_IM_MODULE': 'xim', 'USER': 'root', 'HOME': '/root', 'LIBG
L_ALWAYS_INDIRECT': '1', 'PATH': '/usr/lib/xpra:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'MWWM':
'allwm', 'DISPLAY': '10.0.75.1:100', 'LANG': 'C.UTF-8', 'TERM': 'xterm', 'SHELL': '/bin/sh', 'container': 'docker', 'XAUTHORITY': '/x1
1docker/Xclientcookie', 'SHLVL': '2', 'PYTHON_PIP_VERSION': '19.0.1', 'XPRA_XSHM': '0', 'MWNOCAPTURE': 'true', 'XMODIFIERS': '@im=none
', 'XPRA_LOG_DIR': '/tmp/XDG_RUNTIME_DIR/xpra', 'IMSETTINGS_MODULE': 'none', 'GPG_KEY': 'C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF', 'X
DG_RUNTIME_DIR': '/tmp/XDG_RUNTIME_DIR', 'DISABLE_IMSETTINGS': '1', 'NO_AT_BRIDGE': '1', 'QT_X11_NO_NATIVE_MENUBAR': '1', 'TZ': 'UTC-0
1', 'PYTHON_VERSION': '2.7.15', 'GTK_IM_MODULE': 'xim', 'UBUNTU_MENUPROXY': '', 'OLDPWD': '/tmp', 'HOSTNAME': '50baea70a402', 'PWD': '
/root', 'CKCON_X11_DISPLAY': '10.0.75.1:100'}
2019-02-02 18:01:45,477 X11 extension Composite event_base=0
2019-02-02 18:01:45,478 found X11 extension Composite with version 0.2
2019-02-02 18:01:45,480 XShmQueryExtension()=False
2019-02-02 18:01:45,480 Warning: no XShm support on display 10.0.75.1:100
2019-02-02 18:01:45,480 X11 extension DAMAGE event_base=90
2019-02-02 18:01:45,480 found X11 extension DAMAGE with version 1.0
2019-02-02 18:01:45,480 X11 extension Composite event_base=0
2019-02-02 18:01:45,480 found X11 extension Composite with version 0.2
2019-02-02 18:01:45,481 pointer grab constants: {0: 'NotifyNormal', 1: 'NotifyGrab', 2: 'NotifyUngrab', 3: 'NotifyWhileGrabbed'}
2019-02-02 18:01:45,481 detail constants: {0: 'NotifyAncestor', 1: 'NotifyVirtual', 2: 'NotifyInferior', 3: 'NotifyNonlinear', 4: 'Not
ifyNonlinearVirtual', 5: 'NotifyPointer', 6: 'NotifyPointerRoot', 7: 'NotifyDetailNone'}
2019-02-02 18:01:45,509 ewmh selection owner for WM_S0: 0
2019-02-02 18:01:45,509 compositing window manager _NEW_WM_CM_S0: 0
2019-02-02 18:01:45,510 _NET_SUPPORTING_WM_CHECK for screen 0: None (root=0x36c)
2019-02-02 18:01:45,510 X11 extension XShape event_base=64
2019-02-02 18:01:45,510 found X11 extension XShape with version 1.1
2019-02-02 18:01:45,511 displayHasXShape()=True
2019-02-02 18:01:45,511 XShape=True
2019-02-02 18:01:45,513 XRRQueryExtension()=1
2019-02-02 18:01:45,513 found XRandR extension
2019-02-02 18:01:45,513 found XRandR extension version 1.6
2019-02-02 18:01:45,513 found 1 config sizes
2019-02-02 18:01:45,516 successfully loaded socket C library from libc.so.6
2019-02-02 18:01:45,523 ServerBaseClass(<class 'xpra.server.server_core.ServerCore'>, <class 'xpra.server.mixins.server_base_controlco
mmands.ServerBaseControlCommands'>, <class 'xpra.server.mixins.clipboard_server.ClipboardServer'>, <class 'xpra.server.mixins.audio_se
rver.AudioServer'>, <class 'xpra.server.mixins.fileprint_server.FilePrintServer'>, <class 'xpra.server.mixins.mmap_server.MMAP_Server'
>, <class 'xpra.server.mixins.input_server.InputServer'>, <class 'xpra.server.mixins.child_command_server.ChildCommandServer'>, <class
 'xpra.server.mixins.encoding_server.EncodingServer'>, <class 'xpra.server.mixins.logging_server.LoggingServer'>, <class 'xpra.server.
mixins.networkstate_server.NetworkStateServer'>, <class 'xpra.server.mixins.display_manager.DisplayManager'>, <class 'xpra.server.mixi
ns.window_server.WindowServer'>)
2019-02-02 18:01:45,524 GTKServerBase.__init__()
2019-02-02 18:01:45,524 ServerCore.__init__()
2019-02-02 18:01:45,525 server uuid is bdd2d1978cd0425e84b69e051695923a
2019-02-02 18:01:45,525 file transfer: init_attributes('yes', 10, 'yes', 'no', 'yes', None, True)
2019-02-02 18:01:45,525 file transfer attributes={'open-files-ask': False, 'open-url': True, 'file-ask-timeout': 3600, 'open-files': F
alse, 'file-size-limit': 10, 'file-transfer': True, 'file-chunks': 65536, 'file-transfer-ask': False, 'printing-ask': False, 'open-url
-ask': False, 'printing': True}
2019-02-02 18:01:45,526 ServerBase.__init__()
2019-02-02 18:01:45,526 server uuid is bdd2d1978cd0425e84b69e051695923a
2019-02-02 18:01:45,527 initializing packet handlers
2019-02-02 18:01:45,527 init_virtual_devices({}) got pointer=None, touchpad=None
2019-02-02 18:01:45,527 pointer device emulation using XTest
2019-02-02 18:01:45,527 Warning: XTest extension is missing
2019-02-02 18:01:45,528 XFixesQueryExtension version present: True
2019-02-02 18:01:45,528 XFixesQueryExtension event base=86, error base=139
2019-02-02 18:01:45,528 Error: keyboard and mouse disabled
2019-02-02 18:01:45,528 randr=True
2019-02-02 18:01:45,529 _XPRA_RANDR_EXACT_SIZE=None
2019-02-02 18:01:45,530 get_xrr_screen_sizes()=[(3840, 1080)]
2019-02-02 18:01:45,530 randr=True, exact size=True
2019-02-02 18:01:45,530 randr enabled: True
2019-02-02 18:01:45,530 get_default_cursor=[1920, 540, 16, 16, 7, 7, 1, '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\
xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf
f\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\
xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xf
f\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\
xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x0
0\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x0
0\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xf
f\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x0
0\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x0
0\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xf
f\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\
xff\xff\xff\xff', '']
~ #
mviereck commented 5 years ago

@totaam xpra succeeds to use Xwin from Cygwin/X. See report of @1138-4EB in #122. Xwin is quite similar to VcXsrv and x11docker runs them with the same command line options. Both X servers are connected over IP with DISPLAY = IP:DISPLAYNUMBER so at this point there is no issue with xpra.

mviereck commented 5 years ago

@1138-4EB Are you still working on this? Otherwise we could close this and other related tickets for now and reopen them if they are of interest again.

mviereck commented 5 years ago

Feel free to re-open if this is of interest again.

eine commented 5 years ago

@1138-4EB Are you still working on this? Otherwise we could close this and other related tickets for now and reopen them if they are of interest again.

I'm sorry I missed this comment. I've been quite busy lately, so it is ok to close these issues for now. Nonetheless, I created a project with all of them (https://github.com/users/1138-4EB/projects/2), to make it is easier to come back later.