In response to user demand on the forum we've added Hub support for Amazon EC2 reserved instances.

Reserved instances are an Amazon EC2 feature that allows you to reserve server capacity up to 3 years in advance by paying a low one-time fee.

In exchange the hourly usage rate is significantly reduced and server capacity is guaranteed to be available when you need it.

How much will I save?

For servers that are deployed full-time you can save up to 50% of costs. For example, running a small server continuously:

Similar relative cost savings are available for all server sizes.

Does reserving capacity obligate me to run a server full time?

No. At any time you can further reduce costs by shutting down unused capacity. Servers reserved for 3 years break even at 24% usage.

Which server types can I reserve?

Only EBS-backed TurnKey servers. S3-backed TurnKey servers cannot be reserved.

How exactly does it work?

Through the Hub you reserve a server instance of a specific size in a specific region. Amazon bills you a non-refundable one-time fee. The Hub applies the discounted hourly rate immediately to any matching server. You'll see this reflected in the server dashboard.

If you don't have a running server, the discounted rate will be applied to the next server you launch in the reserved size and region.

Are the reduced usage fees attached to a specific server?

You don't have to worry about that. Reserved instances are a property of the billing system, not your cloud servers. For example, if you shut down an old server and start a new one in the same region the reserved pricing will apply to the new server automatically.

For further details see Amazon's website

• Amazon EC2 - Reserved instances
• Amazon EC2 - Frequently Asked Questions / Reserved instances

Ladies and gentle geeks, I'm proud to announce we've just pushed out 100% free basic server monitoring to all TurnKey Hub accounts. This should make it easier to keep tabs on the health and performance of your cloud servers. Existing Hub users don't need to do anything to enjoy this new feature. It just works.

A better server dashboard

As you can see in the screenshot below, the server dashboard now includes thumbnail graphs of CPU utilization, disk IO and network traffic for the last hour:

Give me more!

Alright, so instead of the last hour, you want data on how your server was doing last night? Or last week? No problem. CloudWatch samples performance at 5 minute intervals, and stores up to two weeks worth of data.

Clicking on the thumbnail graph pops up a larger interactive graph that lets you zoom in and out, sample performance metrics ondifferent timescales (e.g., hourly, daily, weekly, etc.) and move back and forward in time:

No installation, monitoring agents required

You don't need to install or configure any monitoring agents, because the Hub pulls statistics directly from Amazon's CloudWatch API. CloudWatch in turn gets its data directly from the virtualized hardware layer running underneath your server's operating system.

Ho ho ho, happy holidays everyone! I know most of you are already shifting into holiday mode, so I'll keep it short and sweet.

We've just pushed out TurnKey 11.3 - the final maintenance release based on Ubuntu 10.04. The next release will be based on Ubuntu 12.04. We're already shifting into high gear for that. There will be surprises. Hopefully good ones!

Anyhow the new images we just pushed out from our CloudTask automation swarm include fixes for various bruises and scrapes, as well as the very latest security updates.

If you've already installed a previous version of TurnKey 11, you don't need to download anything because by default TurnKey is configured to automatically install all of the security updates over the network.

The maintenance release will mainly be of interest to new users and existing users doing new deployments. Especially those of you who are super impatient like mua and don't care to wait long minutes after deployment for the system to pull over a ton of security updates. This cuts down the time it takes to fully deploy Core in the cloud from 5 minutes to just 30 seconds.

OpenVZ and Proxmox VE has been a recurring topic of discussion on the forums, for which we have Jeremy to blame thank. He's done tons of research, testing, preaching, and then some.

What I love about Open Source is that if you have an itch, and the drive to scratch it yourself, you can.

That's exactly what Jeremy and Adrian did. They wanted OpenVZ optimized builds for their Proxmox VE deployments, so they developed a TKLPatch that would convert an ISO into an OpenVZ container. And if that wasn't enough, took the time to upload some of the builds to sourceforge so it would be easier for others to leverage their work.

Hats off to you guys, you rock!

TurnKey OpenVZ optimized builds

Based on Adrian's and Jeremy's work, we were able to add OpenVZ support to our build infrastructure in no time, and after some initial testing, triggered the whole appliance library to be built as optimized OpenVZ containers.

You can get them from the "Download -> More Builds" link on the appliance pages.

Pre-seeding / default passwords

Because OpenVZ builds are used in headless deployments (without a console), they include an inithook which preseeds default values and passwords (excluding the root password which is handled by the VZ CLI tools).

/usr/lib/inithooks/firstboot.d/29preseed

DB_PASS=turnkey
APP_PASS=turnkey
APP_EMAIL=admin@example.com
APP_DOMAIN=DEFAULT
HUB_APIKEY=SKIP
SEC_UPDATES=FORCE

Depending on your use case, you can preseed the values before the system is booted for the first time, or once the system has booted by executing turnkey-init.

It would be great if someone would add preseeding support to PVE... 

TurnKey Proxmox VE channel

A while back the Proxmox folks came up with the idea of adding a TurnKey channel to PVE, to allow users to download TKL appliances in the same way their custom built appliances are downloaded.

It was a great idea, but unfortunately it never got off the ground.

As I mentioned above, the great thing about Open Source is that you can scratch your own itch, and I was curious how the channel mechanism worked - so I dived in. When I came up for air I had added minimal third party channel support and a TurnKey Linux channel (github).

What this basically means is you can now download and deploy any TurnKey appliance on your PVE server in a couple of clicks without leaving your browser.

