LTSP for Libraries Howto

by Cindy Murdock, Network Administrator
Meadville Public Library & Crawford County Federated Library System
Email: cmurdock at meadvillelibrary dot org


Thin clients running free open source software are a great alternative to expensive, proprietary computer systems for libraries and other non-profit entities. Since thin clients get their operating system from a central server, general maintenance as well as drastic changes can be made to all the clients at once, usually without having to reboot the server or the the thin clients. This lessens downtime as well as saves staff time. Also because of this server-centralized setup, less hardware is required for the thin clients, making them less expensive and maintenance-intensive than conventional computer systems.

There are a few downsides, however. At least one staff member will need to be intensely familiar with the Linux operating system and the various programs being used. Also, some staff training will be required to familiarize them with at least the basics of the new systems. Some time may be required to assemble and develop the new system, though hopefully with this document youīll be able to get a system up and running in much less time than it took me, as much of my time was spent researching how to accomplish setting up the system exactly as we wanted or in how to fix certain problems I encountered. In my searches I could find no documents out there geared toward library use of thin clients, or even conventional Linux systems. Much of what I found I culled from discussion lists, newsgroup archives, and a few documents on setting up systems as Internet kiosks. I also got invaluable help from the subscribers of the LTSP discussion list, as well as the icewm discussion list. One of the most wonderful things about open source software is that you can frequently communicate directly with the author of a program to solve a problem; try doing that with a proprietary product from a large company! The versatility of open source software is incredible; I wouldn't have been able to accomplish what I did with proprietary software, at least not without a lot of expense.

This discussion assumes that the reader has at least a marginal familiarity with Linux, i.e., a familiarity with its file structure, basic commands, etc. This discussion also assumes that you have installed the LTSP software version 2.0 on Red Hat 6.2. I realize that there are newer versions of both LTSP and Red Hat, but that is what I used so that is where my expertise lies. In addition to Red Hat, LTSP also will work under numerous other Linux distributions. My goal here is to relate my experiences in implementing this type of system, and to provide information on specific issues and problems relating to it, including tweaking the user interface. For specific information on implementing LTSP, refer to the documentation at Also for questions regarding the newer versions of LTSP and/or installing it on other linux distributions, LTSPīs Discuss list and their archives is an excellent place to get information.

The Hardware

Our server was custom-built for us by a local merchant; it has 512 MB RAM, a 750 mHz Athalon processor, a 15 GB hard drive, and two network cards. One of the network cards is connected to the libraryīs internal network, and the other is connected to a hub connected to the the thin clients. The thin clients are really just like regular computer systems, except they lack a hard drive or other disk drives, and they have a special network-bootable ethernet card. When the thin client is switched on, instead of searching for a disk drive to boot from, it searches for either a BOOTP or DHCP server from which to get its operating system; the server is configured to listen for BOOTP or DHCP requests only on the network card that is connected to the thin client network, so as not to confuse other computers on the rest of the library's network. After sending the request to the server, the operating system is then stored entirely in the thin clientīs RAM, so not much computing power (or hardware) is required; just a motherboard, a video card, a network card, and some RAM. The advantage of this is that you can reuse old computers, or save money by not having to purchase full computer systems each with or without liscensed operating systems. Our thin clients (which are probably much more powerful than really necessary) have 500 mHz processors, 8 MB AGP ATI 3d Charger video cards, 64 MB RAM, and bootable network cards purchased from (the company is run by the same fellow who runs the LTSP). If you donīt want to purchase special network cards, you can burn your own eproms to install on other network cards, or for an easier solution, use custom floppy boot disks. (See Appendix A for directions on how to create bootable floppies.) The cost of our server was $1485, and the cost of our thin clients were $327.75 each. We reused old cases and power supplies on the thin clients to save a little money. The cost of monitors is not included in these figures. If you would just rather buy the thin clients rather than building them yourself or reusing existing systems, you can buy them from DisklessWorkstations; I believe you can also use certain Internet appliances such as the Nic or the iPaq, with some modification. I have heard of people using old 486's successfully as well. The LTSP Discuss list and its archives are the best place to look for information on thin client hardware, and for making your own bootable network cards and floppies.

Our thin clients are at present primarily intended as Internet stations for public use. We wanted them to have access to Netscape and the major plugins; we also wanted to provide printing capability. In addition to Red Hat and the LTSP software we installed the icewm window manager, Netscape Navigator 4.76, Adobe Acrobat 4.05, Macromedia Flash 5 Player, and plugger, which handles various types of video and audio files (though we don't have sound cards in our thin clients, I believe that sound can be provided on them). We also use squidGuard, an open source filtering program that works in conjunction with the squid proxy program, to filter sites that violate our acceptable use policy. Squid and squidGuard can be installed directly on your thin client server if you wish, but we already had it installed on a separate router/proxy server so I didn't bother setting it up on the thin client server.

Video Cards

One of the first problems I encountered was with video cards. If you're using a different type of video card on the thin clients than the one installed in the server, you will need to generate a separate XF86Config file for each type of card. This is something of a pain since you can't generate the file from the thin client; you actually have to have the video card that you want to generate a file for installed in the server itself. When doing this make sure you save a copy of your original XF86Config file, because it will be overwritten when you run Xconfigurator!

You also must be careful about what type of cards you buy; the first batch of cards I tried (Trident Blade3D's) worked perfectly when installed in the server, but they refused to work correctly on the thin clients. The next batch of cards were ATI 3D Rage IIC's, and they worked perfectly on the thin clients. Your best bet is to do a little research to find out which cards have a history of being well-supported under the X windowing system and to try to get cards that have been around for a year or two. The nice thing about getting one- or two-year-old cards is that you will be able to get them a bit cheaper than the latest cards; however, you may have a hard time finding them, or finding enough of them to put them in all your thin clients. Try looking at for information on card support, and check (or ask) the LTSP discussion list about which cards to use. Recently someone posed this question on the list, and ATI Xpert 98 cards were recommended, or any cards with Nvidia chips. They also recommended avoiding cards with SiS chips. A good place to find vendors and do price comparisons for video cards is at It's probably a good idea to get a few extra in case one goes bad in the future, since you may have even more difficulty finding them at a later date.

The User Interface

There were several criteria we wanted to meet in the user interface; we wanted to limit the Internet stations to just a browser and a few plugins. We didn't want our patrons to have access to the filesystem or to other programs; we didn't want them to be able to download and install programs; we didn't want patrons to be able to change browser preferences such as the homepage or the proxy server settings; and we wanted to provide printing capability. Basically, we wanted to keep the user experience as simple as possible.

Initially, I tried running Netscape without a window manager. However, popup windows posed a huge problem. When Netscape is run without a window manager, popup windows take over the entire screen and cannot be closed. The only way to get back to the main browser was to press Ctrl+Alt+Backspace and log in again. Of course, in doing this you lose your place. At first to remedy this I found a program called Muffin ( which can be used for a variety of purposes, some of which are removing cookies, GIF animations, and ads. I was able to use it to change the "toolbar=no" statement within the javascript argument to "toolbar=yes", so that the popup window would still have a toolbar, to which I added a button for closing the window. Still, this didn't work all the time, and after a lot of research and fiddling around, I discovered that the toolbar argument didn't need to be specified, and Netscape's default, if it is not specified, is to have no toolbar, and I discovered that this default could not be altered in any way without turning javascript completely off, which would vex quite a few of our patrons.

So, to skirt this issue, I started looking at some of the minimal window managers, like blackbox, fvwm, and icewm. I narrowed my choice down to blackbox or icewm, joined their respective mailing lists, and posed the question of how I could limit the user interface. My initial preference was for blackbox, but the only way I could remove some of the unneeded features was to create a patch for its source code, and recompile it. To their credit, someone on the list did send me a patch that would probably have done just what I wanted. [Note: since then I have discovered that someone has put together a package called PANACEA ( that has a tweaked version of blackbox, a copy of Netscape Navigator, and that implements some security features, which could probably be used with LTSP with some modification.] However, in the meantime I figured out how to get rid of the unnecessary features in icewm without having to patch/recompile, so I went with it instead. Someone on the icewm list also suggested that I could add a few lines of text to my .Xclients file that would restart Netscape if someone closed it, so patrons would rarely be faced with a totally blank screen. (On occasion, Netscape crashes, leaving a blank screen. I think this may be due to a dead Netscape process still running in the background under the user account. When this occurs, you can right-click on the desktop, choose Logout, and then log in again. That's much faster than rebooting the whole machine!) Using icewm also helped remedy a problem we had with the keyboard locking up when someone would be filling in a form on a web page. The keyboard would still work, as you could press Ctrl + Alt + Backspace and get back to the login screen, but you couldn't type anywhere within Netscape. We found a workaround by sizing the Netscape window so that there was a narrow strip of desktop visible to the left of the browser window. If you right-click on this, then choose Window List and click on Netscape in the window that appears, the keyboard focus will return to Netscape and you will be able to type.


Netscape isn't the most stable program around; in fact, it's probably the weakest point in this sort of system. However, in looking at the other browsers available for Linux, I couldnīt really find a program that offered the same level of support for the various plugins we wanted to provide, or for the various common scripting languages out there on the net. So, I went with Netscape. Also, since we had Netscape installed on our old Internet stations, it was at least familiar to our patrons. By now, things may have changed; browsers for Linux and support for plugins seems to be improving quickly.

Next came the decision of which version to use. I found the new versions of Netscape and Mozilla to be slow and unstable (though things might have changed since I last attempted using them). Originally I used the version of Navigator that came with Red Hat 6.2, but I noticed it produced a lot of zombie processes (dead processes or programs that take up CPU time). I also read reports of there being problems with the versions of Netscape that came preinstalled with Red Hat, specifically having to do with that version of Netscape being compiled with an older version of glibc. This same report advised using a version of the browser downloaded directly from Netscape, so I settled on using Navigator 4.76. I chose Navigator over Communicator since I had no need for the extra features of Communicator. Since I began using Navigator 4.76, there seem to be a lot fewer zombie processes. To take care of any of Netscape's zombies that do crop up, I installed a script from the LTSP contribution page (the URL is at the end of this document) that kills off these processes and emails me a notification that it has done so. I used a crontab entry to automatically run the script every five minutes.

User Accounts

You will need to create a user account for each workstation that you have. You can log into any user account from any of the workstations, and you can even have more than one workstation logged into a single user account at the same time. but Netscape doesn't like running under one user on more than one workstation at a time. So, what I did was assign a simple user name to each workstation (m1, m2, m3, etcetera, "m" representing "main" since the thin clients are on the library's main floor) and I used the user name as the password, so it would be easy for staff to remember. To ensure that the user accounts could not be tampered with, I changed the ownership of most of the configuration files within each user's home folder to root, and also made sure they were only writable by root, in particular the .Xclients, .Xdefaults, and .bash_profile files, the .icewm folder and all the files within it. The .netscape folder, on the other hand, doesn't seem to like being unwritable, as do many of the files within it. However, several things can be done to keep patrons from changing settings, and to ensure that it will continue to work correctly. Firstly, I made a plugins folder within the .netscape folder, and chowned it to root and made it so that the user couldn't write to it. This prevents patrons from installing plugins on their own. Secondly, once I had configured Netscape to my liking, I changed ownership of the preferences.js file to root and made it read-only to the user. That way the user is unable to change Netscape's configuration. Thirdly, I wrote a script that would replace the cookies file with an empty cookies file, and made a crontab entry for it that would run each night. Sites like Hotmail sometimes save a user's place with a cookie file entry, and if the user abandons their Hotmail session in the midst of, for example, signing up for a new account, the resulting cookie prevents other users from using the site normally. If you don't want to deal with cookies at all, you can alternately make the cookies file read-only and chown it to root, being sure to remove the lines containing cookies also.

Tweaking Netscape

Due to Netscape's plain-text configuration files, you can customize its appearance considerably for each user account. You can get rid of extraneous toolbar buttons, change the function and/or labels of certain toolbar buttons, and change how the mouse functions (so no one can right-click and save, etc.) Most of this is accomplished through the .Xdefaults file in the userīs home directory. The Link below is an example of an .Xdefaults file, annotated with each section's function. Exclamation points are used to denote comments in this file.


This information was culled from several resources, namely Slashdot, the Mandrake Users Organization, and the Public Web Browser Howto. Addresses for these sites follow at the end of this document.

The other major file that can be used to customize Netscape is the preferences.js file in the user's .netscape directory. After altering this file it must be made read-only, as Netscape will override your changes the next time it is started. If you want to customize the Search button on the toolbar to point to a url of your choice, you can add this line at the top of the file, just after the two lines of comments at the top:

config ("internal_url.net_search.url","");

Note, however, that if in the future you make preferences.js readable in order to change Netscape's settings through the Preferences window, the above line will disappear and you will have to re-enter it. However, most of the changes that you can make through the Preferences window you can change by directly editing the preferences.js file instead, eliminating the need in most cases for making the file readable again.

You can also hardwire a default printer for Netscape to use by adding this line to the bottom of the file (or altering it if already present):

user_pref("print.print_command", "lpr -P your_printer");

IceWM Configuration

I chose to use the Icewm window manager because it can be configured easily via a number of plain-text configuration files, and those files can be secured from user changes by making them read-only. Its configuration files are located in the .icewm folder within each user account. The files are as follows: keys, menu, preferences, toolbar, and winoptions.

The keys file: This file contains definitions for a number of keyboard shortcuts. I got rid of them all by commenting them out by putting # in front of each line. I did, however, add one for a printscreen script, so users can print a screenshot. This is useful since occasionally some types of web pages (in particular, .asp files) refuse to print normally. The line I added for this is as follows:

key "Alt+p" /home/m1/printscreen

The printscreen script itself is very simple, and is as follows:

if["$1"]; then
	xwd | convert xwd:- ps:- | lpr -P$1
	xwd | convert xwd:- ps:- | lpr

All you would need to do is cut and paste that into a file, name it "printscreen", save it, and make sure that it's executable.

The menu file: This file defines programs available through a right-click menu on the desktop. Since I didn't want any of these programs to be available to users, I renamed the original file "menu.old" and created a new empty "menu" file. Note that there are a few items left in the right-click menu, but these only consist of a Logout option, a Window List (which opens a list of programs the user is running), and an About Icewm item.

The preferences file: Allows you to alter icewm's appearance and behavior. The lines I changed from the default are as follows: The zeros turn off a particular function, the ones turn them on.

SizeMaximized=0 (Disallows resizing of maximized windows)
ShowWorkspaceStatus=0  (I believe Icewm has a default of 4 workspaces)
QuickSwitch=0   (Quickswitch allows the user to move from program to program with a keyboard shortcut)
EdgeSwitch=0  (When turned on, allows the user to switch to another workspace by moving the mouse pointer to the edge of the screen.)  
EdgeResistance=10000  (Keeps users from moving a window off the screen)
DesktopMenuButton=3  (Brings up the menu as described in the menu file with a right-click)
TitleButtonsLeft=""  (This and the next item allow you to decide which buttons appear at the top of the window; i.e., close, minimize, maximize, etc.  I only allowed the close button, which is in the next item.)
KDEDataDir=""  (We don't need this as we're not running KDE applications.)
LogoutCommand="/usr/bin/slay m1"  (Replace m1 with the account's user name.)  Slay is a handy little program for killing off all programs being run by a user all at once. The url for downloading it is in the list of resources at the end of this document.
ShutdownCommand=""  (If this were available, it would shut down the server!)

Also, I removed all of the keyboard shortcuts defined in the KeyWin and KeySys items at the bottom of the preferences file. Don't delete them, just clear out whatever is between the quotation marks, so that they look like this: "".

The toolbar file: This defines what is at the toolbar at the bottom of the screen. I commented out each line. However, this isn't really necessary, so long as you have "ShowTaskBar" set to 0 in the preferences file, to get rid of it altogether.

The winoptions file: I didn't make any changes to this file. It just defines options for various programs, most of which we aren't using anyhow.

Appendix A: Creating Bootable Floppies

Firstly, go to, preferably in Netscape. Click on the link for the most recent production release of rom-o-matic. From the NIC/ROM list, choose the type of network card that is installed on the computer you want to turn into a thin client. Then click on the Configure button if you want to make changes to the disk image's configuration. The default should be fine; however, I usually uncheck the MOTD, Image Menu. If you make any changes on the configuration page, click on Save Changes at either the top or the bottom of the page. Once you're back to the page where the ROM is generated, make sure that the ROM output format is "Floppy Bootable Rom Image" (that's the default, but look just to be safe), then click on the Get ROM button. When the Save As window pops up, click on OK.

Once the download has finished, go to a command line, and put a blank disk in the floppy drive. Go to the folder where you saved the disk image file. Then type in the following command:

dd if=the-name-of-the-ROM-image of=/dev/fd0

The name of the boot image will be something like eb-5.0.3-yournetworkcard.lzdsk. Hint: you can save yourself from having to type in the whole filename by typing in a little of the beginning of it (i.e., "eb-" or somesuch) and hitting the tab key. If there isn't another file with a name beginning with the letters you type, it will fill in the rest of the filename for you. Then you can just finish typing in the rest of the command and hit enter.

When you are done, and once you have configured your thin client server to accept boot requests from that particular network card (see the LTSP documentation on how to do that), pop in the boot disk and see how it works. Note: an easy way to get the hardware address of that particular network card is by putting in the boot floppy and turning the machine on, regardless of whether it's configured or not. You will see the hardware address displayed on the screen.


a tarball of my configuration files

See the readme in the tarball for more details. You might be able to use these to get up and running, with some customization for your particular setup.

Related Sites


The main page of the Linux Terminal Server Project.

Diskless Workstations:

Sales of bootable network cards as well as entire diskless workstations. Owned & operated by Jim McQuillan, who founded the LTSP.


Here you can generate disk images for network-bootable floppies.


Package containing a tweaked version of blackbox, Netscape, and security features that could possibly be implemented for use on thin clients.


Script to kill off extraneous Netscape processes. Could be modified to kill off other troublesome processes also, if necessary.


Homepage of the icewm window manager.


Homepage of the Blackbox window manager.

Sites for Tweaking Netscape with .Xdefaults:

A discussion on Slashdot:
The Public Web Browser Howto:
Mandrake Users Organization:


A handy program for killing off a user's processes.


Can thin clients work in your library? -- Memorial Hall Library, Andover, Massachusetts