Alestic.com - A Personal AWS Blog by Eric Hammond

The following tutorial (originally published in Aug ‘08) has been extensively updated today:

Running MySQL on Amazon EC2 with Elastic Block Store (EBS)

This tutorial explains one approach to using Amazon’s persistent storage mechanism as the backing for a database and includes pointers on how to create snapshots for secure backups.

The primary goal of the updates was to put forth an approach which works not only on the current Ubuntu and Debian AMIs published on https://alestic.com but also with new AMIs which use the Canonical kernels as well as the new Ubuntu AMIs published by Canonical.

Ubuntu AMIs which use the new Canonical kernels may have AppArmor enabled. The original tutorial required workarounds to function in this environment, but the new tutorial keeps files right where MySQL and the AppArmor configuration expect them to be, while at the same time keeping them on the EBS volume.

There is also a plethora of “sudo"s spread around the tutorial so that it will work if you connected to your instance using a normal, non-root user, as is required by the Canonical AMIs.

I have tested these instructions on a few different AMIs. Please let me know if you run into any problems or have suggestions for improvement.

=> Go read the tutorial

New updates have been released for all of the Ubuntu AMIs listed on:

https://alestic.com

The focus of this update includes enhanced security for ssh host keys, cleaning up the boot process and making it a bit faster, and upgrading desktop AMI software. Specific changes to the AMIs include:

• All Ubuntu packages upgraded to the latest versions as of 2008-04-14.
• Create new ssh host keys on first boot.
• Don’t try to set the hwclock under Xen and save 4 seconds on boot.
• Don’t try to run apparmor as we don’t have the kernel module installed yet.
• Silence grep warnings about missing authorized_keys file on boot.
• Create /tmp earlier in the boot process to avoid warnings.
• Desktop AMIs upgraded to NX Server 3.2.0 (Free Edition).

Additional changes available in the build script include:

• Support for building 64-bit desktop AMIs.
• Add –retry to ec2-upload-bundle.
• AMIs built by the script will not claim they were built by Eric Hammond in /etc/motd :)

Thanks to Thomas Shealy and Hans Omli for many of the above ideas and patches.

The most likely change to cause problems is the generation of new ssh host keys on the first boot. Yesterday’s Debian/Ubuntu ssh key security alert is not directly related, but it did prompt me to reconsider the risk with the current practice of having a single ssh host key for an AMI.

Most public AMIs on EC2 use a fixed ssh host key which means that the entire world can look at it and know what the secret host key is for every instance you start. This spoils the secret and allows man-in- the-middle attacks with no warnings when you ssh to your instance.

Generating a new ssh host key on the first boot solves this problem, but it adds additional complexity in the following case: If you assign a hostname to different instances at different times (dynamic DNS or round robin) then you are more likely to get warnings from ssh about the host key changing when connecting to that hostname.

If you rebundle one of these AMIs, the ssh host key will be shared among new instances of that AMI unless you do the following before bundling:

ln -s ../init.d/ec2-ssh-host-key-gen /etc/rcS.d/S50ec2-ssh-host-key-gen

Bonus for reading this far: I occasionally hang out on IRC channel ##ec2 so swing by and chat sometime.

irc://irc.freenode.net/##ec2