Cover V11, I11



Linux as a Windows Terminal Server Client

Kenneth Hess

For several years, I have been looking for the best way to use Linux at our client sites. Linux as a desktop operating system makes a lot of sense for businesses with limited budgets and computing resources. I am an avid proponent of Linux, and I think a total Linux network works beautifully, but many applications that our clients use are not available or are not easily transferable to Linux. However, I think I have found a way to use Linux in an interesting and money-saving capacity for just about anyone in a corporate network environment.

I set up Linux as a light client using the open source remote desktop client package rdesktop. A minimal Linux X Workstation can boot up and connect to a Windows Terminal Server. The Linux Workstation is a dumb terminal that provides network connectivity and then connects to a central server (or servers) that will supply all the applications you will need.

The advantages of this configuration are:

  • A controlled environment -- Users can't change or even use their workstations. Breaks are going to be hardware only.
  • A reinstall of the Linux workstation is virtually hardware independent and very fast -- The hardware must be on the Hardware Compatibility List for Linux and the image itself has a small footprint (~300 MB).
  • No cost for the client operating system -- Linux is free.
  • One central location to update applications and services -- The server contains all of the applications and services.
  • The workstations are very fast.

And best of all, you are using Linux everywhere. See the "Licensing and TCO" sidebar.

Installing Linux on a System

I used Red Hat 7.1 for this setup and I've been very pleased with it. Here is how I configured my system.

To begin, I did the installation with a 500-MB root filesystem and a 64-MB swap filesystem. You can probably get away with less, especially if you have a 540-MB drive or smaller. I have successfully pared my packages down to a 260-MB installation with a 32-MB swap.


You can use anything that is compatible with Linux, but here are my suggestions:

  • 32-MB RAM
  • A 4MB+ Video Card
  • 500-MB Hard Drive
  • 10/100 NIC

Minimally, I recommend:

  • Classic X window interface (twm)
  • Networked workstation
  • Development tools,
  • kudzu
  • ssh

I also recommend using the Select Individual Packages for installing and get rid of packages that you don't really need, like Sendmail, etc. We're simply creating a light client OS with just enough utilities to work, but we can include a few extras (like ssh) so that an administrator can get to the client box to make necessary changes. There's no magic list of requirements, but as long as you have a twm interface and network connectivity, you are pretty much there. I slimmed down the installation so that I could put it on CD-ROM.


rdesktop is an open source client for UNIX/Linux systems that provides connectivity to a Windows terminal server. rdesktop was created by Matt Chapman and is released under the GPL. See the rdesktop home page at:
You can also download rdesktop through Source Forge:
For this article, I used rdesktop version RDP 5.0. I run rdesktop in full screen mode with the following syntax: rdesktop -f <terminal server>. If you want to run rdesktop in a window, you can use: rdesktop -g 800x600 <terminal server>. I strongly suggest using the rdesktop -f <terminal server> syntax if you are configuring client terminals where the Terminal server is their only desktop. The user will never know that they aren't using a Windows 2000 computer. To begin, download the source code and run make or make the executable on another computer and transfer it (if you didn't install the Development Tools on Install). Put rdesktop in your path. Once rdesktop is installed, you can run it by typing:

rdesktop <terminal server>
where <terminal server> is the alias, DNS name, or IP address for the Terminal Server. There are no specific configuration issues with rdesktop, it is simply an RDP (Remote Desktop Protocol) client.


I use Autologin so that the user does not have to login to the Linux terminal. For all practical purposes, the user thinks that they are on a Windows computer. The computer powers on, boots up, and the user is presented with the Terminal Server login as soon as the boot process is finished. Autologin takes away the user's ability to interact until presented with the Terminal server login screen. Autologin further facilitates the idea that the user is using a generic computer and requires nothing from them.

This also facilitates the ability of IT personnel to create a single installation for all users. If a computer goes bad, there is no reason to worry about passwords on the workstation because there is no need for any. With Autologin, IT personnel can deliver any computer to any user without intervention. As long as the computer boots up and gets to a Terminal server login, the user has a usable desktop. Generic logins like this also allow larger organizations to utilize workstations for multiple users with no need to worry about profiles, downloaded programs, etc. The login that is bypassed is the Linux login. No security is compromised by setting up this way as the workstation is not used in any way. Your security begins with the Windows Terminal Server login.
Download and install with rpm -i autologin-1.0.0-1.i386.rpm. Create a user that you want to automatically log in. Use an actual user of the system or a generic one like I do, called "username", and give it a password.

