1.1. Disclaimer

No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility for that.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.

1.2. Feedback

Feedback is most certainly welcome for this document. Without your submissions and input, this document wouldn't exist. Please send your additions, comments and criticisms to the following email address : <tomchao@lucent.com>.

2.1. Before you begin, some background

Before you begin, it is better to have a basic understanding of how this works. (More details are at the Resources below and LDP HOWTO page)

The X server is usually started from the X Display Manager (DM). Almost all the Linux distributions include the xdm, kdm and gdm to you as your choices. (This document will use gdm and kdm as an example). The Display Manager provides a nice and consistent interfaces for general users (X-based login, starting up a window manager, clock, etc.). X Display Manager manages a collection of X displays, which may be on the local host or remote servers. It is worth noting that the Xsession file is what runs your environment.

When xdm runs, it offers display management in two different ways. It can manage X Server running on the local machine and specified in "Xservers", and/or it can manage remote X Servers (typically Xterminals) using XDMCP as specified in the "Xaccess" file. (refer to the xdm man page).

For kdm (which comes with the KDE desktop), it is a replacement of xdm and configures the same way, except its files are in /etc/X11/kdm in Caldera, /etc/kde/kdm in Red Hat and /usr/share/config/kdm in Mandrake.

The gdm (Gnome Display Manager) is a re-implementation of the well known xdm. gdm has similar functions to xdm and kdm, gdm is the Gnome Display Manager, and its configuration files are found in /etc/X11/gdm/gdm.conf. The gdm.conf file contains sets of variables and many options for gdm, and the Sessions directory contains a script for each session option; each script calls /etc/X11/xdm/Xsession with the appropriate option. gdm has similar functions to xdm and kdm, but was written from scratch and does not contain any original XDM / X Consortium code.

RH 8.0 introduces the new graphical interface called "Bluecurve". The new interface is aimed for XP feel and styles. The setup makes no difference in this case!

Other good references for the similar setup can be found in the following documents:

• The XDM and Xterminal mini-HOWTO, by Kevin Taylor

• Linux Remote X Apps mini HOWTO A very good reference for Remote X in both theoretical and practical view. By Vincent Zweije

• The Xterminal mini-HOWTO, by Scot W. Stevenson

2.2. Security Reminder

Using XDMCP is inherently insecure, therefore, most of the distributions shipped as it's XDMCP default turned off. If you must use XDMCP, be sure to use it only in a trusted networks, such as corporate network within a firewall. Unfortunately, XDMCP uses UDP port 177 and TCP port 6000; therefore, it is not natively able to use it with SSH. Currently, SSH1 and SSH2 are not implemented to securely forward the UDP communication.

To secure the connection with SSH, the technique is called X11 TCP/IP Port Forwarding. Check this Why Port Forwarding? site and the Resources area for additional HOW-TO information. If you would like to experiment this, I have add a little section below to show you how it works. I will give you only the basic idea how it works, and I will leave the more advanced way of running it to other experts and/or HOWTOs.

2.3. The System I use

I have tested the setup running a GNOME (gdm), as well as KDE (kdm) on Red Hat 6.0, 6.2 and Red Hat 7.x and 8.0. I also had a chance to test this on Mandrake 7.2, 8.0, 8.2 and 9.0. SuSE 7.2 and Slakware 8.0's setup are tested by the users, thanks to Peter Van Eerten and others, who helps the test for this HOW-TO. I would like to thank all users who help me on this project). The other I have tried on is Caldera eDesktop 2.4, which is similar to RH's setup, except that it uses KDE. I have not had a chance to test it on other Linux flavors like Debian and Slackware (Slackware users had told me it works the same way as mentioned in this document). However, the setup should be similar and should works fine. If you have successfully setup one other than the Red Hat, Caldera and Mandrake platform, please share it with me. I will add them into this document.

The PC hardware I use is an IBM PC clone running an AMD Athelon XP 1800+ with 384 MB memory and a 60 GB ATA-100 Hard Drive. This machine has been since upgraded from Intel Pentium II 500 MHz PC. (I found out that my old Pentium 100 MHz PC runs this just fine). I use a built-in Fast Ethernet NIC in my new AMD type M/B. In my old machine, I use the 3Com 10/100 (3C509B) NIC with an ATAPI 48X CD-ROM and an IOMEGA ZIP drive. I have also test it on my Toshiba Tecra 8100 laptop connecting using my Agere Wireless LAN card.

