Enabling Mass Computing
Priyadarsan Patra (email@example.com)
June 1, 2005
Given below are the specifics, in a nutshell, of what is needed for a Linux terminal server project suited for a village/small-town setting or in a school classroom. This is derived from a education project in USA called K12LTSP. After describing the resources needed of such a project, we will motivate the reason for terminal computing as a means for mass computing. Then we will delve into the mechanics of setting up the project. I have quoted information from various sources liberally.
We need a P3 or better class of computer as a server, while old machines (dirt cheap) such as 486s can be good thin-clients. Server needs two ethernet cards (one to control the thin clients or dumb terminals and the other to connect to Internet) and an UPS. All the basic+ software on this linux machine is free. Only recurring cost is the Internet connection charge. I have recently sent the setup software (for that I have 3 cd-roms which include RedHat Linux 9.0) to Dr. Dhanada Mishra in Gajapati, Orissa. We should get the old 486 or Pentiums from businesses that are discarding them, thus creating a win-win proposition. Thus, our resource needs:
- CPU: One PIII plus class
- RAM: 1 gig or faster RAM: 512mb + (50mb for each client). I propose 4 to 8 clients.
- HD: ATA/100 15+gig IDE
- Network: (2) 100/base cards and a 100base hub (4 to 8 ports)
- Its more fun/useful if we have an internet connection. If we dont we dont even need the second Ethernet card.
- The minimum usable X terminal is a 386/sx 25mhz with 4 megs of ram. While not that fast, it makes a usable station to run a web browser (such as Netscape). Image will display fast enough. Scrolling won't be fast though (some wave effect). While the machine display slowly, the application server has no problem feeding it. One must note that 386 computers are older than the Linux project. We have found that few have unsupported video adaptors (or less than capable ones). Unfortunately, finding replacement video adaptor for those machines is not easy. Those machines are generally using ISA slots.
- Recommended X terminal
While faster is always better, a 486 computer using a Vesa local bus or PCI video adaptor offers a very good performance. Redrawing and scrolling is crisp. For example a DX/2-66 with an ATI Mach32-2meg is a cool station, running smoothly in 64k colors mode. Each terminal needs keyboard/mouse, an Ethernet card and/or a floppy drive. Floppy drive is not needed if the Ethernet card has the boot rom to boot from the network (served by the server).
- The 3 software CDs I can send
- A good admin/teacher, a room, and community support J
Terminal computing Motivation
A common question which is asked is what is meant by "terminal computing" or a "terminal server." Simply put, terminal computing is using a back-end server computer to power "dumb" and cheap client terminals.
The idea is that a common user is using a terminal machine. That terminal does nothing but display output to a monitor and to accept input via a keyboard, mouse (and possibly other input devices, e.g. a scanner). All programs run on the server computer, using the server's memory and processing power. To the regular user, they think they're using a regular PC. They get a desktop, their application work as they normally do, and to the user everything is normal. There are dramatic advantages to this idea of computing; the advantages of terminal computing are:
· Lower client maintenance costs
· Reduced hardware costs by either using older hardware as clients or by buying cheaper terminals instead of full PCs
· Centralized administration of all clients
· Drastically reduced overall administrative costs
Users break things. They might break their computer hardware or they might "break" software. In a typical computer environment servers should run for months without major maintenance. But users machines always need routine maintenance. That maintenance may be reinstalling application programs, or reinstalling the entire operating system or it may be just basic hardware maintenance. Either way, that maintenance costs money.
Terminal computing radically reduces maintenance costs. Many terminal computers have no moving parts (no fan, no hard drive, nothing -- remember, all computing is done on the server). Some will object that such terminals cost almost as much as a typical cheap PC. But those people miss the point. What you're buying is reliability and reduced maintenance costs.
Other people will use old PCs as terminals. This presents a huge cost savings in not having to buy new hardware. With terminal computing, an old 486 or low-end Pentium computer is still a perfectly useful computer!
You also get radically reduced administrative costs with terminal computing. To give all users an application you don't install it multiple times on every user's computer -- you install it once on the terminal server. So instead of 20 or 50 copies of a word processor that an administrator has to maintain, update, and repair, the admin only has to maintain one copy.
Unix systems pioneered the idea of terminal computing and Microsoft has recently copied the idea and produced Windows Terminal Server to export Windows desktops to cheap terminals. However, the software costs of Microsoft's solution are outrageous, both in sheer dollar costs and also in the "cost" of freedom that you give up by agreeing to Microsoft's license agreement.
Linux systems also offer terminal computing and all the advantages its offers. Using a Linux terminal server you can export a full GUI desktop to users with modern applications which any common computer user would feel right at home with. And you can do this for a $0 software cost.
Curious about terminal computing? Read up on what the city of Largo, Florida has done and how they reduced their information technology budget by more than 1/2 over what other typical cities spend.
Overview of a K12LTSP Open Source Lab to setup our system:
A default K12LTSP installation uses two ethernet cards; eth0 and eth1. One card connects the server to your school network. The other card creates a private network for terminals (thin-clients). Your server and eth1 act as a gateway for the terminals to the Internet and the rest of your network. eth1 is configured to get its IP address via DHCP. A private DHCP server runs on eth0 to give IP numbers to terminals. This configuration is flexible in that you can easily have multiple LTSP servers in your building all sharing the same default configuration. Servers are "plug and play" with little or no configuration required. It only takes about 20 minutes to be up and running.
K12LTSP is based on Red Hat 9.0 with a full set of familiar GUI tools for configuring your server. You have the choice of KDE or GNOME desktops and many applications.
Software Included in the K12LTSP/K12Linux Distribution:
We've included a host of useful applications that will make you productive right away.
- Nautilus file manager
- Mozilla browser with Java(tm) and Flash (tm) support
- Ximian Evolution E-Mail, calendar and contact manager
- Adobe Acrobat Reader
- Auto configuration for many PCI based sound cards
- Auto configuration for both PXE and BOOTP clients
- File sharing for both Windows and Macintosh networks
- Much more...
We've included the rdesktop
package that provides access to Windows2000/NT4 terminal sessions with a simple click of an icon. This gives users a choice of operating systems as needed. Note that this option requires a separate W2K/NT terminal server and licenses for clients.
Detailed info on setting up from the 3 disks: Insert disk I into the cdrom of your server machine to install and configure the server. Read the following
Classroom Server 5+ clients
Your server will have two ethernet cards, one to create a private network (192.168.0.x) on a hub for terminals and one to connect to the rest of your network.
You can install LTSP servers with just one ethernet card. They will then live on your network and be available from all over your school. For single card installations we've prepared a list of files to edit to help you with your network settings.
By default the LTSP sever runs DHCP on the client's card (eth0) and automatically gives out IP #'s upon request. It then accepts bootp and PXE boot requests and passes on the Linux kernel to the client. The default dhcpd.conf file will support over 200 clients. All this happens on eth0. The LTSP server will not answer dhcp requests over eth1 (with the default settings.)
Why do we default to a private network and 2 ethernet cards? Thin-clients and servers can generate a lot of network traffic. By isolating this traffic on a single hub and routing only necessary traffic out to the rest of the network we lower the overall impact of clients on school networks that are often substandard in the first place.
Tip: Our classroom LTSP servers are connected to the rest of our school via 10base ports. We NFS mount /home over eth1 and run the clients from a hub on eth0. This works well and gives us a configuration we can easily replicate throughout our building.
It's a good idea to gather some information before you start installing Linux. If you simply click "Next" and "Yes" straight through the install after selecting "LTSP Server" you'll end up with a working server ready to go.
Not advised, but, If you are planning on using static IP addresses and/or just one ethernet card then you'll need to gather some information on your network. See the list of files to edit at the end of this page.
You can skip all this if you're doing a default install. Just plug eth1 into a port and if you have DHCP running on your network your server will be up and running. Connect eth0 to a hub for clients and you're ready to go!
One or two network cards?
DHCP or static IP numbers?
Classroom server or building/lab server?
Hostname of server?
- LTSP - Creates a terminal server for thin-client workstations. Server defaults to an IP gateway/firewall when 2 ethernet cards are present.
For our LTSP install select "LTSP."
Create user accounts later after system booting into linux and allowing you as the root to login for the first time.
eth0 is the interface on the thin-client side of your LTSP server. You will connect this network card to your terminal hub. The 192.168.0.x address is designated as a "private" IP address for internal networks. IP traffic from you clients is routed to the Internet and the rest of your network through eth1.
Note that the server has the last available address in this range, 192.168.0.254. The first client will be assigned IP # of 192.168.0.253.
You won't have to enter hostname info or any of the information in the lower half of the window. These settings will come from eth1.
The default for eth1 is "Configure using DHCP." If you are using custom settings then you'll need to click on the "eth1" tab and configure the card.
(Not recommended: If you're only using one ethernet card then go ahead and enter the information in the bottom part of this form)
Remember that all of this information can be edited later with the standard Red Hat network configuration tools menu.
Test for a working network connections:
Want to know how to see the IP addresses??? Try this simple command from a terminal window on the server: ifconfig . This will show you the current status of any active network cards. (Note: you'll need to be logged in as root.)
For more on Linux network management see our admin guide at: http://k12linux.org/netadmin/
Now that you know which card is which, plug eth0 into the terminal hub and eth1 into a port on your network. Your Terminal Server will automatically manage the IP addresses on the terminal side (eth0) and route all Internet traffic through the second ethernet card (eth1).
If you don't have dhcp running on your network you can assign any static IP address to eth1 via the control-panel. If you don't know how to do this see the admin guide mentioned above. ;-)
To watch your terminals logging in you can run the tail command on your server:
tail -f /var/log/messages - This will let you watch the log file scroll by as terminals acquire IP numbers and login.
Making Boot Disks for Old PCs that will serve as thin-clients
There are two ways a client can boot.
1) bootp - Bootp is used when the ethernet card has a programmed boot rom onboard. You can emulate an ethernet bootrom by booting from a floppy disk created from the http://www.Rom-O-Matic.net site. We've done much of this for you and have included floppy boot images in a folder of your installed K12LTSP server.
Take a look in /tftpboot/lts/boot/bootroms . You'll find disk images there for many popular cards. If you don't see your ethernet card head for the Rom-O-Matic site and download the right image. It's easy to move the image to a floppy. Just type cat eepro100.lzdsk > /dev/fd0 to send the boot image to a floppy disk. (The example uses eepro100 card. replace this with the right image for your card). You can buy ethernet cards with boot roms all ready for K12LTSP from http://www.disklessworkstations.com/ .
Take a fast look at this detailed ZDNet article, which does an excellent job of describing its basic hardware and software ingredients.
Linux replacements for the spendy Microsoft tools.
There are several ways diskless workstations can connect to your server. You can have bootp enabled boot roms on your ethernet card, bootp rom code that loads from a floppy or you can use the PXE boot protocol from a PXE enabled motherboard or floppy. In all of these the process is the same:
- The client boots and requests an IP number from the server.
- The server looks first in the /etc/dhcpd.conf file to see if there is a static address that matches the MAC address of the client. If there is no match then an IP number is issued from within the IP range specified in the dhcpd.conf file. Note that the dynamic range starts at 192.168.0.100. This means that numbers under 100 are good choices for other servers, printers and workstations with static addresses.
- The first step in trouble shooting is to make sure your client is getting an IP number. You can watch this process by tailing the messages file on the server while the client boots: tail -f /var/log/messages
Once the client has an IP number it will then continue booting and ask for its operating system from the server. There are two protocols for doing this, bootp and PXE. The dhcpd.conf file is configured to answer both kinds of requests.
- · The server gives out boot kernels through a program called tftpboot. All kernels are in the tftpboot dir.
There are two ways to add printers. Adding printers to the LTSP server makes them available to all the clients as well. This is the easiest way to do it. Just run the printtool utility and add printers as you would for any other Linux box. You will need to run the spadmin utility as root to configure printers for OpenOfice. This utility is copied to /root/OpenOffice when root runs OpenOffice for the first time. See the Red Hat Customization Guide for more printtool info.
NOTE: If you are having problems printing from OpenOffice, make sure you've set the paper size to letter.
Sound setup and other questions:
If there are any networking problems persisting, we can take care of them after booting the server. The network settings may be changed by the root from the Gnome desktop.
See http://k12ltsp.org/faq.html or, if needed, write to me.
Quote from an article From Washington Post:
In many ways, India is the perfect laboratory for adapting the Internet to development needs, bringing together abundant technological expertise with an estimated 700 million people in 600,000 rural villages. Although telephone lines arent necessary, electricity is, and unreliable power supplies leave many villages without electricity for all but a few hours each day. And some development experts say money used to equip villages with modems and computers could be better spent on primary schools or health clinics.
The approach pioneered by Jhunjhunwala and his colleagues here in the southern Indian state of Tamil Nadu aims to render that debate irrelevant by turning over the job of connecting rural India to the Internet to profit-minded entrepreneurs.
Central to the effort is Wireless Local Loop technology, which provides cheap, relatively fast Internet connections to fiber-optic cables as far as 18 miles away. Although many villages still lack phone service, Indias fiber-optic network is sufficiently well developed to provide wireless coverage for up to 85 percent of the country, Jhunjhunwala said.
He and his colleagues created an independent company, n-Logue Communications, which identifies promising kiosk owners, trains them and provides equipment computer, printer, battery backup and wireless Internet antenna for about $1,000; n-Logue helps the owners arrange financing, which is then paid off with revenue from the kiosks. The company makes its money from hourly connection fees.
So far, n-Logue has set up more than 500 kiosks in Tamil Nadu and other states, with plans for 10,000 by next June.
While most kiosks are run for profit, one of the most well-established parts of the kiosk network is a demonstration project set up with help from HarvardUniversity and the Massachusetts Institute of Technology, and financed in part by Indias ICICI Bank. Situated in the tropical Madurai district of interior Tamil Nadu, the Sustainable Access in India, or SARI, project has so far set up 40 kiosks in rural villages such as this one. The effort has not been without problems, most centering on the failure of kiosk operators to adequately explain and promote their services, according to Joseph Thomas, who manages the project out of a cluttered office at the Indian Institute of Technology campus.
You have to do a huge amount of awareness generation, and some of these guys are just not into that they think its like setting up a betel-nut shop or cigarette shop, Thomas said. If its to become a part of the community, it needs a person who empathizes with the community.