Sisler High school is the largest high school in Manitoba, with approximately 1,600 students and 120 staff members on campus. The school offers many computer courses at different levels, ranging from computer programming and office skills to vocational subjects, such as trouble-shooting personal computers, networking and advanced operating systems. In 2002, due to a letter from CAAST (Canadian Alliance Against Software Theft), the school spent more than $50,000 to make sure we had all the necessary licenses for our software.

I have been using and teaching Linux on both the high school and university levels since the mid 1990s. I have set up a variety of Linux servers for a variety of purposes: Web server, shell accounts, Java/C++ programming, routers, as well as HA (high availability) clusters and Beowulf clusters.

In 2002, I decided to redesign my school computer lab without MS Windows and try to teach all my courses with open-source materials. I started with an Athlon 1GHz machine with 1.5GB of RAM as my terminal server; 24 IBM 300PLs (a Pentium 200MHz slim-line desktop) as workstations; and three consumer Gnet 100MHz switches for connections. Running Linux Terminal Server Project 2.1 and using Icewin as the default desktop manager, the lab now runs smoothly. We never experienced any problems throughout the entire academic year.

After running my Linux Terminal Server lab for a year, I decided to upgrade my Linux terminal server. At a cost of about $4,000, we built a new dual Xeon (2.4 GHz) server with 4GB of RAM and two Ultra320 SCSI hard drives. In Part I of this article, I summarize the reasons why we made the changes, describe the benefits we gained and begin a detailed description of how to set up the terminal server and what we can teach with a terminal server lab.

First of all, this is not an article to debate whether Linux is better than Windows. Although many good reasons exist to run Windows on a personal computer, we as teachers should at least show students that running Windows is not the only solution. I believe in freedom of choice. In fact, the most important element of open-source and GNU/Linux is we are free to access the source code, free to join the community to improve it, free to redistribute and free to develop better software by ourselves.

Public school systems always are underfunded, and because we are using taxpayers' money, we have the responsibility to get the most for our money. By using a Linux terminal server with cheap, "obsolete" thin clients, I have been able to deliver many computer courses that are fully compatible with if not better than what teachers using Microsoft Windows are offering. With the money saved on a Linux terminal server lab, the school can fund other subject areas.

Unlike working on a Microsoft Windows network, the Linux terminal server basically is a central server system where all processes from users' workstations are executed. It's analogous to people who have access to a mainframe or minicomputer in the good old days--having a central server system is like having your own mainframe or minicomputer.

None of the workstations, or thin clients, has a hard drive. Linux and X running on the workstation are downloaded from the server, and all other programs, such as Netscape and OpenOffice.org, are running on the central server. Adding or upgrading a piece of software is done on the server. Once it is done, it is available to every user on the network. For example, when I was teaching Java programming, I had to install the whole Java development it (JDK). But, once it was installed on the server, it was available to everyone on the terminal server network. Using only a terminal session, the teacher can monitor all student activities. By simply running a shell script, the administrator/teacher can terminate the activities of a student and log him/her out from the server immediately, without accessing the specific hardware.

Having no hard drives on the workstations is, in fact, a big bonus in terms of hardware service and maintenance. After setting up my Linux terminal server lab, I no longer need to worry about hard drive failure on any work station, and maintaining students' filesystem now is done on the server. With a simple command or maybe a simple shell script, I easily can add or delete files on any student's account.

For students who want to further their studies in the computer industry, working in the Linux/UNIX environment gives them a better start. Although many professors (I also teach several courses at local universities) are complaining that many high-school graduates know only how to use a mouse to click and drag, students graduating from my courses are much better prepared for secondary education.

Two years ago, I started my Linux terminal server project with an Athlon 1.2GHz CPU, 1.5GB of DDR RAM and an IDE 40GB hard drive as the server and a variety of older Pentium-grade PCs (ranging from 133MHz to 350MHz CPUs and having 32MB or more RAM) as workstations. To guarantee better network throughput, I bought three 100Mbps 24-port switches, consumer grade, for about $120 each. The system ran fine for up to 15 workstations, but it started running out of resources (I used the top command to monitor) when more workstations were added. As some of the courses have a class sizes of up to 30 students, I had to build a more powerful server to run this Linux terminal server network.

In September 2003, AMD's Opteron 24x series was available at a price comparable to the Xeon's 2.x from Intel. It was a difficult decision to choose between Xeon or Opteron. The Opteron is a 64-bit CPU but it could be purchased at about the same price as a 32-bit Xeon. Plus, it looks especially attractive when future 64-bit upgrades are considered. However, the only distribution with 64-bit support was SuSE, and most other applications, such as OpenOffice.org, still were running on 32-bit. I finally chose Xeon as I found it beats Opteron in most 32-bit tests, and the hyperthreading technology made my dual Xeon system functions like a system with four CPUs.

Having made those decision, below are the specifications of my new Linux terminal server, built in September 2003:

With a special power supply and a server case, the whole server cost $4,500 including tax. By the time you read this article, it certainly would be cheaper and have better, faster and more powerful components.

The Manitoba chapter of Computers for School has been a huge supporter of my Linux terminal project. I received about 36 IBM 300PL slim-line PCs as workstations and a 100Mbps Intel 510P 24 Port switch from them for free. The I300PLs have built-in video and built-in sound as well as built-in Intel 100Mbps network cards. While they do not have enough power to run MS Windows (that, in fact, that was the main reason I was able to get as many as I wanted from Computer for Schools--no other school wanted them), they are perfect as a standard workstation in my classroom. The built-in network card supports PXE booting; some of the older BIOSes needed an upgrade, but that's downloadable from the IBM support site. On top of each on-board Pentium 200MHz CPU is a big heat sink with no cooling fan. Again, this is another advantage as no cooling fans need to be replaced.

My rule of thumb for memory is 100MB for each station. However, ECC RAM works in pairs, and I had no choice but to get the maximum amount of 4GB, the maximum RAM size any 32-bit system can handle. Thus, for people who want to build a LTSP to support more than 30 workstations, 32-bit CPUs are out of the question-- 64-bit CPUs, such as Opteron, should be considered. With the 64-bit support coming in future Linux distribution releases, Opteron definitely will my choice for my next terminal server.

Although the SCSI drives are more expensive (more than double the price of IDE), they deliver excellent performance on my network. With the new server, all the workstations (26 at present) can run KDE, OpenOffice.org, Web browsers and other applications smoothly and seamlessly. Recently, I installed several systems with serial ATA hard drives and found they perform much better than those with Ultra-DMA IDE drives. With the price of serial ATA drives coming down so rapidly (they are almost the same price as the parallel IDE drive), they probably soon will make SCSI obsolete--SCSI is just too expensive.

With a standard configuration of only 32MB of RAM, built-in 2MB S3 video, built-in sound and no hard drive, the workstations performance is comparable to a PC with 2GHz and 256MB of RAM running MS Windows. After typing in the user id and password, a beautiful KDE (or GNOME) window manager can be loaded in less than 10 seconds.

As far as getting software for the Linux terminal server, there are several choices. The easiest way is to download it from K-12 Linux Project site. Most of the mirror sites are educational, and they all are connected to the fastest Internet backbone. I usually can get up to 1Mbps on the ADSL link from my high school (during school hours when many students also are using the ADSL link) and can download the iso image of three CDs in less than two hours. Once the iso images are downloaded, check the download with the md5sum error and then burn your own CD with a standard CD burner. If you don't have access to a high-speed link, you can purchase the CD from the K-12 Linux Project site or from any Linux CD Web site; the cost is a few dollars plus shipping, the shipping cost is usually higher than the CD cost.

If you have your own Linux distribution CDs, you can download only the terminal server components from the Linux Terminal Server Project site. This is the general Linux Terminal Server Project, without the K12 chapter.

The main catch in getting the software is the driver for your mass storage, the hard drive. Unless you need to support only a small number of workstations--say, 5 or less--a SCSI or SATA interface is essential for good performance. Unlike the parallel IDE, neither the SCSI nor the SATA is a standard interface, and a special driver for Linux is needed. Moreover, the driver needed is for the SCSI or SATA interface and, in general, should be supplied by the motherboard maker or the interface maker. The SCSI driver I got from Intel was written for Red Hat 8.0, and as a result, I can choose only the LTSP software that was built on Red Hat 8.0. In fact, the driver from Intel didn't work with Red Hat 9.0, so I had to settle for LTSP 3.0, which was built on Red Hat 8.0.

A few years ago Linux was difficult to install. The three main problems were device drivers, hard drive partitions and TCP/IP setup. At present, most if not all Linux distributions, including the LTSP download based on Red Hat, are easy to install. They all come with a GUI mode that has mouse support. Most beginners can follow the default options, auto-partition and have Linux successfully installed.

On my new server, I choose 3GB as swap. In practice, 3GB was found to be too much as I have never run out of main memory on my new server. A smaller partition of 250MB is needed for /boot. My second hard drive is as a mirror image of my main hard drive and can be used as a replacement for the main hard drive in case of emergency. I wrote a simple script so that all users' data are backed up to the mirror drive on a daily (5 days per week) basis.

Here is my backup script, stored under /etc/cron.daily:

#!/bin/sh
# to backup /home user data to the 2nd SCSI drive
# by C T Leung
# Oct 15 2003
date
echo Daily backup /home and /etc to 2nd SCSI ...

case `date +%a` in
      Mon)
              echo "No backup on Monday..."
              ;;

      Tue)
              cp -a -v /home /backup
              cp -a -v /etc  /backup
              echo "Monday backup completed successfully..."
              ;;

      Wed)
              cp -a -v /home /backup
              cp -a -v /etc  /backup
              echo "Tuesday backup completed successfully..."
              ;;

      Thu)
              cp -a -v /home /backup
              cp -a -v /etc  /backup
              echo "Wednesday backup completed..."
              ;;
      Fri)
              cp -a -v /home /backup
              cp -a -v /etc  /backup
              echo "Thursday backup completed..."
              ;;
      Sat)
              cp -a -v /home /backup
              cp -a -v /etc  /backup
              echo "Friday backup completed..."
              ;;
      Sun)

              echo "No backup on Sunday..."
              ;;

esac
date

To satisfy your own requirements--to install the Java programming environment, set up other servers, such as Apache or Squid and so on--several configuration files have to be modified, including /etc/dhcpd.conf. This file contains basic dynamic IP configuration information for each workstation. Here is my modified file as an example:

# Sample configuration file for ISCD dhcpd
#

default-lease-time            21600;
max-lease-time                21600;
ddns-update-style none;
allow booting;
allow bootp;

option subnet-mask               255.255.255.0;
option broadcast-address      192.168.1.255;
option routers                         192.168.1.3;
option domain-name-servers    192.168.1.3;
option domain-name            "ltsp";
option root-path              "192.168.1.253:/opt/ltsp/i386";
option option-128 code 128 = string;
option option-129 code 129 = text;

shared-network WORKSTATIONS {
  subnet 192.168.1.0 netmask 255.255.255.0 {
     range dynamic-bootp 192.168.1.21 192.168.1.252;
     use-host-decl-names       on;
     option log-servers        192.168.1.253;

     # trick from Peter Rundle <peter.rundle@au.interpath.net>
     if substring (option vendor-class-identifier, 0, 9) = "PXEClient"
     {
        filename      "/lts/pxe/pxelinux.bin";
          # NOTE: kernels are specified in /tftpboot/lts/pxe/pxelinux.cfg/
     }
     else
     {
        filename    "/lts/vmlinuz.ltsp";
     }
  }
}

In the above dhcpd.conf file, I chose 192.168.1.253 rather than 192.168.1.254, the default, because I still had my old terminal server (192.168.1.254) on-line while I was setting up my new server. You may choose 254 as the host address if this is your only terminal server. On the other hand, I have reserved the range 192.168.1.1 to 192.168.1.20 for other Linux servers (web, router, printer). As a result, the range of dynamic IP addresses was set to start with 192.168.1.21 and go to 192.168.1.252.

Because I use IBM 300PL slim-lines as workstations, they all have PS/2 keyboards and PS/2 mice, so I don't need to worry about having a different setup for computers that use the DIN5-type keyboard and/or serial mice. To avoid manual setup, I strongly recommend using computers with the same type of keyboard and same type of mouse as this workstation. On the other hand, you have much more flexibility regarding CPU speeds, RAM sizes and video boards; generic dhcpd configurations should function smoothly.

The workstation startup options are controlled by the files located under /etc/X11/xdm. If you want to change the login logo, for example, simply edit the file /etc/X11/xdm/kdmrc. Here are the lines I modified so my school's logo (instead of the K12 LTSP default JPEG) as well as my own welcome messages pop up when X is started:

# The image to show when LogoArea=Logo. Default is kdelogo.png
LogoPixmap=/opt/ltsp/templates/k12linux/sisler.jpg

#GreetString=K Desktop Environment (%n)
GreetString=Welcome to Sisler Linux/Xeon Terminal Server - Rm 91

Don't forget to place your JPEG of your choice on the server; here's how I saved mine: /opt/ltsp/templates/k12linux/sisler.jpg.

On the other hand, the file /etc/X11/xdm/TakeConsole contains the cleanup procedures as a user logs out from a workstation. To it, I added a line to execute a script called /usr/bin/suicide, a simple shell script to kill the processes of the logout user.

[root@xeon2 xdm]# cat TakeConsole 
#!/bin/sh
# Reassign ownership of the console to root, this should disallow
# assignment of console output to any random user's xterm
# $XConsortium: TakeConsole,v 1.2 93/09/28 14:30:29 gildea Exp $
#
chmod 622 /dev/console
chown root /dev/console
#/usr/X11R6/bin/sessreg -d -w "/var/log/wtmp" -u "/var/run/utmp" \
#       -x "/etc/X11/xdm/Xservers" -l $DISPLAY -h "" $USER
exec /usr/bin/suicide
$xmessage -timeout 10 -default okay -center "$0: sessreg failed."
exit 1


[root@xeon2 xdm]# cat /usr/bin/suicide
#!/bin/sh
# Suicide!
# by C T Leung Jan 18, 2004

if [ $(whoami) != "root" ]
then
   me=$(whoami)
   for i in $(pgrep -u $me)
   do
      kill -9 $i
   done
else
   clear &&  echo no suicide for root!!!
fi

In Part II of this article, I explain