TurnKey Linux Virtual Appliance Library

Extending an LVM volume: Physical volumes (partitions) -> Volume groups -> Logical volume -> Filesystem

Logical Volume Management (AKA LVM) is a powerful, robust mechanism for managing storage space.

In TurnKey 11,  instead of installing the root filesystem directly to a fixed size partition, we setup LVM by default, and install the root filesystem to a Logical Volume, which may later be expanded, even across multiple physical devices.

Unfortunately, as with anything powerful, to get the most out of LVM you first have to negotiate a learning curve. From the feedback we've been getting it seems that confusion regarding LVM is  common with new users, so here's a quick "crash course"...

Python performance tests reaffirms "premature optimization is the root of all evil"

"Premature optimization is the root of all evil"

Today while programming I found myself thinking about the performance impact of various basic Python operations such as method invocation, the "in" operator, etc.

This is a mistake because you really shouldn't be thinking about this stuff while programming. The performance impact of doing things one way vs another way is usually so small that you couldn't measure it.

Time for a human readable privacy policy?

Up until now TurnKey hasn't had an explicit privacy policy, and that seemed ok because no one ever asked about it. But now that the latest release integrates TurnKey appliances more closely with the TurnKey Hub (e.g., TKLBAM, geo-ip auto apt mirror) and the Hub gets access to sensitive data as part of its normal operation, I felt it was about time we gave this some more thought.

On the other hand, even though we didn't have an explicit privacy policy before I do feel our adoption of the Ubuntu Code of Conduct gave us an implicity privacy policy by making it clear we respect our users and expect them to respect us, and each other, in return.

To put it bluntly, we don't need no stinking privacy policy to avoid breaking your trust. But sometimes it doesn't hurt to spell things out and dispell any doubts. For the record. Here's what I came up with...

TurnKey Linux 11 released (part one)

Ladies and gentlemen, part 1 of the TurnKey Linux 11 release is now officially out, including 45 new images based on Ubuntu 10.04.1. We pushed out the 11.0 release candidates 3 months ago, and with the help of the community have tested the images and resolved the few remaining issues.

Practical guidelines for beautiful Python code

Every now and then Liraz and I find ourselves chatting about how much we love Python, but more so the lessons we have learned from coding, and how to apply them to create beautiful Python code. I've tried to refine some of the "lessons" into practical guidelines that I apply religiously to all new code I write, and the refactoring of old code I written.

Secure, flexible and scalable Amazon EC2 instance preseeding

I'd like to introduce Joe. He is a good looking, experienced sys-admin and like all good sysadmins, he has more stuff to do than time to do it.

Joe wants to get up and running on Amazon EC2 with a Wordpress installation, and chooses to do so with a pre-configured appliance. These are the steps Joe performs:

TurnKey website refreshed

I've just finished updating the TurnKey website with a range of improvements designed to smooth over existing rough spots and better accommodate the needs of the project as it expands with the upcoming release. 

Veteran community members using modern browsers may also notice the site looks just a bit more visually pleasing now. Otherwise I've just been obsessively tweaking the stylesheets for nothing.

Git - Fixing commit mistakes

I use Git. I use it a lot. I basically use it for everything I do, from code revision control to revisioning my notes, my journal, even my email archive (don't ask, it's a long story).
 
As with anything you do, you are bound to make mistakes.

Making TurnKey more turnkey - the end to default passwords

In our quest to make the upcoming TurnKey 11.0 release more "turnkey", I set out to extend the firstboot inithooks to include application specific configuration hooks such as setting of the admin password, email and domain to serve (where applicable).

I'm glad to announce that the quest is now over, and that puts the end to default passwords.

Tweaking Django exceptions with custom middleware

When settings.DEBUG is set to False, exception tracebacks will be sent to settings.ADMINS. To make it simpler to track down how and why the exception was raised, it's beneficial to know which user caused the exception.

It's quite simple to do this using some custom middleware. In the Hub, we include the associated users email address in the exception with the following: