在Fedora 22下安装配置RealVNC Server 5.2.3的经验总结

 

首先，当然是从 RealVNC 官方网站下载 for Linux 的安装包。注意，从 5.0 开始，RealVNC 提供了统一的打包安装文件（安装后就已经包含服务端、客户端以及相关附带工具及文档等了），不需要再分别下载服务端、客户端等等了。

 

下载完后，解压缩并执行安装程序，相关可执行文件默认被安装到 /usr/local/bin 目录下。安装完后记得执行 vnclicense 命令添加并查看许可证……过程的细节这里我就不多说了，重点讲一讲如何配置。

 

RealVNC Server 提供两种运行模式，即 Server 模式和 Virtual 模式。Server 模式是指主机启动进入图形模式后，无论登录与否，多个远端都可以通过 VNC 访问主机当前的 X11 图形环境，所有远端共享当前主机上的同一个图形管理器会话，主机上的图形环境下的操作或者某个远端对主机图形环境下的远程操作，包括主机在内以及所有远端都能同时看见。Virtual 模式则有点类似于云桌面方式，即远端通过 VNC 远程连接到主机后，主机上的 VNC Server 开启一个幕后的图形环境会话专供这个远端远程控制使用，每个连接到主机的远端，都拥有一个各自独立的远程图形环境会话，互不干扰，主机自己的图形环境会话也是独立的，不受远端的干扰。

 

这两种模式各有各的优点，我们这里不讨论比较。针对配置而言，首先要知道，RealVNC 的配置文件基本都位于 /etc/vnc 目录下。VNC 至少有三种认证模式，第一种是 VNC 自己的 VNCAuth 认证模式，只需要提供密码即可远程登录，不需要用户名，比较方便；第二种是 Windows 系统认证模式，针对安装在 Windows 上的 VNC Server 而言，可以使用 Windows 系统的账户认证；第三种是 UnixAuth 认证模式，针对安装在 Unix/Linux 上的 VNC Server 而言，可以使用 Unix/Linux 系统的账户认证。我们首先配置 VNCAuth 模式的密码，执行命令：

 

# /usr/local/bin/vncpasswd

 

根据提示输入密码确认即可。生成的密码自动保存在名为 /root/.vnc/passwd 的这个文件中。然后我们开始配置 RealVNC Server 的安全选项及认证模式。进入 /etc/vnc/config.d 目录下，创建两个文件，名字分别为 common.custom.virtual 和 common.custom.x11。这两个文件分别是对应 Virtual 模式和 Server 模式的配置文件。其内容分别如下：

 

common.custom.virtual 的内容为：

AllowHttp=0

AlwaysShared=1

ReverseSecurityTypes=RA2,RA2ne,None

SecurityTypes=RA2,RA2ne

UserPasswdVerifier=UnixAuth

 

common.custom.x11 的内容为：

AllowHttp=0

AlwaysShared=1

ReverseSecurityTypes=RA2,RA2ne,None

SecurityTypes=RA2,RA2ne,VncAuth

UserPasswdVerifier=VncAuth

 

保存好后，根据 RealVNC Server 运行模式的需要，可在 /etc/vnc/config.d 当前目录下创建一个软连接名为 common.custom，指向 common.custom.virtual 或者 common.custom.x11，以便适应两种不同的运行模式。然后返回到 /etc/vnc 目录下，创建一个名为 xstartup.custom.mate 的文件，编辑其内容如下：

 

#!/bin/bash

/usr/bin/mate-session &

 

