Experience in installing and configuring RealVNC Server 5.2.3 under Fedora 22

Source: Internet
Author: User
Tags windows remote desktop

Experience in installing and configuring RealVNC Server 5.2.3 under Fedora 22
RealVNC is currently the most comprehensive and best-performing VNC commercial software suite. Many times, to ensure the unification of performance and functionality, it is still widely used. I recently installed the latest version of RealVNC Server 5.2.3 on the ora 22 workstation and encountered some problems. I took this opportunity to install the RealVNC Server and configure the two service modes (Server mode and Virtual mode) basically, the installation on RHEL/CentOS 6.3/7.0 and other systems is almost the same as that on Fedora. First, download the installation package for Linux from the official website of RealVNC. Note: Starting from 5.0, RealVNC provides a unified packaging and Installation File (after installation, it contains the server, client, and related auxiliary tools and documents ), you do not need to download the server and client separately. After the download, decompress and run the installation program. The executable files are installed in the/usr/local/bin directory by default. After installation, remember to execute the vnclicense command to add and view the license ...... I will not talk about the process details here. I will focus on how to configure the process. The RealVNC Server provides two running modes: Server mode and Virtual mode. Server Mode means that after the host is started and enters the graphical mode, multiple remote terminals can access the current X11 graphical environment of the host through VNC regardless of whether the host is logged on or not, all remote terminals share the same image Manager Session on the current host, operations in the graphical environment on the host, or remote operations in a remote graphical environment on the host, both the host and all remote terminals can be seen at the same time. The Virtual mode is similar to the cloud desktop mode, that is, after the remote connection to the host through VNC, The VNC Server on the host enables a graphic environment session dedicated to the remote control, each remote connection to the host has an independent remote graphical environment session, which does not interfere with each other. The host's own graphical environment session is also independent and is not subject to remote interference. The two models have their own advantages. We will not discuss the comparison here. For configuration, you must first know that the configuration files of RealVNC are basically located in the/etc/vnc directory. VNC has at least three authentication modes. The first mode is VNC's own VNCAuth Authentication mode. You only need to provide a password to log on remotely without a user name. The second mode is Windows Authentication mode, for VNC servers installed on Windows, you can use account authentication in Windows. The third is the UnixAuth Authentication mode. For VNC servers installed on Unix/Linux, you can use account authentication for Unix/Linux systems. First, configure the VNCAuth password and run the command: #/usr/local/bin/vncpasswd. Enter the password as prompted to confirm. The generated password is automatically saved in the file named/root/. vnc/passwd. Then we start to configure the security options and Authentication Mode of the RealVNC Server. Go to the/etc/vnc/config. d directory and create two files named common. custom. virtual and common. custom. x11 respectively. These two files correspond to the configuration files in Virtual mode and Server mode respectively. The content is as follows: common. custom. virtual content: AllowHttp = 0 AlwaysShared = 1 ReverseSecurityTypes = RA2, RA2ne, NoneSecurityTypes = RA2, RA2neUserPasswdVerifier = UnixAuth common. custom. the content of x11 is: AllowHttp = 0 AlwaysShared = 1 ReverseSecurityTypes = RA2, RA2ne, NoneSecurityTypes = RA2, RA2ne, expires = VncAuth. After saving the content, it is required according to the RealVNC Server operating, in/etc/vnc/config. d. Create a soft connection named common in the current directory. custom, pointing to common. custom. virtual or common. custom. X11 to adapt to two different operating modes. Return to the/etc/vnc directory and create a file named xstartup. custom. mate. edit the file as follows :#! /Bin/bash/usr/bin/mate-session & keep in mind that if you want the RealVNC Server to run in Virtual mode, you need to generate a soft connection named xstartup in the/etc/vnc directory. custom, pointing to xstartup. custom. mate; if you want the RealVNC Server to run in Server mode, delete xstartup. custom. Then, use yum or dnf to install the MATE desktop environment. The reason for installing the MATE desktop environment is that since GNOME 3.0 and KDE 5.0, they all use more advanced OpenGL features to implement dazzling desktop effects, as a result, the RealVNC Server cannot support the simulated X Server in the Virtual mode. As a result, the RealVNC Server cannot start GNOME 3.0/KDE 5.0 in the Virtual mode, resulting in a failure to start in the Virtual mode. However, the MATE desktop environment still uses GTK + 2.0 and simple XCompose compound effects. The RealVNC Server's own Virtual mode X Server can support well. Therefore, in Virtual mode, the MATE desktop is displayed after the remote connection to the host, while the host still uses the GNOME 3.0/KDE 5.0 desktop, which does not interfere with each other and is very interesting. Of course, if you like, you can also install XFCE and Other lightweight desktops, and then modify the above configuration so that the remote connection to the host will see the XFCE desktop ...... Finally, the RealVNC Server service is enabled. If you want to use the Server mode of RealVNC, use the following command: # systemctl enable vncserver-x11-serviced.service # systemctl start vncserver-x11-serviced.service if you want to use the Virtual mode, use the following command: # systemctl enable vncserver-virtuald.service # systemctl start vncserver-virtuald.service if you want to modify the RealVNC Server's default network listening port (5900 in Server mode, 5999 in Virtual mode), you can in common. add the RfbPort parameter to m to specify the port number you want. Common. the parameters in custom can be queried through the official RealVNC documentation. Of course, I think the official documentation is very fragmented and difficult to find. Here are two solutions for you, you can view detailed parameter descriptions using commands like # vncserver-x11-help. You can also run vncviewer to view almost all supported parameter names and values on the graphical client through the configuration interface (such as the "advanced" section. It is worth noting that after the RealVNC Server is installed on Fedora 22 and all parameters are configured, the Server mode cannot be started and the listening port cannot start. Finally, I thought a lot of hard work to check the official documentation to know that this is a compatibility issue. Because the Xorg Server version of Fedora 22 is very high, it is estimated that the compatibility issue has caused the RealVNC Server to be faulty, the running X Server cannot be found. The solution is (in the original article, I will not translate it, but it is very easy to understand): 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 here,/etc/vnc/config. d/vncserver-x11-serviced is the configuration file for the vncserver-x11-serviced described in the official documentation Path, which is indeed said in the document, it is also explained to view its manual through the man vncserver-x11-serviced command. Additional instructions (very important): the following supplementary instructions are very important! In Fedora 22, due to the start of showing the Server transition to Wayland, the IIS logon Manager uses wayland by default. If you are using the Server mode of RealVNC, this causes the vncserver-x11-serviced to fail to find the X Server after it is started, as a result, the vncserver-x11-core failed to run, the listening port cannot start! As a result, you cannot use VNC to remotely connect to the host to log on to the machine as a target for the target user! Therefore, you need to modify the configuration of the guid Management System (GTM) so that it uses the X server rather than Wayland by default. The method is to modify the/etc/TPD/custom. conf file, find the # WaylandEnable = false option in it, remove the previous #, save it, and restart the machine to take effect. At this time, you will find that you can use VNC to remotely connect to the host and display the WordPress logon interface, but don't be too happy! After you select a user account and successfully log on, you will find that the VNC connection is disconnected. At this time, through the process view found that the vncserver-x11-core becomes a zombie process, stop the work, resulting in listening port down. At this time, you will find that the desktop environment session logged on to the host has started an Xorg service, and the Xorg service used on the logon interface of the running machine is still present. This could be the result of RealVNC's vncserver-x11-core being unable to identify which Xorg service to use, resulting in freezing. We know that an Xorg must be used for display of Logon interface sessions for the running of the agent. In earlier versions of Linux than Fedora 22, it is estimated that the desktop session entered after login should use the same Xorg as that of the running of the agent, therefore, RealVNC works properly. Currently, the transition from Fedora 22 to Wayland is gradually emerging, resulting in the use of independent Xorg processes in the running and logged-on desktop sessions, which causes RealVNC compatibility problems. It doesn't matter, let's change our mindset, If you log on to the desktop environment, let the current login account start a vncserver-x11 Process Working in user mode can solve the problem, you do not need to change the listening port! The test also confirmed that when the desktop session user logged out of the host, the vncserver-x11 user mode process was randomly destroyed, and the vncserver-x11-serviced that uses the Xorg service corresponding to the previous running session with the running of the vncserver-x11-core zombie process and resume normal listening again! In this way, you can ensure that the remote host can still be remotely connected through the VNC client and display the logon interface of the target machine! Now, we need to solve a problem. How can we make the host automatically execute our custom script after logging on to the GNOME desktop? Simple: Enter the following command in the home directory of the host login account: $ cd ~ /. Config/autostart $ vi autostart. enter the vi editing environment and enter the following content: [Desktop Entry] Name = autostartComment = Desktop Session AutostartExec =/usr/local/bin/autostartTerminal = falseType = ApplicationStartupNotify = trueX-GNOME-FullName = Desktop Session Autostart save and exit vi, switch to root and enter the following command: # cd/usr/local/bin # vi autostart to enter the vi editing environment. Enter the following content :#! /Bin/bashecho "desktop session autostart"> ~ /Autostart. log/usr/local/bin/vncserver-x11-stop/usr/local/bin/vncserver-x11-display: 1 & Save and exit vi, enter the command: # chmod 755/usr/local/bin/autostart to restart the host. Then, you can remotely connect to the host using the VNC client and log on to the host using the MPCS client. After Successful Logon, the connection will be disconnected. You have to try again and connect to the host remotely using the VNC client to access the desktop environment of the remote host. Now, the RealVNC Server has been settled in Fedora 22, and the use effect is very good. From the current situation, only Fedora 22 has this situation, and RHEL/CentOS 6.x/ 7 does not have this situation as mentioned above (the connection will not be disconnected and re-connected after login ). Of course, with the popularization of Wayland, Fedora 23 is about to fully use Wayland to replace the old X service. RealVNC is also developing a new version of VNC Based on Wayland service. I believe the compatibility problem will be solved. Revised again: by default, the RealVNC Viewer will issue a warning because the Signature changes each time the VNCServer (X11 Server mode or Virtual mode) is started, even when the currently connected VNCServer is stopped and a new VNCServer is started, the client connection is terminated due to Signature changes, and the smooth and automatic connection effect (especially in the above Server mode) is not achieved ), it is troublesome to restart VNC Viewer every time. Here, you can modify the VNC Viewer configuration to avoid Signature warnings, this enables VNC Viewer to automatically connect to the GNOME Desktop smoothly and automatically from the connection of the running Server mode to the VNCServer-X11 service in the Fedora 22 environment: in the settings of RealVNC Viewer, find "Expert" and find "VerifyId" in the configuration parameter list. The default value is 2 and the value is 0, tell you the meaning of VerifyId ). So far, everything is perfect.

VNC installation Configuration

Install and configure VNC in CentOS 6.3

In Linux, the dependency installation VNC is not detected.

CentOS6 VNC service installation and configuration

Configure and install VNC in CentOS

VNC remote control installation and Setup

Windows accesses Ubuntu through VNC

Install VNC for accessing Ubuntu 12.04 through Windows Remote Desktop

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.