Using an XDMCP Server

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 Configuration

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:

 DisplayManager.requestPort: 0 

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 

NOTE

It's possible to configure a computer to not accept XDMCP connections through means other than the XDM configuration files. For instance, a computer's firewall rules (described in Chapter 25, Configuring iptables) could block access to a server.

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:

 term.threeroomco.com:0 foreign 

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.

NOTE

You do not need to tell XDM to manage a display if you can configure that server to locate XDMCP servers, as described in the upcoming section, "Configuring a Remote X Login Client." You should tell XDM to manage a display only if the X server in question should be used only to connect to the computer on which XDM is running. You might use this approach with an X terminal that connects to just one computer, for instance.

KDM Configuration

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 Configuration

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:

 0=/usr/bin/X11/X 

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:

 id:5:initdefault: 

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.

TIP

If you make changes to your XDMCP server's configuration, one way to implement those changes is to use telinit to switch out of the X runlevel and into a text-mode runlevel, then switch back to the X- related runlevel. Another method is to use kill or killall to stop the XDMCP server, then run it again. You can use the SIGHUP signal to cause the XDMCP server to reread its configuration files without exiting. (When the XDMCP server exits, it normally terminates the local X display.)

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:

• prefdm ” Some distributions, such as Red Hat and Mandrake, use a script called prefdm (usually stored in /etc/X11 ) to launch the XDMCP server. This script in turn loads the contents of the file called /etc/sysconfig/desktop to determine the default desktop environment and XDMCP server. Common values of this file include KDE , GNOME , and AnotherLevel , which result in KDM, GDM, and XDM as the XDMCP servers, respectively.

• SysV startup script ” Debian and its derivatives start the XDMCP server through a standard SysV startup script, such as /etc/init.d/ xdm . You can edit or replace this file to have the system use a different XDMCP server, as described in Chapter 4, Starting Servers. SuSE Linux uses a similar method, but its xdm startup script starts a specific XDMCP server according to the value of the DISPLAYMANAGER environment variable, which is set in /etc/rc.config .

• Other startup scripts ” Slackware uses the /etc/rc.d/rc.4 script to start the XDMCP server. As described in Chapter 4, Slackware doesn't use runlevels in quite the same way as most other Linux distributions, but the rc.4 script is conceptually similar to the xdm SysV startup script of Debian or SuSE. Caldera uses a similar approach, but calls its startup script /etc/rc.d/rc.gui . The Slackware script is hard-coded to try to use KDM, then GDM, then XDM; the Caldera script only starts KDM. You can edit the script to change this order or add other XDMCP servers, if you like.

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:

• Do Not Use XDM (Passive) ” This method requires that you initiate a manual connection from the X server computer using Telnet or some other login technique, or that you configure the XDMCP server to manage the X server's display (as for instance by creating a foreign entry in the /etc/X11/xdm/Xservers file, as described earlier). If you elect the latter option, the XDMCP server will try to create a login window on the X server computer when the XDMCP server starts. If you restart the X server, though, this login window will disappear and may not reappear until you restart the XDMCP server.

• XDM Query ” This option causes the X server to send a login query directly to the specified host, whose name or IP address you must enter. This server presents an XDMCP login display such as that shown in Figure 14.2 if it's running an XDMCP server. You can't log directly into another computer if you use this option. This option is similar to the preceding one in many ways, but XDM Query causes the X server to query the XDMCP server whenever the X server starts up, which is usually a more sensible behavior than having the XDMCP server manage the X server.

• XDM Broadcast ” If you're on a local network with several X servers, this option may be the best one. It causes the X server to send out a broadcast query to locate all the XDMCP servers on its local network, and to display a list of the servers, as shown in Figure 14.3. Some servers let you limit the broadcast to just some addresses (the Register Hosts to Search button in Figure 14.4 lets you do this).

• XDM Indirect ” This option is useful if you want to allow users to log into any of several computers that are on a remote network. Enter the name or IP address of an XDMCP server on that network, and the X server connects to this system to obtain a list of servers. The XDMCP server must be configured to accept indirect queries, though, as described in the preceding sections.

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.

TIP

If you want to configure a Linux computer as a dedicated X terminal, you can do so. You should configure it so that X does not start automatically via the XDMCP server ”that is, run Linux in text mode. You can then create a custom startup script or SysV startup script that runs X with an appropriate -query , -broadcast , or -indirect option. If you want to see a list of available local servers, you'll need to configure one regular XDMCP server as an indirect server and use the -indirect option when starting X. Used in this way, even an old 386 system can make an adequate X terminal.