保存好后，记住一点，如果要让 RealVNC Server 运行在 Virtual 模式下，则需要在 /etc/vnc 目录下生成一个软连接名为 xstartup.custom，指向 xstartup.custom.mate；如果要让 RealVNC Server 运行在 Server 模式下，则要删除 xstartup.custom。接着，利用 yum 或者 dnf 安装 MATE 桌面环境。之所以要安装 MATE 桌面环境，是因为从 GNOME 3.0 以及 KDE 5.0 开始，由于它们都使用了更高级的 OpenGL 特性实现炫丽的桌面特效，导致 RealVNC Server 再带的 Virtual 模式模拟 X 服务器无法支持，从而导致 RealVNC Server 在 Virtual 模式下无法启动 GNOME 3.0/KDE 5.0，导致 Virtual 模式启动失败。而 MATE 桌面环境仍然采用 GTK+2.0 及简单的 XCompose 复合效果，RealVNC Server 自己的 Virtual 模式 X 服务器可以支持得很好。所以这样一来，在 Virtual 模式下，远端连接到主机后看到的就是 MATE 桌面啦，而主机自己则仍然使用 GNOME 3.0/KDE 5.0 桌面，互不干扰，很有趣。当然，如果你喜欢，你也可以安装 XFCE 等轻量级桌面，然后修改上面的配置，让远端连接主机后看到的是 XFCE 桌面……

 

最后，就是使 RealVNC Server 服务生效并启动了。如果你想使用 RealVNC 的 Server 模式，则使用如下命令：

 

# systemctl enable vncserver-x11-serviced.service

# systemctl start vncserver-x11-serviced.service

 

如果你想使用 Virtual 模式，则使用如下命令：

 

# systemctl enable vncserver-virtuald.service

# systemctl start vncserver-virtuald.service

 

如果要修改 RealVNC Server 默认的网络监听端口（Server 模式下是 5900，Virtual 模式下是 5999），可以在 common.custom 中添加 RfbPort 参数指定为你想要的端口号。

 

common.custom 中的那些参数可以通过 RealVNC 官方文档去查，当然，官方文档我觉得很零散，不好找，这里告诉你两个办法，可以通过类似

 

# vncserver-x11 -help

 

这样的命令查看一些详细的参数说明。还可以通过运行 vncviewer，在图形化客户端里面，通过配置界面（好像是“高级”部分）看到几乎所有能够支持的参数名字以及值。

 

这里还要特别说明一点，在 Fedora 22 上安装 RealVNC Server 并配置好所有参数后，发现 Server 模式无法启动，监听端口起不来。最后想了很多费劲的办法查阅官方文档，才知道这是一个兼容性的问题，由于 Fedora 22 的 Xorg 服务器版本很高，估计兼容性方面让 RealVNC Server 出了问题，找不到正在运行的 X 服务器。解决办法是（原文，我就不翻译了，反正也很简单，看得懂）：

 

The X server on Fedora 22 is not in the XServerBinaries VNC parameter list. If /usr/libexec/Xorg is added to the list VNC Server starts as expected. 

 

Edit (or create if it doesn’t exist) /etc/vnc/config.d/vncserver-x11-serviced and add the following line:

 

XServerBinaries=/usr/libexec/Xorg

 

这里说明一下，/etc/vnc/config.d/vncserver-x11-serviced 是官方文档中说明的 vncserver-x11-serviced 的配置文件路径，文档中确实是说了的，通过 man vncserver-x11-serviced 命令查看其手册也是会有说明的。

 

补充说明（非常重要）：

 

以下补充说明内容非常重要！在 Fedora 22 中，由于开始向 Wayland 显示服务器过渡，GDM 登录管理器默认是使用 wayland 的，如果你使用 RealVNC 的 Server 模式，这会导致 vncserver-x11-serviced 启动后找不到 X 服务器，从而引起 vncserver-x11-core 运行失败，监听端口起不来！导致你无法用 VNC 远程连接到主机进行 GDM 用户登录！因此，要修改 GDM 的配置，让其默认使用 X 服务器而不是 Wayland。方法是修改 /etc/gdm/custom.conf 文件，找到里面的

 

#WaylandEnable=false

 

