Playing with Linux Terminal Server Project

Over the last couple of days I’ve spent some time playing with diskless Linux clients using the Linux Terminal Server Project (LTSP).
I installed Fedora Core 4 as a guest OS in VMware on my JDS3 laptop and then installed the LTSP packages as per the instructions on the web site.
It was a bit of a fiddle to get things up and running, although I seem to be alone in having experienced any trouble! The main culprit turned out to be tftpd. It appeared to be running, but I was getting strange PXE boot errors and the OS wasn’t loading onto the client. The log file in /var/log/messages read Sending NAK (0, permission denied). After a lot of fiddling and some help from a colleague the solution was found: start tftpd manually. First disable it via xinet and then start by hand using the following command –
#tftpd -l -vvv -s /tftpboot
-vvv turns on verbose logging.
DHCP didn’t seemt to want to start at boot time, but starting it manually wasn’t a problem.
My ‘client’ was also a guest OS within VMWare. I found that it would boot up fine with 32MB, but 16MB wasn’t enough.
Once up and running it seemed to function quite well. I need some more memory in my laptop to see how well things run in a more realistic environment.
Once things were set up I grabbed an old Dell from the Sun Dubai office’s ‘laptop graveyard’, set it up to boot from the network, entered its mac address into dhcp.conf on my LTSP ‘server’ and it booted up.
X wouldn’t start on the Dell. The answer turned out to be to configure lts.conf to make it boot into a shell, then run /usr/X11R6/bin/xorg - broadcast. X started fine and I got the Fedora login screen.
Looking at the documentation, I see that it’s possible to configure LTSP to run applications locally if need be, which could be handy if you have very heavy multimedia requirements, although the added administration overhead is considerable.
Apparently K12OS makes things even easier to set up. For some reason I wasn’t able to install this with VMWware though – booting from the first ISO worked fine, but after that the installer seemed not be be able to see the virtual CD drive. If I have a free machine and get around to burning the CDs I’ll give it another go.
Talk to old Unix hands and they’ll sniff that LTSP is nothing but diskless clients, doing exactly what Sun were doing 15 or more years ago. That’s true, but with Linux you have an excellent desktop and a cheap x86 client, which means diskless Unix clients’ younger cousin is much better looking and less expensive to take on. Of course, there’s no reason why you couldn’t use Solaris x86 to do something similar. At this stage though, Linux has better hardware support for the older PCs that are likely to be lying around.
The inevitable question is how an LTSP setup compares to a Sun Ray setup.
What I liked about LTSP –
* It’s free and Free, a fantastic effort totally built on volunteers’ contributions
* It works on old PCs that are lying around
* It seemed to work well without too much fiddling. As I said above, my issues don’t seem to have affected other people.
I can imagine for a small office or classroom it would be an interesting option.
I think where Sun Ray wins over is in its general simplicity and easy manageability – ‘it just works’. You have nothing to manage at all on the desktop. You have smartcard based session mobility, load balancing, ability to run over certain low bandwidth connections and the option of Linux or Solaris to deploy on.
There are also ‘soft’ advantages – no fan noise, minimal amount of electricity used and the fact that there’s nothing to steal.
I’m sure you can buy support from local IT companies for LTSP, but there’s no support for it in the way Sun supports Sun Ray.
A 50 seat LTSP deployment would still need a fair amount of local configuration, especially if you have disparate models of client. Over 5 years I can imagine the client hardware needing replacing for various reasons and each time a new version of client hardware is introduced you’d end up with more complications.
Take a 100, 500, 1,000 or 1,500 seat deloyment and you’d start to spend a lot more time looking after your client hardware, whilst battling with a lack of proper load balancing on the server side.
A 500 seat Sun Ray deployment should still be dead easy to manage. Our largest regional customer has 1,500 Sun Rays in a large hospital. Being able to breeze around from ward to ward and insert your smartcard to access your session quickly from anywhere saves a huge amount of time. Not having any worries about client hardware means the admin now spend their time managing things centrally instead of racing around the buildings fixing broken PCs. Expand the scenario to a company like Sun, with 27,500 thin client desktops and LTSP simply wouldn’t scale in the way large Sun Ray deployments do.
I’m always in favour of using the right tool for the right job. Just because something’s on the Sun pricelist doesn’t mean we should shove it down a customer’s throat. That approach always backfires. I can definitely see where LTSP fits. For most of the business customers I spend my time with however, I can’t see it being a popular choice.
Where local skills are good, the number of clients is small and budgets are non-existent, LTSP would make a good solution.

2 Responses to “Playing with Linux Terminal Server Project”

  1. William R. Walling Says:

    I would take your Sun Ray ware over LTSP for the many reasons explained.
    Review the new WYSE S50/V50 thin clients, their first CHINA (1Mhz Crusoe CPU) owned ware.

  2. Christopher Saul Says:

    Glad to hear it šŸ™‚
    I’ll have a look at the new Wyse boxes…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: