This two-part series presents a novel way to set up a VNC-based X Window System desktop for your Linux system. By the end of this two-part series, you'll have a configuration that allows users to log in to their X-Window desktop (running GNOME, KDE or other preferred window manager environment) via a display manager (like GDM, KDM or XDM). More importantly, the user will have secure access to the same desktop in the same state from the workstation console and anywhere else on a network.
Typically, a workstation system runs a display manager. In this article we refer to such applications as XDM, GDM (GNOME Display Manager) or KDM (KDE Display Manager) generically as display managers. A display manager provides a graphical login prompt for the user. When a user logs in, the display manager starts the appropriate window manager (such as fvwm2, GNOME or KDE). From the window manager, the user can run whichever applications he or she wishes. When the user logs out, applications are closed, the window manager exits and the display manager reappears, ready to allow another user to log in. If the same user logs in again, the display manager starts the window manager anew, and all the applications must be restarted. This is how traditional X Window System desktops work. We refer to such a desktop session as an X desktop. We also say that when a user is using the keyboard and monitor of the workstation, he or she is logging in to the console. This is as opposed to connecting via the network.
In the Linux Journal article titled “Virtual Network Computing” by Choong Ng [available at www.linuxjournal.com ], we learned how to set up VNC in order to allow stateful access to a desktop from any computer on the network. By stateful, I mean that when a user is not connected to the desktop, the desktop does not terminate but remains waiting for a user to reconnect. When the user connects to the VNC server using a VNC client, every window is in the place where it was last left, every application is still in the same state as when last used, and every opened file remains opened in the same position. The nature of the VNC server, which controls the window manager and the applications, permits this.
Therefore, any computer on the network can run a VNC client (such as vncviewer) to connect to the workstation and display the desktop. We even could run the VNC client on the workstation on which the VNC server is running. We refer to such desktop sessions as VNC desktops, and we refer to the workstation where we run the VNC server (and its window manager) as the VNC workstation.
There is one problem with VNC desktops. Suppose you want to log in to the console of the VNC workstation. Your VNC desktop is running on this workstation as well, the same one you connect to from many different computers on the network. You want to continue to have access to the VNC desktop via the network. At the same time, when you log on to the console via a display manager, you want to see the same desktop you see when you connect via VNC. But if you log in to the workstation via the display manager, it will start a new window manager. Basically, you have started a new X desktop, one which is independent of the VNC desktop, already running on this workstation.
If you want to connect to the VNC desktop, you must run a VNC client, such as vncviewer. This is awkward due to the fact that one window of the X-based desktop is itself another desktop (the VNC desktop). Keeping track of the many levels of redirection can be troublesome. Besides being confusing, due to ambiguity as to what desktop the user is actually using, it also is inefficient as it requires two window managers to run concurrently, when only one is needed.
This article explains how to configure an X server, display manager and a VNC server so that the desktop one sees when logging in to the display manager is the VNC desktop, with no second window manager and with all files and applications in the same state as they were last left.
The scheme we discuss can work on any Linux distribution. It requires a working X server, a display manager and VNC. I checked for these packages with this command:
rpm -q XFree86 vnc XFree86-xdm kdebase gdm
It is only necessary to have either XFree86-xdm kdebase or gdm installed. I should note that all the configuration file locations discussed in this article are as shipped with Red Hat 7.1. It is possible to configure any Linux system to allow transparent VNC desktops, but you may have to download software or locate configuration files if they are in different locations.
Whatever display manager you prefer, it should start at boot time. This is usually accomplished with a line in /etc/inittab similar to this:
prefdm is usually a copy of a link to whatever display manager you prefer. X and your preferred display manager must be up and running.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development