Learn more >
Roderick Smith | Updated April 23, 2012 - Published April 24, 2012
Linux® uses the X Window System (X for short) as its graphical user interface (GUI). X is an unusual GUI in several ways, one way being that it’s inherently network enabled. An X server is literally a network server program. Network server programs give client programs access to local resources, and this is true of an X server, as well. The oddity is that the “local resources” in the case of an X server are the display, keyboard, and mouse, which the user uses. In the most common configuration, the X client programs run on the same computer as the server. Thus, LibreOffice, the GNU Image Manipulation Program (GIMP), or other programs are X clients that use X’s network protocols to accept user input and display output for users on the same computer.
When X is used over a network, though, the user sits at the X server computer, and X’s clients are the programs that the user wants to run on another computer. This configuration requires a second network protocol to initiate the connection. This second protocol can be telnet, Secure Shell (SSH), or the X Display Manager Control Protocol (XDMCP). The server for this login protocol runs on the X client computer, and the remote login client runs on the X server computer. The remote login server launches X clients that in turn contact the X server. X remote access requires a client and a server on both computers depicts this relationship. Dashed arrows denote session initiation. (In the case of XDMCP, the XDMCP client is built into the X server program.)
X remote access requires a client and a server on both computers
This type of setup works fine on many local networks, but it has drawbacks. For instance, this configuration requires two-way network protocol initiation, which might not be possible through some firewalls or network address translation (NAT) routers. (SSH can tunnel X sessions, obviating this need.) Furthermore, although X servers are available for most platforms, they’re not routinely installed on computers running Windows®. For these and other reasons, many sites prefer to use another protocol, the Remote Frame Buffer (RFB), which is implemented in the Virtual Network Computing (VNC) family of programs.
VNC is a cross-platform tool that can provide remote access to Linux, UNIX®, Mac OS X, Windows, and other systems from any type of client. With VNC, the user sits at the client computer and accesses a remote server computer. On Linux, the VNC server either mirrors the contents of the local X server’s screen to the remote computer or includes its own X server that can operate independently of the one that manages the local screen. The result resembles A VNC server includes an X server that can communicate with local X client programs. Again, the dashed arrow indicates session initiation. This configuration eliminates the need for the reverse network connection, and because VNC clients and servers exist for so many operating systems, users can employ a single client program to access any server.
A VNC server includes an X server that can communicate with local X client programs
The downside to VNC is that RFB authentication is based on passwords without user names. Thus, each user must launch an independent VNC server session and connect to that VNC instance by specifying the correct port number. This requirement might be tolerable on a single-user system, but is extremely awkward on a multiuser computer.
To work around this issue, you can link the two approaches. You can reconfigure your local XDMCP server to help the X server integrated in VNC provide the missing multiuser authentication (the resulting configuration resembles Adding XDMCP to a VNC configuration provides extra flexibility). The dashed arrow indicates session initiation. Now, when remote VNC users contact the VNC server computer, they’ll be able to enter their user names and passwords to access their own unique VNC sessions, so the computer can handle as many users as you like.
Adding XDMCP to a VNC configuration provides extra flexibility
Several ways to launch VNC exist, including using scripts, linking VNC to your desktop environment using desktop tools, and using xinetd to listen for VNC connections. This last approach is the one described here, because it enables you to launch VNC so it can use your XDMCP server. Before detailing how to configure VNC to launch through xinetd, you must select a VNC server.
Several VNC server programs are available. (Related topics provides pointers to several.) Some of the more popular options include TightVNC, TigerVNC, and RealVNC. This article uses TightVNC as an example. Unfortunately, configuration details vary from one server to another as well as from one distribution to another, so you might need to adjust the instructions provided here for your software.
Many distributions install the xinetd super server by default, but some do not. Because the method described here uses xinetd, you should install xinetd if it’s not already installed. On most distributions, you can install xinetd by using the package system, such as apt-get install xinetd on Debian-based distributions or zypper install xinetd on openSUSE.
apt-get install xinetd
zypper install xinetd
You might also need to configure xinetd to run. You can typically run it on a one-time basis by using its System V (SysV) startup script:
# /etc/init.d/xinetd start
Configuring xinetd to run automatically when the computer boots requires knowledge of the startup script methods for your distribution. Typically, you use a utility such as chkconfig (used in Fedora, openSUSE, and related distributions), update-rc.d (used in Debian and related distributions), or rc-update (used in Gentoo) to do the job, as in:
# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default
Type only one of those commands, or locate an equivalent for your distribution.
Note that xinetd may refuse to start if it doesn’t have any services configured. Thus, you may want to put off launching it until you’ve configured xinetd to manage your VNC server.
Servers that should be managed by xinetd place configuration files in the /etc/xinetd.d directory. Thus, to configure xinetd to handle VNC, you should create or edit a file with a name such as /etc/xinetd.d/vnc. (On some distributions, such as openSUSE, the VNC server package installs such a file.) An example VNC configuration for xinetd provides an example.
An example VNC configuration for xinetd
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
type = UNLISTED
port = 5900
This entry sets several xinetd options, most of which you should leave alone. Those you might want to adjust include the following:
The trickiest part of the xinetd configuration is setting the server arguments. You can use the arguments in An example VNC configuration for xinetd as a model, but you might want to change some of them:
Many other options are available, and some vary from one VNC server to another. Consult the documentation for your VNC server to learn more.
Most Linux distributions configure their XDMCP servers to manage the local display and nothing else. To provide remote access, you must reconfigure your XDMCP server to accept access requests from the VNC server that runs on the same computer. The details vary from one XDMCP server to another. The three in most common use on Linux are the GNOME Display Manager (GDM), the Light Display Manager (LightDM), and the KDE Display Manager (KDM). Other XDMCP servers, such as XDM, require different adjustments than those described here. In any event, after reconfiguring your XDMCP server, you’ll have to restart it.
If you’re not sure which XDMCP server your system uses, you can identify it by searching a process listing for the string dm, as in:
$ ps ax | grep dm
929 ? Ss 0:00 /usr/bin/kdm
962 tty7 Ss+ 0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
30157 pts/3 S+ 0:00 grep --color=auto dm
The first line of this output reveals that KDM is running, so you would have to edit this server’s configuration file to enable VNC to use XDMCP. Most XDMCP programs have configuration files that follow a similar format. They include sections that are identified by section names in brackets, such as [xdmcp]. Lines following the section name set options using an equal sign, as in enable=true. Options to enable XDMCP support for VNC for various XDMCP servers summarizes the configuration file names, section names, and options you must set to enable XDMCP on several common Linux XDMCP servers.
Options to enable XDMCP support for VNC for various XDMCP servers
You might find the XDMCP section in your configuration file, or it might be absent entirely. If present, it might explicitly disable XMDCP support, contain commented-out options, or be empty. Whatever the original state of the file, you want to ensure that the XDMCP section is present and that this support is enabled. As an example, consider a KDM configuration to enable XDMCP:
Some distributions enable extra security measures that you might need to loosen. One of these is a firewall. Firewall scripts tend to be distribution specific, so consult your system’s documentation to learn how to modify your firewall. You should ensure that localhost has access to port 177 and that your VNC clients have access to port 5900 (or whatever other ports that you use for VNC).
OpenSUSE uses an extra configuration file that controls some types of access, including XDMCP access: /etc/sysconfig/displaymanager. Open this file in a text editor and search for the following line:
Change this option to "yes". If it’s left at "no", the login prompt of your XDMCP server is not visible when you connect to the VNC server. This change is not required on most distributions: Only openSUSE uses this file.
With your XDMCP server configured to accept remote logins, you must restart it. On distributions that launch X through a SysV init file, such as Debian and Gentoo, you can pass it the restart option:
# /etc/init.d/gdm restart
If your system uses the runlevel number to start X, such as Fedora and openSUSE, you’ll need to switch to a text-mode runlevel (typically 3), and then back to the GUI runlevel (typically 5):
# telinit 3
# telinit 5
Be aware that either approach shuts down X, so ensure that you have saved all your open work in your X session before proceeding.
At this point, you should be able to log in from a remote computer using a VNC client. For instance, most Linux distributions provide a command called vncviewer; you can type:
. . . to log in to remotename through VNC. The result, when VNC is configured and working correctly, resembles When configured to work with XDMCP, VNC provides a traditional Linux login prompt. If you’ve configured multiple VNC sessions on different ports, you can specify the VNC session number by passing it as part of the hostname, as in:
. . . to log in to session 3 (on port 5903).
When configured to work with XDMCP, VNC provides a traditional Linux login prompt
If you don’t see an XDMCP login screen when you perform this test, you have some debugging to do. Some things to check include:
RFB is not a secure protocol; most VNC clients and servers don’t encrypt their data. (VNC does encrypt its own passwords, but the method described here doesn’t use these passwords.) Be cautious about where and how you deploy VNC. If you want to use VNC over an unsecured network, you have three choices:
Enabling VNC logins as described in this article opens at least two ports (the VNC port and the XDMCP port) to the outside world. You might want to restrict both ports with firewall rules to minimize the risk of abuse. Note that the XDMCP port (UDP port 177) need only be opened to localhost, so its firewall rule can be quite restrictive.
Overall, linking VNC and XDMCP is a useful technique to enable remote GUI logins to multiuser Linux computers. This method has advantages over using XDMCP directly in cross-platform environments or if working around firewall or NAT issues could be a problem. It’s beneficial over more common direct VNC approaches on multiuser computers. If you use this method, be sure to consider the security issues. Be prepared to set up firewall rules to restrict unwanted outside access, and use encryption if your transfers traverse untrusted networks.
The IBM Developer podcast is the place where developers hear all about open topics and technologies.
July 22, 2019
This article introduces the nest hardware Performance monitoring counters and its Linux perf interface in a PowerVM partition. The article…
IBM Power SystemsLinux+
Back to top