XDM and X Terminal mini-HOWTO

Kevin Taylor

      kevin@northants.lug.org.uk
     

Revision History
Revision v1.002002-05-16Revised by: KT
Minor updates to all sections. Added details of Windows/Linux interoperability. Added section on starting XDM. Added details of KDM and GDM. Added new software resources.
Revision v0.0514 November 2000Revised by: KT
Added cross-references to other Howtos
Revision v0.046 November 2000Revised by: KT
Updates after first public draft.
Revision v0.033 July 2000Revised by: KT
Minor updates from first comments
Revision v0.0228 June 2000Revised by: KT
First SGML source draft from HTML source
Revision v0.0127 June 2000Revised by: KT
First HTML source draft

Table of Contents
1. Introduction
1.1. Copyright Information
1.2. Disclaimer
1.3. New Versions
1.4. Credits
1.5. Feedback
1.6. To do
2. Basic Concepts
2.1. What is covered
2.2. About this document
3. XDM
3.1. What is XDM
3.2. What is an X terminal
3.3. Some Terminology
3.4. What can XDM do
4. Configuring XDM
4.1. Configuration Files
4.2. Configuring XDM to Manage X Servers
4.3. Configuring XDM to Receive Queries
4.4. Starting X
4.5. Starting XDM
4.6. The Chooser Application
4.7. Alternatives to XDM
5. Advanced Configuration Options
5.1. Configuration Sets
5.2. X Resources
6. Common Configurations
6.1. Linux to Linux
6.2. Linux to Other Systems
6.3. Other Systems to Linux
7. Resources

1. Introduction


2. Basic Concepts


2.1. What is covered

This document describes the basic concepts behind using XDM (the X Display Manager) to manage X terminals and X servers, in order to provide 'thin-client' computing, using Linux.

X (or the 'X Window System') is the windowing and graphics environment of choice for Unix systems. Its particular strength (and the key bit that we are interested in for this document) is that it separates the running applications (web browser, word processor, etc) from the actual graphics screen and input devices (mouse, keyboard, etc) via a network communications mechanism.

Essentially, this means that you can be running an application on one machine, but have its input and output redirected to another machine via a network. This is the key feature that makes an X terminal possible.

This document should be treated as a 'getting started with XDM' document, in that it describes the basic terms and concepts for using XDM and X terminals, with simple examples that provide the minimum amount of security.

The reader is advised to consult the list of resources provided at the end of the document in order to proceed beyond these basic facilities - in particular, the configuration of the 'authentication' and security settings should be examined, as the examples given in this document utilise the least secure modes of operation.

Please note - the majority of the information in this document was obtained from systems running Debian 2.1, SuSE 6.4, Mandrake 7.0 and RedHat 6.0.

This document does not discuss the installation or configuration of a network or X on Linux. Please refer to the appropriate HOWTO documents from the Linux Documentation Project for details (see Section 7).

This document also does not attempt to describe how to install and configure Linux for operation as an X terminal. For this information, please refer to the 'thin-client' HOWTO document, provided as part of the Linux Documentation Project, or the Linux Terminal Server Project (see Section 7).


3. XDM


3.1. What is XDM

Put simply, XDM (the X Display Manager) can be thought of as a graphical replacement for the command line 'login' prompt. In reality, it can actually do much more than that.

Typically, it would be started by the 'root' user (or the system startup scripts) on power up, and would present a user with a graphical login prompt. It will then manage the users X session once they login - i.e. it will initiate the running of their window manager and applications.

This could be considered a typical 'simple local machine login' configuration, as may be found installed by many Linux distributions by default. However, XDM can also manage remote X servers and provide login prompts to remote 'X terminals'. In short, it is not limited to the local machine - it can easily manage other machines connected via a network.

XDM is a very configurable utility and this document will only just 'scratch the surface' of what may be achieved. This document aims to provide enough information to configure your X terminals and application servers to connect to each other. The reader is referred to Section 7 for further information on the topics discussed here.

A note on security: X (in its default configuration) and XDMCP are not particularly secure. I am assuming that you are running X on a 'trusted' network and that security is not an issue. For details of how to tighten up your X connections (and more details about using the networking capabilities of X) please refer to the 'Running Remote X Applications' Howto document, which is also part of the LDP (see Section 7).


