TurnKey Linux Virtual Appliance Library

UDS - Natty Narwhal summary

New release candidates for TurnKey Linux 11.0 (part 1)

We've pushed out new RC (Release Candidates) builds for part 1 of the upcoming TurnKey Linux 11.0 release and we need your help testing them! See the appliance pages for download links.

The current crop of release candidates only include Ubuntu Lucid based ISO images for now. Debian Lenny based images will follow, as will builds specially optimized for the the full range of supported virtualization and hosting platforms (e.g., VM build, EC2 AMIs, ESX4, Xen, Eucalyptus, etc.).

To Lisp or not to Lisp, that is the question.

Musings on Lisp by a routinely Pythonic programmer

Last week I did some maintenance on various Python projects I haven't touched in years (literally), and I was surprised by how easy, almost trivial it was to reorient myself and make the necessary changes.

That observation came at the right time because I've been reading up on Lisp dialects for a while now and questioning whether or not I should be programming in Lisp instead. Lisp enthusiasts (converts?) certainly make persuasive arguments, typically advocating Lisp as the one-true-language with near religious zeal.

Finding the closest APT package archive using GeoIP and indexing

In preparation for TurnKey's upcoming release based on Ubuntu Lucid 10.04 LTS, we are knocking off todo list items. One of them is code-named auto-apt-archive. As you can guess from its name, the objective is to configure the closest APT package archive mirror, automatically, without user intervention. It does this by leveraging a new GeoIP service provided by the TurnKey Hub.

Meet Rik Goldman

Rik Goldman is the English and Info Systems teacher that led a team of six high school students to help develop 3 new TurnKey Linux appliances for Ampache, LimeSurvey and Elgg.

Rik is the kind of passionate teacher I wish I had in high school. An innovative thinker who isn't afraid to step outside the box to challenge his students to achieve more.

We wanted everyone to get to know Rik better, so we interviewed him for this blog post.

TKLPatch summer contest summary: let the judging begin!

It all started with a happy accident

I have a confession to make. This contest, which is directly fueling the largest expansion of the TurnKey library since the project started, is a happy accident. It wasn't something we planned. It wasn't on our summer todo list. It was just one of those unexpected, spontaneous ideas that light up the inside of your brain like a flash bulb, and demand you take action. Or else! (you won't get any sleep)

Back in June we had just launched the TurnKey Hub and were getting ready to focus all our energies on releasing TKLBAM. I logged into PayPal and noticed our donated beer budget had a sad little beer belly. It was just sitting there, giving me an accusing look. I felt guilty. Surely all those people who donated expected we would put these funds to better use. That's when it hit me. It was too much to buy beer, but not so much that we couldn't risk it all on a fun experiment...

I talked it over with Alon and on an impulse we decided to do a contest, but not just any contest. A wild and wet summer open source bonanza! With ponies!

What happened next took us both by surprise.

LXDE review: it zips, it flies! (base for client-side TurnKey appliances?)

At home we canceled our cable subscription a few months ago. We hardly ever used it any more. Instead we were downloading content to a makeshift media server and watching it on our own schedule. Many of the shows I like (e.g., Colbert Report) aren't even available over here.

Upstairs we had a gorgeous big screen HDTV set that was being powered by one of my old computers, a nice P4 machine with 1GB of memory that was running the TurnKey Torrent Server appliance on bare metal.

Then it died. Traced it back to the motherboard being fried by a faulty power unit. Facing an immediate home entertainment emergency, I rummaged through the basement and found an old P3 machine with 256MB of old-style memory (I.e., the kind you can't get any more of these days).

Passphrase dictionary attack countermeasures in tklbam's keying mechanism

Background: how a backup key works

In TKLBAM the backup key is a secret encrypted with a passphrase which is uploaded to the Hub.  Decrypting the backup key yields the secret which is passed on to duplicity (and eventually to GnuPG) to be used as the symmetric key with which backup volumes are encrypted on backup and decrypted on restore.

When you create a new backup, or change the passphrase on an existing backup, a new backup key is uploaded to the Hub where it is stored in the key field for that backup record.

When you restore, tklbam downloads the backup key from the Hub and decrypts it locally on the computer performing the restore. Note that the Hub only allows you to download the backup key for backup records to which you have access (e.g., you are the owner).

Only you can decrypt your passphrase protected backups

All of this matters because it means that as long as you use a passphrase to protect the key, even the Hub can't decrypt your backups, only you can - provided you remember the passphrase (or failing that, at least have the escrow key stored in a safe place).

In other words, the decryption of the backup key happens locally and at no point does the passphrase reach the Hub, so we can't decrypt your backup even if you asked us to. Neither can an attacker that has theoretically compromised the Hub, or a government agency that comes kicking down our door with a court warrant.

The problem with cryptographic passphrases

But wait. If an attacker has local access to the key, his ability to run dictionary attacks to find the key's passphrase is limited only by the computational resources he can throw at it.

TKLBAM: a new kind of smart backup/restore system that just works

Drum roll please...

Today, I'm proud to officially unveil TKLBAM (AKA TurnKey Linux Backup and Migration): the easiest, most powerful system-level backup anyone has ever seen. Skeptical? I would be too. But if you read all the way through you'll see I'm not exaggerating and I have the screencast to prove it. Aha!

Backups are hard, making sure you got it right - harder

According to Murphy's Law, everything that can go wrong, eventually will go wrong.

This is true for backups on multiple levels. A backup is often our last line of defense when things go wrong, but so many things can go wrong with the backup itself that we usually don't find out about it until, well, horror of horrors, the backup fails.

On the surface, backups can fail for zillions of reasons.