Linux Terminal Server Project [1]

The Linux Terminal Server Project ( LTSP) is a configuration of Linux that allows you to connect lots of low-powered thin client terminals to a Linux server. The LTSP provides a simple way to utilise low cost workstations as either graphical or character-based terminals on a GNU/Linux server.

K12LTSP is based on RedHat Fedora Linux and the LTSP terminal server packages (see Section 7.1.1 for more detail). It’s easy to install and configure. It’s distributed under the GNU General Public License. That means it’s free and it’s based on Open Source software.

Once installed, K12LTSP lets you boot diskless workstations from an application server.

What is Thin Client Computing?
Thin client and fat client (also called “thick” or “rich” client) are mostly marketing terms for different configurations of computer. A thin client asks a central server to do most of its processing, and keeps as little hardware and software as possible on the workstation side. Ideally, the user of a thin client should have only a screen, keyboard, mouse and enough computing power to handle display and network communications — you don’t even need (or want) a hard drive. The less you have, the less there can go wrong.

A fat client does as much processing as possible itself and only passes data required for communications and storage on to the server. A standalone PC is the typical fat client with which everyone is familiar.

A thin client may be a software program executing on a generic PC, or it may be a hardware device, called a terminal, designed to provide only user input and display functions. Because old PCs (whether retired, written off, obsolete or just out of fashion) are easier to find than specialised thin client hardware, Edubuntu labs uses them as thin clients, with the appropriate software. Because they don’t do much work themselves, the hardware requirements for these “old” PCs are very basic. Since every client in a thin client network asks a central server to do its work, all the individual workstations look the same: they all share the same server, and they all behave exactly like the server would if you were using it directly.

In addition, although everyone who uses the lab can have their own computing environment stored on the server, with their own files, desktop, and so on, the individual workstations can’t get viruses or be misconfigured by curious learners — there simply isn’t anything to configure! The thin client doesn’t have enough brains to get confused.

This means that the lab computers are trivial to keep up and maintenance is restricted to the server in the back room.

Thin clients are cheaper and require less administration than fat clients. On the other hand, they tend to require far greater network bandwidth, as display data will probably need to be passed to the thin clients. They can’t do a single thing on their own — for each and every action, they need to talk to the server. This means that a server for a room full of thin clients must be much more capable than a server used by fat clients.

One of the advantages that this configuration entails, is that all the software resides on the server, and so you only have to upgrade it once. In a fat client configuration, every workstation has its own copies of the software, and so any upgrade needs to be rolled out to every workstation.

Drawbacks
Graphics-intensive applications such as games will not perform well, as all the display information will have to be pushed over the network by the server. This is hundreds of times slower than driving a local graphics card. Playing action games, however, is not a goal of the Edubuntu lab project.

Hardware
Minimum specifications for LTSP Client and Server

Server

• Memory The server should have 2GB RAM or more (512MB for the base system, and 50MB for each additional client). As long as you’re using it all up, more RAM means more speed (it doesn’t help to have RAM that you don’t use). Too little RAM will bring your server to a crawl as it starts swapping memory to the hard drive. If you run out of memory, performance will be unacceptable.
• Hard drive SCSI is faster than IDE: We’ve seen LTSP servers slow to a crawl when more than 10 clients are running from IDE drives. SCSI drives are better equipped to handle the multiple read/write requests.
• Network Your server will have at least one Ethernet card to create a private network ( 192.168.0.x). This card connects to a switch for terminals. If there is a school network to which you need to connect, or if the school has a internet connection via the server, it will have a second Ethernet card, which will get an IP address on the second network.

Clients

• Memory Client workstations should have at least 32MB of RAM. Clients aren’t that dependent on swap space for extra memory capacity, since memory usage on them is reasonably constant because they don’t execute applications: they only display them.
• Hard drive Client workstations should not have hard drives.
  Network Each client workstation should have one network card with a boot ROM to enable booting from the network.

DRBL (Diskless Remote Boot in Linux) [2]

DRBL (Diskless Remote Boot in Linux) is a free software, open source solution to managing the deployment of the GNU/Linux operating system across many clients. Imagine the time required to install GNU/Linux on 40, 30, or even 10 client machines individually! DRBL allows for the configuration all of your client computers by installing just one server machine.

DRBL provides a diskless or systemless environment for client machines. It works on Debian, Ubuntu, Mandriva, Red Hat, Fedora, CentOS and SuSE. DRBL uses distributed hardware resources and makes it possible for clients to fully access local hardware. It also includes Clonezilla, a partitioning and disk cloning utility similar to Symantec Ghost®.

