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 ...
Note: Comments are owned by the poster. We are not responsible for their content.
Another M$ bigot!
So he left details out, you know why? Because if he had not left any details out then he would have had to cover everything from installing Linux on the Server, then about configuring the entire network and none of that is relevant.
This is a good article becuase it stays clear of too many distro-specific details. There are a few specific details but anyone not running a RedHat-like distro will Know What They Are Doing so this is not a problem.
On a side note, I expect you have written a really good terminial server, low cost, solution using Windows, yes?
Another M$ bigot!
So he left details out, you know why? Because if he had not left any details out then he would have had to cover everything from installing Linux on the Server, then about configuring the entire network and none of that is relevant.
your childish profanity
I think you wrote an excellant article and you can safely ignore the troll how seems to have slight problems with it.
Please, please, please could people stop complaining about SPAG (spelling,punctuation and grammer), the content was great and the prose was very readable - who really minds if there are a few little language errors (I know I can't spell so good and I'd like it if I could post stuff here without worrying about whether I've made mistakes spelling words).
Well done, keep up the good work and keep us all updated on things that might be of interst.
Ok, so I called you a M$ bigot. I'm truly sorry. I did get the impression that you weren't just a M$ guy. I will try to be a little more subtle in future.
The point I was making is that you did sound a bit like a bigot, a regular slashdot poster. You did raise some valid points though.
I also agree with that about the ISP guy - he should have been kindly poiting people to the good docs without flaming them for asking the wrong questions. This is a Linux geek thing (well, not just Linux - maybe just a geek thing<nobr> <wbr></nobr>;) and I want it to stop as much as you do.
Our hero article writer, though, didn't really take such an atitude - he was writing documentation and refering to other documentation - that's the recursive nature of information. I think he did very well. He may have used the term RTFM but I thought in a jokey-sort-of-way, so lets all lighten up a little.
I once endured a very long conversation on #gentoo about whether Linux should be refered to as GNU/Linux or not (with some strong views about 'clueless users' who didn't know that Linux was just the kernel) - how cares? I personnaly think GNU should have at least the recognition to call Linux GNU/Linux, but the argument repells people who percieve the whole community as petty geeks when in fact most of us are very nice geeks<nobr> <wbr></nobr>;)
octothorpe?
Posted by: Anonymous Coward on December 12, 2002 06:45 PMWhat you need is a good bitchslap. And fast.
ps, hope the two bits you got for writing the article was worth exposing yourself as the ahole that you show yourself to be.
#