3.3. Some Terminology

Before I go any further, I ought to explain the terms I will be using in this document. When talking about X, there is quite a lot of confusion over what is serving facilities to what. This is especially true when you are considering distributed sessions over a network involving X terminals. I will be using the terms described below.

Diskless X terminal

This would be a machine with no local disks, that would perform its boot up from an EPROM (or similar) and utilises a network connection to a server. It would obtain its network configuration, operating system, system configuration and all applications from the server. Once booted however, this would be the same as a 'dumb X terminal' (see below). Typically this configuration would use a combination of the following network protocols in order to boot: BOOTP, DHCP, TFTP, etc. Refer to Section 7 for some references that detail how to build diskless X terminals.

Dumb X terminal

This would be a machine that boots from its local disk into an operating system, and starts the 'X server' program and nothing more. Somehow, a login prompt would be provided on the machine, to enable a user to login to an 'application server' somewhere on the network.

X Workstation

This would be similar to a dumb X terminal, but would provide the option of logging on to the local machine itself, hence would be quite capable of becoming a standalone workstation (i.e. no network connectivity) if required. Most distributions can be configured 'out of the box' as a stand-alone X Workstation, with a graphical login prompt.

Application Server

In the context of this document, I use the term 'application server' to describe a machine that will provide the applications (X clients) that our X terminal will want to run. This can include everything from editors and browsers, through to the actual 'Window Manager' itself.

X Server

This is the program that manages the display of a machine with a physical console (display, keyboard, mouse, etc). It can be thought of as a combined graphics card, keyboard and mouse 'driver'. This will provide these facilities as a service to X clients (hence the term 'server'). Please refer to the X User Howto in Section 7 for more details.

X Client

This is an application that requires the use of an X server to access input (keyboard and mouse) and output (display). An X client cannot produce output without the services of the X server. The X server could be running locally (on the same machine, as is the case with an X workstation) or elsewhere on the network (as is the case with an X terminal connecting to an Application Server).

From the above descriptions, an X Workstation could be thought of as consisting of a dumb X terminal and application server running on the same machine.

This document will be looking at the architecture of the various options listed above and will describe the role that XDM can play in configuring them.


3.4. What can XDM do

XDM is responsible for providing the user with a login prompt and initiating their X session. It can manage local sessions (i.e. people logging into an X workstation) or sessions on remote machines, via a connection to an application server, from a diskless or dumb X terminal.

XDM would typically run on an application server, to permit users to logon and run applications from that server.

There are 2 main ways that XDM can interact with an X Server:


4. Configuring XDM

This section covers what needs to be configured for XDM to perform the functions described so far in this document.

In each case, the configuration described is the minimum necessary to accomplish each goal. In most cases this means that the configuration is also the least secure. Please refer to some of the additional documentation listed in Section 7 for information about securing XDM and X terminals (in particular the 'Running Remote X Applications Howto' from the LDP).


4.1. Configuration Files

This describes the following scheme of XDM configuration files:

These must be setup for the machine actually running XDM itself. They will typically be found in (Debian 2.1. Mandrake 7.0.2, RedHat 6.2):
      /etc/X11/xdm
      
or (SuSE 6.4):
      /usr/X11R6/lib/X11/xdm
      

xdm-config

Defines the names and locations of the other configuration files and the basic access permissions. For all distributions considered for this document, the file names were as listed here (but sometimes the locations varied).

This also defines the scripts to be run for the various state transitions for an X session, i.e. on startup, etc. You should not need to change these, as most distributions would appear to come with this pre-configured for you.

Note that XDM managed X sessions have a different set of startup and configuration scripts to X sessions started via xinit or startx (i.e. non-XDM managed X sessions).

Some distributions (e.g. Redhat 7.1) include the following line in this configuration file, which will prevent XDM from listening for queries:
        DisplayManager.requestPort: 0
        
This must be commented out as follows:
        !DisplayManager.requestPort: 0
        

Xaccess

Determines which machines can connect to XDM - i.e. from which other machines on the network we are accepting XDMCP queries. If a machine is not listed in this file, then it will not be able to request a login prompt from XDM.

Xservers

Contains a list of machines that XDM will connect to, to provide a login prompt, automatically - i.e. those machines already running an X server, but would like this machine to provide the login prompt.

This is only required for 'XDM Managed X Servers'. You do not need any entries in this file if you will be relying on remote X servers to query XDM.

When running as a stand-alone 'X Workstation', there is usually a single entry in this file, listing just the localhost.

Xresources

Details of the X properties used by the XDM widgets (e.g. size of the login 'box', colours, bitmap backgrounds, etc).


4.4. Starting X

The way you start the X server itself, will depend upon how you want it to interact with XDM locally and remotely.

In each case, X will probably have to be started as root.

It is possible to have a machine automatically start X and perform a query for a running XDM on the network. One way is to 'hijack' the inittab setting for running as a graphical login (this is runlevel 5 on Debian and Redhat based systems, and 3 for SuSE - this example assumes runlevel 5 throughout). This is often the line beginning x:5 towards the end of /etc/inittab. Set this to (or add it if it doesn't exist):
    x:5:respawn:/usr/X11R6/bin/X -broadcast
    
Replacing -broadcast with -direct or -indirect, etc. as required. You may have to change your default runlevel to be 5 too, (and then reboot), as follows:
    id:5:initdefault:
    


4.5. Starting XDM

In a standard X workstation configuration, XDM would typically be started up by specifying the default initial run-level to be that corresponding to a full graphical login. On Redhat and Debian based systems this is usually runlevel 5. On SuSE it is run-level 3.

It is possible to run XDM automatically on startup by changing the default runlevel to that described above. This is configured in /etc/inittab as follows:
    id:5:initdefault:
    

Alternatively it is possible to add a startup script for XDM itself to the rc scripts in the startup directories (/etc/rc.d/ for Redhat/Debian), to start and stop XDM in a similar manner to other services on a Linux machine.

The following script is suitable for a Redhat (and probably Mandrake) based system, and should be saved as /etc/rc.d/init.d/xdm. You will have to enable it using 'chkconfig --add xdm'.
    #!/bin/sh
    # xdm start/stop script for RedHat based systems
    #
    # chkconfig: 234 60 60
    # description: xdm permits remote users to logon to this X display
    # processname: /usr/X11R6/bin/xdm
    # config: /etc/X11/xdm/xdm-config

    # source function library
    . /etc/rc.d/init.d/functions

    [ -x /usr/X11R6/bin/xdm ] || exit 0

    prog=/usr/X11R6/bin/xdm

    RETVAL=0

    start () {
    	echo -n $"Starting $prog: "
        # start daemon
        daemon $prog
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch /var/lock/subsys/xdm
        return $RETVAL
    }

    stop () {
    	echo -n $"Stopping $prog: "
        killproc $prog
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f /var/lock/subsys/xdm
        return $RETVAL
    }

    restart () {
    	stop
        start
        RETVAL=$?
        return $RETVAL
    }

    # See how we were called.
    case "$1" in
    	 start)
        start
        ;;
         stop)
        stop
        ;;
         status)
        status $prog
        RETVAL=$?
        ;;
         restart)
        restart
        ;;
         condrestart)
        # only restart if it is already running
        [ -f /var/lock/subsys/xdm ] && restart || :
        ;;
         reload)
        echo -n $"Reloading $prog: "
        killproc $prog -HUP
        RETVAL=$?
        echo
        ;;
         *)
             echo $"Usage: $0 (start|stop|restart|condrestart|reload|status)"
             RETVAL=1
    esac

    exit $RETVAL
    


4.6. The Chooser Application

When XDM receives an indirect query, and assuming that the appropriate options have been specified in Xaccess for the 'chooser' application, it can provide the user with a list of other XDM managed servers that it knows about.

In this mode of operation, instead of the normal XDM login prompt, the user will be presented with a 'chooser' application, which will provide a list of detected hosts on the network that are currently accepting XDM connections.

When I first tried the use the chooser, I found that the Xresources files that came with my SuSE and Debian systems, specified a size for the chooser widget that was too big for the screens ... The following line from the Xresources file fixed that:
      Chooser*geometry:      700x500+300+200
      