Peacefully coexists with other OS
DRBL uses PXE or etherboot, which is similar to Linux Terminal Server Project (LTSP), to boot the client machine. While LTSP is a centralized server, all the client machine users’ access the LTSP server to run their applications on it. The client’s keyboard and mouse are used to input whereas the client’s monitor is used to display the results. This is great when useing a thin client.[1]

The server requirements must be increased when more than 20 or 30 clients are being used. On the other hand, DRBL uses NFS and NIS to provide boot services to the client machines. In essence, the DRBL server is just a NFS and NIS server. All users from all client machines just access the DRBL server to request files or authentication.

Packages are loaded to the client machines and they use their own CPU and RAM for processing. A regular PC can be used as the DRBL server since it is only serving files and authenticating. The client machines, however, should be powerful enough to run the applications they need. Typical installations using DRBL to deploy the Linux classroom have around 30 to 40 clients.

///NOTE/// From LTSP 5.0, there is a fat client (diskless workstation, LowFat client) mode, it’s basically quite similar to DRBL

Save on hardware, budget, and maintenance fees

Hard drives are optional for a DRBL client. Actually, the hard drive is just another moving part that creates more noise and is susceptible to failure. If a hard drive is present, the client can be configured to use it as swap space while GNU/Linux is installed and configured on the centralized boot server.

A lot of time can be saved by configuring the client settings at the boot server when using the DRBL centralized boot environment. This gives the system administrator more control over what software configurations are running on each client.

Besides the diskless (fat/powerful) client mode provided by DRBL, DRBL provides other functions, such as:

(a) Clonezilla, the opensource clone system. It’s a server version of imaging tool, similar to Ghost server edition, True image or Rembo.By using Clonezilla, you can clone a 5.6 GBytes system image to 40 computers within 10 minutes via multicasting.

(b) Small Linux diskless soltion. DRBL provides Damn Small Linux (DSL), PuppyLinux… for clients. You can import those small Linux distributions and let client boot from PXE without hardisk, CD or USB flash drive.

(c) Diskless FreeDOS for clients.

(d) Diskless memtest for clients.

(e) Install GNU/Linux (Debian, Ubuntu, Fedora, CentOS, Mandriva, SuSE…) for clients from network.
LTSP and DRBL each have their own benefits. Choose the one that is best suited to your needs.

What kind of server and client should I buy if I want to use DRBL ?

This depends on what kind of application and GNU/Linux distribution you want to run.
For the education environment, we recommend the following, but faster and newer equipment will always be better, especially if you want to run “moden” GNU/Linux distribution, such as Fedora 7 or Ubuntu 7.04 with OpenOffice 2.x or Firefox 2.x…:

• Server:
  • • x86 CPU at least 450 MHz
    • Memory at least 256 MB
    • Two or more fast ethernet network interface cards (NICs)
    • At least 10 GB HD space
• Client:
  • • x86 CPU at least 200 MHz
    • Memory at least 128 MB
    • One fast ethernet network interface cards

• Fast ethernet switch
  • • An ethernet hub is NOT acceptable. It’s too slow for network booting and NFS. A fast ethernet switch will reduce the collision domain and give you much smoother deployment. The fast ethernet switch should have enough ports for your clients and your server. You can find low cost 12 and 16-port fast ethernet switches just about anywhere. The 40+ port switches are nice but they typically cost more.

Since DRBL will work with any Pentium class hardware, you can start your PC cluster with just about any machine you have laying around. You can expand your cluster as your budget allows.

Where can I download the source codes ?

You can find all the source codes about DRBL/Clonezilla in http://free.nchc.org.tw/drbl-core/src/

Who is the developer of DRBL/Clonezilla?

DRBL and Clonezilla was developed by NCHC http://www.nchc.org.tw

What is NCHC ?

The National Center for High-Performance Computing is located in Hsinchu, Taiwan. For more details, please visit the NCHC website at http://www.nchc.org.tw

What is CloneZilla?

Clonezilla, based on DRBL, Partition Image, ntfsclone, and udpcast, allows you to do bare metal backup and recovery. Two types of Clonezilla are available, Clonezilla live and Clonezilla server edition. Clonezilla live is suitable for single machine backup and restore. While Clonezilla server edition is for massive deployment, it can clone many (40 plus!) computers simultaneously. Clonezilla saves and restores only used blocks in the harddisk. This increases the clone efficiency. At the NCHC’s Classroom C, Clonezilla server edition was used to clone 41 computers simultaneously. It took only about 10 minutes to clone a 5.6 GBytes system image to all 41 computers via multicasting!

