Updated AWS tools PPA for Ubuntu

I thought I would post a quick entry to spread the word about a ppa I've been maintaining with up to date versions of some of the AWS tools. It is named simply awstools. You can find it here.

Right now the ppa has the following packages:

• ec2-api-tools : Amazon's EC2 command line tools
• ec2-ami-tools : Amazon's EC2 AMI tools (rebundling and uploading images)
• iamcli : Identity Access Management (IAM) Command Line Toolkit
• rdscli : Command Line Toolkit for the Amazon Relational Database Service

To add this repository its as easy as:

$ sudo apt-add-repository ppa:awstools-dev/awstools
$ sudo apt-get update


Then, to install the newest available version of ec2-api-tools, do:

$ sudo apt-get install ec2-api-tools


I hope hope that is helpful.

How to find the right Ubuntu AMI on EC2

For anyone getting started on EC2, the first obstacle they're faced with is selecting an AMI (Amazon Machine Image). If your trying to find an Ubuntu image either via the Amazon Console or via the output of ec2-describe-images, you're likely to be overwhelmed. The success of Ubuntu as a platform and Ubuntu's commitment to refreshing AMIs means that there are literally thousands of of images on Amazon EC2 with "ubuntu"in their name. That, combined with and the lack of Ubuntu on the "Quick Start" menu makes this a non-trivial task.

The purpose of this post is to document how you can easily, quickly and safely find the Official Ubuntu AMIs on EC2 via the Amazon EC2 console or via your web browser.

Some General Ubuntu Information

You already may be aware of these items, but I want to point them out for those who are just getting started with Ubuntu or EC2.

• Ubuntu releases every 6 months. Each release has a version number and a codename. The most important thing to note here is that every 2 years a LTS (Long Term Support) release is made. If you want stability and support for 5 years, select an LTS release. If you want the newest packages, select the most recent release. See the wikipedia entry for more information.
  
• At the time of this writing, there are 5 "regions" in Amazon EC2. Each region represents a geographical location. Each region has its own AMI ids. Inside each region there are 2 architectures (x86_64, i386) and 2 "root store" types (EBS or instance). That means that for each build Ubuntu releases, we generate 20 ami ids.

Easiest: Find AMIs From Your Web Browser

You can choose your interface for selecting images. Go to either:

• http://cloud.ubuntu.com/ami
At the bottom of this page, you can select the region, release, arch or root-store. You're only shown the most recent releases here. When you've made your selection, you can copy and paste the ami number, or just click on it to go right to the EC2 console launch page for that AMI. or
• https://cloud-images.ubuntu.com/server/releases/
• Select Your release by number or code-name
• Select 'release/': We keep historical builds around for debugging, but the 'release/' directory will always be the latest.
• Select your AMI from the table and click to launch in the console or copy and paste a command line.

Search through the Amazon EC2 Console

The EC2 Console is a graphical way to sort through AMIs and select one to launch. To Launch an Official Ubuntu Image here, follow the steps below.

• Select the region you want in the top left, under 'Navigation'
Example: "Us East (Virginia)"
• Click "AMIs"
Do not click "Launch Instance", see note below
• for 'Viewing', select "All Images"
• Limit the results to Ubuntu Stable Release images by typing ubuntu-images/
You should expand the 'AMI Name' field as wide as possible (maybe shrink the others).
• Limit the results to a specific release by appending '.*'.
For example: ubuntu-images/.*10.04
• Limit the results to a given arch by appending '.*i386' or '.*amd64'
Note: If you want to run a m1.small or c1.medium, you need 'i386'. If you want to run a t1.micro, you will need to select an 'ebs' image.
• Sort your results by AMI Name and make selection
By sorting by AMI name, you can more easily see the newest AMI for a given set. Each AMI ends with a number in the format YYYYMMDD (year,month,day). You want the most recent one.
• Verify the Owner is 099720109477!
  Any user can register an AMI under any name. Nothing prevents a malicious user from registering an AMI that would match the search above. So, in order to be safe, you need to verify that the owner of the ami is '099720109477'.
  If "Owner" is not a column for you, click "Show/Hide" at the top right and select "Owner" to be shown.
  
• Click on the AMI name, then Click 'Launch'

Notes

• HTTPS Access
Of the options above, right now https://cloud-images.ubuntu.com/server/releases/ is the only one that provides data over https. This may be important to you if you are concerned about potential "Man in the Middle" attacks when finding a AMI id. I've requested Ahmed [kim0 in irc] to support https access to https://cloud.ubuntu.com/ami .
• Web Console 'Launch Instance' dialog
I saw no way in the 'Launch Instance' dialog to see the Owner ID. Because if this, I suggest not using that dialog to find "Community AMIs". There is simply no way you can reliably know who the owner of the image is from within the console. For advanced users, I will blog sometime soon on a way to find AMIs programmatically [Hint].

Getting a larger root volume on a cluster compute instance

At this point, all of the Ubuntu EBS root images are 8GB. This is nice and small. I previously covered how you could increase the size of those disks.

