Log in

No account? Create an account

Previous Entry | Next Entry

Safedesk TS

As I have previously mentioned on my blog, one of my many projects is the Safedesk Terminal Server. Today is a wonderful day because I am proud to release the culmination of several months of work in that project. STS is a GNOME-based hybrid desktop client environment powered by Debian, the Debian Live Project and Ubuntu's Casper framework. This is the first public release that incorporates the hard work of the Debian Live team (Daniel and Marco) we set out to accomplish in April and is hugely divergent from the traditional LTSP-style of thin Linux desktops.

First, a little background. I have 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 200mHz Intel or PPC chips w/ 32-64 MB of RAM. This is an ideal environment for LTSP. But LTSP (and MS Term and Citrix) has it's 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?

Obviously, any alternative would need 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 directory as the root FS. I submitted these patches to the mailing list and Debian Live's Net flavor was born. Sometime later, we hired the two main developers of Debian Live project to work part time on maintaining Debian Live's upstream sync with Ubuntu's Casper and generally polish the existing infrastructure. Last month, Daniel and Marco's hard work paid off and Debian Live was officially accepted in to Debian Unstable's ftp archives. At this moment, any Debian user of Etch or higher can generate their very own Live CD or Live Net environment by running a single make-live command.

So where does that leave Safedesk? Well, making your own Live environment is great and all but it's somewhat complicated, it's hard to know when you've got a stable snapshot, and also to know where to put spit-and-polish to make things nice for your users. We have done these things and released the results today as the Safedesk Terminal Server 3.2.0 (you can just skip the reg. form); it's completely open source/free software. Our objective is to put out regular open source releases of this software - snapshots of the best of all the pieces involved with some polish - which allow anyone to turn 128 MB-or-higher systems in to full-fledged, diskless GNOME desktops. Despite being based on Debian, the software will run on any Linux distro (we have tested it on Ubuntu, Fedora and SuSE). The tarball (which needs to be extracted with the -p tar option) comes with a README containing instructions on setting up ones own terminal server.

Further, this release 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 admin tasks to affect the client experience or may alternatively use some clever chroot+DISPLAY tricks to actually run the system customization tools like Pessulus, Sabayon or Alacarte. The beauty of the Casper 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.

The success of the open source project will depend on how well we build a community around it and Debian Live. For me, from a personal perspective, it would be immensely gratifying just to know that people are using our work. But, also from a business perspective, bouncing off what Luis said in August about open source competing with proprietary vendors, building and maintaining community is the most important thing we can do for this project. Anyways, check it out and please let us know what you think!

P.S. A website update is coming tomorrow.


( 7 comments — Leave a comment )
Sep. 11th, 2006 11:55 am (UTC)
I must say I don't fully master all the technologies that you are talking about. It seems to me that you are running a lot of the application on the thin client (which is great, given the power of modern thin clients), I do not understand how you integrate the applications running on the server on the local desktop.
One technology I personally use a lot in similar situations is nomachine's NX. It is absolutely great in terms of low bandwidth consumption, but the current open source version does not allow for forwarding windows only, and not full desktops.

Sep. 11th, 2006 12:25 pm (UTC)
Re: NX
The idea is great. However, TerminalServer is a bit of a misnomer. I would conisder more the GPL NX server by 2X to be a terminal server. You are essentially providing thin clients. Is it possible to connect to the Terminal Server with a standalone client from other linux (and/or windows) machines?
Sep. 11th, 2006 05:17 pm (UTC)
Re: NX
Not without using something like QEMU to emulate a network boot, no. The server is strictly acting as a root file system for the clients so there is not remote access, yet.

I am working on adding a feature that uses zombie clients and a load balancer to redirect incoming VNC connections to clients that are unused.
Sep. 11th, 2006 05:19 pm (UTC)
Re: NX
We don't try to integrate with apps. on the server at all. This keeps the server cost very low and, for instance, if we were to run OpenOffice from the server and display at the clients, this would be bad because OpenOffice would not be able to see any of the local hardware such as USB pen drives that can be seen by the rest of the client desktop environmnet.
Sep. 12th, 2006 10:56 am (UTC)
Re: NX
You rock my socks. I've been working with pxe bootable thin clients and LTSP for a year now. I will definitely try safedesk as you have described.

Currently working on fat-clients with sub-32meg custom linux builds, turning DevonIT cheapos into easy webstations. I've been hacking ThinStation for my evil deeds, but am looking for a better approach.

Perhaps you've saved me? Thanks.
Sep. 12th, 2006 04:18 pm (UTC)
Re: NX
DevonIT is currently in the process of securing production on VERY inexpensive devices with 400 mHz AMD fanless Geode processors and 256 MB of RAM. I shouldn't really give out exact pricing, but you should check that out.
Sep. 12th, 2006 08:23 am (UTC)
Sounds great!
Hey Jason, this sounds great! I've administered LTSP labs in Namibia and ran into many of the same problems you saw. Your solution looks really good. Good luck with Safedesk!

Andy Wingo (http://wingolog.org/)
( 7 comments — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow