Thursday December 12, 2002 - [ 09:42 AM GMT ]   
Topic - GNU/Linux

- By William G. Canaday -
When my wife asked me to remove Windows and install Linux on her computer, I was happy to oblige. She is familiar with Linux from watching me use it and was quite upset that Windows had lost her desktop photograph -- again. This gave me an excuse to try setting up a terminal / server network. Since we each had beefy desktop machines, this also gave me an opportunity to turn her machine to another use. After resurrecting two retired computers from the basement, we each use a lame workstation as clients to my former desktop machine, now acting as a server only.

I am now looking for a way to dual-boot the clients to Windows to use our hold-out programs from her old machine (which still has Win98 loaded on her HD). This machine will also see use with my old scanner and webcam. The scanner and webcam work flawlessly. I can't justify replacing them with Linux-compatible equivalents until they fail or no longer suit my purposes. I have not yet found Windows terminal software, so the Windows machine sits idle for now. VNC would work, but it can be painfully slow.

With the caveat that the equipment you use should be in good repair (an intermittent ram problem greatly complicated setup for me), I can heartily endorse the Linux Terminal Server Project (LTSP). Once set up correctly, it has not failed in 3 weeks of use. It, as my friend Tom A. on MDLUG says, 'simply works'. I press the power button on the workstation and the monitor. The HP Vectra I am using for a workstation spends most of its boot time checking its bios. Then one quick (4 second) read of the floppy diskette, a quick handshake with dhcp on the server and it's time to login.

The principal is pretty simple. Most desktop machines are wildly overpowered and, even when being hammered on by a 'power user', spend most of their cpu capacity waiting for a user request to do something. The great majority of their capacity is simply wasted. The LTSP allows multiple users to access the same fire-breathing desktop machine and thus put more of it to use without any noticable decrease in performance. It calls for a single strong machine acting as a server to support a large number of truly lame client terminal machines that have been told they are workstations. At boot time, each workstation identifies itself and is passed a copy of the kernel, some networking code and a login splash screen. From that moment forward, all the action is on the server.

The hardware specs are pretty simple, too. The server should be a pretty strong machine. For SOHO use, a single processor machine should work just fine. Load on the ram and give it a 500mHz or better CPU and a decent sized hard drive. Since all the programs are shared and only the data files are unique, a 10 gig hard drive should handle several people unless there are a lot of MP-3's, a large database or large graphics in use. Each adopter will have to establish their own needs in this area. Both ram and disk storage are currently relativley inexpensive; err on the side of too large.

For the client machines, however, the opposite is true. They only need a 486 or slow Pentium cpu, 32 meg of ram and no hard drive. A good graphic card is in order but all of its instructions will be coming over the Network Interface Card (NIC), so extreme capacity here is just wasted. Both ends need NIC's of course and I recommend 10/100 speed cards but don't go spastic about it ... gigabit speeds are not warranted even for gamers. Ten megahertz is probably plenty but, again, 10/100 cards are relatively inexpensive so the vastly greater speed potential makes economic sense. It is possible to buy nics that can login to the server, but I recommend starting with the diskette version until you are comfortable with the whole bundle. The bootable prom is only about four seconds faster at boot than the diskette and not faster at all once things get running. Since there is only one diskette read at boot time that is all the time you would save. Where the bootable prom comes in handy is when security is likely to be a problem and it is useful to eliminate the diskette drive. In my SOHO setting, I can fully trust all the other users.

Neither my wife nor I can tell we are not actually running the server directly. Probably it would take another 20 users before we noticed any loss of speed. This is good. Interestingly, as soon as we started using 'Linux over the wire', my wife noticed that it was faster than running Win98 directly on her (K7-800mHz, 256m ram) machine. My wife is not 'a computer geek'. She wasn't looking for a speed increase ... it was just there boldly enough that it called attention to itself.

The relevant parameters of the equipment we actually use are as follows:

Server: Athlon K7-750, 1.5g ram, 40g HD, 10/100 NIC. Mandrake 8.0 installed, upgraded to kernel 2.4.19, running LTSP 3.0.x

Workstation 1: P5-200, 64m ram, No-brand pci video card, 17 inch svga monitor, MS mouse & MS-Natural keyboard, 10/100 NIC, LTSP 5.0.7 bootrom

Workstation 2: P5-233, 128m ram, ATI pci video card, 19 inch svga monitor, Logitech optical mouse (w/ wheel), MS-Natural keyboard, 10/100 NIC, LTSP 5.0.7 bootrom

You could lower the server to probably 500mHz, 512m ram for office use. On the other hand, if you are buying new equipment, (or supporting more than a few, light weight, uses) you might as well grab additional ram and cpu speed. The workstations could come down to a 486 with 32 m of ram, but we used what we had laying around and would encourage others to take this route. A faster workstation does not alter the overall performance by much as the real work ... all of it ... is done on the server. Did you notice that the workstations do not need a HD? ALL the workstation does is pass user input to the server and display the server output on the local monitor. That's all; and you really don't need much processing power to do that. All the needed code fits easily in the first 32 meg of ram. Spend your money on the monitor and keyboard, if you wish, but go light on the workstation itself. Both of my workstations are horribly overpowered.

How well your first installation of LTSP goes will depend on your general level of computer knowledge, with knowledge of both Linux and networking being at a premium. Most people reading this review in its original form will have the required skills.

Basically, to install LTSP, you need at least one server and one workstation configured more or less along the lines above. Unless you enjoy getting ensnarled in multiple levels of complexity, you should already have a working LAN and the machine you plan to use as a server should already be able to find the internet. In fact, if you can get a LAN working under an existing install of Linux, you have the skills to install LTSP. If you can't, you don't. Adding more workstations is a very simple, and totally obvious, matter of matching up more boot disks with more nics and then wiring the nics to a switch or hub and editing the config files on the server to accommodate the new workstation.

From , obtain a copy of the rom matching your NIC. You may have to do some sleuthing to locate it ... but there is support for well over 100 NICs so your card is probably in there somewhere. Use dd or cat to copy it to a diskette. I prefer dd, but either should work. If you don't know how to use dd or how to find the manual page for it, you aren't ready for LTSP.

From http://www.ltsp.org/ obtain the current versions of:

ltsp_kernel-3.0.5-0.i386.rpm

ltsp_core-3.0.7-0.i386.rpm

to run a text-only server.

To run a GUI server, also grab the current versions of:

ltsp_x_core-3.0.4-0.i386.rpm

ltsp_x_fonts-3.0.0-0.i386.rpm

Most people will want to get the GUI stuff, too.

That's it. Put all four of the .rpm files in the same directory and run them all at once with #rpm -i ltsp.rpm <enter> They are smart enough to run in the correct order. Notice the octothorpe? You have to be root to do this. Find ltsp_initialize and run it. It will create a couple sample config files.

Now go find dhcpd.conf.example, edit it to suit and cp it over to dhcpd.conf. Then find ltsp.conf and edit it likewise. No details about the editing here because there is an excellent series of how-to's on the LTSP website. If you get stuck (after carefully RTFM'ing!) login to the irc channel listed on the LTSP website. The main programmers and how-to authors hang out there. They are there to answer questions, but not to set your machine up for you.

There are four other programs that must be running for this to work. They are dhcpd, tftpd, nfs and portmap. The how-to's tell you how to verify their presence and function. I want you to read the how-to's. That is why I am not detailing them here. In fact, I left a couple details out that will cause it not to run. RTFM.

Who should use this? Linux users looking to expand a network cost effectively or wishing to learn how the client-server model actually works.

What does it take to do this? You'll need moderate skills, one beefy machine, one or more lame workstations, a working internet connection, a working LAN and a handful of freely available program files. If things go well, allow a couple of hours for the first install. Additional machines should come online for about 15 minutes work apiece.

When should you do this? As soon as you recognize that the need may arise eventually. This will probably add to your skills with Linux and that implies a learning curve. Don't wait until your job or reputation is on the line to learn this.

Where is this beneficial? I would tend to think that the smaller business would benefit most. These are the companies that do not yet have a major investment in other technologies and for whom even a small savings is critically important. Competing technologies, such as those from Microsoft, require more in terms of hardware and software expenses with no reduction in training or other personnel costs. Larger companies might want to convert existing installations on a department by department basis at upgrade time. A SOHO should simply embrace it immediately because it greatly simplifies administration and capital outlays. The less tolerance your operation has for waste, the more important the LTSP is to you.

Why? My goodness. If you don't like learning, don't want to save money, aren't interested in simplifying administration and are joined at the hip to some other technology, LTSP has absolutely nothing to offer you. Everyone else should give this a very carefull consideration because all these benefits, and more, accrue to adoption of this technology. It costs little to begin, is greatly expandable, causes even minimalist machines to run like scalded cats, can simply be unplugged at one location and moved to another with very little fuss and no loss of security typical to wireless lans.

The only thing I didn't like about it is that networking problems can mimic hardware problems and it can be difficult to sort them out. Once I got the hardware problem (L2 ram cache developed a nervous twitch) diagnosed, isolated and corrected, LTSP installed like it had eyes of its own. So ... start with known-good hardware. If problems arise, try installing a different workstation. If it works, fix the hardware on the flakey workstation. If it doesn't work, take a fresh look at those config files. Ninety-nine dot nine times out of one hundred, that's where your problem will be. Of course, the other dot one time, you have TWO flakey workstations; or a flakey NIC or a flakey server or bad cabling or ...