IT solutions companies have been generating lots of buzz regarding thin clients basically since the early 1990s, but have yet to really penetrate into many suitable environments. These relatively cheap computer appliances carry broad promises like energy efficiency, space efficiency, and centralized maintenance and data storage. These claims could sound like the computer industry equivalent of snake oil. Kiwi-LTSP, a combination of KIWI imaging technology and Linux Terminal Server Project, is one open source solution for thin client servers.
Why do thin clients or terminal devices matter? For general consumers, home users and office computer users thin clients should have no visible impact. This is nothing new, as companies like Sun, HP, Dell, Wyse and Citrix have always promoted thin clients, dumb terminals and the like from a support perspective. Check out Sun, HP and Wyse product descriptions here, here, and here respectively. In my own experience supporting Windows desktops in an Enterprise environment we were always looking for ways to improve maintenance and customer experience without user interaction.
Allow me to elaborate. The advantages of thin clients make me think of three support issues from my former support job. The first is our roll-out of Windows XP for all users. To fulfill New York State computer security requirements, we updated computers using any OS that did not support limited user accounts. Mostly that meant refurbishing or replacing systems running Windows 98, which offered almost no security. Computers could not be bound to the domain, users were not subject to Active Directory policies (meaning they ran as administrators) and users had to manually update Windows.
I think of supporting Windows 98 in such an environment like a bad rash caused by an allergic reaction to a snake oil. Users treated their computers like home machines, installing such useful business applications as Kazaa. Beyond the support issues, the machines were quite capable of performing their required functions: Outlook email and calendar, web browsing and our in house text only database software. However, much of this functioning hardware had to be replaced. I don’t mean that Windows 98 era hardware should still be used, but that today’s Windows XP hardware is in a similar situation. Windows XP is at the end of it’s support cycle and most Windows XP computers cannot acceptably run Windows Vista. The life of much of this aging hardware could be extended using LTSP.
Even after completing the Windows XP rollout there were some rough areas. Local machines had to be powered on for automatic updates to occur. Since we couldn’t rely on users leaving their workstations powered on at night, we set computers to update at noon. Unfortunately we had a large number of baffled users calling wondering why their computers would slow to a crawl around noon or why they were being interrupted every 10 minutes by a message asking them to reboot.
Another issue we dealt with was user data backup. Most user’s documents and settings only existed on their local machines, and some users were given access to shared folders for their data. Requiring users to consciously backup data is not the best solution and lead to data loss.
A third problem area was support of a large number of public computers that utilized ‘Guest’ logins. Because these computers could not be joined to the domain they required a technician on-site to manually update individual computers.
Kiwi-LTSP is probably best suited for this last scenario. Libraries and schools often offer basic computer access to citizens or students for research, web browsing, email and word processing. Libraries and schools, working under tight budget constraints, tend to utilize computers longer than many commercial environments and attract donations of rather old computer hardware.
Setting up the Kiwi-LTSP server on my desktop (2.2GHZ Intel Core2Duo and 2GB Ram) running OpenSuse 11.1 took less than an hour following the quick start guide. I installed KIWI-LTSP version .70 based on LTSP5, which has support for some very interesting features like running some applications on the client hardware. The most difficult part was setting up my network switch on KIWI-LTSP’s network interface. Even then I only had to disable it’s DHCP server. For the client I hooked up my serviceable IBM x22 which has a PIII 733 and 640MB of ram. On its own it can run lightweight Linux desktop environments like XFCE or LXDE, but chokes and sputters with KDE4 or Gnome.
It booted about the same speed as it usually does according to my subjective test. In KDE4 (my default on my desktop) and Gnome it was quite responsive and usable, if not quite as fast as the desktop itself. After logging in, my KDE session loaded and all of my applications and data were available. All of my settings from my desktop were preserved, no need to setup Kontact again, change the color scheme, add widgets to the desktop or sync my documents. I could play music from my server’s music library in Amarok and run all of my preferred applications instead of their lightweight alternatives. Microsoft Office 2007 ran under WINE and even my VirtualBox virtual machines were accessible. KIWI-LTSP can even be configured to connect the client to a remote desktop server.
I did run into some trouble with regards to keyboard settings. My server uses a standard US keyboard but my client uses a Japanese keyboard. Unfortunately using KDE 3 or KDE 4.2 many of the keys showed up as numbers, which were not even consistent with the differences in layout. While using GNOME this was not a problem and we were unable to track down why the problem only seemed to exist in KDE. While trying to sort out this problem I did discover that the project maintainers lead by Jigish Gohil known as CyberOrg provided some great support. One should also note that the Ubuntu LTSP project appears to have more detailed documentation.
The keyboard problem also prompted me to literally pull out some hardware that I had designated for the scrap heap for further testing. I confirmed that when using the same keyboard layout as the server there were no issues. Even considering my small corner case issue this implementation of a thin client server met my expectations and impressed me with its ease of installation.
The KIWI-LTSP troubleshooting page suggests that a client machine with at least 256MB of RAM should be used. This strikes me as low end, but not extreme. To see if KIWI-LTSP could be used to re-purpose near junk hardware I uninstalled my 512 MB Ram upgrade, and booted my laptop with 128 MB of Ram. Amazingly, my laptop still responded like a spry and much more youthful machine. No doubt if I were serving more clients this performance could deteriorate, but the KIWI-LTSP page does claim that a server should be able to serve 5 clients per 1 GB of memory. Even serving 10 to 20 clients at reasonable performance would be a significant cost savings in terms of hardware and support costs.
Utilizing KIWI-LTSP in a typical office environment also has advantages. Centralization of user data is an excellent way to ensure data is backed up. Only the data from the server would need to be backed up. Further, such a setup would offer a more efficient use of hardware horsepower. In most modern usage environments CPUs rarely maintain 100% utilization for extended periods of time. Sharing the processor(s) of the server or cluster would allow that usually unused portion to be distributed as needed.
In both cases administrators only need to update software on the server. Also operating clients without disks removes one more fail point and reduces its energy footprint. I could see potential problems in scenarios involving high performance computing environments (although there is an interesting project called Icecream which is beyond the scope of this article) or heavy reliance on proprietary Windows software. While many Windows programs can be run in WINE or virtualized, licensing restrictions could undermine the benefits.
KIWI-LTSP is a very useful tool and even if it isn’t really the “Fountain of Youth” it did breathe some more life into my aging laptop. Certainly at a time where many organizations are plotting their upgrade paths and deciding the fate of aging computer workstations and questioning the need to be Microsoft shops, KIWI-LTSP should be considered as a viable alternative to new hardware and software acquisition. Thin client solutions definitely have the potential to save an organization money in terms of support costs, re-purposing aging hardware and even new hardware acquisition.
About the author:
I am a Computer Support Contractor, who is always exploring interesting information technology solutions.
I have had great success with Open Thin Client ( http://openthinclient.org/home )who just released their 0.4.1 release, ( http://openthinclient.org/article26 ).
I highly recommend it.
Thin-clients have their uses. However, if you want to do anything beyond simple web browsing and office document work, you just can’t use thin-client setups. All the processing is done on the server, and the output is pumped down through the network. Try doing anything with audio, 3D, full-motion/full-screen video, or even a lab full of students hitting youtube, and you can bring even a gigabit network to a grinding halt.
Diskless setups are where it’s at. You get all the administrative benfits of a thin-client setup (all the software is installed on the server), but you get all the benfits of local PC (all software is run on the local CPU, using local RAM, local video/soundcards). You still have systems with no harddrive, no optical disk, no floppy, basically just a motherboard and case. But you can do so much more!
We’ve migrated our local school district off Windows and onto LTSP … and then over to a diskless setup using standard Debian 4.0. With full nVidia 3D support, local sound, full USB support, basically everything you can do with a local install of Debian.
Thin-client has its uses … but it’s days are really numbered in Unix-land.