December 12, 2002

Making a home terminal/server network with LTSP

- 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

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 ...

Category:

  • Linux
Click Here!