The chooser will obtain its lists of hosts by one of two methods:

Not that it is possible to include the localhost in the list of machines known to the chooser as well. XDM should be configured not to startup on the local console display though. Login should always be performed via an indirect query to the local chooser application, then the localhost should appear alongside any other hosts on the network.


5. Advanced Configuration Options


5.1. Configuration Sets

The xdm-config file provides a rich set of options, when it comes to defined scripts and other configuration files. In many cases, the defaults provided with your distribution should be fine, but for those of you who want more ...

The names of the startup scripts and configuration files used by XDM are determined by a series of statements in the top-level xdm-config file. This permits you to configure a different set of files for different X servers and X terminals, with different abilities.

For example, say you are using XDM to manage your local display, but also want it to accept queries from other X terminals on the network. It is possible to specify a different Xresources file for each of these cases, by using the following 2 lines in xdm-config:
      DisplayManager._0.resources            /etc/X11/xdm/Xres_0
      DisplayManager*resources               /etc/X11/xdm/Xresources
      
This will use Xres_0 for the local display (_0 is the XDM way of saying :0) and Xresources for everything else (the '*').

Similarly, if you wanted a particular resource file for a specific host, you would use an entry like the following:
      DisplayManager.host_0.resources       /etc/X11/xdm/Xres_host_0
      

Note that XDM configuration files use the terminology host_0, where you would normally use host:0, to designate 'display 0 on host'.

If you look over your default xdm-config file, you will probably find that it has been setup so that your local X server has different files to the remote ones anyway, as different things must be performed on startup and reset of the server. My Debian file has the following for local servers:
      DisplayManager._0.resources:    /etc/X11/xdm/Xresources_0
      DisplayManager._0.setup:        /etc/X11/xdm/Xsetup_0
      DisplayManager._0.startup:      /etc/X11/xdm/Xstartup_0
      DisplayManager._0.reset:        /etc/X11/xdm/Xreset_0
      
and the following for remote servers:
      DisplayManager*resources:       /etc/X11/xdm/Xresources
      DisplayManager*setup:           /etc/X11/xdm/Xsetup
      DisplayManager*startup:         /etc/X11/xdm/Xstartup
      DisplayManager*reset:           /etc/X11/xdm/Xreset
      


6. Common Configurations


6.2. Linux to Other Systems

It is possible to use a Linux X terminal to connect to another system running XDM. The same principles as above apply, but the specifics of configuring XDM (or its equivalent) will be specific to that system.


6.2.2. Linux and Windows

It is not possible to use X to remotely display Windows applications on a Windows box. It is possible to use X to display Windows versions of X applications on a Linux box, using a Windows X Server and Windows X applications (for example the XFree86 Win32 port - see Section 7)

It is possible to view Windows applications remotely on a Linux box using one of the following applications (which don't rely on X or XDM):

  • Windows Terminal Services (WTS). RDesktop is a Linux application that understands the 'RDP' protocol used by WTS. This enables Linux to act as a client to WTS (see Section 7).

  • Vitual Network Computing (VNC). This is an excellent platform independent remote desktop system that provides a bi-directional 'Windows or Linux' to 'Windows or Linux' networked desktop. It can be a bit slow, but works well (see Section 7).

    You can actually do quite strange things with VNC, such has having multiple machines connect and 'control' the desktop (and consequently 'fight' over control of the mouse :). It also doesn't maintain any state in the client, so you can leave your client, shutdown, bootup again, reconnect and carry on from where you left off. There is even a version of the viewer implemented as a Java applet, usable from any Java-enabled web browser.


7. Resources

This section lists some resources that have been consulted in order to construct this document and which provide further details to the concepts described.

Many of the references listed below form part of the Linux Documentation Project (LDP): http://www.tldp.org/

The X Window System

  • X User Howto (from the LDP)

  • Running Remote X Applications Mini Howto (from the LDP)

  • Man pages: X (main concepts), Xserver (X server concepts)

  • X FAQ (on http://www.x.org/)

Thin-clients/X terminals

XDM, XDMCP, etc

  • Man pages: xdm

  • XDMCP Howto Document (from the LDP)

Software