在docker容器中运行Xephyr

Question

我试图在直接访问X11套接字的docker容器中运行嵌套的X-server Xephyr，但是我得到了奇怪的图形错误，我目前还不明白。

Dockerfile的内容只是

FROM ubuntu:14.04

RUN apt-get update
RUN apt-get install -qqy xserver-xephyr

# Clean up APT when done.
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

使用

构建它

sudo docker build -t xephyrtest .

并使用

运行它

sudo docker run -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix xephyrtest Xephyr :1

输出以下内容：

Xephyr unable to use SHM XImages
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension Present
Initializing built-in extension DRI3
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension SELinux
Initializing built-in extension GLX
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list!
[dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!

在这里，第一行Xephyr unable to use SHM XImages似乎是最重要的，因为它并没有出现在Xephyr工作正常的主机上。

虽然弹出了Xephyr窗口，但使用:1显示的应用程序显示出奇怪的故障。例如。 DISPLAY=:1 gedit看起来像这样（当鼠标在窗口内移动时，输出会迅速变化）：

SHM XImages的含义是什么？如何解决它在容器内的不可用性？

Answer 1

事实证明，自Docker 1.5使用命令后，在Docker容器中运行Xephyr非常容易

sudo docker run -e DISPLAY -v /tmp:/tmp --ipc=host --pid=host xephyrtest Xephyr :1

另外两个参数是

• --ipc=host允许容器使用与主机相同的IPC名称空间，因此也可以访问相同的共享内存段
• --pid=host让容器查看（并修改）主机的进程。这是必要的，因为X服务器端口锁定是通过/tmp/.Xi-lock锁定文件（用显示端口替换i）完成的，其中包含在端口i上运行的X服务器的pid。 / LI>

除了容器中的X11 unix套接字之外，您还必须将-v /tmp/.X11-unix:/tmp/.X11-unix更改为-v /tmp:/tmp才能访问锁定文件。

虽然这非常有效，但您必须注意两个附加参数以及对主机/tmp文件夹的访问权限授予容器重要权限，这可能会在某些情况下带来安全风险。

Answer 2

使用选项-extension MIT-SHM运行Xephyr以禁用共享内存的使用。然后，您不需要使用泊坞窗选项--ipc=host来分解容器隔离。

要避免使用docker选项--pid=host，请考虑在主机上运行Xephyr，共享其X套接字并设置-e DISPLAY=:1。仅仅共享套接字文件/tmp/.X11-unix/X1就足够了，不需要共享整个文件夹，甚至不需要整个/tmp。

Answer 3

MIT-SHM扩展是一种允许更快地在客户端和服务器之间显示图像的方式，只要它们在同一台计算机上运行即可。这是通过创建SysV shm共享内存对象来完成的，客户端可以将图像数据写入X服务器直接显示，而不必通过套接字将图像序列化。

如果Docker容器阻止它并且gedit依赖它，我不会感到惊讶。