On Cluster Compute instances, its a bit more difficult. The cluster compute instances have their root filesystem in a partition inside of the disk attached. Thats all well and good, and most likely a partitioned disk is more familiar to you than one that is not partitioned. The cluster compute images have grub2 installed in the MBR of that disk.

The problem with the partition on the disk is that you can no longer simply launch the instance with a larger root volume and then 'resize2fs /dev/sda1'. This is because the kernel won't re-read the partition table of a disk until all of its partitions are unmounted. For the disk that holds your root partition, that means you basically have to reboot after a change.

To avoid that waste of precious time, we've included a utility called 'growpart' inside of the initramfs on the Ubuntu images. It is invoked by the 'cloud-initramfs-growroot' package. This code runs before the root fileystem is busy, so the request for the kernel to re-read the partition table will work without requiring a reboot. To try it out, do:


# us-east-1 ami-1cad5275 hvm/ubuntu-natty-11.04-amd64-server-20110426
$ ec2-run-instances --region us-east-1 --instance-type cc1.4xlarge \
--block-device-mapping /dev/sda1=:20 ami-1cad5275


When you get to the instance, you'll have a 20G filesystem on /. And, if you're interested enough to look in the console output, you'll see something like:

GROWROOT: CHANGED: partition=1 start=16065 old: size=16755795 end=16771860 new: size=41913585,end=41929650


start a 11.04 instance with a larger root filesystem

In order to fit inside the Amazon "Free Tier", Ubuntu made the decision to change its root volume size from 15G to 8G. That decision was made for all refreshed EBS root images. So, our current set of 10.04, 10.10 and 11.04 images have 8G root filesystems.

If you find that space somewhat limiting, it is easy to give yourself a larger root volume at instance creation time. Its easy

Launch the instance with appropriate block-device-mapping arguments


$ ec2-run-instances $AMI --key mykey --block-device-mapping /dev/sda1=:20


That will create you an instance with a 20G root volume. However the filesystem on that volume will still only occupy 8G of the space. Essentially, you'd have 12G of unused volume at the end of the disk.

Resize the root volume

if you've launched an 11.04 based image newer than alpha-2, this step is not necessary. Cloud-init will do it for you. It is just assumed that you want your root filesystem to fill all space on its partition. I honestly cannot think of a reason why you would not want that.

Now, if you are using 10.04 or 10.10 images, you can resize your root volume easily enough after the boot. Just login, and issue:


$ sudo resize2fs /dev/sda1

That operation should take only a few seconds or less, and you'll then have all the space you need.

Migrating to pv-grub kernels for kernel upgrades

After the release of the Ubuntu 10.04 LTS images that use the pv-grub kernel, there were some questions on what to do if you're running from an older AMI and want to take advantage of what pv-grub offers.

Heres a short list of how you might be affected:

• If you are running an EBS root instance launched from or rebundled from an Official Ubuntu image of 10.04 LTS (Lucid Lynx) released 20110201.1 or later, 10.10 (Maverick Meerkat), Natty Narwhal, or later, then you do not need to do anything. You already are using pv-grub, and can simply apply software updates and reboot to get new kernel updates. You can stop reading now.
• If you are running an instance-store instance that is not using a pv-grub kernel, there is nothing you can do. There is simply no way to change the kernel of an instance store instance.
• If you are running an EBS-root based instance rebundled from a Ubuntu 9.10 (Karmic Koala) or older, then there is currently no supported path to getting kernel upgrades. There were no officially released EBS-root based Ubuntu images of 9.10, and with Karmic's end of life coming in April, there is not likely to be support for this new feature.
• If you are running an EBS-root instance launched from or rebundled from an official Ubuntu release of 10.04, read on.

Updating a 10.04 based image basically entails 2 steps, setting up /boot/grub/menu.lst, and then modifying your instance to have a pv-grub kernel.

Step 1: installing grub-legacy-ec2.

If you launched or rebundled your instance from an Ubuntu 10.04 numbered 20101020 or earlier, you need to do this step. If you started from a release of 20101228 you can skip this step.

• Apply software updates.
  
  Depending on how out of date you are, this might take a while.
  
  
sudo apt-get update && sudo apt-get dist-upgrade

  
• Install grub-legacy-ec2
  
  

  The 'grub-legacy-ec2' package is what the images use to manage /boot/grub/menu.lst. If you had used Ubuntu prior to the default selection of grub2, you will be familiar with how it works. grub-legacy-ec2 is basically just the menu.lst managing portion of the Ubuntu grub 0.97 package with some EC2 specifics thrown in.

  To get a functional /boot/grub/menu.lst, all you have to do is:

  
sudo apt-get install grub-legacy-ec2

  

Step 2: modifying the instance to use pv-grub kernels

Now, your images should have a functional /boot/grub/menu.lst, and grub-legacy-ec2 should be properly installed such that future kernels will get automatically added and selected on reboot. However, you have to change your instance to boot using pv-grub rather than the old kernel aki that you originally started with.

