smoser's thoughts

$40 mp3 player with wifi, speaker, linux support (palm pixi plus)

2012-01-04T17:29:00.000-08:00

For almost 4 years I have used a mp3 player from Creative Labs named "ZEN Stone Plus with built-in speaker". It was used it to play music for our toddler all night long, nearly every night.

It was an absolutely wonderful product. Battery life via rechargeable battery was excellent, it was small enough to forget about in your pocket, and the speaker was sufficient for what we needed

The only deficiency in my opinion was that it could not play music while plugged into AC power. That meant that a.) the battery would have to last the 10+ hours every night and b.) we had to plug it into AC power every morning to charge it. In the end, it was the latter that caused me to need to replace it. After probably 1000+ plug-in and remove (many by a child under 5 years old) the pins in the USB connection eventually failed.

If you're looking for a portable MP3 player with a built-in speaker, your options are very few. The Ipod Touch (and Iphone) are perfectly good solutions, but come a hefty price tag even used. So, I had to get creative.

I'd seen the Palm Pixi appear on a couple "deal-a-day" websites at the $30 price range, and that lead me to consider the Palm Pixi Plus. The Pixi Plus has the following features that made it look *very* tempting:

8GB storage
Internal Speaker
wifi
web browser
GPS
Camera
Touch screen and physical keyboard
can play music while charging
runs linux! (just geeky)
open development platform

However, I googling left me unsure about a couple things:

Could I use the pixi's wifi without first activating it with some carrier? I had no interest in a phone, or a monthly bill. It did seem that worst case, I could activate on a pay-as-you-go provider and get going for probably less than $10 total.
If I could manage to avoid activation, could I still have access to the Palm WebOS Store? Having an "App Store" was an unnecessary upgrade from the zen stone we had before, but sure would be nice.

In the end, the answer to each of the above questions was 'Yes'. I now have a MP3 player with a builtin speaker, that also has all the functions generally associated with a smart phone (see above). I'm really happy with it. It cost me $40 shipped in 2 days (I do have amazon prime, so total cost may be a little bit more). The only two issues at the moment are:

Getting it plugged in for charge is a bit of a pain, and it seems to me that likely the thing that will end up failing is that connection, because its not 100% trivial (and remember, toddlers/young kids are using it). There is, however, a $15 solution for that. I've not purchased it yet, so I'm not 100% certain, but it looks like I can get a Touchstone Palm Pixi Charging Dock and Palm Pixi Touchstone Cover shipped for under $10.
The music player stops somewhere after 2 hours or so when its on repeat of a single song. Obviously this is not an issue for many people, but it affects my use case.

In Summary, if you think an 8GB mp3 player with GPS, speaker, camera would be a generally cool toy for $40, then buy one today. I'm really happy with this one. I'll try to write another article soon that describes how to use Meta Doctor to flash with activation disabled and then run the first use program to set up a profile.

Chuck sightings

2011-11-17T10:27:00.000-08:00

Chuck loves the Red Wings!

Chuck has a 4 year old

RFC: anyone using vmdk or ovf files from cloud-images?

2011-08-29T09:49:00.000-07:00

Friday I posted the following on ec2ubuntu and ubuntu-cloud mailing lists. I'm posting here in an effort to reach a larger audience.

If you are using the OVF files or VMDK files, please respond.

Date: Fri, 26 Aug 2011 16:34:41

From: Scott Moser

Subject: Anyone using the .ovf and/or .vmdk files on cloud-images?

Hey all,

   Is anyone using the .vmdk or .ovf files on

http://cloud-images.ubuntu.com [1] ?

   In the 11.04 cycle, I started building .ovf files with corresponding

.vmdk images.  The goal of this was to make Ubuntu available for use via

software that supported importing OVF.

   I chose to to create the disk as VMDK formated images rather than a

more open-source friendly format such as qcow.   The OVF file and

associated disk image is consumable by both vmware tools and by

VirtualBox.  There are no OVF consumers that I'm aware of that would

function with a qcow (or even 'raw') disk image.  I feel compelled to also

mention that this format of vmdk (compressed) is not supported by qemu-img

or kvm.

   Since having an OVF that could not be used by any software is not

significantly more useful than not having an OVF, we went with vmdk.

   Largely prompted by the interest in providing a download format that is

ideal for OpenStack users [2], I am re-considering my decision.  I would

like to avoid adding another full disk image format to the output of the

build scripts.  As a result I'm thinking about replacing the .vmdk images

with compressed qcow images and updating the OVF files to reference those.

   The reason behind not wanting to just add yet another deliverable is

that more downloads are confusing, and disk space is not necessarily free.

If I can drop a deliverable not used by anyone, then I'd like to do that.

   So, would anyone object to the removal of .vmdk files from

cloud-images?  Is anyone using these that could not just as easily use

qcow2 formated images?

   Thanks,

   Scott

--

[1] http://cloud-images.ubuntu.com/server/oneiric/current/

[2] https://bugs.launchpad.net/ubuntu/+bug/833265

Amazon issues with EBS affect Ubuntu images in the EU-WEST region

2011-08-09T08:46:00.000-07:00

Note: This blog post has been updated in-place.

We have received information from Amazon that the EBS snapshots for our released 10.04 images from 20110719 were not affected (ami-5c417128 and ami-52417126). ~~It seems that an api issue incorrectly marked them as such~~. It was an error in our logic that associated snapshot-ids with amis that gave us the incorrect output. The only Ubuntu images that were affected were old daily builds and milestone releases. If you are interested in reading the original message, please do so on the Ubuntu cloud-announce mailing list archives.

We received this morning an automated email[1] from Amazon informing us of possible loss of data in EBS snapshots on the EU-WEST-1 region. Our engineering team immediately started an assessment of the damages this might have caused to the EBS images that we publish for our users. We are working with Amazon to re-mediate customer impact and prevent any future outages.

A number of non-current daily build and old alpha or beta images have been affected, but we hope that no one would have been using these images for production use; we are not planning corrective actions for these images. You can see the full list of AMIs affected at http://paste.ubuntu.com/662210/.

To have this type of announcements sent to your email directly, please subscribe to our ubuntu-cloud-announce mailing list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-cloud-announce..

Our support services are available to help customers of the Ubuntu Advantage Cloud Guest program. Details about this program can be found at http://www.canonical.com/enterprise-services/ubuntu-advantage/cloud

[1] Email received from Amazon on Aug 9 2011 at 9:11 UTC

Hello,

We've discovered an error in the Amazon EBS software that cleans up unused snapshots. This has affected at least one of your snapshots in the EU-West Region.

During a recent run of this EBS software in the EU-West Region, one or more blocks in a number of EBS snapshots were incorrectly deleted. The root cause was a software error that caused the snapshot references to a subset of blocks to be missed during the reference counting process. This process compares the blocks scheduled for deletion to the blocks referenced in customer snapshots. As a result of the software error, the EBS snapshot management system in the EU-West Region incorrectly thought some of the blocks were no longer being used and deleted them. We've addressed the error in the EBS snapshot system to prevent it from recurring.

We have now disabled all of your snapshots that contain these missing blocks. You can determine which of your snapshots were affected via the AWS Management Console or the DescribeSnapshots API call. The status for any affected snapshots will be shown as "error."

We have created copies of your affected snapshots where we've replaced the missing blocks with empty blocks. You can create a new volume from these snapshot copies and run a recovery tool on it (e.g. a file system recovery tool like fsck); in some cases this may restore normal volume operation. These snapshots can be identified via the snapshot Description field which you can see on the AWS Management Console or via the DescribeSnapshots API call. The Description field contains "Recovery Snapshot snap-xxxx" where snap-xxx is the id of the affected snapshot. Alternately, if you have any older or more recent snapshots that were unaffected, you will be able to create a volume from those snapshots without error. For additional questions, you may open a case in our Support Center: https://aws.amazon.com/support/createCase

We apologize for any potential impact this might have on your applications.

Sincerely,
AWS Developer Support

This message was produced and distributed by Amazon Web Services LLC, 410 Terry Avenue North, Seattle, Washington 98109-5210

How to find the right Ubuntu AMI with tools

2011-07-29T17:22:00.000-07:00

A while ago, I gave instructions on how you could find the right Ubuntu AMI. I promised to write about how you could accomplished programmaticly.

When we publish Ubuntu AMIs, we simultaneously publish machine consumable data to https://cloud-images.ubuntu.com/query/. The data there contains information so that you can:

Find the latest ami of a given type (hvm/ebs/instance-store), arch, and region.
Download the pristine image files

