Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Save the Children

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 69 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here



Current HOWTO: Remote X Apps mini-HOWTO

Remote X Apps mini-HOWTO: Setting Up an X Terminal Next Previous Contents

9. Setting Up an X Terminal

Make use of your old PC! Turn it into an extra work place! No need for buying expensive new hardware! You've already got all it takes!

Seriously, you can set up an old PC as an X terminal. An X terminal is a computer that basically runs nothing but an X server. You can log in on it, and get an X session, with xterms, xbiff, xclock, every other conceivable X client. However, all clients are running on a remote host, and are using remote X to display their output on your local X terminal. Even the window manager is running remotely.

An X terminal takes very few resources, compared to a full blown unix machine. Over here I have an X terminal with a 486 CPU, 16M of RAM, and 250M of disk space. Oh, and a network connection, of course. It doesn't even have user home directories.

For some related reading, have a look at:

Contrasted to the above documents, this document (the Remote X Apps mini-HOWTO) limits itself to a short description of XDMCP, but puts more emphasis on the security issues involved.

9.1 Once More, a Little Theory First

As far as X is concerned, the X terminal will be running nothing but an X server. This X server will be configured to talk to a remote host using XDMCP (the X Display Manager Control Protocol). It will ask the remote host for an X session. The remote host will put up a login window on the X terminal, and after login it will run an X session with all bells and whistles, including the window manager, all using remote X to display on the X terminal.

You will probably notice that the remote host is acting like a server, though not an X server. The remote host is providing X sessions to X servers that ask for one. So, with respect to XDMCP, the remote host is actually a server, providing X sessions, also known as an XDMCP server. The X server is playing the role of an XDMCP client! Are you still with me?

The program that provides the XDMCP service on the XDMCP server is xdm. So, in order to get an X terminal up and running, you must configure two programs: X (the XDMCP client) on the X terminal, and xdm (the XDMCP server) on the remote host.

You must always remember that the X protocol (and the XDMCP protocol) are not encrypted. If you use remote X, everything that goes over the network can be sniffed by other hosts on the network. This is especially bad with remote X sessions, since the first thing that happens is logging in by giving a username and password. So, you must run remote X over a trusted network only!

9.2 Configuring X as an XDMCP Client

If you want to set up a Linux machine as an X terminal, you need very few resources. Basically, you need what it takes to get a bare bones Linux machine running, plus an X server. Specifically, you do not need the X clients and libraries. It can be useful to install some X fonts, but you can also use a font server somewhere on the network.

There are a few ways for an X server to get an X session from an XDMCP server. The simplest one is to go straight to a known XDMCP server and ask for one. Alternatively, the X server can broadcast a request for an XDMCP service and use the first XDMCP server that responds. Lastly, the X server can go to an XDMCP server, ask it for a list of hosts willing to provide a session, and let the user choose a session host.

  1. When you know the host that is going to provide you with sessions, go straight to it. Run
    X -query sessionhost
    and, assuming xdm is running on sessionhost, you'll get a login window, and after login, an X session.
  2. When you don't really care on which host you're getting your session, use the broadcast method. Run
    X -broadcast
    and, assuming xdm is running somewhere on the network, you'll get a login window from the first (and hopefully quickest) xdm that responds, and after login, an X session.
  3. When you want to choose the host where you want to have your session, ask an XDMCP server for a list. Run
    X -indirect xdmcpserver
    and, assuming xdm is configured right there, you'll be presented a list of hosts to choose from. Choose one; you'll get the login window for that host, and after login, the session you were looking for.

You may have noticed the absence of the -auth option. The X server will use XDMCP to negotiate a magic cookie with the XDMCP server. The XDMCP server will put the cookie in your remote ~/.Xauthority after login.

After a session is over, the X server will loop and go back to the original XDMCP server and ask for another session (or chooser list). If you don't want that, you can use the -once option. Note: this doesn't seem to work with the -indirect option due to the implementation of the chooser.

When you have determined the way in which you want to run the X server, you can also put it in a startup script, or even run it straight from /etc/inittab. Please consult your own distribution's documentation for how to modify your startup scripts or /etc/inittab.

Do not run an X server like this from the Xservers configuration file. xdm expects to be able to connect to such servers, and may kill them if it can't connect.

9.3 Configuring xdm as an XDMCP Server

The program that provides the XDMCP service (the session service) is usually xdm. There are variants of this such as wdm or gdm on Linux, but these basically work the same way. So, make sure xdm or variant is installed on the host where you want to run your X sessions. If you've got a local graphical login on the X session host, xdm is already installed; most Linux distributions come that way these days.

In addition to xdm, you will need the programs that you wish to be able to run in an X session. That is, all X clients like xterm, xfig, xclock, window managers and all that. However, for an XDMCP server, you do not have to install an X server; the X server will be running on the X terminal instead.

From the X server story above, you can conclude that there are basically two kinds of XDMCP service. There is the direct service, consisting of letting an XDMCP client log in, and then providing it with an X session. Alternatively, there is the indirect service, in which an XDMCP client is provided with a list of hosts, providing a direct service, to choose from.

All xdm services are configured in the access file, generally located at /etc/X11/xdm/Xaccess or a similar location. This location is actually defined in the general xdm configuration file /etc/X11/xdm/xdm-config, through the accessFile resource. See your xdm manual for the default location.

  1. If you want to allow xdm to provide connecting XDMCP clients with an X session, whether by broadcast or not, you put the host name of the XDMCP client (the X server, remember?) by itself on a line in Xaccess. Actually, you can put a pattern on the line matching multiple hosts. Here are some valid patterns:

    xterm023.my.domain      # xterm023.my.domain can get an X session
    *.my.domain             # any host in my.domain can get an X session
    *                       # any host on Internet can get an X session (unsafe)

    Whether you should want to provide any host in Internet with an X session is arguable. Obviously, any service you provide is one more possible hole in your server's security. On the other hand, the server should be secure itself, and an XDMCP client asking for an X session has to provide a valid authentication before the X session is granted.

    Furthermore, the X session uses a remote X connection, which is not encrypted. The username/password pair for the login will be transported on this connection. People out there could be sniffing valid username/password combinations, just as with plain telnet connections. This is even worse then having xauth magic cookies sniffed.

    Make your own decisions here, but I recommend not enabling this service to the world unless you have a good reason.

  2. If you want to provide XDMCP clients (X -indirect xdmcpserver) with a chooser list (a list of hosts to choose from to get an X session), follow the client pattern with the keyword CHOOSER and the list of hosts that that client may choose from. Instead of the list of hosts to choose from, you can also specify BROADCAST; with this, xdm broadcasts on the network to query for servers willing to provide the session. Some valid examples:

    xterm023.my.domain      CHOOSER seshost1 seshost2
    *.my.domain             CHOOSER BROADCAST
    *                       CHOOSER extseshost1 extseshost2
    The first lets xterm023 choose between sessions on either seshost1 and seshost2. The second lets any host in my.domain choose from any host that is willing to provide an X session. The third lets any host out there choose between a session on extseshost1 or etsseshost2.

    It is probably not a good idea to do * CHOOSER BROADCAST. This will allow hosts outside your network to get information about the hosts inside your network. You probably don't want to pass out such information. In fact, allowing a chooser to any outside host is probably not useful anyway, since you should not be enabling arbitrary direct connections either.

When you have reconfigured xdm, send it the HUP signal to make it re-read its configuration files.

# kill -HUP pid-of-xdm

9.4 XDMCP Technically

Technically, as far as I can see, XDMCP is not entirely what you would expect from the above description. xdm can redirect connecting X servers to another place, and uses this trick to implement the chooser. So, the choosing happens inside xdm, not in the X server, although the chooser list is represented on the X server's display. This is also why the X server's -once option does not combine with -indirect.

Next Previous Contents

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.

Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can get all the latest Site and Linux news by checking out our news page.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.43 Seconds