这一项，把前面的 #去掉，保存好后重启机器即可生效。这时你会发现，你可以用 VNC 远程到主机并显示 GDM 登录界面了，但别高兴太早！当你选择某个用户账号并成功登录后，你会发现 VNC 连接断开了。这时，通过进程查看发现，vncserver-x11-core 变成了僵尸进程，停止了工作，导致监听端口宕掉了。而这时你会发现主机上登录进去的桌面环境会话又启动了一个 Xorg 服务，而 GDM 登录界面使用的那个 Xorg 服务也仍然存在。这可能是导致 RealVNC 的 vncserver-x11-core 无法判别到底使用哪个 Xorg 服务从而引起僵死。我们知道，GDM 必须要使用一个 Xorg 以便用于显示登录界面会话，而 Fedora 22 之前的老版本 Linux 估计是让登录后进入的桌面会话使用与 GDM 相同的 Xorg，所以 RealVNC 是能够正常工作的。而现在 Fedora 22 在逐渐向 Wayland 过渡，导致出现 GDM 和登录进去的桌面会话分别使用各自独立的 Xorg 进程，引起 RealVNC 兼容性问题。没有关系，我们换个思路，如果登录进入桌面环境后，让当前登录的账户启动一个在用户模式下工作的 vncserver-x11 进程就能够解决问题了，连监听端口都不用换！通过试验也证实了，当这个桌面会话用户在主机注销后，vncserver-x11 用户模式进程随机销毁，而使用先前 GDM 登录会话的对应的 Xorg 服务的那个 vncserver-x11-serviced 连带启动的 vncserver-x11-core 僵尸进程又重新恢复正常监听了！这样就可以保证远端主机仍然可以通过 VNC 客户端远程连接上来并显示 GDM 登录界面！

 

那么，现在就要解决一个问题，如何让主机在登录成功进入 GNOME 桌面后自动执行我们自定义的脚本？很简单，在主机登录账户的家目录下输入如下命令：

 

$ cd ~/.config/autostart

$ vi autostart.desktop

 

进入 vi 编辑环境，输入如下内容：

 

[Desktop Entry]

Name=autostart

Comment=Desktop Session Autostart

Exec=/usr/local/bin/autostart

Terminal=false

Type=Application

StartupNotify=true

X-GNOME-FullName=Desktop Session Autostart

 

保存并退出 vi，然后切换到 root，输入如下命令：

 

# cd /usr/local/bin

# vi autostart

 

进入 vi 编辑环境，输入如下内容：

 

#!/bin/bash

echo “desktop session autostart” > ~/autostart.log

/usr/local/bin/vncserver-x11 -stop

/usr/local/bin/vncserver-x11 -display :1 &

 

保存并退出 vi，输入命令：

 

# chmod 755 /usr/local/bin/autostart

 

重启主机��这时你就可以用 VNC 客户端远程连接主机，在 GDM 中登录，登录成功后会断开连接。你得麻烦一下，再重新用 VNC 客户端远程连接主机，就可以进入到远程主机的桌面环境了。

 

好了，至此，RealVNC Server 就在 Fedora 22 中安家落户了，使用效果非常好。从目前情况来看，只有 Fedora 22 有这种情况存在，RHEL/CentOS 6.x/ 7 都不存在上面结尾说的这种情况（登录后不会断开连接又要重连）。当然，随着 Wayland 的普及，Fedora 23 开始就要全面使用 Wayland 替代老的 X 服务了，RealVNC 现在也在开发基于 Wayland 服务的新版 VNC，相信兼容性问题会得到解决。

 

再修订：

 

默认情况下，RealVNC Viewer 会因为每次 VNCServer（无论是 X11 Server 模式还是 Virtual 模式）启动时 Signature 改变而发出警告，甚至会在当前连接的 VNCServer 停止并启动一个新 VNCServer 时因 Signature 变化而终止客户端连接，起不到平滑自动连接的效果（特别是上面 Server 模式下），每次还得重新再启动 VNC Viewer 很麻烦。这里可以通过修改 VNC Viewer 的配置来做到不进行 Signature 警告，从而可以实现 VNC Viewer 在连接 Fedora 22 环境中运行的 Server 模式下的 VNCServer-X11 服务时自动从 GDM 的连接平滑自动连接到进入 GNOME 桌面，方式是：在 RealVNC Viewer 的设置中，找到“Expert”，在配置参数列表中找到“VerifyId”，默认值是 2，改为 0 即可（其实在修改处已经有说明，告诉你了 VerifyId 取值的含义）。到此为止，一切都完美了。