Assuming there are no obstructing firewalls or other obstacles, any system running an X server may be used as a display for any computer that can run X applications. Sometimes this isn't quite enough, though; sometimes you want your X server to work just like a local X server would, displaying a desktop environment that's controlled by the remote system. The login procedure that uses Telnet, SSH, or other remote-access protocols can also be a bit on the tedious side, particularly when you want to give complete control to the remote system. These issues are both addressed by entirely X-based login protocols, such as the X Display Manager Control Protocol (XDMCP). Most Linux systems come with the software that's necessary to use XDMCP as a server (on the X client side), but most configurations restrict access to the XDMCP server to the local system. Reconfiguring the server allows it to serve many XDMCP clients (X servers). It's possible to use a Linux system as an XDMCP client, but this requires modifying the X configuration to use XDMCP to present a login display that's generated remotely rather than locally.
Understanding XDMCP Operation
Preceding sections of this chapter have presented a model of remote X use that involves using a remote login protocol such as Telnet, running the Telnet server on the X client in order to establish the initial connection and allowing the user to establish a reciprocal X connection. XDMCP effectively replaces Telnet, SSH, or some other text-based remote access protocol. When a user connects to a remote system with Telnet, the Telnet server launches a login process and, ultimately, a text-based shell. The textual data from these processes pass back over the Telnet session to the client system. XDMCP is similar in some ways, but instead of launching a text-based shell, the XDMCP server initiates an X-based login process, including a GUI login prompt and the launching of the user's normal window manager, desktop environment, and so on. These programs run through a reciprocal X connection; XDMCP automatically configures both the client and the server via xauth , and sets the DISPLAY environment variable appropriately. In short, XDMCP automates many of the login steps described earlier.
In fact, the XDMCP server isn't used only for remote X connections; it's used by Linux computers that are configured to boot directly into X. When so configured, the XDMCP server runs and connects directly to the X server, creating a GUI login prompt such as the one shown in Figure 14.2. Because the XDMCP server creates this prompt, it differs from one server to another; in fact, it can be customized, and so varies from one distribution to another.
Figure 14.2. An XDMCP server's login prompt lets you enter your username, password, and sometimes additional information, such as the desktop environment or window manager you want to use.
Configuring a Login Server to Accept Connections
XDMCP servers are configured through files that are typically stored in the /etc directory tree, and usually in /etc/X11 . Most distributions ship in such a way that their servers are only accessible from the localhost as a security precaution. If you want to permit remote XDMCP logins, you must loosen this configuration. In addition, you must ensure that the XDMCP server is running. There are three XDMCP servers commonly used in Linux: The original X Display Manager (XDM) and the newer KDE Display Manager (KDM) and GNOME Display Manager (GDM).
XDM is the oldest and simplest of the popular XDMCP servers. Unlike GDM and KDM, XDM has no link to any Linux desktop environment. It allows users to enter their usernames and passwords, but no additional information, such as what window managers they want to use. Instead, users' login parameters are controlled through the .xsession files in their home directories. (This script is run from the global Xsession script, normally found in /etc/X11 or /etc/X11/xdm ). Users' .xsession files normally end with a line that starts a window manager or desktop environment; when the script terminates (after the user logs out, thus terminating the window manager), the X session ends, and XDM terminates the remote link or (on a local display) redisplays the login prompt.
Adjusting XDM's Availability
XDM's availability to nonlocal systems is controlled through its main configuration file, /etc/X11/xdm/xdm-config . Specifically , many distributions ship with a line like the following:
This line tells XDM not to listen on its usual port (UDP port 177) for external connection requests . You should comment out this line by adding a pound sign ( # ) to its start if you want to allow others to use XDMCP to log onto the computer.
In addition to editing xdm-config , you may need to adjust the /etc/X11/xdm/Xaccess file. This file indicates the specific computers that may access the XDM server. This file consists of a series of lines, each of which contains a host specification followed by an indication of what type of access the host is allowed. (Lines that begin with pound signs are comments, and are ignored.) If the access type is not specified, the clients are permitted direct access, which is the most important type. Other common options include CHOOSER , which causes XDM to display a list of other computers that have XDMCP servers running on the local network when the XDMCP client sends a so-called indirect query; and BROADCAST , which is generally used in conjunction with CHOOSER to tell the chooser to broadcast a query for other XDMCP servers when the system receives an indirect request. An asterisk ( * ) as the host list causes XDM to allow any host to connect. For instance, the following entries allow any computers to connect to the system directly or use it as an indirect server, to obtain a list of local XDMCP servers:
* * CHOOSER BROADCAST
If you want to restrict access to certain hosts, you should create lines that list those hosts , and eliminate the asterisk entry. You may also use an asterisk as part of a name to grant access to a domain. For instance, the following system allows only the members of one domain and two outside computers to connect to the XDMCP server for remote logins, and only the outside systems for indirect queries:
*.threeroomco.com bronto.pangaea.edu stego.pangaea.edu bronto.pangaea.edu CHOOSER BROADCAST stego.pangaea.edu CHOOSER BROADCAST
Setting Displays XDM is to Manage
The /etc/X11/xdm/Xservers file specifies a list of displays that XDM is to manage. When XDM starts, it tries to connect directly to these displays, presenting a login screen for them. By default, this file contains a line similar to the following (the details differ from one distribution to another):
:0 local /usr/X11R6/bin/X
This line tells the system to connect to and manage the local display ( :0 ). Thus, XDM manages the local X display, starting X in the process if necessary. (This is the reason that starting XDM in a SysV startup script or the like launches X.) If you want XDM to directly manage the displays of remote systems such as X servers without using an intervening login prompt, you can list those systems here:
The foreign specification tells XDM that this is a remote system, and to contact it as such. Of course, that system must be configured to allow the XDMCP server to connect to it and display the login prompt. Another reason to edit the Xservers file is to remove the default local specification. If you do this, the computer won't launch X locally when you start XDM. This might be useful if you want to use a powerful central system via remote X terminals or the like. Such a system might run many X programs, but have no need of an X server running locally.
KDM is designed as a "drop-in" replacement for XDM, but KDM offers expanded capabilities. Of most interest to most users, KDM offers a clickable list of usernames, a Session Type list box in which users may enter a window manager or desktop environment, and a Quit or Shutdown button to exit from the local X server (when run remotely) or shut down the computer (when run locally). Figure 14.2 shows a KDM login display.
KDM uses the same configuration files as does XDM, so you should refer to the preceding section, "XDM Configuration," for instructions on setting up KDM to accept remote logins. Some of KDM's additional features require configuration above and beyond that of XDM, though. These features are controlled through the kdmrc file, which is stored in different locations on different distributions. Common locations include /opt/kde2/share/config and /usr/share/config . Options in this file control the size of the login window, the GUI style, and so on. One of the most important of these options is called SessionTypes . It determines the names of the session types displayed for users ”that is, the window managers or desktop environments from which they can select. If you add session types to this list, you must also add them to the Xsession or Xsession.d file in /etc/X11 or /etc/X11/xdm . Unfortunately, deciphering this file is tedious at best, and it differs from one distribution to another. Look for lines that use the variable SESSION or something similar. Some distributions ship with a tool called chksession , which can automatically add window managers or desktop environments to both KDM and GDM configurations ” if the window manager or desktop environment ships with appropriate configuration files. In most cases, it's simpler for users to customize their environments as they do in XDM, by editing the .xsession files in their home directories. Users must select a specific KDM session entry, usually called Default, to have the system use this file.
GDM is GNOME's entry to the display manager race. Like KDM, it offers users features such as the ability to select from among several desktop environments and the ability to terminate a remote X session or shut down the local computer. Unlike KDM, GDM uses its own configuration files, which are normally stored in /etc/X11/gdm . The most important of these files is gdm.conf .
Systems that use GDM, like those that use most other XDMCP servers, ship with the server configured to not accept logins from remote servers. You can change this by locating the [xdmcp] section in gdm.conf and altering one or two entries. Most importantly, you should change the line that reads Enable=0 to read Enable=1 . If you want GDM to provide a list of other XDMCP-enabled computers to X terminals or the like, you should also change the HonorIndirect=0 line to read HonorIndirect=1 .
If you want to run GDM for remote access without starting X locally, you can do so by commenting out the local servers in the [servers] section. Normally, this section contains an entry like the following:
This entry tells GDM to start X (the program /usr/bin/X11/X , to be precise) to manage the first X session, much like the default Xservers configuration for XDM or KDM. Commenting out this entry causes GDM to run without managing the local display, or starting X if it's not already running.
Like KDM, GDM gives users a choice of window managers or desktop environments. (In GDM, these choices are accessible from the Session menu.) You can add or delete sessions by creating appropriate scripts in the /etc/X11/gdm/Sessions directory. The default scripts usually call /etc/X11/xdm/Xsession , sometimes passing it a parameter to indicate what environment should be launched. You might therefore have to edit this script, or create one that does some of the same job, but add the capability to launch whatever new window manager or desktop environment you want to use. Alternatively, on most systems, users can edit their .xsession files to customize their startup environments.
Running an XDMCP Server
Running an XDMCP server is normally accomplished by setting the computer to start X and accept GUI logins automatically. Most distributions reserve runlevel 5 for this purpose, but some use other runlevels ”specifically, SuSE prior to version 7.2 uses runlevel 3 for GUI logins, and Slackware uses runlevel 4. Debian and its derivatives try to start X in all multi-user runlevels.
You can set the default runlevel in /etc/inittab by editing a line that resembles the following:
Most distributions include comments preceding this line that describe the purpose of various runlevels. The number in the second colon -delimited field is the runlevel that the system enters when it boots. If this number is associated with the computer starting X, then the XDMCP server will also run.
You can change runlevels with the telinit command. For instance, telinit 5 changes to runlevel 5. This change remains in effect until you issue another telinit command or reboot the computer.
Each distribution has its default XDMCP server, but you can reconfigure any distribution to use any XDMCP server. Different distributions use different methods to specify which XDMCP server is run. Methods of selecting the XDMCP server include the following:
Configuring a Remote X Login Client
As with other protocols, an XDMCP server alone isn't useful; it must be matched with one or more XDMCP clients. These clients are normally built into or included with X servers or X terminals. The XDMCP client may contact an XDMCP server directly, or it may present a list of available X servers, as shown in Figure 14.3, which shows the chooser for the Xmanager (http://www.netsarang.com) X server for Windows. When you select a computer and click Connect (or your chooser's equivalent), you'll see an XDMCP login display such as the one shown in Figure 14.2. When you log in, the X server will either take over your entire display or open a large window in which your X desktop will appear, depending upon the X server's capabilities and configuration.
Figure 14.3. A chooser displays a list of available XDMCP servers; you select one to run X programs hosted on that computer.
Most X servers for Windows and MacOS provide a dialog box in which you can configure their XDMCP operation. Figure 14.4 shows this dialog box for Xmanager. Of particular interest are the radio buttons in the top half of the dialog box. These may be called slightly different things in different programs, but they illustrate methods the XDMCP client that's built into the X server may use to create the initial connection to the XDMCP server:
Figure 14.4. Most XDMCP clients provide several options for how to locate and interact with XDMCP servers.
Windows X servers aren't the only ones that can present a list of available XDMCP servers. You can have XFree86 on Linux do the same thing, although in this case you tell it to do so by starting X in different ways. Specifically, you use the -query host.name , -broadcast , and -indirect host.name options, as in:
$ /usr/X11R6/bin/X -indirect xdmcp-server.threeroomco.com
These options work much like those in Windows X servers, as just described, with one major exception: The XFree86 -broadcast option doesn't present a chooser list; it connects to the first XDMCP server that responds to the query, allowing you to log into that computer only.