在Fedora 22下安装配置RealVNC Server 5.2.3的经验总结
RealVNC是目前功能最全、性能最好的VNC商业软件套件,很多时候为了确保性能和功能的统一,还是大量地在使用RealVNC。最近在Fedora 22工作站上安装RealVNC Server 5.2.3最新版,碰到了一些问题,借这个机会,把RealVNC Server的安装、两种服务模式的配置(Server模式和Virtual模式)都基本上弄清楚了,在RHEL/CentOS 6.3/7.0等系统上的安装也几乎与Fedora别无二致。
首先,当然是从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取值的含义)。到此为止,一切都完美了。
相关推荐
86294251 2020-01-28
星愿心愿 2020-11-24
rikeyone 2020-11-04
一路到黑 2020-10-30
89437401 2020-10-29
86417413 2020-11-25
89612310 2020-11-09
tianyayi 2020-08-16
83911930 2020-07-28
89612310 2020-07-27
CNxuwang 2020-07-20
86477414 2020-06-28
TuxedoLinux 2020-06-17
87354452 2020-06-10
行万里 2020-06-09
jLawrencee 2020-05-19
songxiugongwang 2020-03-07
hahhah0 2020-05-08