The following is from the Autologin package README file:

How is it configured?
Create the file /etc/sysconfig/autologin, containing the following settings:

    Start the session as the user specified here.
    This setting is mandatory. If omitted, autologin will not run.
    If autologin was compiled with --enable-paranoid, autologin will
    not run if the user specified has UID or GID 0.
EXEC=[script or program]
    The script or program listed here will be executed as the user
    specified above. If this setting is omitted, /usr/X11R6/bin/startx 
    will be used.
    You can use this setting to turn off autologin even if it is
    installed and the config file exists and is considered safe.
    If this setting is omitted, "yes" is assumed.

/etc/sysconfig/autologin must not be writable by anyone but root. If it 
is, it is detected as a possible cracking attempt and autologin will 
not run.

Do I need to do anything else?
Yes - you need to have runlevel 5 start autologin. Starting from the
initscripts 5.15 package, Red Hat Linux does this for you.
If you are running a prior version or a different OS, simply replace
the call to kdm, gdm or xdm with a call to autologin, or better yet, to
a script that calls autologin and falls back to [kgx]dm if autologin fails.

My /etc/sysconfig/autologin looks like: 

The username that you enter will show up in the User box on the Terminal Server.

Autologin User Home Directory

I use .xinitrc to have twm start automatically once my user has logged in. This also auto-starts rdesktop. "Server" is the name alias in /etc/hosts.

/usr/local/bin/rdesktop -f server &
This is an excerpt from my user's .twmrc file, where the left-click menu is defined. I took out all options that I didn't want the user to have and only provided the ability to reconnect if the he or she disconnects or is disconnected by not logging in quickly enough. You may want to leave in the ability to reboot.

# And a menu with the usual things
menu "defops"
"Menu" f.title
""       f.nop
"Reconnect"       f.exec "/usr/local/bin/rdesktop -f server &"
""       f.nop
I have had good luck with desktop sizes from 640x400 to 1024x678, but have only been able to use 16-bit color depth. I suggest that using at least a 4-MB video card so that your video doesn't "swim" or flash.

Configuring the Client Computer

It's unlikely that you will have the same hardware on every computer on which you install this image, so I developed a configure script that walks an installer through the configuration. This script is placed in root's home directory and is named "configure". Make it executable with chmod 755 configure, then run it (./configure). The script assumes that you are using Red Hat Linux, and you must modify it for any other distribution:

echo "Do you want to setup a server to connect to?"
read YN
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "What is the IP Address of the Server this client will be connecting to?"
echo "$IPADDR server" >> /etc/hosts
echo " " >> /etc/hosts
echo "Do you want to run kudzu now?"
read YN
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "Do you want to run netconfig now?"
read YN
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "Do you want to run Xconfigurator now?"
read YN
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "You are done!"
The first time you boot up after installing everything, you may see your X window interface flash several times and then die with some message such as "respawning too fast, will attempt again in 5 minutes". This means that the /etc/hosts file points to a terminal server that doesn't yet exist, or you have the incorrect IP address listed.

To fix this, you can do a "Ctrl-Alt-F2" to get a CLI prompt, log in, and correct the problem. You can then kill -HUP (PID of twm) and then should get a terminal server login prompt with the user's name already in the username slot.

I named this installation Hessix, but feel free to offer suggestions for a really cool name. Have fun, send me your success stories, and of course, give me some credit somewhere.

The Future

I would really like to set up a light client to do a broadcast for a list of both UNIX and Windows terminal servers, so that you get the list upon boot up and can connect to any of the choices. A bootable ISO CD-ROM would be nice for the light client as well, using the detect package to detect all hardware on boot so that even a hard drive is not needed. I'd like to have a Linux server with WINE, which would truly contain all of the applications that my client uses and allow me to minimize the need for other software.

Kenneth Hess, the CEO of AHCC (a computer consulting company based in Tulsa, Oklahoma), has worked with Linux for several years and began the Tulsa Linux Users Group in 1996. He attended several 12-step programs to rid himself of his Slackware addiction and has been on Red Hat therapy since 1997. He can be contacted at: