RealVNC is currently the most versatile and best-performing VNC business software suite, and many times, in order to ensure a consistent performance and functionality, it is still heavily used in RealVNC. Recently installed the latest version of RealVNC server 5.2.3 on the Fedora 22 workstation, encountered some problems, taking this opportunity to make the installation of RealVNC server, the configuration of the two service modes (server mode and virtual mode) basically clear, The installation on Rhel/centos 6.3/7.0 and other systems is also almost indistinguishable with fedora. First of all, of course, download the installation package for Linux from the RealVNC official website. Note that, starting from 5.0, REALVNC provides a unified package installation file (which is already included in the server, client, and associated tools and documentation) without having to download the server, client, etc. separately. After downloading, unzip and execute the installer, the relevant executable file is installed to the/usr/local/bin directory by default. After installation, remember to execute the vnclicense command to add and view the license ... Details of the process I'm not going to say much here, but I'll focus on how to configure it.  REALVNC Server provides two modes of operation, namely server mode and virtual mode. Server mode refers to the host boot into the graphics mode, regardless of login or not, multiple remote can access the host's current X11 graphics environment through VNC, all the remote share the same graphics manager session on the current host, operations on the host or a remote operation in the graphics environment of the host , including the host, and all the far end can be seen simultaneously. Virtual mode is a bit like the cloud desktop approach, that is, the remote connection to the host via VNC, VNC server on the host to open a behind-the-scenes graphics environment session for this remote control use, each connected to the remote side of the host, have a separate remote graphics environment session, Non-interference, the host's own graphics environment session is independent, not affected by the remote interference. These two models each have their own merits, and we don't discuss comparisons here. For configuration, the first thing to know is that the RealVNC configuration file is basically located in the/etc/vnc directory. VNC at least three kinds of authentication mode, the first is VNC own Vncauth authentication mode, only need to provide password to Telnet, do not need user name, more convenient; the second is the Windows System authentication mode, for VNC server installed on Windows, You can use the Windows system's account authentication, and the third is the Unixauth authentication mode, which can be used for the Unix/linux system's account authentication for VNC server installed on Unix/linux. We first configure the Vncauth mode password, execute the command: #/usr/local/bin/vncpasswd Follow the prompts to enter the password confirmation. The generated password is automatically saved in this file named/ROOT/.VNC/PASSWD. Then we start configuring the RealVNC Server security options and authentication mode. Enter the/ETC/VNC/CONFIG.D directory and create two files with names of Common.custom.Virtual and common.custom.x11. These two files are the configuration files that correspond to virtual mode and server mode, respectively. The contents are as follows: common.custom.virtual: Allowhttp=0alwaysshared=1reversesecuritytypes=ra2,ra2ne, The contents of nonesecuritytypes=ra2,ra2neuserpasswdverifier=unixauth common.custom.x11 are: AllowHttp=0AlwaysShared= After the 1reversesecuritytypes=ra2,ra2ne,nonesecuritytypes=ra2,ra2ne,vncauthuserpasswdverifier=vncauth is preserved, Depending on the RealVNC server run mode, you can use the/etc/vnc/ CONFIG.D Create a soft connection named Common.custom in the current directory, point to Common.custom.virtual or common.custom.x11 to accommodate two different modes of operation. Then go back to the/etc/vnc directory, create a file named Xstartup.custom.mate, and edit its contents as follows: #!/bin/bash/usr/bin/mate-session & save it Well, Remember, if you want the RealVNC server to run in virtual mode, you need to generate a soft connection named Xstartup.custom in the/etc/vnc directory, point to Xstartup.custom.mate, and if you want to make RealVNC Server is running in server mode, you want to remove Xstartup.custom. Next, install the Mate desktop environment with Yum or DNF. The reason for installing the Mate Desktop environment is that starting with GNOME 3.0 and KDE 5.0, since they all use the more advanced OpenGL features to achieve stunning desktop effects, the virtual mode of the REALVNC server is not supported by the Emulation x server. This causes RealVNC server to fail to start Gnome 3.0/kde 5.0 in virtual mode, resulting in virtual mode startup failure. Mate desktop environment still uses gtk+2.0 and simple xcompose compound effect, RealVNCServer's own virtual mode x server can be supported very well. So, in virtual mode, the remote connection to the host after seeing is the mate desktop, and the host is still using GNOME 3.0/kde 5.0 desktop, non-interference, very interesting. Of course, if you like, you can also install a lightweight desktop such as XFCE, and then modify the above configuration, so that the remote connection to the host after the installation of the XFCE desktop ...... Finally, the RealVNC Server service takes effect and started. If you want to use RealVNC's server mode, use the following command: # systemctl enable vncserver-x11-serviced.service# systemctl start vncserver-x11-serviced.service If you want to use virtual mode, use the following command: # systemctl enable vncserver-virtuald.service# Systemctl start vncserver-virtuald.service If you want to modify REALVNC server's default network listening port (in server mode is 5999 in 5900,virtual mode), You can add the Rfbport parameter to the Common.custom to specify the port number you want. common.custom in the parameters can be RealVNC official documents to check, of course, the official documents I feel very fragmented, not easy to find, here tell you two ways, can be similar to # vncserver-x11-help This command looks at a few detailed parameter descriptions. You can also see almost all of the supported parameter names and values in the graphical client by running Vncviewer, through the Configuration interface (which appears to be the "Advanced" section). It is also important to note that after installing RealVNC server on Fedora 22 and configuring all parameters, it is found that the server mode cannot be started and the listening port does not come up. Finally think of a lot of hard ways to check the official documentation, only to know that this is a compatibility issue, because the Xorg server version of Fedora 22 is very high, the estimated compatibility of the REALVNC server has a problem, unable to find a running X server. The solution is (the original, I will not translate, anyway is very simple, understand): the X Server on Fedora are 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 profile path of the vncserver-x11-serviced described in the official documentation, which is exactly what the document says, through man vncserver-x11-serviced command to view its manual is also explained. Supplemental notes (very Important): the following supplemental instructions are important! In Fedora 22, the GDM login manager is using Wayland by default, since the server transition to Wayland is started, and if you use RealVNC's server mode, This causes the vncserver-x11-serviced to fail to find the X server after startup, which causes the Vncserver-x11-core to run down and the listening port does not come up! Prevents you from using VNC to remotely connect to the host for GDM user login! Therefore, to modify the configuration of GDM, let it use the X server by default instead of Wayland. The method is to modify the/etc/gdm/custom.conf file, find inside the #WaylandEnable =false this item, the previous # removed, save and restart the machine can take effect. At this point you will find that you can use VNC remote to the host and display the GDM login interface, but don't be happy too early! When you select a user account and log in successfully, you will find that the VNC connection is disconnected. At this point, through the process to see the discovery, Vncserver-x11-core turned into a zombie process, stopped working, causing the listening port to go down. At this point you will find that the desktop environment session in which the host is logged in also initiates a xorg service, and the xorg service used by the GDM login interface still exists. This could be caused by the vncserver-x11-core of RealVNC, which could not discriminate which xorg service was used to cause zombies. We know that GDM has to use an XORG in order to display the login interface session, and the old Linux version prior to Fedora 22 was estimated to allow the desktop session to enter after login to use the same xorg as GDM, so RealVNC is working properly. Now Fedora 22 is transitioning to Wayland, causing GDM and logged in desktop sessions to use their separate xorg processes, causing RealVNC compatibility issues. No matter, we change the idea, if the login into the desktop environment, let the current login account start a vncserver-x11 process in user mode to work can solve the problem, even the listening port does not need to change! The experiment also confirms that when the desktop session user logs off, the vncserver-x11 user mode process is randomly destroyed, The vncserver-x11-serviced of the corresponding xorg service that uses the previous GDM login session, and the Vncserver-x11-core zombie process that started up again, resumed normal monitoring! This ensures that the remote host can still connect remotely via the VNC client and display the GDM login interface! So, now it's time to solve a problem, how do we get the host to automatically execute our custom scripts after the login has successfully entered the GNOME desktop? Very simple, enter the following command in the home directory of the host login account: $ CD ~/.config/autostart$ VI autostart.desktop Enter the VI editing environment, enter the following: [desktop Entry]name=autostartcomment=desktop Session autostartexec=/usr/local/bin/autostartterminal=falsetype= Applicationstartupnotify=truex-gnome-fullname=desktop Session autostart Save and Exit VI, then switch to root and enter the following command: # CD/ usr/local/bin# VI autostart into the VI editing environment, enter the following: #!/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 Restart the host, then you can use the VNC client remote connection host, in GDM login, login successful will be disconnected. You have to bother, and then re-connect the host remotely with the VNC client, you can go to the desktop environment of the remote host. Well, so far, RealVNC server has settled in Fedora 22, and it works very well. From the current situation, only Fedora 22 has this situation, Rhel/centos 6.X/7 does not exist in the above-mentioned situation (after login will not disconnect and re-connect). Of course, with the popularity of Wayland, Fedora 23 started with the full use of Wayland to replace the old X service, RealVNC is now also developing a new version of VNC based on Wayland Services, believing that compatibility issues will be resolved. Re-revision: by default, the RealVNC Viewer warns of signature changes each time Vncserver (whether X11 server mode or virtual mode) starts, Even when the current connected Vncserver stops and starts a new vncserver, the client connection is terminated due to signature changes, and the effect of smoothing the automatic connection is not achieved (especially in the server mode above), and it is cumbersome to restart the VNC viewer every time. This allows the VNC viewer to connect to Fedora by modifying the configuration of the VNC viewer so that no signature warnings can be implemented. 22 The VNCSERVER-X11 service in the server mode running in the environment is automatically connected automatically from the GDM connection to the GNOME desktop, by locating "Expert" in the settings of the RealVNC Viewer, and locating in the configuration parameters list " Verifyid ", the default value is 2, change to 0 (in fact, in the modification has been explained, tells you the meaning of the Verifyid value). So far, everything is perfect.
Experience Summary of installing configuration RealVNC Server 5.2.3 under Fedora 22