• Shut down the instance
  
  The best way to do this is probably to just issue '/sbin/poweroff' inside the instance. Alternatively, you could use the ec2 api tools, or do so from the AWS console.
  
% sudo /sbin/poweroff

  
• Modify the instance's kernel to be a pv-grub kernel
  
  Once the instance is moved to "stopped" state, you can modify its kernel to be a pv-grub kernel. The kernel you select depends on the arch and region. See the table below for selecting which you should use:
  

  region	arch	aki id
  ap-southeast-1	x86_64	aki-11d5aa43
  ap-southeast-1	i386	aki-13d5aa41
  eu-west-1	x86_64	aki-4feec43b
  eu-west-1	i386	aki-4deec439
  us-east-1	x86_64	aki-427d952b
  us-east-1	i386	aki-407d9529
  us-west-1	x86_64	aki-9ba0f1de
  us-west-1	i386	aki-99a0f1dc

  
  Then, assuming you have $AKI represents the appropriate aki above, and $IID represents your instance id, and $REGION represents your region, you can update the instance and then start it with:
  
$ ec2-modify-instance-attribute --region ${REGION} --kernel ${AKI} ${IID}
$ ec2-start-instances --region ${REGION} ${IID}

  

Your instance will start with a new hostname/IP address, so get that out of describe-instances and ssh to your instance. You can check that it has worked by looking at /proc/cmdline. Your kernel command line should look something like this:


$ cat /proc/cmdline
root=UUID=7233f657-c156-48fe-8d60-31ae6400d0cf ro console=hvc0


In the future, your instance will now behave much more like a "normal server". If you apply software updates (apt-get dist-upgrade) and reboot, you'll boot into a fresh new kernel.

Getting ephemeral devices on EBS images

When you launch an instance in EC2, be it EBS root or instance-store, you are "entitled" to some amount of ephemeral storage. Ephemeral storage is basically just extra local disk that lives in the host machine where your instance will run. How much instance-store disk you are entitled to is described with the instance size descriptions.

The described amount of ephemeral storage is allocated to all instance-store instances. However, at register time of EBS-root instances the default "block-device-mapping" is set. Because an EBS-root AMI may be run with different instance-types, it is impossible to set the correct mapping for all scenarios. For the Ubuntu images, the default mapping only includes ephemeral0, which is present in all but t1.micro sizes.

So, if you want to "get all that you're paying for", you'll have to launch instances with different '--block-device-mapping' arguments to ec2-run-instances (or euca-run-instances). I've written a little utility named bdmapping to make that easier, and hold the knowledge.

You can use it to show the mappings for a given instance type:


$ ./bdmapping
--block-device-mapping=sdb=ephemeral0 --block-device-mapping=sdc=ephemeral1


Or, use it with command substitution when you launch an instance:

$ ec2-run-instances $(bdmapping -c m1.xlarge) --key mykey ami-c692ec94
#
# the above is the same as running:
# ec2-run-instances --block-device-mapping=sdb=ephemeral0 \
# --block-device-mapping=sdc=ephemeral1 --instance-type=m1.large \
# --key mykey ami-c692ec94


You can view or download 'bdmapping' at https://gist.github.com/809587

New Ubuntu 10.04 LTS images with pv-grub support

Yesterday I announced the availability of updated Ubuntu images on EC2 for 10.04 LTS (Lucid Lynx).

This post is mainly to mirror that one to a possibly wider audience, but also to go into more detail on the key change in these images:

You can now upgrade the kernel inside your 10.04 based EC2 image by running 'apt-get update && apt-get dist-upgrade && reboot!

Now, for a little more detail on that.

Around the time that 10.04 released, or shortly there after, Amazon released a new feature of EC2 as "Use Your Own Kernel with Amazon EC2". What this really meant was that there were now "kernels" on EC2 that were really versions of grub. By selecting this kernel, and providing a /boot/grub/menu.lst inside your image, the instance would be in control of the kernel booted. Previously, the loading of a kernel was done by the xen hypervisor, and could not be changed at all for a instance-store image, and only non-trivially for an EBS-root instance

Yes, you read that right, midway through the year of 2010 you were able to change the kernel that you were running in an EC2 instance with a software update and a reboot.

We took advantage of this support in our 10.10 images, but for many people, only LTS (Long Term Support) releases are interesting. So, to satisfy those people, we've brought the function into our 10.04 images.

If you're using our images, or have rebundled an image starting from them, I *strongly* suggest updating to the 20110201.1 images or anything later. You'll want to do that because

• You can receive kernel upgrades as normal software upgrades to your running instance.
• This is by far the most supportable route for upgrade from 10.04 to our next LTS (12.04). If your instance is not using the pv-grub kernel, and you want to upgrade to a newer release, you will have to upgrade, shutdown the instance, modify the associated kernel, and start up the instance. That is both more painful, and will result in larger downtime.
  

So, in short, grab our new images!