Brian Carpio

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.

Hardware

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

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:

http://www.rdesktop.org

You can also download rdesktop through Source Forge:

http://prdownloads.sourceforge.net/rdesktop/rdesktop-1.1.0.tar.gz

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 800×600 <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.

AutoLogin

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.

ftp://ftp.linux-easy.com/pub/linux-easy/i386/autologin-1.0.0-1.i386.rpm

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:

USER=[username]

    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.

AUTOLOGIN={yes,no}

    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:

USER=username

AUTOLOGIN=yes

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.

.xinitrc

/usr/local/bin/rdesktop -f server &

twm

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.

.twmrc

#

# 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 640×400 to 1024×678, 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:

#!/bin/sh

echo "Do you want to setup a server to connect to?"

read YN

if [ $YN = "y" ] || [ $YN = "Y" ]

then

echo "What is the IP Address of the Server this client will be connecting to?"

read IPADDR

echo "$IPADDR server" >> /etc/hosts

echo " " >> /etc/hosts

fi

echo "Do you want to run kudzu now?"

read YN

if [ $YN = "y" ] || [ $YN = "Y" ]

then

kudzu

fi

echo "Do you want to run netconfig now?"

read YN

if [ $YN = "y" ] || [ $YN = "Y" ]

then

netconfig

fi

echo "Do you want to run Xconfigurator now?"

read YN

if [ $YN = "y" ] || [ $YN = "Y" ]

then

Xconfigurator

else

echo "You are done!"

fi

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.

The use of Server Based Computing for home workers or connecting a small branch office is very appealing to small companies. However this often means that most companies buy their first Terminal Server without any prior knowledge of the technology. Here are some useful recommendations to keep in mind when purchasing your first Terminal Server.

Introduction
When you have a small office, Server Based Computing technology can be very appealing, especially for home workers or for connecting to the new small branch office.

If the concept of SBC is new to you, then you’re confronted with what server to buy, and what is needed to get it working. Extensive training on everything is often a sharp contrast to the price of the solution, so it’s up to your IT administrator to go out there, and make the best of it. This article should prevent him/her from misconfiguring or buying an overprized server.

The Hardware
When shopping for a server, there are few vendors out there. (I would not advise on self-built hardware, because for smaller offices good hardware support is more important then a few $ saved). The main vendors these days are HP, Dell and in Europe, Fujitsu-Siemens is also a large player.

Caging
When buying a server, the first choice to make is to whether it’s going to be a rack-mount 19” or a tower server. Rack mount is more expensive, but can save you quite some room in the long term - if your server park is growing.

CPUs
Keep in mind, that a Terminal Server can be a complete desktop replacement for some users, so serious power is needed. In my opinion, powerful CPUs are a must. When looking at Intel, the use of Xeon’s with MB level 2 cache is just fine (Larger level 2 cache is used more in database-like servers). At the time of writing, the most powerful is the 3.6, and the price is accordingly higher. Going for the 3.2 would give you a much better power/price ratio. These days you can go for 64-bit processors, but keep in mind that at this point, besides a 64-bit version of the OS, and/or Citrix, there is not yet much out there that is 64-bit, so you will not benefit greatly from it.

When thinking about the number of CPUs it’s easy to say, “Never go for a single CPU server.” Duals are quite affordable these days (and I’m not talking about Intel’s hyperthreading, but actual processors). Many tests in the past have shown that using quad CPUs is not worth the investment in hardware/enterprise OS, versus the extra number of users you can get on a box (it does not scale linearly). Right now it’s better to scale out than up, but I see a good future for the new 64-bit processors tackling all the limitations we currently have.

Memory
Memory is very cheap these days so there’s not much to think about. Just get the fastest type available for your server. When looking at 32-bit servers and OSes, there is a 4GB limitation for a standard servers (Enterprise can handle more, but is not the best investment). This 4GB is split into 2GB for user mode memory space, and 2GB for kernel mode.

When using the /3GB switch in the boot.ini you can move 1GB from kernel mode memory to user mode, providing more users, but real life has shown that this can compromise server stability more easily. My advice is to not use that switch, and try to get the most resources out of the 2GB user mode memory space.

My advice is to go for a 4 GB total server.

Disk setup
Depending on your company policy on redundancy, you can have lots of variation. Keep in mind, that the most well set up servers contain zero user data, making them easily reinstalled if needed (All user data needs to reside on other file servers). With that in mind and to have the fastest redundancy available, I would advise a RAID-1 setup, and to have 1 extra disk as a hot spare available (3 disks in total). Using 15k disks over the 10k ones, can gain you additional performance.

When looking at the partitioning of the disk, try not to scale the OS drive to low. An average Windows install is about 3GB, the page file is about 1.5x the RAM (ex. a 4GB memory system = a 6GB page file) and if Microsoft ever needs a full memory dump, then it HAS to come from the same OS disk, and can also contain the full memory from the server (another 4GB). That leaves you with 13GB used, without installing a single program. So if you bought a server, using 35GB disks, I would advise to use at least 20 of it, for the C drive.

If the concept of a terminal server is new to you, you can easily be surprised by bringing a server to its knees after a minor OS or Citrix update. If this happens you will have to fix it, while dozens of people are screaming at your desk, trying to understand why they can’t work, wishing you could turn back time. Turning back time is actually quite simple. During your partitioning, add a simple 5GB FAT32 partition for storing a server image.

Create an image of your server with the tool you prefer (my favorite is ghost) before running ANY update on your server, and you will find this method will save your a** one day. It’s easier to restore the old environment in a 10 min job, rather than trying to fix the issue for hours, and having your boss looking over your shoulders while doing it.

Raid controller
When using the RAID construction mentioned above, you need to purchase a good quality RAID controller with your server. Get one with at least 128MB and make sure it has an option which you can set to divide the write and read memory on it. (HP calls that a BBWC (Battery Backed up Write Cache) add-on and it’s NOT standard on an HP raid controller. Many people in the past have experienced issues with Controllers that just had read cache enabled, and encountered users with frozen sessions, which only clear up after some time when the cache got emptied, or needed a server reboot to clear the cache.

Setting the cache at 50% read and 50% write access has proven the optimal setting.

Network card
Most servers these days come with a 10/100/1000 auto sense network card (or sometimes even 2) already preinstalled. You can use teaming software to increase the total load, but it could also be wise to split the front-end connected to the users, and the backend connected to fileserver or application servers by using 2 nics. That way the traffic type would not interfere with each other. If your backend is not on gigabit yet, consider that it’s just the investment of a gigabit switch and then some client/server applications (where the client runs on the terminal server) could benefit a lot from this set up.

It’s extremely important to fix the nic speed on the server (100 of 1000MB Full duplex), and if possible on the switch also. Afterwards do some speed testing, by copying a large file from a file server to the terminal server, and the other way around (to double-check that the speed can be handled by the switch both ways).

Video card
Some people starting with terminal server for the first time could be led to think that they need a top of the line video card. Let me pop that bubble right here. The video card processor in the server is not used whatsoever in the screen scraping process, and you can get the cheapest one available.

The number of users you can load

This is one of the most often asked questions out there, and it cannot be answered.

It all depends on the applications you plan to load on that server. Some applications can be so aggressive, that loading 5 sessions takes all the resources, whereas a simple app like notepad can load over a 100 users on a dual CPU box.

Intensive testing before deploying can give you a more exact number of the users you can load, before performance degradation starts kicking in. To at least get an average, a simple dual CPU with 2GB memory box, roughly gets about 30 to 35 concurrent users using well behaved apps at a time. Some people out there buy expensive 8-way boxes with 16GB memory, because they want hundreds of users, but often experience limitations on the hardware, forcing them to lower the number of users.

Like I mentioned before; with the current technology it’s best to scale out, and not up.

Conclusion
If you’re a first timer, and are not really sure of what to buy for your first terminal server, the above advice can be very useful. If you’re an experienced terminal server administrator, you probably developed your own set of rules and preferences on the above advice.

So for the first time, my summary of all the above advice, for a nice first terminal server:

• Dual CPU with 4GB RAM,
• RAID 1 disk setup with hot spare,
• Running on a 128MB RAID controller that has read/write cache set at 50%,
• And Gigabit NIC enabled

For more information or if you are looking for a terminal server call The Tek (http://thetek.net) 877-4-TheTek