I hope to see this integrated in the upcoming PVE 2.0 release [update: it's coming...]. If you're running PVE 1.9 then you can add the TurnKey channel as follows:

cd /usr/share/perl5/PVE
mv APLInfo.pm APLInfo.pm.bak
wget https://raw.github.com/turnkeylinux/pve-patches/master/PVE/APLInfo.pm

# update appliance list
pveam update

As we mentioned before, making TurnKey easy to deploy on as many public and private clouds is an important goal for us. Unfortunately there are too many players in the cloud software space for us to support every single one. It's much easier to put effort into making TurnKey work well with the winning horses.

TurnKey has been supported on the leading public cloud platform Amazon EC2 from early on, not to mention simplifying management and deployment via the Hub.

OpenStack is particularly interesting, because as it is most likely the future of open source clouds.

I originally got intrigued when I heard about NASA planning to open source Nebula in 2009, which has become the basis for Nova, the compute component in OpenStack. Since then, I've been following OpenStack development from a far and have been itching to develop support for TurnKey on the platform.

The time has finally arrived, and I'm pleased to announce TurnKey optimized builds are hot out of our build farm, and available for immediate download and deployment.

You can get them from the "Download -> More Builds" link on the appliance pages.

TurnKey OpenStack optimized builds

• EBS auto-mounting support: we've updated our custom EBSmount mechanism for OpenStack, which automatically mounts EBS devices when attached.
• Support for automating instance setup: via the user-data scripts mechanism.
• Automatic APT configuration on boot: saves bandwidth costs by using the closest package archive for maximum performance.
• SSH key support: instances that are launched with a key-pair will be configured accordingly.
• SSH host key fingerprints displayed in system log: verification of server to prevent man-in-the-middle (mitm) attacks.
• Randomly generated root password: is set on first boot, and displayed in the system log **.
• Randomly generated mysql/postgres passwords: the MySQL root and/or PostgreSQL postgres passwords are set to to the same random password as root **.
• Instance metadata python library and CLI: used internally, but useful for advanced users. (learn more).

** Because OpenStack builds are used in headless deployments (without a console), they include an inithook which preseeds default values, and random passwords:

/usr/lib/inithooks/firstboot.d/29preseed

MASTERPASS=$(mcookie | cut --bytes 1-8)

cat>$INITHOOKS_CONF<<EOF
export ROOT_PASS=$MASTERPASS
export DB_PASS=$MASTERPASS
export APP_PASS=turnkey
export APP_EMAIL=admin@example.com
export APP_DOMAIN=DEFAULT
export HUB_APIKEY=SKIP
export SEC_UPDATES=FORCE

Depending on your use case, you can utilize user-data (note the security implications) to preseed during boot, or once the system has booted by executing turnkey-init.

Exemplary import of TurnKey Core on OpenStack

There are several ways of uploading an image into an OpenStack deployment, below is one way to get you started.

# cd /tmp
# tar -zxf turnkey-core-11.3-lucid-x86-openstack.tar.gz
# ls turnkey-core-11.3-lucid-x86
    turnkey-core-11.3-lucid-x86-initrd
    turnkey-core-11.3-lucid-x86-kernel
    turnkey-core-11.3-lucid-x86.img

# IMG=turnkey-core-11.3-lucid-x86

# glance add -A $GLANCE_TOKEN \
    is_public=true \
    container_format=aki \
    disk_format=aki \
    name="$IMG-kernel" \
    < /tmp/$IMG/$IMG-kernel

Added new image with ID: 5

# KERNEL_ID=5

# glance add -A $GLANCE_TOKEN \
    is_public=true \
    container_format=ami \
    disk_format=ami \
    kernel_id=$KERNEL_ID \
    name="$IMG" \
    < /tmp/$IMG/$IMG.img

Added new image with ID: 6

# glance -A $GLANCE_TOKEN index

ID  Name                                Disk Format  Container Format  Size
--  ----------------------------------  -----------  ----------------  ---------
6   turnkey-core-11.3-lucid-x86         ami          ami               688498688
5   turnkey-core-11.3-lucid-x86-kernel  aki          aki               4179712

# euca-describe-images

IMAGE   ami-00000006    turnkey-core-11.3-lucid-x86         available  public                  machine aki-00000005
IMAGE   aki-00000005    turnkey-core-11.3-lucid-x86-kernel  available  public                  kernel

As we mentioned before, making TurnKey easy to deploy on as many public and private clouds is an important goal for the project.

Recently we announced TurnKey optimized builds in a number of new formats, which brings the supported list to: ISO, VMDK, OVF, Amazon EC2, OpenStack and OpenVZ.

I'm pleased to announce that we have just added Xen to the list of optimized builds. They are hot out of the build farm and available for immediate download.

You can get them from the Download link on the appliance pages.

Pre-seeding / Default passwords

The Xen images are mainly built for hosting providers who utilize the Xen Hypervisor.

Because Xen builds are used in headless deployments (without an interactive console), they include an inithook which preseeds default values and passwords.

/usr/lib/inithooks/firstboot.d/29preseed

MASTERPASS=turnkey

cat>$INITHOOKS_CONF<<EOF
export ROOT_PASS=$MASTERPASS
export DB_PASS=$MASTERPASS
export APP_PASS=$MASTERPASS
export APP_EMAIL=admin@example.com
export APP_DOMAIN=DEFAULT
export HUB_APIKEY=SKIP
export SEC_UPDATES=FORCE
EOF

You will most likely want to have your provisioning system to override the defaults by creating /etc/inithooks.conf.

Note that inithooks.conf will be blanked out once its no longer needed for security. You should also make sure that inithooks.conf includes *ALL* of the variables, otherwise the inithook system will turn on interactivity.

If you cannot support preseeding, the alternative is to have the user execute turnkey-init on first login.

Muchas Gracias to Marc from GigaTux (an official TurnKey partner) for testing the Xen images and providing feedback!
 

Like TurnKey so much you want a local copy of all the appliances but too lazy to download individual appliance images from SourceForge by hand via browser?

I know exactly how you feel. Sloth is a virtue, and in the beginning was the command line.

So now you can use rsync or ftp to batch download the entire virtual appliance library in whatever build type you like best from a high-speed mirror near you. The way the net gods intended!

Thanks to generous donations of bandwidth and storage space from opensource friendly network samurais around the world TurnKey now has 16 high-speed rsync/ftp capable mirrors in 12 countries: China, Ireland, United Kingdom, France, Germany, Sweden, Japan, Belarus, Bulgaria, Denmark, Argentina, and Israel. And we're just getting started...

This means if your network is good enough you can now grab a copy of the entire TurnKey appliance library in any of the 6 supported build types (ISO, VMDK, OVF, Xen, OpenVZ and OpenStack) from a high-speed (e.g, 10-Gbps) mirror close to you in under 5 minutes.

A few minutes ago in a practice run I rsynced TurnKey images to my Amazon EC2 instance at an average 288 Mbps effective download rate over the network.

Wowsers! Up until I upgraded to a nice SSD a couple of weeks ago that was about as fast as I could copy files on my local hard drive.

If you find these network speeds hard to believe I invite you to log into your TurnKey Hub account and launch a small instance in Ireland. Now let's rsync the entire TurnKey appliance library in Xen format - all 8 GBs worth from the HEAnet mirror:

$ rsync rsync://ftp.heanet.ie/[snip]/turnkeylinux/

Welcome to the HEAnet mirror site, ftp.heanet.ie (http://ftp.heanet.ie/about)
-----------------------------------------------------------------------------

 NOTE: All connections and transfers are logged; if this is disagreeable,
 please disconnect now.

 * ftp.heanet.ie is located in Dublin, Ireland and operated by HEAnet, the
   Irish National Research and Education Network.

 * This is a four node cluster with 10 Gigabit access to the HEAnet backbone.

 * Please contact mirrors@heanet.ie with any operational queries.

 * You are connected to ftp-node2 (kokapetl)

-----------------------------------------------------------------------------

drwxr-xr-x         157 2012/02/12 17:05:27 .
drwxr-xr-x        4709 2012/02/08 18:00:08 iso
drwxr-xr-x        5686 2012/02/08 18:00:58 openstack
drwxr-xr-x        5434 2012/02/08 18:01:10 openvz
drwxr-xr-x        4930 2012/02/08 18:01:21 ovf
drwxr-xr-x        2759 2012/01/13 08:31:59 pve
drwxr-xr-x        5014 2012/02/08 18:00:44 vmdk
drwxr-xr-x        5266 2012/02/09 20:41:48 xen

$ time rsync -av -P rsync://ftp.heanet.ie/[snip]/turnkeylinux/xen ./

receiving incremental file list
xen/
xen/turnkey-appengine-11.3-lucid-x86-xen.tar.bz2
   299570436 100%   30.43MB/s    0:00:09 (xfer#1, to-check=83/85)
xen/turnkey-appengine-11.3-lucid-x86-xen.tar.bz2.sig
         490 100%    0.38kB/s    0:00:01 (xfer#2, to-check=82/85)
xen/turnkey-bugzilla-11.3-lucid-x86-xen.tar.bz2
   191193216 100%   34.68MB/s    0:00:05 (xfer#3, to-check=81/85)
xen/turnkey-bugzilla-11.3-lucid-x86-xen.tar.bz2.sig
         490 100%    0.48kB/s    0:00:00 (xfer#4, to-check=80/85)

[ .. snip .. ]

sent 1629 bytes  received 7993104501 bytes  36919658.80 bytes/sec
total size is 7992120707  speedup is 1.00

real    3m35.152s
user    0m29.290s
sys     0m30.220s

$

Speaking with the authority of someone that used to download shareware from a local BBS 20,000 times slower (I.e., 6MB/hour on a 14400 baud modem) I can unequivocally state that this is just friggin awesome. The future is now!

Shouts out to TurnKey mirror best buddies all over the globe:

• Zhang from the USTC Linux User Group in China
• James from Bytemark hosting in the UK
• Arnoud from LIP6 in France, and Manuel from Ircam, also in France
• Carsten from RWTH Aachen in Germany
• Mattias from Umea Uni in Sweden
• Mitry from Beltelecom MGTS in Belarus
• Boian from IPACCT in Bulgaria
• Georg from dotsrc.org in Denmark
• Ariel from Cooperativa Telefonica in Argentina
• Lior from the Israel Internet Association in Israel

Not yet a TurnKey mirror best buddy but thinking you might want to be? If you have the resources to provide a mirror for TurnKey in your country reach out to our global mirror commando team 24 hours a day in any real or fictional language!

I'm pleased to announce a spanking brand new release candidate for TurnKey Core 12.0 - the common base for all appliances, based on the rock solid Debian Squeeze (6.0.4). The rumors were true! Hurrah! Hurrah!

This is an RC release, so take it for a spin and let us know what you think. If you come across any issues, please report them. If you have ideas on how to make it better, let us know!

Download RC:138MB ISO (changelog, signature, manifest)

Did you say Debian?

Why yes, yes I did. Here's the back story...

In mid-2010 we released our first ever Debian appliance based on Lenny. In the announcement Liraz discussed whether Debian based appliances are worth the trouble as well as some notes on Ubuntu vs. Debian.

Back then we decided not to release the entire TurnKey library based on Lenny as Squeeze was around the corner, and we were spread quite thin.

Fast forward to a few weeks ago, Liraz and I were discussing the upcoming Ubuntu LTS release, which is scheduled for April. We were deliberating when would be the best time to begin the transition.

During the conversation we revisited the idea of supporting Debian, and decided it was time. We've been wanting to support Debian since TurnKey's inception, and it seems that a significant 59% of users want Debian-based appliances "a lot"!

Rolled up my sleeves

So, I rolled up my sleeves and got to work. It wasn't too long and I had a working TurnKey bootstrap image (102MB ISO, Meta) based on Squeeze.  The most annoying part of that was dealing with the non-backwards compatible bootsplash. Turns out that was a good thing, as it forced me to do cleanup, and remove panel options that weren't actually doing anything. How nobody filed a bug on that is beyond me :)

Then I moved onto Core. Upgrading our Live Installer (di-live) was a little boring, but after fixing some bugs and seeing it work, not to mention setup LVM and install the entire OS in under a minute, it put a smile on my face.

After upgrading several key components, fixing bugs (thanks to everyone who submitted bug reports, and Jeremy for his excellent work triaging and keeping the bug tracker up to date), tweaks here and there, and testing, I was a happy camper.

To summarize, there were ups and downs but all in all it was good fun - ask my wife, I updated her on progress every evening whether she wanted to know or not.

But, there is still a long road ahead, and this is only the first milestone.

Changes

• New and improved signature files: include detailed steps on how to verify image integrity, as well as md5 and sha1 checksums for convenience. Take a look.
   
• Locale improvements: default locale is now set to en_US.UTF-8, updated configuration for compatibility with Squeeze. Freeing up disk space is now performed by localepurge.
   
• Boot splash and loader: upgraded bootsplash for compatibility, removed unused panel options, and tweaked bootloader timeouts.
   
• Live installer (di-live): upgraded for Squeeze compatibility and misc bugfixes.
   
• Webmin: upgraded to latest upstream release and disabled inline upgrades (managed by APT).

All other changes, bugfixes and tweaks are available in the changelog.

As for the features, not much has changed except for the base distribution.

I usually get excited when adding new features to the TurnKey Hub. Recent excitement included server monitoring, reserved instances, domain management, and the Hub API.

I'm very excited about todays annoucement, not only is it awesomely useful, it's also technically cool!

So what are snapshots?

I'm sure you can guess, but let me explain anyway.

Snapshots can be used with EBS-backed instances to create point-in-time snapshots of the root filesystem, which are persisted to Amazon S3 for storage durability. Snapshots are incremental, meaning that only changes since the last snapshot are saved, taking up less storage, time, and reducing costs (see below for technical details).

Snapshots ask Amazon's fiber-optic storage backplane to save your server's disk state while it's running without impacting performance.

Ok, but what can I do with them?

Server clones

Snapshots can be used as the basis for a new server, essentially creating a clone (the cloud server equivalent of a time machine crossed with a portal to a less obnoxious alternative dimension), for example:

• You can clone a production server to create a staging enviroment for testing new features, hacking away, whatever, without the worry of hosing your production server (guess how I tested this new feature).
• You can essentially upgrade your servers hardware if you need the extra horse power, memory or even disk space. Say you were testing an idea with a micro instance, and now its taking off. Firstly congrats, secondly just clone the micro's latest snapshot to a larger instance size and update the DNS record / re-associate the elastic IP.
• Let you're imagination run wild!

EBS Volumes

Snapshots can be used as a starting point for a new EBS volume, for example:

• You mistakenly deleted a file, hosed your database, or whatever bad thing that can happen. You create a volume from the snapshot of your choice, attach it to your instance (which is auto-mounted via ebsmount) and access the data you need.
• Again, let you're imagination run wild!

Can I schedule automatic snapshots?

You sure can! You can schedule automatic zero-load server snapshots for hourly, daily, weekly and monthly frequency, or manually create one at anytime.

There is however a snapshot limit per Amazon account, per region, so when configuring automatic scheduled snapshots, snapshot retention is also configurable to prune old snapshots, keeping you within the limit and saving you money.

Sounds cool, what does it look like?

We've added 2 new fields to the server record:

And this is the snapshot dashboard:

Are there any limitations?

Snapshots only support EBS-backed instances, and not S3-backed instances. This is a technical limitation as snapshots are performed on the EBS-backed root volume, which S3-backed instance do not have.

Snapshots are saved to S3 storage, but they will not appear in your S3 buckets, nor can you access them using the standard S3 API. To access snapshot data you need to create an EBS volume or a server clone.

As mentioned above, there is a limit of the amount of snapshots each Amazon account can have, but you can request to increase your limit (specify you want the snapshots limit increased in the comments.)

Data consistency: Do not solely rely on snapshots for backups, as they may become inconsistent due to disk-buffering and locking. We use TKLBAM for our backups, and suggest you do the same.

Technical details - snapshots explained

I mentioned that snapshots are technically cool, and that they are incremental - let me try and explain what that means at how it works behind the scenes.

A snapshot of an EBS volume can be taken at anytime, which asks Amazon's fiber-optic storage backplane to save the data stored on the volume, at the block level, at that exact point-in-time, to S3 storage.

To improve performance and reduce storage space, Amazon will only copy the blocks of the volume that have changed since your last snapshot - hence incremental.

Now for the extra cool part, unlike regular incremental backup chains, you can delete any previous snapshot. Huh? What? Yep, snapshots are not chained, but are rather conceptually like a table-of-contents of pointers to saved data blocks.

When you delete a snapshot, only the data blocks that are solely used by that specific snapshot are deleted. Data blocks that are used by subsequent snapshots are not. In the below illustration, if SNAP-B is deleted, only SNAP-B:block-2 will be deleted from Amazon S3 as a newer version (SNAP-C:block-2) has already been saved.

Bottom line, take snapshots for a spin and let us know what you think.

Last month we announced the release candidate for TurnKey Core 12.0 - the common base for all appliances, based on the rock solid Debian Squeeze (6.0.4).

It took a little longer than expected, but we've finally released all the optimized builds for TurnKey Core 12.0RC: ISO, VMDK, OVF, Amazon EC2, OpenStack, OpenVZ and Xen.

The optimized builds can be downloaded from the core appliance page, directly via the TurnKey channel in ProxmoxVE (OpenVZ), deployed in the Amazon EC2 cloud via the TurnKey Hub, or via one of the official TurnKey partners (soon).

Build specific release notes

Common (ISO)

• See the announcement.

Amazon EC2

• Deployment: The TurnKey Hub has been updated to support Core 12.0 deployment and management (Launch new server -> 12.0). Once the full library has been updated to TKL 12.0 it will become the default, and the current release will be moved to Legacy.

VM optimized (VMDK, OVF)

• Open-VM-Tools: Previous VM optimized builds included the proprietry VMWare-Tools, but since VMWare have released a large portion of the code under the GPL, we've moved to open-vm-tools.
• Swap warning: VMware products might display a warning that no swap space was detected. This is a false positive, as swap is configured in LVM.

OpenStack

• Ramdisk required: TurnKey 12.0 requires the initrd to be registered for successful boot (exemplary import and registration code).

OpenVZ

• Naming convention: We've updating the naming convention for openvz builds to support vanilla OpenVZ out of the box, and eliminate duplication for the Turnkey PVE channel. Thanks Jeremy!
• Removed NTP daemon: The NTP daemon has been removed as the clock is managed by the host. Thanks Martin!
• No more upstart hacks: Removed Ubuntu upstart hacks as they are not relevant in Debian.

Xen

• Xen optimized kernel: Moved to the Xen optimized kernel provided by Debian (linux-image-xen-686).

As always, we need your help in testing the builds. If you come across any issues or have ideas how they can be improved, please post a comment.

Ladies and gentlemen, the 12.0 release is finally out after nearly 6 months of development and just in time to celebrate TurnKey's 4th anniversary. I'm proud to announce we've more than doubled the size of the TurnKey Linux library, from 45 appliances to over 100!

As usual pushing out the release was much more work than we expected. I'd like to chalk that up to relentless optimism in the face of vulgar practical realities and basic common sense. On the flip side, we now have 100+ appliances of which 60+ are brand spanking new. Lots of good new applications are now supported.

Despite all the hard work, or maybe because of it, working on the release was the most fun I've had in a while.

You look away and then back and suddenly all this new open source stuff is out there, ready for prime time. So many innovations and competing ideas, all this free energy. We feel so privileged to have a front row seat and not just watch it all play out but also be able to play our own small role in showcasing so much high-quality open source work while making it just a bit more accessible to users.

Unlike previous releases this latest release is based on Debian, not Ubuntu. We realize this may upset hardcore Ubuntu fans but if you read on, I'll try to explain below why "defecting" to Debian was the right thing for TurnKey.

What's new?

New appliances

Upgraded appliances

Deprecated appliances

• AppEngine: With the addition of Go, we decided to split the Google App Engine SDK appliance into 3 separate language specific appliances (appengine-go, appengine-java and appengine-python).
• Joomla16: 1.6 has reached end-of-life, and has been replaced with the Joomla 2.5 appliance.
• EC2SDK: Insufficient amount of interest to warrant maintenance, especially now that the TurnKey Hub exists.
• Zimbra and OpenBravo: Will be re-introduced once TurnKey supports 64bit architectures. Sorry folks. We're still working on that.

Drumroll please... I'm thrilled to make not one, but two announcements!

1. TurnKey Core 13.0RC: This is a release candidate of TurnKey Core 13 based on Debian 7.0 ("Wheezy")- the upcoming version of Debian, which hasn't officially been released bu shouldn't be too far off.
    
2. 64-bit support: TurnKey Core 13RC is available in both 32bit and 64bit versions. This means we can now guarantee that TurnKey 13 will come with 64-bit support. The wait for is nearly over. To be honest lack of 64-bit support been a nagging source of embarrassment for TurnKey for quite a while now. A significant 66% of users said this was "Very important" to them. We agree.

Download the RCs and help us test them

64bit / amd64 build: 146MB ISO (changelog, signature, manifest)

32bit / x86 build: 144MB ISO (changelog, signature, manifest)

Getting ahead of the curve for TurnKey 13

In the past we've released updates to the TurnKey library a few months after a new operating system release came out. We want this to change. Ideally new releases of the TurnKey library should come out roughly in sync with new releases of the underlying Linux distribution it is based on.

We're going to try and make that happen for the next release. Hence this early version of the new TurnKey Core release candidate.

This time around there's more than just wishful thinking involved. We have better tools. Part of the motivation for improving TurnKey's development infrastructure was to simplify development and increase efficiency to make it easier for the project to keep up with new OS releases while the growth of the TurnKey library continues.

That means for the next release we won't be waiting. Even though Debian 7 ("Wheezy") is still officially in the "testing" phase, it is coming together very nicely and we're moving into position for an early release. Because we can!

Multiple architectures

As Liraz mentioned, we've been hard at work cleaning up and upgrading our development infrastructure, re-engineering the build process from the ground up, reducing complexity, adding automation and making the whole structure easily reproducible and extendible.

We've been working towards three primary goals: efficiency, multi-architecture support, and easily reproducible open development toolkit that would allow the community to participate in the development of TurnKey on equal footing.

The first two goals are now complete and we're almost there with regards to the last goal: enabling anyone to build TurnKey appliances from scratch using the same tools the core development team uses.

Getting back to the RC's - all changes, bugfixes and tweaks are available in the changelog. As for the features, not much has changed except for the base distribution at this point.

Long story short, try the RC's and tell us what you think.

TurnKey 12.1 is out and it's the first 64-bit maintenance release to be built with tkldev - TurnKey's shiny new open appliance build system in a box.

With 64-bit support out the door, we've also pushed out a round of updates to the Hub so that users can finally deploy TurnKey on all instance sizes.

Full details on the changes to the Hub below, but first I'd like to talk a little bit about tkldev, TurnKey's new open build system. tkldev will soon be released as a standalone appliance along with the full source code to all appliances in the TurnKey Linux roster, which we will be maintaining on TurnKey's GitHub page.

Today we proudly announce the official release of TKLDev, the new mothership of all TurnKey Linux appliance development. With TKLDev, building TurnKey Core from scratch is as easy as running make. If you can handle that you're ready to roll:

root@tkldev ~$ cd core
/turnkey/fab/products/turnkey/core
root@tkldev turnkey/core$ make

As you might expect, we're pretty stoked to finally (finally!) be able to make this announcement. It's the culmination of a couple of years worth of unglorious work behind the scenes upgrading the development plumbing that makes TurnKey possible.

I personally believe it's also a critically important milestone for TurnKey, a project I've poured my heart and soul into and would like to see grow up to embrace it's full potential.

So what's the big deal with this new build system?

Here's the problem: as much as we'd like to be the omnipresent, omnipotent, and omniscient developers that can do everything ourselves there is way more awesome open source software out there than we (or any other closed group of developers!) could ever hope to bottle up into a working library of ready-to-use solutions. Not without a great deal of help anyhow!

We started this project about five years ago. It took us a couple of years to start realizing we had a problem and another year or so to realize we had a really big problem. TurnKey was all about open source but it wasn't truly open source itself because the relationship of the core development team with the community was pretty much one sided. We could look out, but nobody could look in.

We tried plugging the hole with TKLPatch, at least as a temporary stopgap, but that didn't work and we think part of the reason was that we hadn't gone nearly far enough. It wasn't enough to make it possible for the community to customize appliances. That just made the community into limited second class citizens and while it may have been better than nothing nobody really wants to be a second class citizen in a purported open source project. Give me full access to the source code and build chain or give me death! (or... a casual hrmpf of disinterest).

We realized that meant TurnKey was either doomed to stagnate or we figure out a way to re-engineer the development process in a way that truly democratized it so that everyone could join in on the same level.

So as many of you know (we've been waving our hands around about this for a while) a couple of years ago we started working on this in earnest and we've been gradually re-engineering all our legacy build infrastructure with the ultimate goal of creating the mother of all appliances - a self-contained appliance that can be used to build any appliance (including itself) from source code.

Like Liraz said in a previous blog post:

We've actually had this in our sights for quite a while now. We made some bad technical decisions early on with regards to how we setup our legacy build infrastructure and realized a bit too late that we would have to redo everything if we wanted to get the open source community truly on board with TurnKey's development.

With everything on our plate (e.g., developing over a hundred appliances and the TurnKey Hub) it sometimes feels like we're running in place. So it's taken longer than we would have liked to make this happen.

TKLDev and appliance sources released

Long story short we've re-engineered our entire build infrastructure, bottled it up into a self-contained appliance and battle tested it by building the entire TurnKey 12.1 maintenance release. We also moved to GitHub to streamline collaboration with the community.

TKLDev is ready for immediate download in all the standard build formats in both 32-bit / i386 and 64-bit / amd64 architectures. You can also deploy it straight in the cloud via the TurnKey Hub.

Although TKLDev is relatively easy to use, it'll probably save you some time if you read through the documentation first to get an overview of how things works, development best practices, etc.

TKLDev lets you build any TurnKey appliance from scratch, directly from source. You can find the source code for all appliances in the TurnKey library at github.com/turnkeylinux-apps. All our other repositories live at github.com/turnkeylinux. We put appliances in a separate GitHub account because with so many of them they need their own namespace.

The way forward - TKL 13.0 Wheezy, a community effort?

A while back we announced release candidates for TurnKey Core 13.0, but then back tracked a little with the 12.1 maintenance release, and then side tracked again with TKLDev and the move to GitHub.

Well, it was all for a very good cause but I think we're done playing hop-scotch. With all the pieces now in place, we're moving full force on the TKL 13.0 release. The first things we'll be doing is updating all the TurnKey specific components, Core and TKLDev for 13.0. With that, the infrastructure is set to start upgrading the appliances.

We're hoping with the release of TKLDev and full appliance source code that the upcoming release will be more of a community effort. Thanks to the new infrastructure there is no special sauce, no wizard behind the curtain driving TurnKey development. We're giving Linux geeks everywhere the (super?) power to build any appliance, including Core, from scratch. What you do with it is limited only by your imagination but we're hoping at least a small part of that imagination will go towards helping us improving TurnKey for everyone's benefit.

Hopefully, we've made this stuff easy enough to use so nearly anyone with the inclination can jump in and make cool stuff happen. All the hard, really technical bits are automated so you don't need a lot of Linux experience to work with TKLDev. The same amount of experience you'd need to install and configure a regular Debian installation will take you a long way. The difference being that you can mass reproduce the results and collaborate with others on the development in ways you couldn't do otherwise.

If we've done our job well, we won't be able to anticipate all the different ways the community is going to put TKLDev to use. Some of the basic uses should be pretty obvious though. Let's say you want to improve an existing appliance. Maybe upgrade an appliance to use the latest upstream versions of your favorite open source application. Or maybe you've come up with a cool new feature that will make TurnKey Core (and by extension all other appliances) more useful? Fork, update, test, send a pull request, and your commit becomes an official part of TurnKey. It's that easy.

I can't wait to see how this evolves. Lets get hacking!

This is really two separate announcements rolled into one:

1. TurnKey 13 - codenamed "satisfaction guaranteed or your money back!"

   The new release celebrates 5 years since TurnKey's launch. It's based on the latest version of Debian (7.2) and includes 1400 ready-to-use images: 330GB worth of 100% open source, guru integrated, Linux system goodness in 7 build types that are optimized and pre-tested for nearly any deployment scenario: bare metal, virtual machines and hypervisors of all kinds, "headless" private and public cloud deployments, etc.

   New apps in this release include OpenVPN, Observium and Tendenci.

   We hope this new release reinforces the explosion in active 24x7 production deployments (37,521 servers worldwide) we've seen since the previous 12.1 release, which added 64-bit support and the ability to rebuild any system from scratch using TKLDev, our new self-contained build appliance (AKA "the mothership").

   To visualize active deployments world wide, I ran the archive.turnkeylinux.org access logs through GeoIPCity and overlaid the GPS coordinates on this Google map (view full screen):
   
    

2. TKLBAM 1.4 - codenamed "give me liberty or give me death!"

   Frees TKLBAM from its shackles so it can now backup files, databases and package management state without requiring TurnKey Linux, a TurnKey Hub account or even a network connection. Having those will improve the usage experience, but the new release does its best with what you give it.

   I've created a convenience script to help you install it in a few seconds on any Debian or Ubuntu derived system:

   URL=https://raw.github.com/turnkeylinux/tklbam/master/contrib/ez-apt-install.sh
   wget -O - -q $URL | PACKAGE=tklbam /bin/bash
   

   There's nothing preventing TKLBAM from working on non Debian/Ubuntu Linux systems as well, you just need to to install from source and disable APT integration with the --skip-packages option.

   Other highlights: support for PostgreSQL, MySQL views & triggers, and a major usability rehaul designed to make it easier to understand and control how everything works. Magic can be scary in a backup tool.

   Here's a TurnKey Hub screenshot I took testing TKLBAM on various versions of Ubuntu:
   
   

root@tkldev ~$ cd awesomenix
/turnkey/fab/products/turnkey/awesomenix
root@tkldev turnkey/awesomenix$ make

In a nutshell, LXC (LinuX Containers) can be thought of as the middle ground between a chroot on steroids and a full fledged virtual machine, making it possible to run multiple isolated "containers" on a single host.

There has been quiet a lot of interest in supporting TurnKey on LXC, so I set out to see what it would take.

Plan A, no B, ok C

The initial plan was to generate LXC optimized builds for all appliances and document how to create containers. The problem was that the process to outline in the docs wasn't very streamlined: download build, unpack build, run a couple commands, download example config, tweak config.

With plan A out the window, I moved onto plan B - create an LXC template script to automate the process. The new direction meant there was no need to generate yet another optimized build format, instead we could just patch a current build format (OpenVZ) on the fly.

This was a good plan, but lots of documentation was still required, for example: how to setup LXC, the different networking options, and the different ways to expose containers services.

Plan B was good, but code is better than documentation, moving onto plan C. Create a TurnKey LXC appliance with LXC pre-installed and configured, networking setup for both bridged and NAT, and include convenience scripts and tools for easily exposing container services.

So that's the story, and I'm pleased to announce two outcomes:

TurnKey LXC appliance

We've just released a TurnKey LXC appliance, pre-configured with everything LXC requires, including LXC itself, the TurnKey LXC template, bridge and NAT networking out of the box, dnsmasq providing DHCP and DNS services, apt-cache-ng so containers can share cached package downloads, as well as convenience scripts (nginx-proxy, iptables-nat) and related tools for exposing NAT'ed containers services to the network.

If you're new to LXC, or just want a turnkey LXC host, then this is for you. TurnKey LXC is available in all build formats for bare-metal and virtual environment installations, as well as deployment in the Amazon EC2 cloud.

Generic TurnKey LXC template

The TurnKey LXC template was developed from the get-go to be generic, and should be usable on any Linux distribution that supports LXC (which should be all of them, although we've only tested on Debian Wheezy).

Once LXC is setup on your distro, just download the template and drop it in the lxc templates directory (/usr/share/lxc/templates on Debian), and you should be able to create any of the 100+ TurnKey Linux appliances as LXC containers with a simple command:

lxc-create -n CONTAINER_NAME -t turnkey -- APPLIANCE_NAME -i /root/inithooks.conf

See the usage documentation for further details.

Keep in mind, this is the initial release of TurnKey LXC, so let us know what you think. If you have ideas for improvement, or if you come across any issues (ie. we haven't tested all appliances as of yet), drop us a line.

As with all TurnKey appliances, the source code is available on GitHub and we love pull requests.

As we've mentioned before, making TurnKey easy to deploy no matter your platform of choice is an important goal for the project. TurnKey already supports a mirade of build types including ISO, VMDK, OVF, Amazon EC2, OpenStack, OpenVZ, OpenNode, Xen, and recently added support for LXC.

I'm pleased to announce that today we are updating the above list, with support for Docker.

Docker is an open-source project to easily create lightweight, portable, self-sufficient containers from any application. The same container that a developer builds and tests on a laptop can run at scale, in production, on VMs, bare metal, OpenStack clusters, public clouds and more.

Deploying TurnKey on Docker

All TurnKey appliances are available on the public docker index (generously provided by Docker, Inc), which streamlines deployment. For example:

docker pull turnkeylinux/core-13.0
docker run -i -t -d turnkeylinux/core-13.0

Docker containers can be run in the foreground or the background, so we've tried our best to support all use cases with regards to initialization (aka. inithooks) - secret regeneration, setting of passwords, application configuration, etc. 

Depending on your use case, we recommend two options:

Option 1: Initialization via ssh (interactive)

On first login, you will be prompted to initialize the appliance.

CID=$(docker run -i -t -d turnkeylinux/core-13.0)
CIP=$(docker inspect -format='{{.NetworkSettings.IPAddress}}' $CID)
docker logs $CID | grep "Random initial root password"
ssh root@$CIP

Option 2: Create new image with preseeded values (non-interactive)

The appliance will initialize itself with the provided configuration.  Once initialized, the configuration will be deleted. For more information see inithooks.

mkdir /root/wordpress

cat > /root/wordpress/inithooks.conf <<EOF
export ROOT_PASS=secretrootpass
export DB_PASS=secretmysqlpass
export APP_PASS=secretadminwppass
export APP_EMAIL=admin@example.com
export APP_DOMAIN=www.example.com
export HUB_APIKEY=SKIP
export SEC_UPDATES=FORCE
EOF

cat > /root/wordpress/Dockerfile <<EOF
FROM turnkeylinux/wordpress-13.0
ADD inithooks.conf /etc/inithooks.conf
EOF

docker build -t wordpress-13.0 /root/wordpress
docker run -i -t -d wordpress-13.0

Notes

Pre-configured run command

Docker is designed for "application or process" containers - for example, running mysql, and only mysql. Docker short-circuits /sbin/init so you can't really "boot" a container like in vanilla LXC.

To work around this, we've included /usr/sbin/start.sh (default run command) which will start all services and drop to a shell. When the shell is exited, the services will be stopped. For this reason, SSH is recommended for regular console usage.

STDIN and TTY options required

The -i and -t options are required to attach STDIN and allocate a TTY to the container. Unfortunately this cannot be pre-configured as it is not yet supported.

Pre-configured to expose ports

All TurnKey Docker appliances are configured to expose their custom services. This means that the host can access the services, but they are not exposed to the network.

Exposing ports to the network needs to be done at runtime (docs), for example:

# bind port 80 on the host to the container's port 80
docker run -i -t -d -p 80:80 turnkeylinux/lamp-13.0

Skipping security updates on first boot

During development I added support to start.sh to override the default SEC_UPDATES value to speed up my testing. I was going to remove this support or leave it undocumented, but decided others might find it useful when testing (and only in testing).

# THIS IS NOT RECOMMENDED, USE AT YOUR OWN RISK!
docker run -i -t -d -e SEC_UPDATES=SKIP turnkeylinux/openldap-13.0

Keep in mind, this is the initial release of TurnKey Docker support, so let us know what you think. If you have ideas for improvement, or if you come across any issues (ie. we haven't tested all appliances as of yet), drop us a line.

Hi all! This is my virgin TurnKey blog post. Many of you on the forums would have come across me in your travels no doubt. I have been a volunteer serial poster on the forums now for many years. I have even had the privilege of having a blog post written about me by Liraz (one of the core TurnKey devs).

Those that pay attention to the 'karma' stats (see bottom of the forums page) may have noticed that whilst I still retain the "Most awesome of all time" crown I'm not in the "Most awesome this month" list, despite my posting frequency still being quite high. Forum regulars may have also noticed a subtle change in the way that I have been writing my posts lately. I feel like I write with a little more authority now. And that is for a very good reason!

Earlier this year I had the incredible honour of being asked by Alon and Liraz to join the TurnKey team on a full time basis! I have felt like part of the team for quite some time now, but to be formally asked to quit my job and come on board with TKL full-time blew my mind! But it also scared me a little bit too!

Never the less, I sucked it up and gave notice at my old job and started work on TurnKey part time almost straight away (I had a few lose ends to tidy up before leaving my old job). So here I am, the latest TurnKey Linux developer (in the loosest sense of the term); joining forces with the dynamic duo that is Alon and Liraz!

So what does it all mean for TurnKey?

So what will this mean for TurnKey Linux? Well from the outside, probably not a lot really. I will still be posting on the forums and on GitHub but I will be doing other (more behind the scenes) stuff too! :D

One of the most important roles will be to talk with people from other organisations, like hosting providers (to encourage them to partner with TurnKey Linux and host TurnKey appliances on their cloud/VPS platform) and to start some of the discussions with upstream developers; especially Debian (to seek to contribute TKL code back upstream and develop ideas such as upstream usage of TKLDev).

I will also be taking up the 'level one support' role. So chances are if you contact TKL Support email it will probably be me politely suggesting that you post in our forums :D (unless of course it is the sort of question that should be handled via email...).

Also I will be pondering questions about the community (with Alon and Liraz) regarding such things as how to build a better, bigger but sustainable TurnKey library, if and how to build in financialrewards and other such exciting ideas!

Most of all though, my role will be to make sure that any important TKL business (whether from community members, hosting providers, upstream developers, general users or anyone else really) gets taken care of and that Alon and Liraz are up to speed with what is happening without needing to take too much time out from development. Hopefully this will mean that the core devs do more core deving but also issues that I don't know how to answer can get their attention quicker!

So let the fun begin...! :D

It is with great pleasure that I announce the release of Core v14.0RC1 and TKLDev v14.0RC1! But first a little history and context... We had always intended to do a v13.1 maintenance release. Ideally it should have been out long ago! Actually we probably should have released v13.2 or perhaps even v13.3 by now, but time just got away from us. :(

Things have been pretty crazy behind the scenes here over the last year or so. Alon and Liraz have both been tied up with other important stuff; including major improvements to both the Hub and TKLBAM. So with the recent release of Debian Jessie we have decided to cut our losses and sidestep the v13.1 maintenance release. As Alon and Liraz are still pretty busy, I am driving the v14.0 release. Alon is providing assistance and guidance but I'm pretty much running it, with a few freelance dev guys doing a lot of the work. :)

Core and TKLDev

In times passed, our first release candidate (RC) only included Core but this time around we thought it would make much more sense to release TKLDev at the same time! This means that the community (yes I'm looking at YOU!) can not only test Core - the base appliance that all others are built on. But you can also test the build, install and usage of the whole library using TKLDev! How cool is that?!

Update: Here's a tutorial showing step by step instructions for building any TurnKey ISO from source.

Download the RCs and help us test them

Core (64bit / amd64 build):  205MB ISO  ( changelog ,  signature ,  manifest )

TKLDev (64bit / amd64 build):  263MB ISO  ( changelog ,  signature ,  manifest )

Help needed to complete the upgrade to Jessie

As many seasoned TurnKey users would know, historically a major version bump means a rebase on a new OS version. And as I mentioned above, v14.0 is no exception. TurnKey Linux v14.0 is built on top of Debian Jessie (aka Debian 8).

As there are significant changes that come with Jessie we could really do with some community help on this one. Alon has built these first RCs but I am sure that there will be plenty of issues we'll need to resolve. Just finding the bugs and reporting them on our Issue Tracker (or even just posting here) would be a massive help!

64 bits...

Many may note that there are only 64 bit downloads available this time around. Some may recall that we considered discontinuing 32 bit support back with the v13 release. Even though we decided not to, we have considered the 32 bit builds to be legacy builds for some time now. For this release we are focused on the 64 bit release only at this stage.

We are not totally clear whether this will be the end of 32 bit builds or not. We are deferring that decision for now and will revisit it once we get closer to a final stable release. As a general rule though, the only people that should be affected are those using really old hardware.

Track the progress

[UPDATE] the table linked to below may be out of date. Please see this google spreadsheet for up to date info regarding the v14.0 appliance updates.

As with the v13.0 development we plan to use the GitHub based dev wiki (v14.0 page - appliance status table) and issue tracker so everyone can keep up to speed on progress. Alon and/or Liraz will be merging pull requests at least once per week (often daily). Hopefully we'll get any show-stopper bugs sorted out pretty quickly.

So with a bit of community involvement tweaking and upgrading I hope v14.0 to be our best release yet! I know that with your help we can make it happen! :)

New appliances

There are also a number of new appliances that have been community developed that we hope to get into this release. If you have a favourite open source project or are associated with open source development and would like to see it released as a new TurnKey appliance then now is the time to act! If your appliance is ready and meets the standards by the time the stable release is ready then we'll include it in v14.0!

As anyone who has been paying attention would realise; v14.0RC1 has been out for over a month now. And here at TurnKey central we have been very busy updating the appliances. To be honest I wish that I was announcing the final release, but alas we're not there yet - there's still lots of work to do...

But we are certainly getting closer and I hope to be announcing a RC2 release very soon... Hopefully we may even be able to provide some prebuilt ISOs of v14.0RC2 appliances too! Obviously you could build them yourself but hey, we get that it's easier if that part is already done...

Progress Report

As you can see on our v14.0 Appliance Build Status Spreadsheet many of them (70+) are basically complete. While we've been at it we have managed to close 30 issues (mostly bugs). However we still have over 100 to go....

So most of the existing appliances are done. But we still have to test most of them and we also have a ton of bugs to squash. Depending on how things go we may need to hop over some of the feature requests to v14.1...

Outstanding appliances

Of particular note are the appliances which are still outstanding. These are (with some notes): [updated 07-07-2015]

• asp-net-apache - apache-mod-mono didn't make it into Jessie so will need to use upstream
• django - TKL Django example app needs rewriting from scratch
• domain-controller - needs testing (and possibly tweaking) due to Samba4 now being default Samba
• drupal7 - upgrade existing drupal6 appliance (so that it uses drupal7 from Debian repos - might rename 'drupal-stable') Note: we decided to just reuse the existing Drupal7 appliance (installed from upstream with drush)
• drupal8 - update of existing drupal7 appliance (install from upstream - probably rename drupal-dev) Thinking perhaps just name drupal8.
• ejabberd - Speeqe not compatible with Django1.7; either need to install replacement app (such as CandyChat?) or install Django1.4 to be deferred for now
• fileserver - Ajaxplorer has been radically updated since v13.0 and is now Pydio - old integration doesn't work... - we ended up doing things a little differently this time...
• joomla25 - needs update to latest stable Joomla (and renaming) - now Joomla3 (tracking the v3.x.x branch)
• lighttpd-php-fastcgi
• mysql - currently being worked on by Ken
• nginx-php-fastcgi
• openldap
• owncloud - oC7 in Debian repos; but probably need to document installation/upgrade from upstream... - partially done
• postgresql - also currently being worked on by Ken
• torrentserver - relies on fileserver to be deferred for now
• trac - some packages missing from Jessie
• typo3 - currently in progress
• xoops
• lxc

Keep in mind that some of these are already in progress but if you have some specific interest (e.g. you use that appliance, are involved with upstream, really love that software, are an expert, etc) then please post (or contact me directly) and I can give you some guidance.

Also as noted above we still have plenty of issues to close, so perhaps you can help with those?

Credit Where Credit is due!

I would also like to take this opportunity to give some credit to those that have been working to get this release to where it is. Some are long standing TKL community members who have contributed much over a number of years; others are new comers who have just started helping us out.

Some have contributed new appliances, or updated existing appliance build code. Some have reported bugs and some have fixed them I have tried to name everybody but I'm sure that I've missed some. Please feel free to speak up if you didn't get a mention and think that you should!

In no particular order:

• Jonathan Struebel
• Jeroen Peters
• Landis Arnold (TKL)
• Ken Robinson (TKL)
• Tim Hibberd (TKL)
• John Carver (TKL)
• @SiKing
• Lloyd Ernst and Cloudstaff.com including Bryan Santos, Adrian Del Rosario, Rodolfo Lansangan & Justin Ashley Salvacion
• Tim Buckland
• Hans Harder
• @wvengen
• Anton Pyrogovskyi
• Stefan Davis
• Alfonso Valdes
• Vinitha Cejo John
• Mark Krueg
• Richard van Dijk
• Rob Fantini
• pee

  Part of me would really like to get into the detail of what each of these great people have contributed but I'd probably never finish this blog post. Plus it would make it more likely that I would miss some important info...

  More Help Needed

  Despite the progress and all the great work already done by those noted above (and others I've possibly missed) we still need a big push to get this over the finish line. I am concerned that without some more hands pushing us along I might be writing a similar post in another month's time. Please help me avoid that! :)