Linux-Based X Terminals with XDMCP

A tutorial for configuring XDMCP on your network so you can use old equipment, cut down on administration duties and cut costs.
Customizing the Login Screen

The display manager login screen and chooser interface are fully customizable. If you are running gdm, you may use the graphical setup utility gdmsetup or modify the text file /etc/X11/gdm/gdm.conf. If you are running kdm, modify /etc/X11/xdm/kdmrc. If you are running xdm, start with modifying /etc/X11/xdm/Xresources. If you don't find everything you want to customize in these files, look at the other files in /etc/X11/xdm/, for example, XSetup_0 or xdm-config. I expect most people choose to use gdm or kdm, so I won't go into details on xdm customization. Also, because gdm offers a graphical customization tool, I scratch only the surface of customizations, focusing on kdm customization under Red Hat only.

Regardless of which display manager you run, you may want to consider customizing a few things. For example, you may want your own background image and your own welcome message to appear on the login screen, and you definitely want to prevent users from shutting down the server through the login window. For kdm users, the background image is presented on the login screen by an auxiliary program called xsri. Under Red Hat, the script /etc/X11/xdm/XSetup_0 checks for the existence of the program and the associated file /etc/X11/xsrirc. If both exist, xsri is run and the graphic indicated in /etc/X11/xsrirc is displayed on the login screen. So, if you want to change the background image, simply change the graphic file listed in /etc/X11/xsrirc. To change the welcome message, find the GreetString option under the [X-*-Greeter] section of the file kdmrc. You may set this string equal to anything you like, but long messages may not display fully or may distort the appearance of the login window. Macros may be used in the GreetString too. For example, the default greeting is "Welcome to %s at %n" where %s is expanded into the operating system and %n is expanded into the node name (usually the hostname without domain name). Other macros are available and are listed above the GreetString line in kdmrc.

Finally, and most importantly, you need to keep regular users from shutting down the server. Allowing them to shut down is dangerous because they may shut it down while other users are working on the same machine. Again, inside the file kdmrc, find the AllowShutdown option under both the [X-*-Core] section and the [X-:*-Core] section and set them both to Root. This change requires the root password in order to shut down the machine from the login window. Additionally, when a user logs out of a session, the shutdown option does not appear in the ensuing dialog box. However, you may prefer to set these options to None, in which case the shutdown button will not appear at all in the login window.

Multiple Server Setup

Multiple servers may be set up in exactly the manner described in the section on configuring a server, and they can be accessed by X terminals in exactly the manner described in the section on configuring an X terminal. However, this requires the user to pick a server to login to and to know its name or IP address. A more effective method of managing multiple servers is to run a chooser and have users of X terminals submit indirect queries.

To begin, configure each server as described previously. Then, pick one machine to run a chooser. On this machine, modify the file /etc/X11/xdm/Xaccess in one of two ways. The easiest way is to uncomment the line * CHOOSER BROADCAST. When an indirect query is received, the chooser sends out a broadcast query and displays a list of machines that responded to the query. The X terminal user then may select to log in to one of these machines. This setup does not work in all environments, however, and you may not want to give users access to all servers on your network.

To be selective as to which servers are reported by the chooser, comment out the line * CHOOSER BROADCAST by putting a # at the beginning and uncomment the lines #%hostlist host-a host-b and #* CHOOSER %hostlist. Then, replace host-a host-b with a space-separated list of all hosts that you wish to appear in the chooser. This way, the chooser can send direct queries to each machine in the list and report the results to the chooser.

Finally, to see the chooser from an X terminal, run X with the option -indirect my.XDMCP.chooser, where my.XDMCP.chooser is the name of the machine configured to supply a chooser. Under UNIX, remember the command to run X is X and under Cygwin it is XWin.exe.

Further Information

Advantages: the main advantages of running XDMCP are clear from the goal you wish to meet by running it. However, there are some disadvantages, one big one being the lack of security. Additionally, access to the X terminal's sound card, floppy drive, CD-ROM drive, scanner and any other local hardware besides the keyboard, mouse and monitor is difficult at best. I do not have a reasonable solution to offer on this issue. Perhaps someone can offer one in a future article.

Security: as stated earlier, XDMCP is an insecure protocol. However, if you require X terminal services over an insecure network, there is at least one option. Instead of setting up your server to run XDMCP, configure it as an SSH (secure shell) server. Then, from the X terminal, start an X session running nothing but an xterm, not even a window manager. From this xterm, issue the command ssh -X loginname@ssh.server, where ssh.server is the name or IP address of the ssh server and loginname is your login on the server. The -X enables X11 forwarding over the secure connection. After logging in, issue startkde to begin a KDE session or gnome-session to begin a GNOME session. Alternatively, you may run a full blown desktop environment on the X terminal, run an xterm there and issue the command ssh -X loginname@ssh.server command where command is the command/program you wish to run. This allows you to run a single program at a time on the remote machine rather than on a desktop environment.

Installing and running an SSH server and client should be straightforward. For example, Red Hat ships with an optional sshd (server) package and the client is installed by default. For Cygwin, an OpenSSH client is an optional package. For more information than you probably care to know about SSH, see or read the man pages on SSH and sshd.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

best open source server OS with thin client enviroment

Anonymous's picture

can anyone please suggest which is the best Open source OS to run as server and connecting to it through Thin Clients by XDMCP.

XDMCP in 9.04

Anonymous's picture

I m having issues in ubuntu 9.04 enterprise server.
I have enabled XDMCP and using Thin Clients to connect to server.
While in XDMCP connection from thin clients my office application(open office3.1) works very slow. Browsing is fine. Gnome version is 2.0.
can anyone suggest how can i make this work.


Anonymous's picture

this was very helpful

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Instructions works as advertised. Took less than a hour from start to finish. 1/3 of that was downloading, and installing cygwin. I do have many years of Unix/Linux experense. However, this was a very clear path to making X avaible to Windows with very little effort.


Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

First off great article...people that nit-pick should write their own article if they think they can do a better job.

For anyone out there using kdm I noticed that I didn't have to edit the /etc/X11/xdm/* files at all since kdm is what manages the connections the only files need editing are in /etc/kde2/kdm

I setup a debian woody laptop (P-133Mhz, 32MB, 1GB disk) to run KDE off the KDM server (AMD K6-400Mhz, 340MB RAM, 20GB disk) and the performance is excellent on my home network of about 8 machines. I was just about to toss the laptop into the dumpster but thanks to Linux and wonderful folks like the author the laptop will live a little while longer. The monitor resolution of 800x600 and 8bit colors does suck however! :)

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Is anyone aware of a project that would allow you to use old windows/citrix terminals with LTSP? For example, this one ( can be found for $12.00 My church is looking at starting a computer lab for local students, and if I could get these working with LTSP life would be very good.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Generally, any thin client that can connect to a X-windows server can work .. there are a number out there and I remember reading about the City of Tampa using this concept.

Many require custom kernels but most can be obtained from the manufacturer's web site

I couldn't find any info about the Wyse 2315 having any ability to connect to an X-windows server .. so I think it is not possible with that model (maybe it is possible with other Wyse models)

what about MIT magic cookies?

Anonymous's picture

i've been using this set up for a while, but every so often get the connection refused because of MIT magic cookies. how do we turn them off??!?!?!

Re: what about MIT magic cookies?

Anonymous's picture

"man xauth"

Craig Ringer
POST Newspapers

Articles about XDM

wrochal's picture

In case that they have interest in articles on LTSP, it follows link below:

Citrix Metaframe

Anonymous's picture

I am currently planning moving from a Windows Terminal/Citrix Metaframe setup to Linux running XDMCP. The main drawback is that there seems to be no suitable replacement for Metaframe for Linux. I see Citrix have the Presentation Server for Unix, but it only supports the commercial unixes. Tips on suitable solutions?


Re: Citrix Metaframe

Anonymous's picture

>> I am currently planning moving from a Windows Terminal/Citrix Metaframe setup to Linux running XDMCP. The main drawback is that there seems to be no suitable replacement for Metaframe for Linux. I see Citrix have the Presentation Server for Unix, but it only supports the commercial unixes. Tips on suitable solutions?

I experimented for some time with X, LTSP, VNC and IIRC, XDMCP, too. My testing environment was a Fast Ethernet LAN (100 Mbps full-duplex). The greatest problem I saw was latency. Ordinary X protocol connections were quite good, except for massive data transfers which occur, e.g., when continuously scrolling a browser window. Compressing protocols (like VNC or XDMCP) helped then but did introduce undesirable additional latency for simple operations, like pressing Page Down, for instance. VNC (in fact, TightVNC) was specially tricky to setup.

Things would be totally different had I needed to use a dial-up link.

At the end of my tests, I found NX, a protocol for highly efficient data compression, itself a kind of XDMCP (AFAIK). There is a free version on SourceForge, but browse at where a commercial version is available (along with free trial downloads).

Though this is claimed to be as efficient as Citrix' ICA (or even more), I didn't have the time to test it (in fact, I had trouble in finding a library upon which the free trial version depended).

This would be my best bet as an alternative solution; have in mind, though, that the bigest problem is server memory consumption, around 50 megabytes per connected user!

Re: Citrix Metaframe

Anonymous's picture

I've been using XDMCP for quite a few years, although I have looked at Citrix it just seems too much for our small shop. What does the Metaframe PS do exactly? does have a few non-active projects, however I don't think there is an opensource alternative...

Re: Citrix Metaframe

Anonymous's picture

Unless I'm confusing terminology, Metaframe PS is just what is commonly called Metraframe, which is similar to VNC in concept. That is, a "virtual desktop" can be kept running on a server and be displayed on a user terminal.

But while VNC is somewhat clunky, and practically unusable in Windows due to processor overhead, Citrix' Metaframe integrates well with the underlying Windows OS and gives a very light and smooth (but costly) experience.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

From the article: Want to get some use out of your early 90s vintage PC, the one barely powerful enough to run Windows 3.1? . . . .

For Mac, consider installing XDarwin . . . .

From the XDarwin site: XDarwin is an implementation of the window server for version 11 of the X window system on the Darwin operating system, underlying Mac OS X.

Maybe the author should tell us exactly which early 90's vintage PC's he's managed to install OS X to? This sort of oversight really detracts from an otherwise valuable article like this. The author is either severely exaggerating certain capabilities, or has simply not done his homework. The bottom line is as follows: this solution is not going to work for any of the legacy Macs he seems to want to include among target hardware for XDMCP. By giving the impression that it will, the article risks alienating people from Linux by leading them into a project doomed to failure. This does not help the OSS movement, damages the reputation of Linux and could waste alot of someone's valuable time. A call for a greater sense of responsibility in writing articles about Linux and its capabilities. More realism, less starry-eyed idealism. Otherwise - for legacy x86 owners - a helpful article and good collection of links. Thanks. But please be more careful in the future.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Your flame is entirely unfounded. Let's review the objectionable line from the article:

"Want to get some use out of your early 90s vintage PC, the one barely powerful enough to run Windows 3.1?"

I don't see how you can interpret this to mean a vintage Mac. No Mac ever ran Windows 3.1. Perhaps you simply need to pay closer attention to details. The article is very well written.

Both the XDarwin and Cygwin suggestions seem to be intended as answers to the question

"Want to introduce Linux to a group of Windows or Mac users with the least amount of resistance?"

I do, however, agree with the general philosophy of the flame. It simply doesn't apply to this article. Please be more careful in the future.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Sorry, but I stand by my criticism. This author needs to clearly distinguish between the modern Macs that can run XDarwin and the legacy/budget network talk the article starts off with. Not having done that, he presents a confusing picture that could easily give the false impression this project is suitable for legacy Macs. That impression is going to lead someone wanting to put into practice the otherwise helpful tips in this article down a dead end, waste alot of that person's time, and risk giving Linux a bad name. The solution to this sort of oversight? Like I said, less starry-eyed idealism about Linux and its capabilities, more realism about what it really can do and which hardware it really is suitable for. If it won't run on legacy Macs in an article that starts off talking about the virtues of XDMCP on legacy systems, that point needs to be made crystal clear up front. Not doing so will not help - but could rather hurt - the Linux cause. Case rested.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Actually, the author's unstated advice is that all you need to participate in this remote-execution XWindow-terminal metaphor is an X11 CLIENT. He did a poor job of stressing that point, alas.

Many exist for Mac OS, Windows, etc. For the Macintosh, eXodus and others will work just fine.

You do NOT need to be running a UNIX to run X11 clients. In fact, I used to do remote X sessions from my 8500/120 running OS 8.6 to both Linux 2.2 (years ago) *and* MachTenX running locally on my 8500.

Lord Apollyon

Nope, what you want on your

Anonymous's picture

Nope, what you want on your desktop machine is a X11 _SERVER_, not a client. A X11 client is an application, like "xterm", "xemacs", "gnome-panel", and so on. (After all, it is the application that connects to a display server, not the other way around).

To make the confusion complete:
- You need a X11 SERVER on your application client machine (the one you are directly interacting with)
- You will be running X11 CLIENTS (xterm, etc) from your application server machine.


Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

In response to the complaint: "Actually, the author's unstated advice is that all you need to participate in this remote-execution XWindow-terminal metaphor is an X11 CLIENT. He did a poor job of stressing that point, alas."

Again, I think there has simply been a misunderstanding on the part of the reader. An X11 "client" is actually called an X server even if it is running on an isolated un-networked computer. I'm not sure how much clearer one can be than this snippet from the article:

"This means the X terminal must have some operating system with a configured X server installed. In case of Linux, Windows or Macintosh, an implementation of XFree86 is available free of charge."

You provide good advice on the availability of other X servers for Macs, though. Thanks.

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

Whats the difference between this and the Linux Terminal Server project?

Also, on a switched network with a modern dual Opteron server, how many clients could you support and what would the main bottleneck be?

Re: Linux-Based X Terminals with XDMCP

Anonymous's picture

The LTS project uses this procedure to establish an X session. However, it goes beyond, providing remote boot capabilities, so you don't need to install the operating system at each station. With one configuration, using dhcp or bootp on the server, all you need is to attach the "thin" station on the network and the machine will be booted and the X login prompt will appear to you.

Sorry for my english!

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot