This and its linked pages are here to guide you in to creating your own Debian-Live based thin client server. The benefit of such an approach is that the clients run the software directly on their hardware which means direct access to sound, video and other local I/O devices like USB.
Howto Sections
DebianLive/Howto/Starting X11 Applications in Chroot and chroot'ing for client image customization.
DebianLive/Howto/Network User Authentication and mounting home directories and printers.
DebianLive/Howto/Network LDAP Authentication and mounting home directories and printers.
DebianLive/Howto/Netbooting Servers such as a netboot caching server.
Common Problems
Commercial Support Vendors
The following vendors offer commercial support of Debian Live Netboot:
- Safedesk Solutions, Inc.
Hardware Suggestions
Clients
Clients should have at least a 400 MHz CPU to have a reasonably tolerable experience with OpenOffice and other heavy applications. 128 MB of RAM is the minimum amount which can be used in a Debian Live environment. You should consider upgrading the clients to 256 MB of RAM to avoid the possibility of an "OOM Kill" (Out of Memory Kill) condition that would indiscriminately kill processes on the client to free RAM. Also see DebianLive/Howto/Local Swap File.
Ideally, clients should have PXE-bootable NIC cards either as an add-on card or built in to the motherboard. In cases where this is not possible, rom-o-matic.net can be used to generate a floppy or CD-ROM image which can be used to get the client to the server.
Here are some hardware vendors that sell fanless, hard drive-less clients which meet the requirements above:
- Devon IT
Server Size
Servers should emphasize RAM. Any RAM not being used for programs is used as hard drive cache. Since the server is only acting as the root filesystem for the clients, the most important factor is delivering requested files as quickly as possible. The more RAM, the faster this will occur.
A typical Netboot root file system is 2 GB - 3 GB. However, during a client's lifetime, it's actually only likely to access < 1.0 GB of that. So a server with 2.0 GB of RAM should be more than sufficient for any network layout.
The limiting factor in any setup will be the amount of bandwidth needed. During a typical boot sequence, clients access roughly 150-200 MB of data from the root filesystem. So, if the server has a gigabit NIC card available:
1,000 Mbits / 9 (for overhead) = roughly 111.11 MB per second on a gigabit network.
If you want the clients to be able to all boot in under 2 minutes then:
200 MB / 120 sec = 1.67 MB/sec required for each client
So that allows for a maximum of:
111.11 MB/s max / 1.67 MB/s/client = 70 clients max
As for other hardware considerations, NFS servers require very little CPU power, so you should safely be able to buy the least expensive CPU available.
Consider buying a RAID 1 or RAID 5 configuration for data integrity.
Background
(this section was written by JasonClinton who contributed the first netboot patches)
I had been working in Linux thin clients for about two years. At the time I got in to it, customers were coming to us with old machines that typically had 200 MHz Intel or PPC chips with 32-64 MB of RAM. This is an ideal environment for LTSP. But LTSP (and MS Term and Citrix) has its problems; most notably, local device access. That is, sound, video and local USB disk access are painful if not prohibitively bandwidth restrictive. About nine months ago I started to realize that our customers were coming to us with old computers with 400 MHz CPU's and 128 MB of RAM and also that prices on brand new thin clients with more RAM were coming down significantly. As you might have guessed, these are sufficient system requirements to run a full Linux desktop. Slow, yes, but functional, none the less. So, why waste all this good client hardware by running all the apps off a $5,000 - $10,000 server with several thousand more in switch upgrades?
An alternative needed to offer the central management and the ability to run off of clients with no hard drives. So, using KNOPPIX as a cutting board, a proof-of-concept was born. NFS has always been hard to debug on customer sites so I threw it out the window for the POC. Instead, I choose to use Samba to get the KNOPPIX data to the client. In this early prototype, I used a compressed squashfs filesystem to get the OS to the client. Once on the client, the client read its squashfs file from the network and ran as though it had a CD-ROM. File access was faster than a CD-ROM by approximately a factor of 5-10 because the squashfs file (700 MB) was stored entirely in the server's 1 GB of RAM disk cache. Each subsequent booting client received its requested data immediately from the RAM on the server. The results were exciting and generated a lot of interest in a few of our tech savvy customers and early testers.
The downsides to using KNOPPIX were two fold: one, that the init system was custom and largely opaque and two, remastering a squashfs file takes way too long to allow our users to customize their desktops in any reasonable amount of time. Some clever guys got around this second downside by doing boot-time injection with rsync. But, of course, you can only copy so much in to the RAM on the clients before you run out.
So, I had two requirements for something long-term: a standard init system and a directory filesystem on the server for the client root filesystem. The former for easy customization; the later for chroot-style modifications to the client environment. After some searching in April, I found the just-then launched Debian Live project. I hacked on it for a few days and added support for networking booting using Samba CIFS POSIX extensions as the root network filesystem and I also added support for using a flat, uncompressed directory as the root FS. I submitted these patches to the mailing list and Debian Live's Net flavor was born.
Today netboot supports both NFSv3 and Samba CIFS 3.0.23c+ as the root filesystem for the clients. Administrators may chroot in to the client environment and performs system related administration tasks to affect the client experience or may alternatively use some clever chroot+DISPLAY tricks to actually run the system customization tools like Kiosktool, Pessulus, Sabayon or Alacarte. The beauty of the live-initramfs system is that it turns a "normal" Debian init system in to a Live environment so no special care needs to be taken when upgrading client system services. Because of Linux disk caching, one server with a cheap CPU, 2 GB of RAM and 1 GB NIC card can serve 50 clients - that's a lot smaller than a typical server-side-computing-based thin client server.
Best of all, if the proper video codecs are installed, full screen video playback, autodetected audio and local USB device access with HAL should all work out of the box on almost all the client hardware that Linux will run on.
New thin clients that fit this model can be had from various places around the Internet at cheap prices. For a system with 1 GHz processor and 256 MB - some of theme even fanless - the prices are still very reasonable.