Previously on UnixWars …
I said in another post that I would be using a Thin Client as my home server. The machine is fanless, diskless and it makes no noise. The system boots from a low power Compact Flash. After setting things up, some friends decided to buy the exact same machine, so I’m going to write down the steps I followed to configure the server. Please note that Ubuntu Jaunty is still in Alpha 5 stage, so you might want to rethink which release you are going to install. I’ve had no problems whatsoever, so for a setup such as mine you should be safe. Alpha 6 is due to be released shortly and the first beta will be out on March 21st. Then, just one month will separate us from the official release day, so by now I’d say Jaunty has done most of it’s homework.

The easiest thing to do would be installing the system normally through PXE (look for the link at the end of this post if you’re interested), but there is a problem. Flash devices have a limited number of write-cycles, and wear levelling is not used on consumer grade cards. There are file systems optimized for flash devices -such as JFFS2- but the benefits are not obvious here. As I understand it, these are designed for industrial devices with direct access to the memory cells. Consumer devices have an abstraction layer that make them transparent and enable us to use them as any other normal storage. It should provide everything we need, such as wear levelling. But as I said before, it normally doesn’t for consumer-type devices.

Alternatives

Having discarded the optimal solution for both technological and budget limitations, we are left with three alternatives.

1. Use the CF as an ordinary device, with total disregard for the premature death of the drive. This is the simplest, and provided you have a lifetime warranty for your media it might not be such a bad idea.
2. Use the CF as if it were a LiveCD, maybe even adding persistence for our changes. This option should prove perfect if we want to use the Thin Client as a desktop system. Temporary changes are written to RAM, permanent changes will be stored on disk and even software updates will remain between reboots. It is a bit more complicated, so I’ll leave this in my TO DO list for now.
3. Install everything by hand on a local copy, configure the system to be able to run with as little disk access as possible (ideally, from a read-only root file-system), and dump it to the CF. Since space is not a problem for me (I have both a 1GB and 8GB CF cards), I’ll prefer this approach. In case everything was set as read-only, we would only  have to remount the file systems as writable during the process. As for SquashFS, though it seems an ideal choice for an embedded system that needs no upgrades, I’ll discuss this in other posts. It is simpler to deal with a “standard” system, not having to recreate binary boot images every time you update the box.

My home server is used to share media and printers on my local network, manage downloads, and above all, provide a permanent access to my home network from wherever I might be. This is, by far, the handiest thing ever. At least it is for me. You never know when you are going to need to bypass Internet filters when you are roaming, for example. The wonders of SSH truly never cease to amaze me :)

I’ve opted for letting some writing be done to the CF, albeit the write-intensive tasks have been dealt with, because it is easier for the system to be updated, and because some of the services I’ll be using refuse to work on read-only mode. However, my next entry will be about using aufs/unionfs, and replicating this setup on totally read-only and compressed system that will run from the 256MB standard CF that comes with the computer.