Features of Clonezilla[3]

• Free (GPL) Software.
• Filesystem supported: ext2, ext3, reiserfs, xfs, jfs of GNU/Linux, and FAT, NTFS of MS Windows. Therefore you can clone GNU/Linux or MS windows. For these file systems, only used blocks in partition are saved and restored. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla.
• LVM2 (LVM version 1 is not) under GNU/Linux is supported.
• Multicast is supported in Clonezilla server edition, which is suitable for massively clone. You can also remotely use it to save or restore a bunch of computers if PXE and Wake-on-LAN are supported in your clients.
• Based on Partimage, ntfsclone and dd to clone partition. However, clonezilla, containing some other programs, can save and restore not only partitions, but also a whole disk.
• By using another free software drbl-winroll, which is also developed by us, the hostname, group, and SID of cloned MS windows machine can be automatically changed.

Editions
Clonezilla Live: Allows you to use CD/DVD or USB flash drive to boot and run clonezilla (Unicast only)
Clonezilla server edition: A DRBL server must first be set up in order to use Clonezilla to do massively clone (Both unicast and multicast are supported)

Which one is suitable for diskless gaming platform?

So Which one are the perfect candidate for Diskless Linux Gaming Server and Client? My answer is DRBL, why? Because DRBL client is a fat client that doesn’t rely too much hardware dependencies on Server like LTSP Client.

References :

[1] : https://help.ubuntu.com/community/EdubuntuDocumentation/EdubuntuCookbook/ThinClient

[2] : http://drbl.sourceforge.net/about/

[3] : https://help.ubuntu.com/community/Clonezilla_Server_Edition

If you have any question, do not hasitate to post it on our comment form.

Before I go on, a bit of a disclaimer: Following the instructions below may not provide you with results that fit your particular needs. If you have specific and detailed requirements, see the DRBL documentation. If you would like to hire LightCube Solutions to provide assistance in setting up a Clonezilla solution for your organization, send an email to info@lightcubesolutions.com.

The Steps

1. Install Linux

You’ll need a Linux machine to run your Clonezilla services. These instructions were successfully tested on Ubuntu 9.04 and 9.10 and Debian 5. DRBL will also run on Fedora.

2. Install DRBL

First off, open up a Terminal. In Ubuntu and Debian, this is located in ‘Applications -> Accessories -> Terminal’. If you have sudo configured, you can change to super-user access by typing:

sudo -i

Otherwise, use the root password with the following:

su -

Next, add DRBL’s GPG key to your system:

wget http://drbl.sourceforge.net/GPG-KEY-DRBL 

apt-key add GPG-KEY-DRBL

Update your apt configuration so that you can install software from the DRBL guys:

cp /etc/apt/sources.list{,.bak}echo "deb http://drbl.sourceforge.net/drbl-core drbl stable" \  >> /etc/apt/sources.list

Finally, install DRBL:

apt-get update 

apt-get install drbl

3. Configure a Network Alias

DRBL requires that you have two network interfaces. We can get around this by adding a virtual interface:

cat >> /etc/network/interfaces << "EOF"auto eth0:1iface eth0:1 inet static   address 192.168.222.1   netmask 255.255.255.0EOFifup eth0:1

To verify that you have set up the alias properly, type:

ip addr show eth0 | grep eth0:1

You should see something like this:

inet 192.168.222.1/24 brd 192.168.222.255 scope global eth0:1

4. Configure Your New DRBL Server

Run the following two interactive commands (note that this will require an internet connection and may take some time):

/opt/drbl/sbin/drblsrv -i/opt/drbl/sbin/drblpush -i

Congratulations! That’s it, you have a DRBL/Clonezilla server ready to create and deploy custom images. All you need to do to start cloning is run:

/opt/drbl/sbin/dcs

Then, boot up your client machines using PXE. See, that wasn’t too painful…

What a success, actually this is quite late for me to post this, but I just wanna share this with others that’s diskless linux gaming terminal is possible to do. From 5th to 7th June our exhibition our open source software technology at Rompin Fest 2009 was a big success.

Our DRBL Server Specification :

• P4 2.4 Ghz
• 40GB Hard Disk
• 2 x 10/100Mbps NIC
• with Ubuntu 8.04
• Games Installed: Warzone2100/Warsow/Glest/Alien Arena/Tremulous/Savage2

Our DRBL Client :

• p4 1.6Ghz – 1.8Ghz
• 512MB – 768MB DDR1 Memory
• 256MB NVidia FX 5500 AGP
• 1 x 10/100Mbps NIC