2.4. Remote piece

I use the Hummingbird Exceed 7.0 (Exceed 6.x also works fine) on my PC and have tested them on Windows 98 SE, Windows NT 4.0 and Windows 2000 Pro. I found out that other popular choices are X-Win32 and X-ThinPro. There are also many open-source apps as well as commercial one available.

2.5. Server Preparation

In RH 7.x, you need to setup DNS lookup, in order for some networking function to work properly (such as telnet that we will use to test the setup). You can use "netstat -r" and/or "arp -a" command to verify your DNS setup or response time. If you are in a small environment (like home or small office, etc.) that do not have your own DNS and is relying on your ISP's DNS Server, then add the entry of your DNS Server name(s) in the "resolv.conf" file. If you are only use it in the lab or at home, then, you can add the host name of all workstations in your local "host" table.

To prepare your X Server for XDMCP session, you need to make sure the following are properly installed:

1. Install your Linux OS. In my case, I installed Red Hat 7.3 (Custom Installation). If you plan to use SSH Port Forwarding, you need to install the OpenSSH package or compile SSH with your kernel. Also, RH 7.x comes with firewall installed by default (unless you choose not to). You may encounter problem, if you do not add firewall rules or temporary disable it in setting up XDMCP. I will not cover the firewall rules here in details, since this is not the focus of this document. I will share only how to make it works first and you can fine-tune it yourself.

   To show your firewall rules, in kernel 2.2x, use the command ipchains -L to list your default rule sets. To temporary disable it, use this command ipchains -F to flush the rules (Don't worry, it will restore by re-loading or re-boot). For kernel 2.4x, replace command ipchains with iptables. One user shared with me that by adding this rule, you can do it without disable your firewall and can allow yourself to access the X Server (you can verify this yourself).

   ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT

   You should be able to use the iptables in the similar way. (Check for iptables references at the Resources area).

   For more firewall details, check the IP Masquerade HOWTO page.

   One other easy way is to add rules that only accept certain IP address(es) from your trusted workstations. For using the command iptables, please feel free to experiment it. Again, I will not cover it here. I am the lucky one, because I use my company's firewall to protect me.

2. Setup your Networking. To test it out, ping, ftp and telnet are good commands to use to determine if your network works. RH 7.x and up do not have telnet daemon turn on by default (for security reason). Remember to enable it, if you prefer to use it for your test. You can always turn it off when you are done (Using ntsysv with root privilege). One other thing is to remember firewall rules are there. Add your own rules or temporary disable it (as mentioned above) to make these commands work.

3. Setup X. Do not setup with a resolution higher than what the remote users are able to use for their display. Test the X Server by typing either startx or telinit 5. Make sure X is running properly.

4. Creates the necessary user accounts (and associated groups) for user who will access via the Xterminal.

2.6. Steps to Complete the Procedures

These are steps I used to setup the X Server for accepting XDMCP requests:

1. In Linux X environment, you need to provide font using either X font server (xfs) or hard coded font path in XF86Config and XF86Config-4 configuration files. If you plan to use xfs font server (check here to see the xfs advantages), do this in RH 6.2 and Mandrake 8.x and 9.0, modify /etc/rc.d/init.d/xfs and make the following changes. Change all (this is where the Font Server port):

   daemon xfs -droppriv -daemon -port -1

   to:

   daemon xfs -droppriv -daemon -port 7100

   In Mandrake 7.2, the port is already set to 7100. Also, in RH 7.x, it is by default, for security enhancement, not listening to TCP port any longer! If you like to setup X font server, do the following steps:

   Change this line in /etc/rc.d/init.d/xfs:

   daemon xfs -droppriv -daemon

   to:

   daemon xfs -droppriv -daemon -port 7100

   Then, in /etc/X11/fs/config, comment out this line:

   # don't listen to TCP ports by default for security reasons #no-listen = tcp

   If you change or add the port, use this command to restart your X font server (requires root):

   service xfs restart

   You do not have to use port 7100. You can set a different port, as long as you carefully plan it first to make sure no conflicts in using the port number and change it accordingly. It is better to consult your Linux admin before doing so, so that he/she knows the port has been taken! Different Linux distribution may put the xfs in different folder under /etc/rc.d. You may search for it if that's the case.

2. Modify /etc/X11/xdm/xdm-config and make the following change. Be default (in most Linux distributions), this line is set, so that it is not listening to XDMCP connection. This is for security reason. For Caldera using kdm, this file is at /etc/X11/kdm. Find this line:

   DisplayManager.requestPort: 0

   and comment it out as:

   ! DisplayManager.requestPort: 0

   Remember, this does not affects gdm. For gdm setup, it is in the following section.

3. In /etc/X11/xdm/Xaccess, change this. (this allow all hosts to connect). For Caldera using kdm, this file is at /etc/X11/kdm. Set the security to 644 (chmod 644):

   #* # any host can get a login window

   to:

   * # any host can get a login window

   The above setup is in a Broadcast mode, which will list all the X Server that are listening and willing to manage your X connection. If you only want to allow certain connections, use the CHOOSER section in this same file. An example can be found in the Resources.

4. I use the gdm as default and use gdm login window to switch between KDE and GNOME. For gdm, edit /etc/X11/gdm/gdm.conf. This activates XDMCP, causing it to listen to the request. For kdm (if you pick KDE as your DM in your installation), edit /usr/share/config/kdm/kdmrc for Mandrake and /etc/kde/kdm/kdmrc for Red Hat or /opt/kde2/share/config/kdm/kdmrc for Slackware version (KDE2). Change this line:

   [xdmcp] Enable=false (may shown as 0 in some distributions)

   to:

   Enable=true (or 1 in some distributions)

   Make sure "Port=177" is at the end of this block.

5. Now edit /etc/inittab and change the following line:

   id:3:initdefault:

   to:

   id:5:initdefault:

   In Slackware, the X11 mode is number "4", not "5".

   This is switching from Text Mode login to Graphical Mode using Display Manager. Before changing this line, you can use the telinit command to test prior to modifying the line. Use either telinit 3 to set to level 3, or telinit 5 to set to level 5, graphics mode (you can issue this command on the second machine that telnets into this server).

6. Make sure the proper security of the file /etc/X11/xdm/Xservers is set to 444 (chmod 444).

7. Locate /etc/X11/xdm/Xsetup_0 and chmod 755 this file.

8. Edit the XF86Config file (if you are using XFree86 4.x, the file is XF86Config-4) at /etc/X11 and change the line:

   FontPath "unix/:-1"

   to:

   FontPath "unix/:7100"

   If you decide to use the port number other than the usual 7100, be sure to change both in "/etc/rc.d/init.d/xfs" file and here!

   To save your time and energy, I recommend you to add the FontPath in the XF86Config and XF86Config-4 configuration files. If you are not sure what fonts are available to you, you can use this command to check it out (requires root):

   chkfontpath --list

   The following are some of the example fonts for your reference. Make sure you have these fonts before editing these path.

   FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/"

9. (You do not have to make this change. You can keep the default setting, but this is what I prefer. If you are not sure, leave this alone.) Change this line to the end of /etc/inittab:

   x:5:respawn:/usr/bin/gdm

   If you decided not to change this line, it is fine! This is not a required step, but of a personal preference!

You are now ready to run a test.

One other thing to know (that some users have asked) is how to display with Willing to manage message with load info As I know this is available in xdm by adding the following to the /etc/X11/xdm/xdm-config.

DisplayManager.willing: su noboby -c /etc/X11/xdm/Xwilling

and the XWilling script must exist. For gdm, add this line to the /etc/X11/gdm/gdm.conf in [security] section:

Willing=/etc/X11/gdm/Xwilling

A sample of Xwilling script is here for your reference. Adding this script or not is your preference. It is not required step here!

2.7. Testing

To test if your XDMCP with X Server is ready to accept connection(s), do these steps. I find it easier using the X Server and another machine to test it:

1. (Re-)Start your X (which is in runlevel 5). If you are not sure how to do this, simply reboot your system (but this is really not necessary, if you know how to restart it using command line. That's the beauty of Linux, when comparing it to my Windows).

2. If you have not modify your firewall rules, you need to temporary disable it by using iptables -F (or ipchains -F).

3. Make sure the Graphical login page comes up. Make sure the display resolution and mouse work. Log in from the console to see if the local access is OK. If OK, do not log off.

4. Setup Hummingbird Exceed (or other X Client software) to either query this machine (using the IP address or fully qualified DNS name) or set to use XDMCP-Broadcast and try to connect to the X Server. You should see the X Session come up and the login screen appear.