Ÿ 10 " 1024x600 TFT LED Backlit LCD Ÿ Fanless ARM9 400Mhz Processor Ÿ Analog Resistive Touchscreen Ÿ Up to 1 GB Flash & 256 MB RAM Ÿ 10/100 Base-T Ethernet Ÿ 3 RS232 & 1 RS232/422/485 Port Ÿ 1 USB 2.0 (High Speed) Host port Ÿ 1 USB 2.0 (High Speed) OTG port Ÿ 2 Micro SD Flash Card Sockets Ÿ SPI & I2C ports
Ÿ I2S Audio Interface w/ Line-in/out Ÿ Operating Voltage of 12 to 26 Vdc Ÿ Pricing starts at $595 for Qty 1 Ÿ Optional 2D Accelerated Video & Decoder
E
QUIPMENTM
ONITORA
NDC
ONTROLTHE OPEN-SOURCE CLASSROOM
“fat-client” model. Basically, rather than depending on the LTSP server for running applications, the NBD chroot image
contains a complete Linux install, so every application, even down to the window manager, is run from the client. In this model, all the server is responsible for is serving out the NBD image. To enable the fat-client mode, you need to add the --fat-client flag when running ltsp-build-client to create your chroot.
As with every scenario, this has its shortcomings. Because absolutely everything is run from the client, the fat-client model requires powerful machines.
In fact, the specs for a fat client are similar to that of a standalone computer, with the exception of a hard drive. The fat clients require a substantial network connection to the server, and unless you
have a very fast network infrastructure, you might be better off with actual standalone computers.
If you have a bunch of workstations without hard drives, or if the maintenance time saved by having a single chroot environment for all your workstations is worth it, fat clients can be incredibly useful. I’ve noticed,
however, that even top-end Atom-based thin-client devices tend to bog down in fat-client mode. If you’re going to depend on your clients to run the complete OS, it’s important to test them first to make sure they’re up to snuff.
Because you may have a combination of new and old client machines, it is also possible to mix and match the fat-client and thin-fat-client model from the same server. It means creating two NBD images, but assigning the proper image is as simple as specifying a new filename in your dhcpd.conf file. This is a nice way to take advantage of a few really powerful workstations without making your slower hardware obsolete.
All Things Are Possible, Not All Things Are Wise
My last few articles have torn the LTSP system apart and looked at its juicy insides. Perhaps that’s a gross Figure 1. The Web interface is confusing, but useful.
WWW.LINUXJOURNAL.COM / MAY 2012 / 47
COLUMNS THE OPEN-SOURCE CLASSROOM
metaphor, but hopefully, it’s a little more clear how powerful thin clients can be for your organization. My favorite part is how many different ways LTSP can be implemented. If you’re just starting the process, a few classroom labs are the perfect way to see if LTSP will work for you. In fact, by recycling older workstations and using them as thin clients, the cost of implementation is often zero. It just takes a few adventurous users willing to learn a new way to compute.
As the system administrator, you have several ways to set up your LTSP system.
Table 1 gives some pros and cons of
each scaling method discussed here, but if you’re just starting, I recommend going with a single server and a handful of clients. Once you get to the point of scaling, you’ll have a much better idea of what fits into your environment best. If you have questions along the way, feel free to drop me an e-mail or ask the professionals in the IRC #ltsp channel on Freenode.■
Shawn Powers is the Associate Editor for Linux Journal. He’s also the Gadget Guy for LinuxJournal.com, and he has an interesting collection of vintage Garfield coffee mugs. Don’t let his silly hairdo fool you, he’s a pretty ordinary guy and can be reached via e-mail at [email protected]. Or, swing by the #linuxjournal IRC channel on Freenode.net.
Table 1. Scaling Models, the Pros and Cons
MODEL DESCRIPTION BEST FOR ADVANTAGES DISADVANTAGES
Classroom Server Workstation class machines with extra Ethernet card server, 3–8 clients per classroom.
Environments with poor network infrastructure and/or lack of big servers.
Minimal server costs, utilizes existing workstations as mini-servers, keeps thin-client bandwidth off main network.
Classroom thin clients isolated from each other, potential for double-NAT problems, more servers means more configurations to manage.
Single Ethernet Centralized servers have a single Ethernet port, with a separate DHCP server allocating clients to servers.
Large network installations with sufficient network infrastructure.
Troubleshooting is simple, clients can be reassigned by modifying dhcpd.conf file, configuration is similar to standalone model.
Manual load balancing is cumbersome and often incorrectly done, multiple servers to configure means repeating the same admin tasks over and over, no automatic failover if server goes down.
LTSP Cluster Centralized NBD server load balances over any number of application servers.
Large installations with sufficient network infrastructure and experienced LTSP administrator.
Clustering allows for central configuration of all clients and single chroot for quick updates.
Web interface slightly cumbersome, layers of complexity make troubleshooting more difficult, NBD server failure can take down entire network.
LTSP Fat Client Powerful client machines load entire operating system over NBD, running all applications locally.
Powerful client machines with sufficient network infrastructure.
Client machines handle all computing, so server requirements are minimal.
Requires quite powerful client machines and solid network infrastructure.
Standalone hard drive installs should be considered.
NEW PRODUCTS