as a Windows Terminal Server Client
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
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
- 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,
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)
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
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
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
"Reconnect" f.exec "/usr/local/bin/rdesktop -f server &"
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"
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?"
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?"
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "Do you want to run netconfig now?"
if [ $YN = "y" ] || [ $YN = "Y" ]
echo "Do you want to run Xconfigurator now?"
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
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.
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
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: firstname.lastname@example.org.