Resumable VNC Sessions

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Desktop 15
 

Resumable VNC Sessions

In most environments a user’s default VNC session with a server lasts as long as the user’s client session remains connected to the VNC server. That’s very effective in a reliable network environment but begins to lose effectiveness in an unreliable network environment where the session might fail and be disconnected outwith the control of the user. Common VNC servers will treat that as as having the same effect as all the applications on the desktop crashing without any user managed saving of any open files. Basically all the desktop applications are children of the VNC session. The VNC session instance is killed when the disconnect happens and since all the desktop applications are children of that killed VNC server application all the desktop applications that were running at the disconnect are automatically killed as well. There are even some applications where closing them in that manner creates problems trying to start them afresh in a new desktop session whether it’s local or over another VNC session. A very trivial, but slightly irritating example, is when using an editor like vi, say in a desktop shell window, and the shell and vi are killed while a document is open and modified in vi. The restarted remote desktop session will let me open another shell and use a vi command-line to open the same document but in normal use vi will have had a temporary file (what it calls a swap file) with a re-usable name open during the editing process and it will not have been removed when the first vi edit session was killed as the vnc session failed. The second attempt to use vi will complain that the file being edited has a swap file that already exists and offer me the option to open the file read-only, edit the file anyway (without the changes I previously made), recover the file and edit with the changes I made before (though vi still won’t automatically delete the swap file from the first vnc session’s vi use), or I can delete the swap file and edit the intended file with no changes, or quit starting vi or abort the vi session. There’s probably not much difference between quit and abort. Like I said, this is an example that can be irritating but it is easily recovered from without losing previous work. However, there are cases that are much more severe and might even require restarting the work done in the first session from scratch and that might even be required in a state where original files that were being modified in the first session are no longer present and it can be like starting from scratch with no reference data to work from.

That itself describes another problem with a typical VNC session that might not be obvious but a solution to it can make for a much more useful VNC server. What if I know I want to get something started via the VNC server, also know I won’t finish it but can be sure I will have to disconnect my VNC client at some point before I finish my work. Applications typically support the ability to cleanly save and close a document, exit the application and start from the same place later by launching the application again and opening the document to see it as it was when I saved it earlier. However, not all things I might be doing are going to be applications with built-in document semantics that will allow me to save and re-load and might even be as severe as the worst case of losing all my previous work, losing all the state that was present before I started my previous VNC session and effectively having to start again with nothing as a starting point.

The easy solution would be if VNC supported the ability for me to end a session (either by choice or due to failure) but without the VNC server session ending thus allowing me the ability to connect to the VNC server later and see my desktop session with all the open applications as they were when I ended the previous session. On linux that requires a VNC server that leaves running the VNC X-Server hosting my desktop when I disconnect the VNC session. For most uses it probably requires another feature as well, the ability for the VNC server to authenticate connecting users so that that the desktop they see on re-connect is actually their own desktop that was disconnected from earlier.

The most obvious VNC server on SUSE linux and the one that would be installed by default using a software pattern will be the one in the x11vnc package, the executable implementing the listening network service will be vncserver. On a successful connect it launches the X server XVnc to service the connection and the XDM desktop is displayed and operated over that XVnc instance. All the items running in that desktop are child processes of that user’s XVnc instance. Then, if the user disconnects intentionally or due to a network failure the XVnc instance will be killed by the vncserver and all the desktop items that are children of the XVnc instance will be killed at the same time. Everything running in the user’s desktop at the disconnection will be terminated.

However, there’s also a listening VNC session manager called vncmanager that can be installed instead. In the case of vncmanager. Installed by default it provides it’s own “greeter” screen for connecting users and the greeter requires users to authenticate with vncmanager using their credentials from the system running vncmanager. If a user is successfully authenticated there are two paths that can be followed. I’ll begin with the case where there is no pre-existing VNC desktop session for that user. In that case, on an otherwise default linux desktop environment (only the xdm service for the desktop) a new instance of Xvnc is launched and the xdm service provides the desktop view for the user.  New applications launched in this session are child processes of the XVnc instance that was launched for the user. So far it’s effectively the same behavior as obtained from X11vnc’s vncserver but from this point the behavior starts to differ.

If the user of a given session disconnects their VNC client either deliberately by closing it or if it fails due to a network error then the XVnc instance that provided the desktop rendering is not killed and all the user’s desktop applications that are children of that XVnc instance remain running as well. A new attempt to connect to the VNC server (vncmanager) will see the greeter screen and if authentication identifies a user with an already running Xvnc instance then the user’s VNC session will be serviced by that already running XVnc session including the view of the desktop view being as it was at disconnect with all the previously running applications still running with documents and other user content unchanged from the view at the previous disconnect. In other words, a continuation of the previous session without changes.

It’s not a “restore” of the previous desktop from any kind of saved state, it’s literally continued running with no user changing it between a disconnect and re-connect.

Among the requirements that this type of VNC server creates is that there can only be one desktop session per-user ID. If that was not the case then the vncmanager greeter would have no means to identify which desktop to re-connect with.

It’s also the case that any user that can use the desktop UI to restart the computer can break the “pending” sessions that any other users have present so it becomes wise to disable the ability to reboot, poweroff, suspend or hibernate the system from the X-Desktop.

Configuration details

The description above is how it can be made to work but it will require some relatively modest configuration details to make it behave as described.

The configuration file for vncmanager on SLES and SLED 15-SP1 will be /etc/vnc/vncmanager.conf
A minimal content required for re-usable sessions would be as follows:

disable-manager = no
always-show-greeter = yes
xvnc-args = -extension MIT-SHM

Configured like that, vncmanager will require greeter based authentication by users, making it possible to identify connecting users and an existing session running in their name. Plus, vncmanager will not be disabled.
The xvnc-args option to enable the MIT-SHM extension permits X-Windows to exchange data between X server and client on the server host only via the /dev/shm  device instead of via a socket, the assumption being that performance will be improved.

The display manager that is assumed to be used for this environment is xdm and via the display-manager.service system service.

It may be necessary to adjust configuration in /etc/xinetd.d/vnc  such that the server is set to be Xvnc and that the server_args are set to NOT include -noreset -one -query

YaST or the systemctl command-line tool should be used to  configure the vncmanager.service to start on boot and to start now (after any needed configuration changes have been made).

Client usage

Using a client like tigerVNC from a shell command-line on a remote desktop the steps required to create a new session are as follows:

1. Launch the vncviewer-tigervnc executable
2. Enter the name/address and screen ID for the target VNC server. The screen ID is simply an index of the TCP port number the vncmanager being connected to is listening on with port 5900 being the default port and default screen ID of :0, e.g. enter myvncserver.mydomain.com into the “VNC server:” to connect to the default port 5900 on the host with network name myvncserver.mydomain.com. To specify another TCP port, such as 5902 append :2 in the “VNC server:” field, e.g.  myvncserver.mydomain.com:2 to connect to a VNC server at TCP port 5902 on the host with network name myvncserver.mydomain.com. A VNC greeter view will be displayed where a list of “Existing Sessions” is show and a “New Session” button
3. Click the “New Session” button
4. A welcome dialog for the VNC server is displayed prompting for a login name
5. Enter a valid login name for the target system
6. A prompt is displayed for a password
7. Enter the correct password for the login name used in the welcome dialog
8. A new X Desktop for the authenticated user is displayed in the VNC client window

It’s not quite enough that the session is left in that state, it needs to be configured to be persistent and visible in the greeter.

So, as a first step in the new session carry out these steps:

1. Open a terminal window on the new X Desktop session in the VNC viewer window
2. Launch vncmanager-controller from the shell prompt
3. Fill in the vncmanager-controller dialog as follows:
   1. Persistence and Visibility: Select “Persistent, Visible”
   2. Session Name: Enter something appropriate, it doesn’t have to be your username but it probably doesn’t reveal anything meaningful that your username appears in the greeter’s list of live sessions
   3. Security: Set “Require user login”
   4. Allowed Users: Enter user ID’s of permitted users, in general this should rarely be more than the user you are currently connected as
   5. Sharing: Set as needed, “Allow one client at a time” is probably a realistic preference
   6. Click Apply
   7. Click OK

Now, if you close the vncviewer-tigervnc window on your local system and start it again you should be able to re-connect to the session previously created using the following steps:

1. Set the “VNC server:” control to the same location you used on the first connection above
2. In the VNC greeter view the “Existing Sessions” list should include the name you used as the “Session Name:” in the vncmanager-controller instructions above. Plus the New Session button should still be shown.
3. Click on the name of our saved session in the “Existing Sessions” list
4. You will be prompted to input a Username and Password on a view that also includes an OK and Cancel button
5. Enter the username that was used in the “Allowed Users:” field in vncmanager-controller (by default this would commonly be the user that created the New Session above)
6. Enter the password for the user at item 5) above
7. Press OK
8. The X Desktop as it was when you closed the vncviewer above should be re-displayed

Be advised that, at the time of writing, the YaST tool for “Remote Administration (VNC)” is disfunctional and behaves as follows:

1. As root, start YaST
2. Open Network Services and start the “Remote Administration (VNC)” tool
3. Activate “Allow Remote Administration With Session Management”
4. Confirm your settings with “Next (no firewall is configured)”
5. No packages are installed and it asks that display-manager.service be restarted
6. Restart display-manager.service
7. Verify vncmanager is running and can be connected to successfully
8. Goto step 1 in this list

The configuration displayed at step 1 is always “Do Not Allow Remote Administration”, even if:

• Steps 2), 3), and 4) above have been performed with no errors reported
• vncmanager is running and can be connected to successfully
• Regardless of how you start YaST (in a desktop or console session, root session, or su, local on the host, or over VNC, over ssh)
• If the vncmanager.conf has content matching that which would be expected if Remote Administration (VNC) was enabled and active
• With a default vncmanager.conf from installing the vncmanager package

The appearance is that the YaST tool “Remote Administration (VNC)” has a bug and cannot be used to make the configuration changes needed for the functionality described in this document.

However, it doesn’t prevent that configuration from being created and doesn’t break it if it exists. Since the required configuration changes are quite small the problem with the YaST VNC configuration tool is not fatal or an overhead to getting working configuration. This problem in the YaST VNC configuration tool doesn’t prevent the use of the YaST Services Manager tool to launch and enable boot time launching of an installed and configured vncmanager.service. 

Some problem cases you may experience

It may be necessary to permit access via the firewall to the TCP port vncmanager is listening on, typically TCP port 5900 or a nearby following port number, e.g. 5901, 5901, 5903 or 5904, etc. Usually there will only be one that vncmanager is listening on.
The configuration that set’s it is typically set in an entry in the configuration file /etc/xinetd.d/vnc that the Configuration Details above described what value should be used for the server and the removal of some of the server_args.

Here’s a full example that would result on a VNC server listening on port 5902 (accessed as servername:2 on the VNC client):

service vnc2
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = /usr/bin/Xvnc
        server_args     = -inetd localhost -geometry 1024x768 -depth 16
        type            = UNLISTED
        port            = 5902
}

Unless there is something already listening on port 5900 it’s easier to use the port for the :0 screen by setting port to 5900.

All of these instructions assume that the VNC server has the display-manager.service default system service set for X and that the desktop manager is xdm. That means that no special service is created for xdm and display-manager.service is used as created by a default desktop install.
It also assumed that no system service is created to launch XVnc. That will supersede the ability of vncmanager to launch XVnc instances and the VNC sessions will still close on client disconnect killing all running applications in the user’s desktop.
The same for any desktop provider such as gdm or kde, these should not be started as it’s own service they should be left for display-manager.service to start on demand instead.
The listen port for the VNC server should be set via /etc/xinetd.d/vnc and not via /etc/systemd files such as /etc/systemd/system/xvnc.socket.d

As was said before it will probably be wise to prevent a random user from performing tasks like reboot, poweroff, hibernate and suspend.
These can be configured with the policykit rules such as by adding /etc/polkit-1/rules.d/60-logoff-dialog.rule by ensuring it includes the following:

polkit.addRule(function(action, subject) {
  if (action.id == "org.freedesktop.login1.power-off" ||
    action.id == "org.freedesktop.login1.reboot" ||
    action.id == "org.freedesktop.login1.suspend" ||
    action.id == "org.freedesktop.login1.hibernate" ||
    action.id == "org.freedesktop.login1.power-off-multiple-sessions" ||
    action.id == "org.freedesktop.login1.reboot-multiple-sessions" ||
    action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
    action.id == "org.freedesktop.login1.hibernate-multiple-sessions" )
  {
    return polkit.Result.NO;
  }
});

Then make it generally readable with:

chmod go+r /etc/polkit-1/rules.d/60-logoff-dialog.rule