I think the format of the data is generally discernible, but there is some more information on the Ubuntu Wiki.

I've put an example client together. Here is some example usage:

Launch the latest released image in us-east-1

$ euca-run-instances --instance-type t1.micro --key mykey $(ubuntu-ami)

Open the Amazon EC2 console to launch the latest Oneiric daily build

directly link

$ ami=$(ubuntu-ami us-west-1 oneiric daily i386)
$ gnome-open https://console.aws.amazon.com/ec2/home?region=us-west-1#launchAmi=${ami}

Download and extract the latest tarball for lucid

$ wget $(ubuntu-ami -f "%{url} -O %{pubname}.tar.gz")
$ uec-publish-tarball *.tar.gz my-ubuntu-images

I don't think I'll get this into 11.10, but I'd like to have something with this function into 12.04, and support launching AMIs directly through it for ease of use. I'd love to hear input on what you'd like a "ubuntu-run-instance" command to look like and do.

Updated AWS tools PPA for Ubuntu

2011-07-25T08:36:00.000-07:00

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

2011-07-18T07:01:00.000-07:00

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
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'
Click "AMIs"
for 'Viewing', select "All Images"
Limit the results to Ubuntu Stable Release images by typing ubuntu-images/
Limit the results to a specific release by appending '.*'.

ubuntu-images/.*10.04

Limit the results to a given arch by appending '.*i386' or '.*amd64'
Sort your results by AMI Name and make selection
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

Ahmed

Web Console 'Launch Instance' dialog

Hint

Getting a larger root volume on a cluster compute instance

2011-07-15T14:04:00.000-07:00

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

2011-03-02T13:43:00.000-08:00

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

2011-02-03T18:59:00.000-08:00

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

2011-02-03T11:34:00.000-08:00

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

2011-02-03T08:03:00.000-08:00

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!

Failsafe and manual management of kernels on EC2

2011-01-11T10:47:00.000-08:00

On 10.10 and later, Ubuntu images use the Amazon provided pv-grub to load kernels that live inside the image. The selected kernel is controlled by /boot/grub/menu.lst. This makes it possible to install a new kernel via 'dpkg -i' or 'apt-get dist-upgrade' and then reboot into the new kernel.

The file /boot/grub/menu.lst is managed by grub-legacy-ec2 package. The program 'update-grub-legacy-ec2' is called on installation of Ubuntu kernels through files that are installed in /etc/kernel/postinst.d and /etc/kernel/postrm.d.

By default, as with other Ubuntu systems, the kernel with the highest revision will be the behavior will be automatically selected as the default, and selected on the next boot. Because EC2 images is read-only, you may want to manually manage your selected kernel. This can be done by modifying /boot/grub/menu.lst to use the grub "fallback" code.

I'll launch an instance of the current released maverick (ami-ccf405a5 in us-east-1 ubuntu-maverick-10.10-i386-server-20101225). Then, on the instance, create hard links to the default kernel and ramdisk so even on apt removal, they'll stick around, and then change /boot/grub/menu.lst to use those kernels.


sudo ln /boot/vmlinuz-$(uname -r) /boot/vmlinuz-failsafe
sudo ln /boot/initrd.img-$(uname -r) /boot/initrd.img-failsafe

Then, copy the existing entry in /boot/grub/menu.lst to a new entry above the automatic section. I've changed/added:


# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default         saved

...<snip>...

# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

# this is the failsafe kernel, it will be '0' as it is the first
# entry in this file
title           Failsafe kernel
root            (hd0)
kernel          /boot/vmlinuz-failsafe root=LABEL=uec-rootfs ro console=hvc0 FAILSAFE
initrd          /boot/initrd.img-failsafe
savedefault

title           Ubuntu 10.10, kernel 2.6.35-24-virtual
root            (hd0)
kernel          /boot/vmlinuz-2.6.35-24-virtual root=LABEL=uec-rootfs ro console=hvc0 TEST-KERNEL
initrd          /boot/initrd.img-2.6.35-24-virtual
savedefault     0

And then update grub to store that the first kernel is the 'saved', which for grub 1 (or 0.97) modifies /boot/grub/default.


sudo grub-set-default 0
sudo reboot

Now, a reboot will boot into the failsafe kernel (which we can verify by checking /proc/cmdline) and see 'FAILSAFE'. Then, to test our "TEST-KERNEL", run:


sudo grub-set-default 1
sudo reboot

After this reboot, the system come up into "TEST-KERNEL" (per /proc/cmdline) but /boot/grub/default will contain '0', indicating that on subsequent boot, the FAILSAFE will run. In this way, if your kernel failed to boot all the way up, you can then just issue:


euca-reboot-instances i-15b77779

And you'll boot back into the FAILSAFE kernel.

The above basically allows you to manually manage your kernels while letting grub-legacy-ec2 still write entries to /boot/grub/menu.lst.

I chose to use hardlinks for the 'failsafe' kernels, so that even on dpkg removal, the files would still exist. Because the 10.10 Ubuntu kernels have the EC2 network and disk drivers built in, you'll still be able to boot even after a dpkg removal of the failsafe kernel or an errant 'rm -Rf /lib/modules/2*'

Using euca2ools rather than ec2-api-tools with EC2

2011-01-07T07:25:00.000-08:00

The Ubuntu UEC Images that Ubuntu produces on EC2 are in every way fully supported, "Official Ubuntu". As with other official releases, access to source code for security and maintenance reasons affects our decisions on what is included.

In the UEC images, the most notable packages left out are 'ec2-api-tools' and 'ec2-ami-tools'. I personally use the ec2-api-tools and ec2-ami-tools quite frequently and Amazon has done a great job with them. However, the license and lack of source code prevents them from being in Ubuntu 'main'.

Fortunately
a.) There are packages made available in the Ubuntu 'multiverse' component.
b.) The euca2ools package is installed by default and provides an almost drop in replacement for the ec2-api-tools and ec2-ami-tools.

I think that many users of EC2 aren't aware of the euca2ools, so I'd like to give some information on how to use them here.

The ec2-api-tools use the SOAP interface and thus use the "EC2_CERT" and "EC2_PRIVATE_KEY". The euca2ools sit on top of the excellent boto project. Boto uses the AWS REST api, which means authentication is done with your "Access Key" and "Secret Key". As a result, configuration is a little different. (Note, bundling images, you still need the EC2_CERT and EC2_PRIVATE_KEY for encryption/signing).

Configuration for euca2ools can be done via environment variables (EC2_URL, EC2_ACCESS_KEY, EC2_SECRET_KEY, EC2_CERT, EC2_PRIVATE_KEY, S3_URL, EUCALYPTUS_CERT) or via config file. I personally prefer the configuration file approach.

Here is my ~/.eucarc that is configured to operate with the EC2 us-east-1 region.


CRED_D=${HOME}/creds/aws-smoser
EC2_REGION="${EC2_REGION:-us-east-1}"
EC2_CERT=${CRED_D}/cert.pem
EC2_PRIVATE_KEY=${CRED_D}/pk.pem
EC2_ACCESS_KEY=ABCDEFGHIJKLMNOPQRST
EC2_SECRET_KEY=UVWXYZ0123456789abcdefghijklmnopqrstuvwx
EC2_USER_ID=950047163771
EUCALYPTUS_CERT=/etc/ec2/amitools/cert-ec2.pem
EC2_URL=https://ec2.${EC2_REGION}.amazonaws.com
S3_URL=https://s3.amazonaws.com:443

Things to note above:

euca2ools sources the ~/.eucarc file with bash, and then reads out the values of EC2_REGION, EC2_CERT, EC2_PRIVATE_KEY, EC2_ACCESS_KEY, EC2_USER_ID, EC2_URL, S3_URL. This means that you use other bash functionality in the config file as I've done above with 'EC2_REGION'. This allows me to do something like:
EC2_REGION=us-west-1 euca-describe-images
If there is no configuration file specified with '--config', then those values will be read from environment variables

Amazon's public certificate from the ami tools is included with euca2ools in ubuntu, and located in /etc/ec2/amitools/cert-ec2.pem

Many of the euca2ools commands will run significantly faster than the ec2-api-tools. The reason for slowness of the ec2-api-tools is their man java dependencies (please correct me if I'm wrong).
Your ~/.eucarc file contains credentials and therefore it should be protected with filesystem permissions (ie 'chmod go-r ~/.eucarc').

Hopefully this will make it easier for you to use euca2ools with EC2 on Ubuntu.

Ubuntu Natty Narwhal Cluster Compute Instances

2010-12-14T12:07:00.000-08:00

Some time ago, Amazon announced two new instance types aimed at high performance computing. The new types differ from Amazon's previous offerings in that

They use Xen "hvm" (Hardware Virtualization Mode) rather than 'paravirtualization'
Only priviledged accounts can create images of the 'hvm' virtualization-type.

The result is that there are very few public images for cluster compute nodes, and up until today, there were no Ubuntu images.

I'm happy to announce that you can now run Official Ubuntu images on cluster compute instance types. From today forward we will be publishing daily builds of Natty Narwhal builds.

These images are identical to the other Ubuntu images. For AMI ids, you can browse the list at http://uec-images.ubuntu.com/server/natty/current/, or use more machine friendly data at http://uec-images.ubuntu.com/query.

There is one known bug (bug 690286) that prevents you from using ephemeral storage on the CC nodes.

If you've got a couple dollars burning a whole in your pocket, you can try one out with:

   qurl="http://uec-images.ubuntu.com/query/" 
ami_id=$(curl --silent "${qurl}/natty/server/daily.current.txt" | 
    awk '-F\t' '$11 == "hvm" && $7 == "us-east-1" { print $8 }')
  ec2-run-instances --key mykey --instance-type cc1.4xlarge "${ami_id}"

lvm resizing is easy

2010-12-07T07:33:00.000-08:00

I have a local mirror of the ubuntu archive, using some scripts based on the Ubuntu Wiki. When I set up "/archive" on my local mirror, I used lvm. The reason for that was primarily so that I could use sbuild with lvm.

Since then, 2 things have happened:

sbuild has gained the ability to use aufs rather than LVM snapshots. The solution is much lighter weight, and doesn't require some lvm space sitting around waiting to be used.
The ubuntu archive has grown in size from ~ 250G to ~ 400G right now.

So, it was time for me to resize the filesystem that had my archive up to accommodate. For my own record, and possibly others, I thought I'd share what I did.


$ sudo pvscan
  PV /dev/sdb    VG smoser-vol1   lvm2 [931.51 GiB / 315.57 GiB free]
  PV /dev/sda1   VG nelson        lvm2 [148.77 GiB / 44.00 MiB free]
$ sudo lvscan
  ACTIVE            '/dev/smoser-vol1/smlv0' [585.94 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/hardy_chroot-i386' [5.00 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/lucid_chroot-i386' [5.00 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/karmic_chroot-i386' [5.00 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/karmic_chroot-amd64' [5.00 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/lucid_chroot-amd64' [5.00 GiB] inherit
  ACTIVE            '/dev/smoser-vol1/hardy_chroot-amd64' [5.00 GiB] inherit
  ACTIVE            '/dev/nelson/root' [142.65 GiB] inherit
  ACTIVE            '/dev/nelson/swap_1' [6.07 GiB] inherit

I had 2 physical volumes, sdb and sda1. 'sdb' had my old sbuild snapshots on it, and also some free space. So, I deleted sbuild snapshots with:


$ sudo lvremove /dev/smoser-vol1/hardy_chroot-i386 \
   /dev/smoser-vol1/lucid_chroot-i386 /dev/smoser-vol1/karmic_chroot-i386 \
   /dev/smoser-vol1/karmic_chroot-amd64 /dev/smoser-vol1/lucid_chroot-amd64 \
   /dev/smoser-vol1/hardy_chroot-amd64

Then, resized the 'smlv0' volume that had my '/archive' on it up to the largest that I could on that physical volume:


$ sudo vgdisplay smoser-vol1
  VG Name               smoser-vol1
  System ID             
  Format                lvm2
<snip>
  VG Size               931.51 GiB
...
$ sudo lvresize /dev/smoser-vol1/smlv0 --size 931.51G
  Rounding up size to full physical extent 931.51 GiB
  Extending logical volume smlv0 to 931.51 GiB
  Logical volume smlv0 successfully resized

Then, just resize the ext4 filesystem on that volume:


$ grep archive /proc/mounts
/dev/mapper/smoser--vol1-smlv0 /archive ext4 rw,relatime,barrier=1,data=ordered 0 0
$ sudo resize2fs /dev/mapper/smoser--vol1-smlv0
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/mapper/smoser--vol1-smlv0 is mounted on /archive; on-line resizing required
old desc_blocks = 37, new_desc_blocks = 59
Performing an on-line resize of /dev/mapper/smoser--vol1-smlv0 to 244190208 (4k) blocks.

The filesystem on /dev/mapper/smoser--vol1-smlv0 is now 244190208 blocks long.

That last operation did take probably 30 minutes, but in the end, I now have:


$ df -h /archive/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/smoser--vol1-smlv0
                      917G  544G  327G  63% /archive

Using Ubuntu Images on AWS "Free Tier"

2010-11-03T13:47:00.000-07:00

[Update 2011-01-20]

There are now official Ubuntu AMIs that fit into the Free Tier disk requirements. You can get a list of the AMIs for 10.04 or 10.10.

This article is still useful as documentation, but is not necessary if you only want to use Ubuntu on Amazon's Free Tier.

Amazon AWS recently announced an AWS Free Usage Tier. The summary of which is that new AWS customers can run a t1.micro instance 24x7 for the next year and pay nothing (or at least very little).

There are various restrictions on what you get for free, but the most interesting to the Ubuntu images is:

10 GB of Amazon Elastic Block Storage, plus 1 million I/Os, 1 GB of snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests*

The Official Ubuntu Images have a 15GB root filesystem. What that means is if you're using any of our official images (10.04, 10.10), then you will be charged for 5GB of provisioned storage per month. In the us-east-1 region that would be $0.50/month. In other regions, that would be $0.55/month.

This issue has been raised on the AWS Discussion Forums, but it seems like Amazon is not willing to budge.

Similarly, bug 670161 was opened requesting "10GB root partition for EBS boot AMIs on EC2". If you're interested in following this discussion, subscribe yourself to that bug. I will make sure that it is kept up to date.

I don't want to comment right now on whether or not we will release future EBS root AMIs of 10.04 and and 10.10 with a 10GB filesystem instead of a 15G filesystem. What I do want to discuss is how you can create your own AMI that has a 10G (or smaller) root filesystem, which will perform otherwise identically to the official images.

If you want to use Ubuntu on the Amazon Free Tier *right now*, then you can follow these instructions, which assume you have the ec2-api-tools correctly configured on your laptop. And you have a keypair named "mykey" available in the target region.

In the code (shell prompt) snippits below, '$' prompt indicates command run on my laptop. '%' prompt indicates command run on the ec2 instance. lines beginning with a '#' are comments.

Launch an instance to work with:


# us-east-1 ami-548c783d canonical ebs/ubuntu-maverick-10.10-amd64-server-20101007.1
$ ec2-run-instances --region us-east-1 --instance-type t1.micro \
--key mykey ami-548c783d
$ iid=i-1855ea75
$ zone=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $12 }' iid=${iid} )
$ echo ${zone}
us-east-1d
$ host=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $4 }' iid=${iid} )
$ echo ${host}
ec2-174-129-61-12.compute-1.amazonaws.com

create a volume in correct zone of the desired size to attach to the instance. Change '10' to '5' if you wanted a 5GB root filesystem.


$ ec2-create-volume --size 10 --availability-zone ${zone}
$ vol=vol-c64d55af
$ ec2-attach-volume --instance ${iid} --device /dev/sdh ${vol}

Then, ssh to ubuntu@${host}, and download the uec reference image and extract it. Below, I've downloaded the i386 image for maverick. You could browse through at http://uec-images.ubuntu.com/releases/10.10/release/ and find an amd64 image or a 10.04 base image.


% sudo chown ubuntu:ubuntu /mnt
% cd /mnt
% url=http://uec-images.ubuntu.com/releases/10.10/release/ubuntu-10.10-server-uec-i386.tar.gz
% tarball=${url##*/}
% wget ${url} -O ${tarball}
% tar -Sxvzf ${tarball}
maverick-server-uec-i386.img
maverick-server-uec-i386-vmlinuz-virtual
maverick-server-uec-i386-loader
maverick-server-uec-i386-floppy
README.files
% img=maverick-server-uec-i386.img
% mkdir src target

create target filesystem, mount the attached volume, and copy source filesystem contents to target filesystem using rsync.


% sudo mount -o loop,ro ${img} /mnt/src
% sudo mkfs.ext4 -L uec-rootfs /dev/sdh
% sudo mount /dev/sdh /mnt/target
# the rsync could take quite a while.  for me it took 22 seconds.
% sudo rsync -aXHAS /mnt/src/ /mnt/target
% sudo umount /mnt/target
% sudo umount /mnt/src

Now, back on the laptop, snapshot the volume.


$ ec2-create-snapshot ${vol}
$ snap=snap-b97dfdd3
# now you have to wait for snapshot to be 'completed'
$ ec2-describe-snapshots ${snap}
SNAPSHOT  snap-b97dfdd3  vol-c64d55af   completed   2010-11-03T17:31:52+0000   100%  950047163771   10

Turn the contents of that volume into an AMI. Note, you must set 'arch', 'rel', and 'region' correctly. Then, we use that information to get the aki associated with the most recent released Ubuntu image.


$ rel=maverick; region=us-east-1; arch=i386; # arch=amd64
$ [ $arch = amd64 ] && xarch=x86_64 || xarch=${arch}
$ qurl=http://uec-images.ubuntu.com/query/${rel}/server/released.current.txt
$ aki=$(curl --silent "${qurl}" |
awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' \
arch=$arch region=$region )
$ echo ${aki}
aki-407d9529
$ ec2-register --snapshot ${snap} \
--architecture=${xarch} --kernel=${aki} \
--name "my-ubuntu-${rel}" --description "my-ubuntu-${rel}"
IMAGE ami-4483742d
$ ami=ami-4483742d

Clean up your instance and volume


$ ec2-detach-volume ${vol}
$ ec2-terminate-instances ${iid}
$ ec2-delete-volume ${vol}

And now run your instance


$ ec2-run-instances --instance-type t1.micro ${ami}
$ ssh ubuntu@
% sudo apt-get update && sudo apt-get dist-upgrade
# if you got a new kernel (linux-virtual package), then you will
# need to reboot
% sudo reboot

Now, your newly created image has filesystem contents that are identical to those of the official Ubuntu images, but with a 10G filesystem.

Once you've launched your image, you can actually clean up the snapshot and the AMI id that you launched. To do that:


ec2-deregister ${ami}
ec2-delete-snapshot ${snap}

The cost of the above operations will probably be on the order of pennies, and will remove the costs you would have incurred due to having 15G root volume.

create image with XFS root filesystem from UEC Images

2010-11-03T11:58:00.000-07:00

A post was made to the ec2ubuntu google group asking if Ubuntu had any plans to create images XFS root filesystems.

The Official Ubuntu Images for 10.04 LTS (lucid) and prior have an ext3 root filesystem. For Ubuntu 10.10 (maverick) and the development builds of 11.04, the filesystem is ext4.

The selection of ext3 or ext4 is because ext4 is the filesystem selected by default on an Ubuntu install from CD or DVD. This selection is carried over to our Ubuntu images for UEC or EC2. The 10.04 images really should have been ext4, but the change didn't get in for that release.

Ubuntu fully supports the XFS filesystem, it simply wasn't chosen as the default. The -virtual kernel has filesystem support available as a module, and the xfsprogs package is in the main archive.

So, just as you can get full support for the Ubuntu images using ext4, you can get full support from Ubuntu (and paid support from Canonical) by using xfs as your root filesystem. You will simply have to create your own images.

Luckily, due primarily due to the fact that the Ubuntu images are downloadable at http://uec-images.ubuntu.com, the process for creating a XFS based ebs image is trivial.

In the code (shell prompt) snippits below, '$' prompt indicates command run on my laptop. '%' prompt indicates command run on the ec2 instance. lines beginning with a '#' are comments.

Launch an instance to work with:


# us-east-1 ami-688c7801 canonical ubuntu-maverick-10.10-amd64-server-20101007.1
$ ec2-run-instances --region us-east-1 --instance-type m1.large \
--key mykey ami-688c7801
$ iid=i-bcc679d1
$ zone=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $12 }' iid=${iid} )
$ echo ${zone}
us-east-1d
$ host=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $4 }' iid=${iid} )
$ echo ${host}
ec2-174-129-61-12.compute-1.amazonaws.com

create a volume in correct zone of the desired size to attach to the instance.


$ ec2-create-volume --size 10 --availability-zone ${zone}
$ vol=vol-c64d55af
$ ec2-attach-volume --instance ${iid} --device /dev/sdh ${vol}

Then, ssh to ubuntu@${host}, and download the uec reference image, extract, and get necessary packages:


% sudo chown ubuntu:ubuntu /mnt
% cd /mnt
% url=http://uec-images.ubuntu.com/releases/10.10/release/ubuntu-10.10-server-uec-i386.tar.gz
% tarball=${url##*/}
% wget ${url} -O ${tarball}
% tar -Sxvzf ${tarball}
maverick-server-uec-i386.img
maverick-server-uec-i386-vmlinuz-virtual
maverick-server-uec-i386-loader
maverick-server-uec-i386-floppy
README.files
% img=maverick-server-uec-i386.img
% mkdir src target
% sudo apt-get install xfsprogs

create target filesystem, mount the attached volume, and copy source filesystem contents to target filesystem using rsync.


% sudo mount -o loop,ro ${img} /mnt/src
% sudo mkfs.xfs -L uec-rootfs /dev/sdh
% sudo mount /dev/sdh /mnt/target
% sudo rsync -aXHAS /mnt/src/ /mnt/target
% sudo umount /mnt/target
% sudo umount /mnt/src

Above, you could have mounted /proc and /sys into /mnt/target, chrooted into it and done a dist-upgrade. I left that out for simplicity.

Now, back on the laptop, snapshot the volume.


$ ec2-create-snapshot ${vol}
$ snap=snap-b97dfdd3
# now you have to wait for snapshot to be 'completed'
$ ec2-describe-snapshots ${snap}
SNAPSHOT  snap-b97dfdd3  vol-c64d55af   completed   2010-11-03T17:31:52+0000   100%  950047163771   10


$ rel=maverick; region=us-east-1; arch=i386; # arch=amd64
$ [ $arch = amd64 ] && xarch=x86_64 || xarch=${arch}
$ [ $arch = amd64 ] && blkdev=/dev/sdb || blkdev=/dev/sda2
$ qurl=http://uec-images.ubuntu.com/query/${rel}/server/released.current.txt
$ aki=$(curl --silent "${qurl}" |
awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' \
arch=$arch region=$region )
$ echo ${aki}
aki-407d9529
$ ec2-register --snapshot ${snap} \
--architecture=${xarch} --kernel=${aki} \
--block-device-mapping ${blkdev}=ephemeral0 \
--name "my-${rel}-xfs-root" --description "my-${rel}-xfs-description"
IMAGE ami-4483742d
$ ami=ami-4483742d

Clean up your instance and volume


$ ec2-detach-volume ${vol}
$ ec2-terminate-instances ${iid}
$ ec2-delete-volume ${vol}

And now run your instance


$ ec2-run-instances --instance-type t1.micro ${ami}

ssh to your instance, verify that it is in fact xfs:


% grep uec-rootfs /proc/mounts 
/dev/disk/by-label/uec-rootfs / xfs rw,relatime,attr2,nobarrier,noquota 0 0

Now, your newly created image has filesystem contents that are identical to those of the official Ubuntu images.

Some notes on the above:

Many people believe that transition to btrfs as the default filesytem is inevitable, possibly even for the 12.04 LTS release. Doing this on EC2 would require that amazon release btrfs support in a pv-grub kernel.
Outside of creating a 'xfs' filesystem, the steps above are very generic "create a custom EBS root image" instructions. In fact, the process outlined above is used for the actual publishing of ebs images via the ec2-publishing-scripts (see ec2-image2ebs)
The process above will work using the maverick based images. Lucid images are not likely to work out of the box because they do not boot with a ramdisk. Where maverick images use pv-grub to load the kernel and ramdisk from inside the image, Lucid kernels are loaded by xen directly and Canonical did not publish ramdisks for the lucid release.

UDS-N Call for participation

2010-10-22T09:17:00.000-07:00

The Ubuntu Developer Summit (UDS) is the event in which the Ubuntu community discusses and plans the upcoming Ubuntu release. UDS Natty begins Monday, October 25th (this monday) outside of Orlando, FL, USA. If you're in the Orlando area, this event is free, and open to anyone.

If you've not yet made plans to attend physically, then its unlikely that you'll be present in the rooms. However, the Canonical IS does an outstanding job of making remote participation possible. For more information, on how you can participate remotely, read the Remote Participation document. In short, you join an IRC channel, listen to a live high quality audio stream from the room, and can see edits to a live gobby document.

The comprehensive list of all sessions is available through the summit schedule, or a filtered list of only the 'Cloud track'.

Some of the sessions that I personally am interested (ok, interested *and* leading) in are:

cloud-server-n-cloud-images: Here we'll discuss how we can make the Ubuntu Images on EC2 or UEC better. If you've used them, then we're interested in your feedback.
cloud-server-n-image-rebundle: Here we'll discuss possible improvements in the rebundling process. Ie, how can you take one of the Ubuntu images, and customize it and turn it into your own AMI. This is a common operation, and unfortunately, one that has some sticking points. If you have other ideas for "cloud utilities" this is the place to bring them up.
cloud-server-n-desktop-images: Ubuntu has made desktop images available on ec2 in a "tech preview" like manner for 2 releases. We've not fully supported these images, but a version of the cloud images with a remote-desktop interface is a common request. If you want to see what it might look like, try out the free Edubuntu demo using NX
cloud-server-n-cloud-init: Here we'll discuss improvements to cloud-init or cloud-config. If you've customized images via user-data, then you've used cloud-init. How can we make it better ?
cloud-server-n-ubuntu-trial: We threw together awstrial fairly quickly, and with the 10.10 release, we allowed anyone interested to Try Ubuntu Free. We got a great response and we see lots of ways this can be used. Come and let us know what you think

There are loads of other interesting sessions. If 'Server' or 'Cloud' isn't your thing, there are other tracks that might peek your interest.

How to rebundle Ubuntu 10.10 (Maverick Meerkat) EBS root

2010-10-22T07:48:00.000-07:00

There was a post on the ec2ubuntu list regarding a problem the poster had with re-bundling a Ubuntu 10.10 instance. The poster followed another blog entry. I responded to the post, but figured that a blog entry might reach a larger audience.

The simple summary of my long winded post is this:

To rebundle an EBS root image, use ec2-create-image.

If you've launched one of the Official Ubuntu 10.10 Images and modified it a bit, the best way to create a new AMI with the modifications in it is to:

1.) stop the instance (do not terminate it)
2.) "create-image"
3.) wait for your new AMI to become available and run your new instance

Note, that all of the above steps can be done from the EC2 console as well as by using the command line tools. I don't think I previously realised how nice this api call is.

The reason that the title of this post includes 'Ubuntu 10.10' rather than just "Ubuntu", is that releases of 10.04 and earlier do not utilize pv-grub. If you're re-bundling one of those images, you have to take additional steps to get a new kernel upgrade. You really should take those steps, as kernel upgrades include important security fixes, and newly created AMIs should always be created with the most recent kernel available.

Try out Ubuntu Server 10.10 on EC2 for FREE!

2010-10-08T13:30:00.000-07:00

I'm mostly disappointed that it wasn't my idea. Dustin deserves all the credit. The implementation (awstrial) was a fairly straightforward programming exercise. I don't mean at all to discount the work of the others who contributed to the awstrial project, and I had a blast in my first django experience, but the idea was the brilliance.

What idea ? The idea to allow anyone to try out Ubuntu 10.10 on EC2 for free for 55 minutes. No hardware is needed. While you're waiting for your desktop or server ISO to download, you can give a test drive to the server. You'll have 170Gb disk, 2G memory, and a very high speed internet connection with local LAN access to Ubuntu mirrors.

You do not need an AWS account or a credit card.

Here is how it works:

Sometime on Sunday, October 10, 2010 Ubuntu 10.10 (Maverick Meerkat) will be released.
At that point, and a limited time following, you'll be able to go to 10.cloud.ubuntu.com and launch an instance.
wait 3 minutes or less
ssh to the instance
do something
55 minutes after launch, your instance will be terminated

In order to take part in this, you'll need to have a launchpad.net or Ubuntu Single Singon account. If you don't have one, then create one. If you're reading this, you probably have ssh keys in a file called ~/.ssh/id_rsa.pub, so go to https://launchpad.net/~YOUR_LOGIN/+editsshkeys and paste those keys in.

Now, back to the 'do something' item above. What should you do?

Heres some suggestions, but I'm certain that you're more creative than I am.

Check if a bug you opened (or were annoyed by) in 10.04 LTS is still present. If it was fixed, then make sure the bug in launchpad is marked 'Fix Released'.
Take Postgres 9.0for a spin, thanks to Martin Pitt's PPA builds
run 'rm -Rf /' just to see what happens.
Find something that is broken. Open a bug, using 'ubuntu-bug'.
Hack on awstrial

Whatever you do, I hope you enjoy taking the "Official Ubuntu Image" for a spin. Do something cool, blog about it, tell people how easy it was.

Using Policies in AWS Identity and Access Management

2010-09-27T07:51:00.000-07:00

For a project I'm working on here at work, I wanted to create a AWS user that could only launch instances, but could not write to S3, query SDB

{
 "Statement":[ {
    "Effect":"Allow",
    "Action":["ec2:RunInstances","ec2:RebootInstances",
              "ec2:GetConsoleOutput", "ec2:DescribeInstances" ],
    "Resource":"*"
  }, {
    "Effect":"Allow",
    "Action":["ec2:StopInstances","ec2:StartInstances",
              "ec2:TerminateInstances"],
    "Resource":"*"
  }, {
    "Effect":"Allow",
    "Action":["ec2:DescribeImages"],
    "Resource":"*"
  }, {
    "Effect":"Deny",
    "NotAction":["ec2:*"],
    "Resource":"*"
  } ]
}

I had hoped that I could allow this user to create his own security groups and keypairs (for launching instances with 'ec2-run-instances --key', and that I could also allow him to modify or delete those items as well. Unfortunately, I was not able to figure out how to do this. What I had hoped I could do was something like was something like:

{
  "Effect":"Allow",
  "Action":["ec2:*SecurityGroup*"],
  "Condition" :  {
     "StringLike": {
        "ec2:groupName":"foouser*"
     }
  },
  "Resource":"*"
},
{
  "Effect":"Allow",
  "Action":["ec2:*KeyPair*"],
  "Condition" :  {
     "StringLike": {
        "ec2:keyName":"foouser*"
     }
  },
  "Resource":"*"
}

The 'keyName' is an atribute of the [Add,Delete,Describe]KeyPair API calls, and 'groupName' is an attribute of the [Add,Delete]SecurityGroups and AuthorizeSecurityGroupIngress API calls as described in the EC2 API

My goal was to limit the user ('foouser') to manipulating SecurityGroups or KeyPairs that begain with 'foouser'. This would be a clear indication to other users of the account when they came across them.

However, the 'Condition' syntax isn't as "open" as that (couldn't think of a better term for than 'open'). I can think of reasons as to why it would be difficult or undesireable to make Conditions function like I wanted, but it would have been nice.

The IAM EC2 documentation indicates that EC2 only supports the following Condition types: aws:CurrentTime aws:EpochTime aws:SecureTransport aws:SourceIp and aws:UserAgent.

It seems to me that SecurityGroups and keypairs are an essential piece of Using EC2, but it seems like these are stuck at the account level, with no ability to limit them at the user level.

Another thing that I would like to do is give the user the ability to launch / stop / start / terminate her own instances, but not other users of the account. If I truly try to use IAM to split up my account usage, say with 'Development' and 'Production' users or groups, this is essential. When I use the 'Development' user I want to be protected from an accidental reboot or terminate of a 'Production' instance.

For example, I test our Official Ubuntu images. The testing scripts launch several instances. While they're running, I'll often be doing development, and also have an instance running. I would like my 'development' work to not accidentally terminate (or otherwise affect) my test runs. As it is right now, a 'euca-describe-instances' will show me all instances in either account, just waiting for me to copy and paste wrong and terminate one.

It is quite possible that I've missed something, if so, please let me know.

Playing with AWS Access Identity Management

2010-09-22T10:54:00.000-07:00

Today I finally found some time to play with AWS Identity and Access Management. If you hadn't seen the announcement, or aren't familiar, the IAM tools basically allow you to create, manage, and limit multiple AWS accounts under a single account.

There are 2 reasons that immediately spring to mind for when you should use this:

If you're sharing an single AWS account between multiple people, then using this is almost required.
you want to use some AWS facility from inside an EC2 instance. Here, it just seems scary to put the entire keys to your account onto a remote machine.

To get started, I walked through the Getting Started guide. I downloaded the IAM Tools, and set them up as described. On Ubuntu, that consisted of:

$ wget http://awsiammedia.s3.amazonaws.com/public/tools/cli/latest/IAMCli.zip $ unzip IAMCli.zip $ vi my-account-creds.txt $ cat my-account-creds.txt AWSAccessKeyId=ABCDEFGHIJKLMNOPQRST AWSSecretKey=zyxwvutsrqponmlkjihgfedcbazyxwvutsrqponm $ export AWS_CREDENTIAL_FILE=my-account-creds.txt $ export AWS_IAM_HOME=$PWD/IAMCli $ export PATH=$AWS_IAM_HOME:$PATH JAVA_HOME=/usr

Then, I created a user and admin group as described in the guide:


$ iam-groupcreate -g admins
$ cat AdminGroupPolicy.txt
{
   "Statement":[{
      "Effect":"Allow",
      "Action":"*",
      "Resource":"*"
      }
   ]
}


$ iam-groupuploadpolicy -g admins -p AdminGroupPolicy -f AdminGroupPolicy.txt
$ iam-usercreate -u smoser -g Admins -k -v
TSRQPONMLKJIHGFEDCBA
mnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
arn:aws:iam::950047163771:user/smoser
AHDAIABBGZ3Q31XMUE4AN

The first line of the iam-createuser output is the AWSAccessKeyId, and the second is the AWSSecretKey. I quickly added those to a file my-user-creds.txt as shown above, and set AWS_CREDENTIAL_FILE=my-user-creds.txt .

That's all it took. Now I have a set of credentials that I can use, and if they're lost or stolen, I can revoke them with the (now safely locked up) account credentials.

At this point, I could use the euca2ools with a config file like:


$ cat my-user-eucarc
AWSAccessKeyId=ABCDEFGHIJKLMNOPQRST
AWSSecretKey=mnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
EC2_SECRET_KEY=${AWSSecretKey}
EC2_ACCESS_KEY=${AWSAccessKeyId}
EC2_USER_ID=950047163771
EC2_URL=https://ec2.amazonaws.com
S3_URL=https://s3.amazonaws.com:443
EC2_CERT=/etc/ec2/cert-ec2.pem
$ euca-describe-instances --config my-user-eucarc

Additionally, the above will also suffice as an AWS_CREDENTIAL_FILE for the iam-tools.

Thats great, but for one reason or another, I end up using the ec2-api-tools for a large amount of my work. Those tools require a private key and certificate. So, I had to go about creating one for my new user. Thanks to Nate@AWS in an EC2 Forum Post, that was easy also.


$ openssl version
OpenSSL 0.9.8o 01 Jun 2010
$ openssl genrsa 1024 > pk.pem
$ openssl req -new -x509 -nodes -sha1 -days 730 -key pk.pem -out cert.pem
# follow prompts here
$ iam-useraddcert -u smoser -f cert.pem
$ export EC2_PRIVATE_KEY=$PWD/pk.pem EC2_CERT=$PWD/cert.pem
$ ec2-describe-instances ...

Now my ec2-api-tools are functional. I have to admit to not completely understanding the implications of self signing a certificate here and uploading it. However, as I was authenticated to do the upload (via https and the given credentials) and only my user will use that signing key, I don't know what harm there could be.

Now I have the following TODOs:

Post about creating an IAM Policy
package the IAM tools for Ubuntu multiverse

Updates:

2010-10-12: update case in AWS_IAM_HOME string ('IamCli' -> 'IAMCli')

running Ubuntu on an Amazon "micro" instance

2010-09-09T13:27:00.000-07:00

Amazon announced today a new instance type. The "micro" instance type (t1.micro) has 613 MB of memory and can be used with AMIs of either x86 or x86_64. The cost for either is only $0.02 per hour.

That means that you can try out Ubuntu on EC2 for 2 measly cents. The official images of Ubuntu 10.04 LTS (Lucid Lynx) are perfect for this. If you're more adventurous and want to try out 10.10, please try out a daily build.

I think this smaller instance size really makes EC2 available to a lot more people. The minimum price for running an instance for a month goes from something like $70 (31 * 24 * 0.095) to less than $15. If you add to that the fact that you can shut down the instance and not be charged for unused CPU time, then start it back up when you need it, it can be really cheap. If you happen to need more CPU power, you can even shut it down, and start it back up with more resources!

So what are you waiting for!


$ MY_LAUNCHPAD_ID="smoser"
$ printf "#cloud-config\n%s\n" "ssh_import_id: [${MY_LAUNCHPAD_ID}]" > user-data.txt
$ ec2-run-instances --region us-east-1 --user-data-file=user-data.txt ami-1234de7b

A few things to note:

Bug 634102 has to be worked around or you will not be able to reboot your instance. There are cloud-init debs available in my personal PPA with fixes. 10.10 won't have the issue, and I'll work on getting the fix backported to 10.04. You can easily fix that by running:
arch=$(uname -m) [ "$arch" = "x86_64" ] && ephd=/dev/sdb || ephd=/dev/sda2 sudo sed -i.dist "\,${ephd},s,^,#," /etc/fstab
One interesting feature of this instance type is that it will run images that are x86 or x86_64 arch. Previously each instance type only ran a single arch.
Above, I launched the instance with cloud-config syntax that will pull in my keys from launchpad rather than using public ssh keys stored in EC2. Thats why I didn't need to pass '--key <mykey>'

edits

I fixed the ami id above, I had listed a instance-store image. Also, a thing to note is that with t1.micro instances you *have* to use EBS images.
I fixed the 'sed' command above, and fixed the price for m1.small (0.095, not 0.95)

Verify SSH Keys on EC2 Instances

2010-07-28T13:22:00.000-07:00

Like every server, every EC2 instance should have a unique ssh fingerprint. On "real servers" this fingerprint is generated at first installation of the openssh-server package. On EC2, instead, it is done on first boot of an instance. This is because each instance is a byte for byte copy of a registered image.

What this means to you, is that when you launch an instance and then connect with ssh, you'll see something like:


$ ssh -F /tmp/smoser/foo ec2-67-202-47-56.compute-1.amazonaws.com
The authenticity of host 'ec2-67-202-47-56.compute-1.amazonaws.com (67.202.47.56)' can't be established.
RSA key fingerprint is f1:40:a7:4e:0f:28:8d:12:21:59:f1:ff:03:5f:63:54.
Are you sure you want to continue connecting (yes/no)?

The ssh client is informing you that you are connecting to a host that you do not have ssh keys stored for. In short, it cannot confirm the identity of 'ec2-67-202-47-56'. There could be a "Man in the Middle" who is attempting to trick you. Just as with "real servers", you should identify that remote system via an out of band method. To do this outside of EC2, you might call a hosting provider up and ask them to verify the fingerprint that you see. On EC2, the only out of band transport is the ec2 console.

In order to provide you with the fingerprint that you need, the ssh fingerprint is written to the console when it is booted. You can see this with ec2-get-console-output.

As seen with the results of Eric's poll on alestic.com, this is a very little known or used piece of information. Over 50% of alestic.com voters have "never verified the fingerprint".


$ euca-get-console-output i-72bf1518 | grep ^ec2:
ec2: 
ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 f1:40:a7:4e:0f:28:8d:12:21:59:f1:ff:03:5f:63:54 /etc/ssh/ssh_host_rsa_key.pub (RSA)
ec2: 1024 28:f3:ef:a6:86:05:50:33:76:16:24:32:56:14:06:13 /etc/ssh/ssh_host_dsa_key.pub (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################

Note that the ssh fingerprint reported on the console matches the one that ssh client asked me to confirm above. So, I now know that the host I've connected to is the one that I just started.

Putting this all together, lets say you have booted a new EC2 instance, with instance-id i-72bf1518 and hostname ec2-67-202-47-56.compute-1.amazonaws.com.

First we will use ssh-keyscan to get the fingerprint that is being reported by the remote host, and store that in a shell variable 'fp'


$ iid=i-72bf1518
$ ihost=ec2-67-202-47-56.compute-1.amazonaws.com

$ ssh-keyscan ${ihost} 2>/dev/null > ${iid}.keys
$ ssh-keygen -lf ${iid}.keys > ${iid}.fprint
$ read length fp hostname id < ${iid}.fprint
$ echo $fp
f1:40:a7:4e:0f:28:8d:12:21:59:f1:ff:03:5f:63:54

This fingerprint should also appear on the console output of the instance. If it doesn't, then something is wrong. So, we'll get the console output, and grep through it looking for the fingerprint:


$ euca-get-console-output ${iid} > ${iid}.console
$ grep "ec2: ${length} ${fp}" ${iid}.console
ec2: 2048 f1:40:a7:4e:0f:28:8d:12:21:59:f1:ff:03:5f:63:54 /etc/ssh/ssh_host_rsa_key.pub (RSA)

We've now verified that the host we're connecting to is the host we just launched, so we can connect safely. Now you can clean out any old occurences of that host in known_hosts and tell the ssh client that this is a "known_host"


# remove existing entries in ~/.ssh/known_hosts for this host
$ ssh-keygen -R "${ihost}"

# hash the output of the known hosts file.  This prevents someone
# from reading known_hosts as simple list of remote hosts you have
# access to in the event that one of your keys was compromised.

$ ssh-keygen -H -f ${iid}.keys

# Add the key to your known_hosts
$ cat ${iid}.keys >> ~/.ssh/known_hosts

# remove the temporary files we created
$ shred -u "${iid}."*

There, we've now verified that the remote host is the instance we started and told the ssh client about it.

Unfortunately, console output on ec2 is only updated approximately every 4 minutes. So, you can't run through this process until you have console output to check.

Updates

[2010-09-22]: fix mismatched use of 'iid' and 'ihost'

Easily test or demo Ubuntu Enterprise Cloud (UEC) in EC2 instance

2010-05-20T06:18:00.000-07:00

Consider the following items:

recent efforts by Robert Collins, Dustin Kirkland and others have enabled running all components of UEC on a single system.
while performance suffers greatly, Eucalyptus can easily be made to use qemu rather than kvm for virtualization without hardware virtualization extensions
Ubuntu server images are quickly launchable on EC2

Now, re-read those, but do so while thinking about wanting to provide people with an easy way to test UEC.

Thats right, if you have $0.40 per hour, and an EC2 account, you can play with UEC. No real hardware required.

This nested virtualization is obviously not going to provide you with the worlds fastest performing cloud, but it will provide a functional system for test or demo purposes.

I've put some copy-and-paste shell code in commands.txt in a bzr branch uec-on-ec2.

check out the bzr branch: lp:~smoser/+junk/uec-on-ec2
bzr branch lp:~smoser/+junk/uec-on-ec2
follow 'commands.txt', copy and pasting its content bit by bit in a root shell (run 'sudo -s').
Publish and run an instance (do this as 'ubuntu' user):
$ uec-publish-tarball fastboot-amd64-0.11.tar.gz fastboot-amd64-0.11 amd64 # the above creates an emi, see its output $ ( umask 066 ; euca-add-keypair mykey > mykey.pem ) $ euca-run-instances --addressing private --key mykey emi-4D6C12BF # soon this will enter 'running' state and have an IP address associated with it. $ ssh -i mykey ubuntu@${IPADDR}

Your instance should now be functional.

There are a couple things that could be cleaned up on this, patches are very welcome:
* ideally all of the setup could be done from a '#!' user data script, I've just not worked out all the timing yet.
* separate the node out, allowing for multiple nodes
* fix the requirement of private addressing for functional nodes
* fix the issue with the NC being eventually discovered 3 times (with each of its 3 IP addresses)

That said, you should be able to test this and try out UEC on EC2 in a m1.large for less than $0.40 per hour.

UDS Maverick: Call for Participation

2010-05-09T09:10:00.000-07:00

The Ubuntu Developer Summit (UDS) is the event in which the Ubuntu community discusses and plans the upcoming Ubuntu release. UDS Maverick begins Monday, May 10 (tomorrow) in Brussels.

If you've not yet made plans to attend physically, then its unlikely that you'll be present in the rooms. However, the Canonical IS does an outstanding job of making remote participation possible. For more information, on how you can participate remotely, read the Remote Participation document. In short, you join an IRC channel, listen to a live high quality audio stream from the room, and can see edits to a live gobby document.

The comprehensive list of all sessions is available through the summit schedule, or a filtered list of only the Ubuntu Server sessions.

Below is short, self centered, list that you might find interesting. The Ubuntu Community would love to have your participation.

Running cloud images outside UEC or EC2 (Tuesday 11:00 UTC+1): The UEC images that we produce to run in EC2 or UEC are ready-to-go filesystem image of Ubuntu Server. It seems that these images might also serve a more general purpose as a live demo of ubuntu server, or a very convenient starting point for customizing your own. Here we'll discuss other ways these images could be used, and what would need to be done to make that possible.
Improvements for cloud-init (Tuesday, 09:00 UTC+1) : This session will cover ways in which the cloud images can be made more user friendly. If you've ever booted one of the Ubuntu images, or re-bundled one, I'd like to know what we could do to the images to make that easier.
Handling kernel upgrades in EC2 and UEC (Wednesday 11:00 UTC+1): When a user starts a UEC/EC2 instance, they specify they have the option of specifying the kernel/ramdisk to use with it or use the default associated with the instance. Afterwards, the instance has no ability to modify that initial selection. We'll discuss ways that we could improve the user experience by making that limitation more clear, or possibly providing ways to overcome it.
Improve cloud libraries in ubunt (Thursday, 10:00 UTC+1): Throughout the 10.04 release, we packaged some popular libraries for interaction with AWS. We'd like to continue that work in Maverick. If you have suggestions on libraries you use that are not present in Ubuntu, please let us know
Utilties for easier interaction with UEC or EC2 (Tuesday, 10:00 UTC+1): If you have ideas on utilities that would make your life using Ubuntu on EC2 or UEC easier, please attend this session and let us know.
server-maverick-conffiles-and-puppetThis should be an interesting session discussing how Ubuntu can improve the management of conffiles. Soren Hansen has sent an email with more information
Discussion on plans for vmbuilder (17:10 UTC+1): Many people have used vmbuilder to build virtual machine images. In this session we'll discuss where vmbuilder is and where it is going.

If you have input for any session, but are not able to attend in real time, feel free to send me input at smoser at sign ubuntu dot com, and I'll try to make sure it gets brought up.

Oh, and if you're reading this on Sunday, May 9, don't forget Mother's Day.

Update 2010-05-10: Added times for sessions and used the titles rather than blueprint names so you can find them on the schedule

Ubuntu 10.04 LTS - Lucid Lynx available in all EC2 Regions

2010-05-05T13:00:00.000-07:00

I'm a bit late to the party. Ubuntu 10.04 LTS (Lucid Lynx) was released almost a week ago at this point. Multitudes of others have blogged, reviewed, used, etcetera.

That said, I wanted to announce it here, and point out a few things. To get a list of AMI ids for Ubuntu 10.04 LTS Server, look at either:

http://uec-images.ubuntu.com/releases/10.04/release/ and release-20100427.1. These pages are the official source, they are managed by the "promote" scripts. The 'release' directory will point to the latest release version, while the link containing the serial number will be static.
Amazon AMI pages for 10.04 i386 and amd64 builds

Now, some miscellaneous items I wanted to mention:

10.04 LTS was released on EC2 in all 4 regions (us-east-1, us-west-1, eu-west-1, and the new ap-southeast-1) at the same time as all other Ubuntu releases. The 10.04 LTS images were available on the ap-southeast-1 region less than 24 hours after it was officially announced.
The published EC2 images do not have a ramdisk associated with them. This is by design. The kernel has enough smarts built in to find the root filesystem and boot the system. The end result is that we only have to update and manage 2 pieces instead of 3, and the instances should boot faster.
In addition to 10.04 images, we also populated the ap-southeast-1 region with the latest released versions of 8.04 and 9.10 images.

Upgrading an EBS Instance

2010-04-22T07:43:00.000-07:00

Update 20110323: If you are reading this article, you almost certainly should be reading my Migrating to pv-grub kernels for kernel upgrades. The process described here will still work for 10.04 images, but the process described there is ultimately much easier. If you are using 10.10, or 11.04 images, you do not need to do anything, simply 'apt-get update && apt-get dist-upgrade && reboot' to get a new kernel.

For the majority of the existence of EC2 there was no way to change the kernel that an instance was using. With the addition of EBS instances, that changed. I wanted to explain how you can take advantage of that EBS feature by upgrading a Ubuntu 10.04 LTS (Lucid Lynx) instance launched from a Beta-2 AMI to the Release Candidate. This same basic process should also allow you to upgrade across a release, perhaps from a 9.04 Alestic instance to Ubuntu 10.04 LTS.

In reality, if you're hoping to upgrade you're kernel and EBS instance, its because you already have one running and need to upgrade. But for the sake of this excercise, we'll launch a new instance based on the Beta-2 image in the us-east-1 region and then connect to it.

$ ec2-run-instances --key mykey ami-4be50b22
# wait a bit
$ ec2-describe-instances | awk '-F\t' '$1 == "INSTANCE" { print $4 }'
ec2-184-73-101-171.compute-1.amazonaws.com
$ ssh -i mykey.pem ubuntu@ec2-184-73-101-171.compute-1.amazonaws.com

Now, on the instance we'll go ahead and do the upgrade. Whenever I'm working on ec2, I like to use GNU screen to protect against lost network.

% screen -S upgrade

This is the same basic process as upgrading any Ubuntu system. First update and then upgrade. Here, I've run '--dry-run' to point out that there would be kernel upgrades.

Also, the ec2 images suffer from a bug where grub will be installed and prompt you for some information even though its of no value. Because I know what those prompts will be, I'm go ahead and set them here so you're not interrupted during the dist-upgrade.

% sudo apt-get update
% sudo apt-get dist-upgrade --dry-run | grep "linux.*ec2"
  libparted0debian1 linux-image-2.6.32-21-virtual linux-image-2.6.32-305-ec2
  libpolkit-gobject-1-0 libpython2.6 libss2 libudev0 linux-ec2 linux-firmware
  linux-image-ec2 linux-image-virtual linux-virtual locales module-init-tools
Inst linux-image-2.6.32-305-ec2 (2.6.32-305.9 Ubuntu:10.04/lucid)
Inst linux-ec2 [2.6.32.304.5] (2.6.32.305.6 Ubuntu:10.04/lucid) []
Inst linux-image-ec2 [2.6.32.304.5] (2.6.32.305.6 Ubuntu:10.04/lucid)
Conf linux-image-2.6.32-305-ec2 (2.6.32-305.9 Ubuntu:10.04/lucid)
Conf linux-image-ec2 (2.6.32.305.6 Ubuntu:10.04/lucid)
Conf linux-ec2 (2.6.32.305.6 Ubuntu:10.04/lucid)

% echo grub-pc grub2/linux_cmdline string | sudo debconf-set-selections
% echo grub-pc grub-pc/install_devices_empty boolean true | sudo debconf-set-selections

% sudo apt-get dist-upgrade
..
94 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 84.1MB of archives.
..

Above, If you were upgrading from a previous release to 10.04, then you would use 'do-release-upgrade' from the 'update-manager-core' package.

At this point we've got 2 kernels installed, the new one and the old one. Unsurprisingly, we're booted into the old one.

% dpkg-query --show | grep "linux.*ec2"
linux-ec2       2.6.32.305.6
linux-image-2.6.32-304-ec2      2.6.32-304.8
linux-image-2.6.32-305-ec2      2.6.32-305.9
linux-image-ec2 2.6.32.305.6
% uname -r
2.6.32-304-ec2

Above, we can see that the 2.6.32-305.9 version of the kernel is the newest one. Its installed locally, but to boot it we have to find the aki of the version that is published by Ubuntu to ec2. The Ubuntu kernels are registered in ec2 such that you can correlate the dpkg version to the registered aki. We're going to query all the images, save that output to a file and then search for results that are owned by the Canonical user, and match our version string and arch.

$ owner=099720109477; # this is the canonical user's id
$ ver=2.6.32-305.9; arch=i386
$ ec2-describe-images --all > /tmp/images.list
$ awk '-F\t' '$4 == o && $3 ~ v && $8 == a { print $2, $3 }' \
   a=${arch} "o=${owner}" "v=${ver}" /tmp/images.list
aki-1f02ec76 099720109477/ubuntu-kernels-milestone/ubuntu-lucid-i386-linux-image-2.6.32-305-ec2-v-2.6.32-305.9-kernel
aki-d324caba 099720109477/ubuntu-kernels-testing/ubuntu-lucid-i386-linux-image-2.6.32-305-ec2-v-2.6.32-305.9-kernel

That shows us that we have 2 kernels available matching that explicit version. One is "testing", and one is "milestone". These are actually the same thing. We label the kernels differently so the user easily knows what is testing and what is "released". The released kernel version will be labeled with 'ubuntu-kernels'. The RC kernel version gets labeled "ubuntu-kernels-milestone".

In order to change the kernel, we have to stop the instance, modify the 'kernel' attribute, and then start it up again.

$ ec2-stop-instances i-23453048
$ ec2-modify-instance-attribute --kernel aki-1f02ec76
kernel   i-23453048  aki-1f02ec76

$ ec2-start-instances i-23453048
# wait a bit
$ ec2-describe-instances | awk '-F\t' '$1 == "INSTANCE" { print $4 }'
ec2-184-73-116-205.compute-1.amazonaws.com

So, in theory, we should have booted into our nice and shiny-new kernel. Lets test that theory:

$ ssh ubuntu@ec2-184-73-116-205.compute-1.amazonaws.com 'uname -r'
2.6.32-305-ec2

There you have it! This process can be applied to upgrading the RC to Release (which likely won't have a kernel change), or, eventually to upgrading your 10.04 LTS instance to a Maverick one.

Introducing cloud-init's cloud-config syntax

2010-03-29T10:33:00.000-07:00

Since this is my first post on a brand new blog, *and* I'm fairly new to the Ubuntu community, I figure I should introduce myself. My name is Scott Moser, I've been a member of the Ubuntu Server team for the past 9 months or so. The majority of my time has been focused on Ubuntu's cloud efforts, both on ec2 and on the Ubuntu Enterprise Cloud (UEC).

Thats enough personal introduction, now on to the content.

The cloud-init package provides "first boot" functionality for the Ubuntu UEC images. It is in charge of taking the generic filesystem image that is booting and customizing it for this particular instance. That includes things like:

setting the hostname
putting the provided ssh public keys into ~ubuntu/.ssh/authorized_keys
running a user provided script or otherwise modifying the image

If you have used the Official Ubuntu Images for Hardy or Karmic, you may be aware that the above functionality was previously provided by ec2-init. The cloud-init is package is largely a "cloud agnostic" replacement for ec2-init. The AWS specific portion of the name didn't fit with UEC at the moment, and seemed limiting for the future. We hope to have it working on other cloud offerings as well.

Setting hostname and configuring a system so the person who launched it can actually log into it are not terribly interesting. The interesting things that can be done with cloud-init are made possible by data provided at launch time called user-data.

ec2-init, cloud-init, and the Alestic images support customization through user-data in one very simple yet effective manner. If the user-data starts with '#!', then it will be stored and executed as root late in the boot process of the instance's first boot (similar to a traditional 'rc.local' script). Output from the script is directed to the console. For example:

$ cat ud.txt
#!/bin/sh
echo ========== Hello World: $(date) ==========
echo "I have been up for $(cut -d\  -f 1 < /proc/uptime) sec"

$ ec2-run-instances ami-a908e7c0 --key mykey.us-east-1 \
   --user-data-file=ud.txt
# wait now for the system to come up and console to be available

$ ec2-get-console-output i-97fc7afc | grep --after-context=1 Hello
========== Hello World: Mon Mar 29 18:05:05 UTC 2010 ==========
I have been up for 28.26 sec

The simple approach shown above gives a great deal of power. The user-data can contain a script in any language where an interpreter already exists in the image (#!/bin/sh, #!/usr/bin/python, #!/usr/bin/perl, #!/usr/bin/awk ... ).

For many cases, the user may not be interested in writing a program. For this case, cloud-init provides "cloud-config", a configuration based approach towards customization. To utilize the cloud-config syntax, the supplied user-data must start with a '#cloud-config'. For example:

$ cat cloud-config.txt
#cloud-config
apt_upgrade: true
apt_sources:
- source: "ppa:smoser/ppa"

packages:
- build-essential
- pastebinit

runcmd:
- echo ======= Hello World =====
- echo "I have been up for $(cut -d\  -f 1 < /proc/uptime) sec"

$ ec2-run-instances ami-a908e7c0 --key mykey.us-east-1 \
   --user-data-file=cloud-config.txt

Now, when the above system is booted, it will have:

added my personal ppa
run an upgrade to get all updates available
installed the 'build-essential' and 'pastebinit' packages
printed a similar message to the script above

The 'runcmd' commands are run at the same point in boot that the '#!' script would run in the previous example. It is present to allow you to get the full power of a scripting language if you need it without abandoning cloud-config.

Note, that in this case the fairly large amount of output to the console from 'apt-get upgrade' ended up scrolling our 'Hello World' message off the ec2-console buffer, so it didn't appear there. That is something that will need to be addressed in lucid+1.

For more information on what kinds of things can be done with cloud-config, see doc/examples in the source.

cloud-init supports a couple other formats of user-data which provide more customization possibilities. I hope to write another blog entry covering those other formats soon.