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.
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!
X as an XDMCP ClientIf 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.
and, assumingX -query sessionhost
xdm is running on sessionhost, you'll get a login window, and after login, an X session.
and, assumingX -broadcast
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.
and, assumingX -indirect xdmcpserver
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.
xdm as an XDMCP ServerThe 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.
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.
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:
The first letsxterm023.my.domain CHOOSER seshost1 seshost2 *.my.domain CHOOSER BROADCAST * CHOOSER extseshost1 extseshost2
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 #
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.