Somewhere in a land a long time ago, there was this steel factory in the heartland of Pennsylvania.  In this steel factory there was a bulletin board on a factory floor room, and on the board were two large posters.  The first poster was a reminder of the upcoming layoffs on Friday with procedures for filing paper work and such.  The other poster was an announcement of the new IBM mainframe computer that was arriving that week.  This new marvel of modern technology just happened to be arriving on that same Friday.  The IBM poster encouraged employees to gather and witness this historic event, and that they did.  So when Friday rolled around, the poor IBM’rs with their blue suites and dark ties were meet with harsh resentment.  The factory floor workers harassed them unmercifully, and in some cases they were actually spat on.  I take it you see the irony of the poor steel workers assumed correlation between the new computer and the layoffs.  It’s easy to see now that the new “computers” had nothing to do with the layoff… Or is it?

Read the complete post…

We are delighted to welcome Matt Asay to the Canonical fold, taking up the role of Chief Operating Officer with immediate effect. The details can be found in the press release. Matt has also written about the new challenge in his Open Road blog.

So all that remains to say here is how much the whole company is looking forward to working with and learning from Matt in the months and years to come.

Jane Silber

Ryan Dahl's node.js - AMQP integration

The inaugural Opscamp meeting went really well. About two years ago Mark Hinkle and I tried to run a barcamp called BarcampESM. There were only around 20 people at the event. We had a great time. The bottom line was that there really wasn’t as much interest in the topic of “Operations/Systems Administration” in 2007 via a barcamp. Two years later. . . BOOM, it is a “Cloudy” world and 130 people register for a Saturday meetup on the same subject. The idea of changing our small barcamp style idea into a larger more impactful event was due in part to the help of the “CloudCamp”, Dave Nielsen. Dave was instrumental in helping us get this first CloudCamp (opscamp) vertical off the ground.

All told, we wound up with around 95 attendees. Zenoss was our platinum sponsor providing the venue, breakfast, lunch and non-alcoholic drinks. Rackspace and Reductive Labs were the Gold sponsors and Spiceworks, Opscode, and Bitnami were all Silver sponsors. Opscamp Austin seemed to have a really good mix of vendors and non-vendors enabling the sessions to have a good mix. Some other vendors that were in attendance were DTO Solutions, Groundworks Open Source and Cloudswitch. We were also fortunate to have some of the big guns like IBM and Dell, and let’s not forget our favorite analyst, Michael Cote from Redmonk (also a media Sponsor). Here is a link to the Redmonk “IT Management Guys” podcast we did at the after hours free drinks party.

The conference really started to kick into gear once the un-panel started. Monitoring seemed, as it usually does, to dominate the discussion. However, it set the stage nicely for the rest of the conference. In classic “CloudCamp” style we setup the open session agenda for the rest of the day based out of two themes that evolved from the un-panel, Configuration Management and Monitoring. To make it sound cooler, we called the themes Service Delivery and Service Assurance.

On the service delivery side we talked about how to identify services and workloads. Some of the participants described their process of trying to take workloads and define them into ensembles. We even started a little bit of an “Agile Operations” discussion. Later in the afternoon we had an operations tool chain session that seemed to get a little heated; however, no harm, no foul. This reminds me of a great quote “Strong opinions loosely held.”

Over on the service assurance side, we had some great discussions about monitoring with plenty of experts from Zenoss, Groundwork, and IBM. One of the early sessions focused on a discussion about “agents” for monitoring. This lead into the age old agentless vs. agent based discussion. There was also a fair amount of non-open source enterprise people to contribute from the IBM Tivoli, IBM Micromuse, and BMC Patrol perspectives.

I saw a lot of video cameras and flips floating around, so I am sure there will be a lot of Youtube and Blip.tv videos showing up in the next few weeks. Opscamp will try to coordinate a summary links page for all the blogs, podcasts, and videos that surface up.

Opscamp Austin was sort of like a “Beta” for future Opscamps. We had a few bugs in the beginning transitioning from the lighting talks to unpanel to open sessions. However, we collected some positive feedback on how to make this a little smother for the next time. I think Opscamp Austin proved that this new CloudCamp vertical called Opscamp is ready for GA. We look forward to seeing you in a city near you.

What really strikes me about RabbitMQ is the activity in their community especially their mailing lists and IRC channels. This was astounding to me as I feel like I am pretty up-to-date on active open source projects but before John’s post I was in the dark about RabbitMQ. Of the ones listed so far it’s really one that I feel like there’s really something substantial there.

A good friend of mine ping'd me by email on Friday, asking me about Allan Leinwand's article on GigaOM entitled Where Are the Network Virtual Appliances? As server virtualization moves into the enterprise and cloud data centers, networking needs to follow with virtual appliances. I'm a long-standing believer in Allan's vision for network virtual appliances. Yep. I've often taken to...

Scott Moser (Canonical) built and released new Ubuntu 8.04.3 LTS Hardy images and AMIs for Amazon EC2. I also published new EBS boot AMIs using the same images. I’ve listed all of the AMI ids on http://alestic.com (pick your region at the top).

These AMIs should work better in the us-west-1 region (apt sources.list) and have updated software packages so upgrades on new instances should be faster.

The 8th Southern California Linux Expo (aka SCaLE 8x) is a community organized, non-profit event. Those words and the incredibly cheap price might lead you to believe that it is not worth going to, but if this is your first time you’ll be amazed by the size, scope, and professionalism of the event with nearly a hundred exhibits and dozens of informative talks.

Even though you’re not paying hundreds of dollars for the conference fee, it’s still worth traveling to if you’re not in Los Angeles. If you are in LA, then you have no excuse.

Just like last year at SCaLE, I will be leading another “Try-It Lab” where we’ll help folks get started with using Amazon EC2 and Ubuntu Linux. More information about preparation will be posted on the SCaLE web site, so be sure to review it before attending if you’re interested in a hands-on, guided, workshop experience with EC2. The lab seats “sold out” quickly last year, so make sure you get in early.

Deal for readers of Alestic.com: When you register for SCaLE, use the code “ERIC” for 50% off of the listed price. If you sign up today, that gives you a full access pass for a ridiculously low $35. Prices may go up as the weekend gets closer.

The week of February 8th Opscode will be having some fun in Atlanta.  Josh Timberman @jtimberman, one of the Opscode senior engineers, will be in Atalanta do some work with Chef.  Here are some of the highlights.

Chef “Bootcamp Workshop” Sprint

Ignition Alley, Monday February 8th – 10th (9am to 5pm)

If you are interested in learning more about the Chef open source project feel free to join us in defining and developing the Chef bootcamp training material.

---

Awsome Atlanta Cloud Computing Group

Georgia Tech ATDC , Tuesday February 8th ( 7pm to 9pm)

Configuration Management and Provisioning in the Cloud using Chef

---

Ignition Alley “Lunch and Learn”

Ignition Alley, Monday February 10th (11:39am to 12:30pm)

Configuration Management and Provisioning in te Cloud using Chef

---

Atlanta Ruby User’s Group

Georgia Tech ATDC , Tuesday February 10th ( 7pm to 9pm)

AltRUG

Join us on February 4th for a webinar on the latest features of Landscape.   Ken Drachnik, the Landscape product manager will demo the latest version and review the newest features, including Cloud computing support, configuration management updates, the latest GUI updates and will discuss what new features can be expected from Landscape in 2010.  The webinar is being offered twice on Thursday, at 1500 and 2000 UTC, so that people across the many time zones we service can attend.  To participate, please register

The official Ubuntu AMIs published by Canonical for EC2 starting in October have proven to be solid and production worthy. However, you may still on occasion run into an issue which deserves to be brought to the attention of the Ubuntu server team developing these AMIs and the software which enables Ubuntu integration with EC2.

The easiest, most efficient, and most complete way to report problems with Ubuntu on EC2 is to use the ubuntu-bug tool which comes pre-installed on all Ubuntu systems.

The ubuntu-bug command requires a single argument which is one of:

1. the name of an Ubuntu software package experiencing a problem,

2. the path to a program related to the problem,

3. the process id of the program experiencing the problem, or

4. the path of a crash file.

When reporting EC2 startup issues with an Ubuntu instance, the involved package is generally ec2-init so the command to run would be:

ubuntu-bug ec2-init

This command should be run on the EC2 instance that is experiencing the problem. The ubuntu-bug command will collect relevant information about the instance and file it with the bug report to assist in tracking down and correcting the issue.

If the instance with the problem is no longer running or accessible, try to run another instance of the same AMI to report the bug. This will help submit the correct AMI information with the bug report.

If ubuntu-bug reports “This is not a genuine Ubuntu package” you might have to first run

sudo apt-get update

and then try again.

Unfortunately, ubuntu-bug is an interactive program which does not accept command line options to set choices, so you will need to respond to a couple prompts and then copy and paste a URL it provides to you. First, it asks:

What would you like to do? Your options are:
  S: Send report (1.5 KiB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  C: Cancel
Please choose (S/V/K/C): S

Respond by hitting the “S” key because you really do want to report a problem.

ubuntu-bug then displays a URL and asks if you would like to launch a browser.

Choices:
  1: Launch a browser now
  C: Cancel
Please choose (1/C): C

Respond by hitting the “C” key as ubuntu-bug running on the EC2 instance can’t launch the web browser on your local system and you probably don’t want to use a terminal based browser.

Make a note of the URL displayed in:

*** To continue, you must visit the following URL:
  https://bugs.launchpad.net/ubuntu/+source/ec2-init/+filebug/LONGSTRINGHERE?

Copy the URL and paste it into your web browser. You will continue reporting the problem through your browser and the system information will be attached after you submit.

If this is the first time you have used Launchpad.net, you will be prompted to create an account. Use a valid email address as you will need to confirm it.

Launchpad will prompt you to enter a “Summary” which should be a short description of the bug. If it is not a duplicate of one of the bugs already entered, click “No I need to report a new bug” and enter the “Further Information”. Include as much information as possible relevant to the issue. If a developer can reproduce the bug using this description, then it will be addressed more easily.

For general information on submitting bugs in Ubuntu, please see:

https://help.ubuntu.com/community/ReportingBugs

You can see also see a current list of open ec2-images bugs.

If you are reporting Ubuntu on EC2 bugs directly using Launchpad without ubuntu-bug (not recommended) make sure you include the AMI id and tag the bug with “ec2-images”.

Note that ubuntu-bug is not a mechanism to support general support questions. One place to get help with running Ubuntu on EC2 is from the community in the ec2ubuntu Google group and there’s always the general Amazon EC2 forum. You can occasionally get live help with Ubuntu on EC2 on the #ubuntu-server IRC channel on irc.freenode.net

If you’ve been following along, you probably know that I have been recommending that folks using EC2 switch to the official Ubuntu AMIs published by Canonical (Hardy or Karmic). I have been building and publishing Ubuntu AMIs since 2007 (including Dapper, Edgy, Feisty, Gutsy, Hardy, Intrepid, Karmic), but the last year my focus on this project has been to transition these responsibilities to Canonical who have more time and resources to support the initiative.

I’m happy to say that I’ve finally followed my own advice. For my personal Amazon EC2 servers (including for the Alestic.com web site) I am using Ubuntu 9.10 Karmic images published for EC2 by Canonical.

While I was making the transition, I also switched to EBS boot AMIs. However, since it sounds like Canonical is not planning to publish EBS boot AMIs until Lucid, I decided to continue in service to the community and make available EBS boot AMIs for running Ubuntu on EC2.

I have published EBS boot AMIs for Ubuntu 9.10 Karmic and Ubuntu 8.04 Hardy, both 32- and 64-bit architectures, in all current EC2 regions, for a total of a dozen new AMIs.

I chose to use the exact Ubuntu images which Canonical built for running Ubuntu on EC2. This means that these EBS boot AMIs work exactly the same as the official Canonical AMIs including ssh to the ubuntu user. Again, even though I’m publishing the EBS boot AMIs for Karmic and Hardy, the contents of the image were built by Canonical.

The EBS boot AMIs are listed on Alestic.com. I have restructured the table to better feature Canonical AMIs, and now you need to pick an EC2 region to see the IDs.

Give the EBS boot AMIs a spin and let me know if you run into any issues.

Here are a few little-publicized benefits that were launched with Amazon EC2’s new EBS boot instances: You can lock them from being accidentally terminated; you can prevent termination even when you try to shutdown the server from inside the instance; and you can automatically save your data storage when they are terminated.

In discussions with other EC2 users, I’ve found that it is a common feeling of near panic when you go to terminate an instance and you check very carefully to make sure that you are deleting the right instance instead of an active production system. Slightly less common but even worse is the feeling of dread when you realize you just casually terminated the wrong EC2 instance.

It is always recommended to set up your AWS architecture so that you are able to restart production systems on EC2 easily, as they could, in theory, be lost at any point due to hardware failure or other actions. However, new features released with the EBS boot instances help reduce the risks associated with human error.

The following examples will demonstrate with the EC2 API command line tools ec2-run-instances, ec2-modify-instance-attribute, and ec2-terminate-instances. Since AWS is Amazon’s “web service” all of these features are also available through the API and should be coming available (if they aren’t already) in other tools, packages, and interfaces using the web service API.

1. Shutdown Behavior

First, let’s look at what happens when you run a command like the following in an EC2 instance:

sudo shutdown -h now
# or, equivalently and much easier to type:
sudo halt

Using the legacy S3 based AMIs, either of the above terminates the instance and you lose all local and ephemeral storage (boot disk and /mnt) forever. Hope you remembered to save the important stuff elsewhere!

A shutdown from within an EBS boot instance, by default, will initiate a “stop” instead of a “terminate”. This means that your instance is not in a running state and not getting charged, but the EBS volumes still exist and you can “start” the same instance id again later, losing nothing.

You can explicitly set or change this with the --instance-initiated-shutdown-behavior option in ec2-run-instances. For example:

ec2-run-instances                             \
  --instance-initiated-shutdown-behavior stop \
  [...]

This is the first safety precaution and, as mentioned, should already be built in, though it doesn’t hurt to document your intentions with an explicit option.

2. Delete on Termination

Though EBS volumes created and attached to an instance at instantiation are preserved through a “stop”/”start” cycle, by default they are destroyed and lost when an EC2 instance is terminated. This behavior can be changed with a delete-on-termination boolean value buried in the documentation for the --block-device-mapping option of ec2-run-instances.

Here is an example that says “Don’t delete the root EBS volume when this instance is terminated”:

ec2-run-instances                          \
  --block-device-mapping /dev/sda1=::false \
  [...]

If you are associating other EBS snapshots with the instance at run time, you can also specify that those created EBS volumes should be preserved past the lifetime of the instance:

  --block-device-mapping /dev/sdh=SNAPSHOTID::false

When you use these options, you’ll need to manually clean up the EBS volume(s) if you no longer want to pay for the storage costs after an instance is gone.

Note: EBS volumes attached to an instance after it is already running are, by default, left alone on termination (i.e., not deleted). The default rules are: If the EBS volume is created by the creation of the instance, then the termination of the instance deletes the volumes. If you created the volume explicitly, then you must delete it explicitly.

3. Disable Termination

This is my favorite new safety feature. Years ago, I asked Amazon for the ability to lock an EC2 instance from being accidentally terminated, and with the launch of EBS boot instances, this is now possible. Using ec2-run-instances, the key option is:

ec2-run-instances           \
  --disable-api-termination \
  [...]

Now, if you try to terminate the instance, you will get an error like:

Client.OperationNotPermitted: The instance 'i-XXXXXXXX' may not be terminated.
Modify its 'disableApiTermination' instance attribute and try again.

Yay!

To unlock the instance and allow termination through the API, use a command like:

ec2-modify-instance-attribute     \
  --disable-api-termination false \
  INSTANCEID

Then end it all with:

ec2-terminate-instances INSTANCEID

Oh, wait! did you make sure you unlocked and terminated the right instance?! :)

Note: disableApiTermination is also available when you run S3 based AMIs today, but since the instance can still be terminated from inside (shutdown/halt) I am moving towards EBS based instances for all around security.

Put It Together

Here’s a command line I just used to start up an EC2 instance of an Ubuntu 9.10 Karmic EBS boot AMI which I intend to use as a long-term production server with strong uptime and data safety requirements. I wanted to add all the protection available:

ec2-run-instances                                    \
  --key $keypair                                     \
  --availability-zone $availabilityzone              \
  --user-data-file $startupscript                    \
  --block-device-mapping /dev/sda1=::false           \
  --block-device-mapping /dev/sdh=$snapshotid::false \
  --instance-initiated-shutdown-behavior stop        \
  --disable-api-termination                          \
  $amiid

With regular EBS snapshots of the volumes, copies to off site backups, and documented/automated restart processes, I feel pretty safe.

Runtime Modification

If you have a valuable running EC2 instance, but forgot to specify the above options to protect it when you started it, or you are now ready to turn a test system into a production system, you can still lock things after the fact using the ec2-modify-instance-attribute command (or equivalent API call).

For example:

ec2-modify-instance-attribute --disable-api-termination true INSTANCEID
ec2-modify-instance-attribute --instance-initiated-shutdown-behavior stop INSTANCEID
ec2-modify-instance-attribute --block-device-mapping /dev/sda1=::false INSTANCEID
ec2-modify-instance-attribute --block-device-mapping /dev/sdh=::false INSTANCEID

Notes:

• Only one type of option can be specified with each invocation.

• The --disable-api-termination option has no argument value when used in in ec2-run-instances, but it takes a value of true or false in ec2-modify-instance-attribute.

• You don’t specify the snapshot id when changing the delete-on-terminate state of an attached EBS volume.

• You may change the delete-on-terminate to “true” for an EBS volume you created and attached after the instance was running. By default it will not be deleted since you created it.

• The above --block-device-mapping options currently generate a Server.InternalError for me. I reported it to Amazon.

You can find out the current state of the options using ec2-describe-instance-attribute, which only takes one option at a time:

ec2-describe-instance-attribute --disable-api-termination INSTANCEID
ec2-describe-instance-attribute --instance-initiated-shutdown-behavior INSTANCEID
ec2-describe-instance-attribute --block-device-mapping INSTANCEID

Unfortunately, the block-device-mapping output does not currently show the state of delete-on-termination value, but thanks to Andrew Lusk for pointing out in a comment below that it is available through the API. Here’s a hack which extracts the information from the debug output:

ec2-describe-instance-attribute -v --block-device-mapping INSTANCEID | 
  perl -0777ne 'print "$1\t$2\t$3\n" while 
  m%<deviceName>(.*?)<.*?<volumeId>(.*?)<.*?<deleteOnTermination>(.*?)<%sg'

While we’re on the topic of EC2 safety, I should mention the well known best practice of separating development and production systems by using a different AWS account for each. Amazon lets you create and use as many accounts as you’d like even with the same credit card as long as you use a unique email address for each. Now that you can share EBS snapshots between accounts, this practice is even more useful.

What additional safety precautions do you take with your EC2 instances and data?

In the last article, I described how to use the vmbuilder software to build an EBS boot AMI from scratch for running Ubuntu on EC2 with a persistent root disk.

In the ec2ubuntu Google group, Scott Moser pointed out that users can take advantage of the Ubuntu images for EC2 that Canonical has already built with vmbuilder. This can simplify and speed up the process of building EBS boot AMIs for the rest of us.

Let’s walk through the steps, creating an EBS boot AMI for Ubuntu 9.10 Karmic.

1. Run an instance of the Ubuntu 9.10 Karmic AMI, either 32-bit or 64-bit depending on which architecture AMI you wish to build. Make a note of the resulting instance id:

   # 32-bit
   instanceid=$(ec2-run-instances   \
     --key YOURKEYPAIR              \
     --availability-zone us-east-1a \
     ami-1515f67c |
     egrep ^INSTANCE | cut -f2)
   echo "instanceid=$instanceid"
   
   
   # 64-bit
   instanceid=$(ec2-run-instances   \
     --key YOURKEYPAIR              \
     --availability-zone us-east-1a \
     --instance-type m1.large       \
     ami-ab15f6c2 |
     egrep ^INSTANCE | cut -f2)
   echo "instanceid=$instanceid"
   

   Wait for the instance to move to the “running” state, then note the public hostname:

   while host=$(ec2-describe-instances "$instanceid" | 
     egrep ^INSTANCE | cut -f4) && test -z $host; do echo -n .; sleep 1; done
   echo host=$host
   

   Copy your X.509 certificate and private key to the instance. Use the correct locations for your credential files:

   rsync                            \
     --rsh="ssh -i YOURKEYPAIR.pem" \
     --rsync-path="sudo rsync"      \
     ~/.ec2/{cert,pk}-*.pem         \
     ubuntu@$host:/mnt/
   

   Connect to the instance:

   ssh -i YOURKEYPAIR.pem ubuntu@$host
   

2. Install EC2 API tools from the Ubuntu on EC2 ec2-tools PPA because they are more up to date than the ones in Karmic, letting us register EBS boot AMIs:

   export DEBIAN_FRONTEND=noninteractive
   echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
     sudo tee /etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list &&
   sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873 &&
   sudo apt-get update &&
   sudo -E apt-get dist-upgrade -y &&
   sudo -E apt-get install -y ec2-api-tools
   

3. Set up some parameters:

   codename=karmic
   release=9.10
   tag=server
   if [ $(uname -m) = 'x86_64' ]; then
     arch=x86_64
     arch2=amd64
     ebsopts="--kernel=aki-fd15f694 --ramdisk=ari-c515f6ac"
     ebsopts="$ebsopts --block-device-mapping /dev/sdb=ephemeral0"
   else
     arch=i386
     arch2=i386
     ebsopts="--kernel=aki-5f15f636 --ramdisk=ari-0915f660"
     ebsopts="$ebsopts --block-device-mapping /dev/sda2=ephemeral0"
   fi
   

4. Download and unpack the latest released Ubuntu server image file. This contains the output of vmbuilder as run by Canonical.

   imagesource=http://uec-images.ubuntu.com/releases/$codename/release/unpacked/ubuntu-$release-$tag-uec-$arch2.img.tar.gz
   image=/mnt/$codename-uec-$arch2.img
   imagedir=/mnt/$codename-uec-$arch2
   wget -O- $imagesource |
     sudo tar xzf - -C /mnt
   sudo mkdir -p $imagedir
   sudo mount -o loop $image $imagedir
   

5. [OPTIONAL] At this point /mnt/$image contains a mounted filesystem with the complete Ubuntu image as released by Canonical. You can skip this step if you just want an EBS boot AMI which is an exact copy of the released S3 based Ubuntu AMI from Canonical, or you can make any updates, installations, and customizations you’d like to have in your resulting AMI.

   In this example, we’ll perform similar steps as the previous tutorial and update the software packages to the latest releases from Ubuntu. Remember that the released EC2 image could be months old.

   # Allow network access from chroot environment
   sudo cp /etc/resolv.conf $imagedir/etc/
   # Fix what I consider to be a bug in vmbuilder
   sudo rm -f $imagedir/etc/hostname
   # Add multiverse
   sudo perl -pi -e 's%(universe)$%$1 multiverse%' \
     $imagedir/etc/ec2-init/templates/sources.list.tmpl
   # Add Alestic PPA for runurl package (handy in user-data scripts)
   echo "deb http://ppa.launchpad.net/alestic/ppa/ubuntu karmic main" |
     sudo tee $imagedir/etc/apt/sources.list.d/alestic-ppa.list
   sudo chroot $imagedir \
     apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BE09C571
   # Add ubuntu-on-ec2/ec2-tools PPA for updated ec2-ami-tools
   echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
     sudo tee $imagedir/etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list
   sudo chroot $imagedir \
     apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873
   # Upgrade the system and install packages
   sudo chroot $imagedir mount -t proc none /proc
   sudo chroot $imagedir mount -t devpts none /dev/pts
   cat <<EOF > $imagedir/usr/sbin/policy-rc.d
   #!/bin/sh
   exit 101
   EOF
   chmod 755 $imagedir/usr/sbin/policy-rc.d
   DEBIAN_FRONTEND=noninteractive
   sudo chroot $imagedir apt-get update &&
   sudo -E chroot $imagedir apt-get dist-upgrade -y &&
   sudo -E chroot $imagedir apt-get install -y runurl ec2-ami-tools
   sudo chroot $imagedir umount /proc
   sudo chroot $imagedir umount /dev/pts
   rm -f $imagedir/usr/sbin/policy-rc.d
   

   Again, the above step is completely optional and can be skipped to create the EBS boot AMI that Canonical would have published.

6. Copy the image files to a new EBS volume, snapshot it, and register the snapshot as an EBS boot AMI. Make a note of the resulting AMI id:

   size=15 # root disk in GB
   now=$(date +%Y%m%d-%H%M)
   prefix=ubuntu-$release-$codename-$tag-$arch-$now
   description="Ubuntu $release $codename $tag $arch $now"
   export EC2_CERT=$(echo /mnt/cert-*.pem)
   export EC2_PRIVATE_KEY=$(echo /mnt/pk-*.pem)
   volumeid=$(ec2-create-volume --size $size --availability-zone us-east-1a |
     cut -f2)
   instanceid=$(wget -qO- http://instance-data/latest/meta-data/instance-id)
   ec2-attach-volume --device /dev/sdi --instance "$instanceid" "$volumeid"
   while [ ! -e /dev/sdi ]; do echo -n .; sleep 1; done
   sudo mkfs.ext3 -F /dev/sdi
   ebsimage=$imagedir-ebs
   sudo mkdir $ebsimage
   sudo mount /dev/sdi $ebsimage
   sudo tar -cSf - -C $imagedir . | sudo tar xvf - -C $ebsimage
   sudo umount $ebsimage
   ec2-detach-volume "$volumeid"
   snapshotid=$(ec2-create-snapshot "$volumeid" | cut -f2)
   ec2-delete-volume "$volumeid"
   while ec2-describe-snapshots "$snapshotid" | grep -q pending
     do echo -n .; sleep 1; done
   ec2-register                   \
     --architecture $arch         \
     --name "$prefix"             \
     --description "$description" \
     $ebsopts                     \
     --snapshot "$snapshotid"
   

7. Depending on what you want to keep from the above process, there are various things that you might want to clean up.

   If you no longer want to use an EBS boot AMI:

   ec2-deregister $amiid
   ec2-delete-snapshot $snapshotid
   

   When you’re done with the original instance:

   ec2-terminate-instance $instanceid
   

In this example, I set /mnt to the first ephemeral store on the instance even on EBS boot AMIs. This more closely matches the default on the S3 based AMIs, but means that /mnt will not be persistent across a stop/start of an EBS boot instance. If Canonical starts publishing EBS boot AMIs, they may or may not choose to make the same choice.

Community feedback, bug reports, and enhancements for these instructions are welcomed.

[Update 2009-01-14: Wrapped upgrade/installs inside of /usr/sbin/policy-rc.d setting to avoid starting daemons in chroot environment.]

[Update 2010-01-22: New location for downloadable Ubuntu images.]

This week were very pleased to see three companies behind three great technologies announce their support for Ubuntu. In the run up to the LTS in late April we are keen that our users are aware of the growing number of application options that they can have on their preferred operating system. These will be a mix of open source solutions, the ‘enterprise’ version of open source solutions or  proprietary applications. A healthy and growing ecosystem is an obvious prerequisite for any successful OS.

PGP has extended its enterprise-focused data protection solutions to include Ubuntu in addition to Windows and Mac. For companies running a mixed environment (an increasingly common scenario as Ubuntu begins to find a place in businesses as a replacement technology) security and administrative concerns are reduced as the same tool can used whatever the choice of OS.

GroundWorks Open Source announced its support for Ubuntu Server. GWOS’ excellent systems monitoring and management tools will give users a great, low-cost option for their Ubuntu deployments, something that is very important as Ubuntu Server is pushed into larger and more critical use environments.

Finally LikeWise and the Ubuntu development team were able to confirm the latest version Likewise Open 5.4 has made the alpha of Ubuntu 10.04 where it will undergo rigorous testing for stability before confirmation in the release. Users from 9.10 and 8.04LTS will have a direct upgrade path at release and a version supported for five years when they do.

I hope you take time to consider these options as part of your Ubuntu deployment. Expect to see more of these types of announcements as we broaden support for the 10.04 release. We will also be able to give details soon of some programs for the ISVs themselves to more easily come on board with the LTS release and understand why it is a great addition to their portfolios. We’re looking well set for a great release.

Steve George, Corporate Services at Canonical

January 19th, 2010 – (Austin, TX) – CloudCamp, an organizer of local events to exchange ideas, knowledge and information in a creative and supporting environment, advancing the current state of cloud computing and related technologies, today announced the first OpsCamp for systems management and cloud development professionals. OpsCamp is an event aimed at bringing together IT professionals who are interested in the evolution of systems management and application deployment as it bridges physical and virtual infrastructure and especially cloud computing technologies. The event will be a participant driven unconference style event made popular by events like BarCamp, Bloggercon and Mashup Camp.

Event Details

The event will be held in an unconference format starting with an Unpanel discussion about cloud computing followed by a self-organizing conference format where topics are proposed and then voted on by the attendees.

Saturday, January 30, 2010
8:00 am – 5:00 pm

Spider House Cafe
2908 Fruth St.
Austin, TX 78705

While attendance is free, RSVP is required: http://www.opscamp.org/austin

Event Sponsors

This free event is being made possible by the generous donations from the following sponsors:
• Bitnami - Cloud Deployable Software Stacks
• Reductive Labs - Open Source Data Center Automation
• Zenoss - Unlegacy IT Management Emphasizing Virtualization and Cloud Management

Supporting Quotes

Dave Nielsen, co-Founder CloudCamp

“With rapid change occurring in IT operations, we realized that a place is needed where operations personnel and sysadmins can meet to share their experiences, challenges and solutions. OpsCamp is organized as an unconference which encourages the open exchange of ideas around next generation technologies and strategies for IT Operations. End users, IT professionals and vendors are all encouraged to participate.”

John M. Willis, Author of Cloud Computing and Systems Management Blog, co-hostIT Management Podcast and the Cloud Cafe

“While the cloud has lowered the barrier to entry for businesses to own a data center; it has not decreased the complexity of managing complex applications and data center operations.  OpsCamp is about exploring the opportunity to intersect ideas like agile development, continuous deployment, and data center operations to promote the rise of a new movement that breaks down the traditional walls between development and operations (i.e., DevOps).”

Mark Hinkle, VP of Community, Zenoss

“Operations personnel and sysadmins are becoming programmers because of the virtualization/cloud and automation trend where everything is managed through an API. The line between application developers and IT operations is becoming blurred. Many of the principles that apply to Agile application development translate to operations. So if you are a developer with a interest for system administration, or a systems administrator interested in development, OpsCamp is the place to be.”

Michael Coté, Analyst at Redmonk, co-host IT Management Podcast

“After many years of steady pace in the IT world, the tools and technologies used to do the daily work of operations are rapidly changing. Thanks to virtualization and cloud computing moving mainstream, new, hopefully better ways to deliver IT are emerging. These things aren’t always fully baked yet, but the thought-leaders and early adopters are quickly crystallizing. OpsCamp is an exciting chance to get involved in these conversations whether you want to start directing this shift in operations, figure out if it works for you, or just check it out. And, not only is it free, it’s in a damn fine spot: Austin.”

Luke Kanies, Founder of Puppet and Reductive Labs

“OpsCamp is a great opportunity to share expertise and experience in managing operations in the cloud.  The unconference setting provides a perfect mix between learning and sharing, and the intimate setting guarantees everyone gets something out of it.”

Erica Brescia, CEO, BitRock and Bitnami Project Lead

“In rapidly evolving disciplines such as how to deploy and manage software in the cloud, the one-way dialogue found at typical conferences just doesn’t cut it. OpsCamp will give early adopters and innovators the opportunity to share best practices and guide the development of the next generation of cloud operations tools and services.”

About CloudCamp

CloudCamp is an unconference where early adapters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place we can meet to share our experiences, challenges and solutions. At CloudCamp, you are encouraged you to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate. For more information about future CloudCamp events visit http://www.cloudcamp.org/schedule.

About Zenoss

Zenoss is a leading commercial open source provider of Unlegacy IT enterprise management products. Zenoss Enterprise is a single model-based product that enables organizations to seamlessly manage physical, virtual and cloud based infrastructure with unprecedented power, agility and value. Leveraging a commercial open source model, Zenoss products monitor over one million network and server devices daily and are used in over 25,000 organizations in 180 countries around the world. Commercial customers include leading companies such as Rackspace, VMware, WebMD, LinkedIn, Tyco Electronics, Carlson, Motorola and Deutsche Bank. To learn more about Zenoss’ award-winning IT operations management software, visit http://www.zenoss.com.

About Reductive Labs

Reductive Labs provides a comprehensive set of enterprise-class software, support and services directly from the developers of the Puppet project. With a global team of trained and experienced experts, Reductive Labs can deliver training, consulting, and technical support services to help customers deploy, develop and maintain their infrastructure. Customers get access to features, tools and technical support not otherwise available. For a single annual fee, a Reductive Labs subscription offers a unique combination of support, sophisticated management tools, and reduced total cost of ownership (TCO), making it a must-have for enterprise-level deployments and mission-critical applications. For more information about Puppet and Reductive labs visit ReductiveLabs.com

Bitnami

BitNami.org simplifies the process of deploying web applications natively, virtually and in the cloud. Each BitNami Stack contains an application that is fully integrated with all of the software it requires to run. BitNami Stacks are available free of charge as native installers, virtual machine images and cloud templates, so they can easily be deployed in any environment. Popular BitNami-packaged applications include Drupal, Joomla!, Wordpress, SugarCRM, Alfresco, Redmine, Subversion and many more. For a complete list, visit BitNami.org/Stacks.
For additional information please contact the conference organizers:

John M. Willis – john@opscode.com
Mark Hinkle – mrhinkle@zenoss.com
Damon Edwards – damon@dtosolutions.com

For sponsorship opportunities contact Dave Nielsen:

At Lotusphere today we announced the availability of the IBM Client for Smart Work complete with support from Canonical. It is a significant milestone both for potential end users and for the Canonical and IBM channel.

One of the gating factors to widespread adoption of Linux in the corporate desktop has been the perceived availability of the the required software stack on top of the operating system. While there have been various solutions available, either they have been too much work to assemble or self-support, or the feature set is not complete enough.

ICSW on Ubuntu offers the full set of replacement technologies for a typical Microsoft shop. Calendaring, scheduling, email and office productivity are all delivered via the Lotus product suite. There is access to Lotus Live which brings cloud-based services for those who prefer that route with minimal hardware overheads.

Lotus Live also delivers (deep breath) file sharing, document/content management, instant messaging, presence awareness, web conferencing, VoIP, IP telephony integration, application integration, mashups, blogs, wikis, community, social bookmarks, activities, profiles, portal,  and dashboards/scorecards depending on the level of subscription required. Which is an impressive feature set.

Ubuntu as the operating system also bring freedom from the licensing and upgrading cycle and allow the savings to be spent in more innovative ways. Canonical will support these infrastructures for as little as $5.50 per month for a typical 1000 seat installation. Compare that to the licensing and support for a Microsoft installation.

You can get an unsupported version of ICSW from the Ubuntu site today. IBM partners who would like to adding this product to their portfolio and reselling Ubuntu support should contact us here. Canonical partners can contact their account manager.

Steve George, Canonical

I would love to use this opportunity to inform you of something the “Cloudcamp.org” has setup.  CloudCampHaiti is a virtual unconference we are running this Wednesday afternoon ( http://www.cloudcamp.org/haiti ).  Our primary goal is to raise money for the Red Cross.  One hundred percent of the proceeds will be going to the Haiti earthquake victims.  However, we also have a theme “How The Cloud Can Help” .   We want to see how cloud computing and expert resources can be used to help in disasters like this.  Our registration process is simple, $25 to attend the virtual conference, $50 to be listed as a special donor, and $250 to have your company logo.

Cloudcamphaiti is going to be a great event.  We are going to have some of the biggest names in cloud computing present and we will also have a panel session and open discussion based on the on the “How The Cloud Can Help”  theme.  This is a great opportunity to learn, participate and help.

engineers building NASA's Nebula infrastructure cloud have been working with the team put together by federal CIO Vivek Kundra to build a new species of federal websites, and that in the "near future," Kundra's group will unveil some sort of built-from-scratch federal portal that runs atop Nebula

About CloudCamp Haiti (virtual unconference):

CloudCamp Haiti is a virtual unconference held as a public webinar. CloudCamp-in-the-Cloud builds upon the popular CloudCamp format by providing a free and open place for the introduction and advancement of cloud computing. For this event, we are raising funds to donate to the aid effort in Haiti.

Using an online meeting format attendees can exchange ideas, knowledge and information in a creative and supporting environment, advancing the current state of cloud computing and related technologies.

Please help us spread the word, twitter, facebook, IM, tell your neighbours and friends. Hashtag #CloudCampHaiti or copy and paste this post.

Registration: http://cloudcamp-haiti-2010.eventbrite.com/

Date/Time:
- Jan 20th 11:00am – 2:00pm Eastern Standard Time (EST)

Location:
- Online (GotoMeeting)

Get involved:
If you are interesting in getting involved as a presenter contact John Willis (john.willis AT zabovo.com) If you are interested in sponsoring contact Dave Nielsen (dave AT platformd.com).

Agenda:

11:00am – 11:30am – Sign in and registration (Main Room)
11:30am – 11:45am – Introductions & Overview (Main Room)
11:45am – 12:30pm – Lightning Talks (Main Room)

Lightning Talks – TBD

12:30pm – 1:00pm Unpanel Choosen by attendee’s of CloudCamp Haiti (Main Room)
1:00pm – 2:00pm Break Out Sessions – Round 1

1. Unconference Room #1: main gotomeeting room (TBD)
2. Unconference Room #2: 2nd gotomeeting room (TBD)

2:00pm – 2:30pm CloudCamp Haiti Wrap up (Back in “Main Room”)

Organizers:
- John Willis
- Reuven Cohen
- Dave Nielsen

Interested in sponsoring?

Labels: cloudcamp, Haiti

Graphite - a carbon listener that works with RabbitMQ also:

A friend sent me a URL to Henry Blodget's recent post in the Silicon Alley Insider, with the the cover question... Is this really going to happen? Is Apple about to get steam-rolled?

The premise of the article is that by the end of the 1990s, Apple had came close enough to landing in the Deadpool of Hell that they picked up souvenirs.

What was (Apple's) mistake?

The insistence on selling fully integrated hardware and software devices, instead of focusing on low-cost, widely distributed software.

Yes, Apple also made other mistakes--most notably, maintaining a premium price point, ditching its famous founder and spiritual leader, and developing clunker products. But the mistake that doomed its primary business, the Macintosh, to niche status was the insistence on maintaining complete control over every aspect of the product while Microsoft drove for software ubiquity. ...

It seems much too premature to make this comparison. And, as smart as Henry Blodget is, I'm surprised that this article reduces the competition to a single dimension.

Google will definitely be the big competitor in many markets, but Apple is not 'just insisting on selling integrated hardware and software devices', rather than focusing on low cost distributed software...
What this article does not take into account is how Apple used their high-quality, high-margin integrated products to create service businesses, and particularly content businesses that have (in the same 10 year period) completely changed the added value mobile service market and (.... wait for it ...) the recorded music business... and made a boatload of money in the process.

Google is going to have to capitalize on the Android platform in some very smart ways ... They will get a lot of ISVs and OEMs to use Android, but they have to make serious service and/or content revenues on the result. Maybe it's ebooks... Maybe they become the conduit that truly changes the 20th century model of newspaper and magazine publishing. ... Or perhaps (and I'd believe this) they actually get augmented reality right, and, in combination with their location-based information, turn the Android smart phone into everything from the Yellow Pages to turn-by-turn in car navigation to location based e-commerce. (I have visions of a Craigslist overlaid on everything from virtualized garage sales to real estate.)

I suspect that Apple, in the meantime, will be taking aim on becoming the preeminent conduit for video entertainment content -- television and movies. Apple may also go after 21st century hybrid publishing (... multi-media publishing done right). And, if I had to guess, this is where Apple and Google will go head-to-head.

There's no doubt in my mind that Google can capitalize on Android in a big way. But, Google is just as much at risk of becoming what Microsoft became in the realm of mobile handset platforms. (Remember Windows Mobile? ... Face it. WinMo sux and always has.) MSFT's ability to own a consumer content delivery has not exactly set the world on fire. So, if one follows the analogy, Google runs the risk of creating a platform for its partners that becomes fragmented and therefore becomes a nightmare to support.

(As an aside: Where has Microsoft succeeded? Well, the Xbox gaming platform could very well be described as a fully integrated hardware and software device, supported by a closely integrated networked service.)

Sorry, Henry. Your line of reasoning is too unidimensional, and SO 1990s. Creating a success based on a product platform is about content distribution and service delivery. Retaining the 'appropriate' amount of control and close integration is the challenge for both.

Following up on the action I accepted during last week's server meeting, I searched the web a bit for PHP libraries for EC2 (or AWS in general).

As far as I can tell, a few exist, but only a few of those seem to be maintained regularly:

• PHP-AWS
• The Zend framework which has a AWS extension since version 1.8 and 1.9.6 is available in lucid universe 
• CloudFusion - ex Tarzan (thanks to Darren Govoni for pointing it to me)

As I might be missing some, if you have been using those or other PHP libraries to control EC2, could you please speak up and let us know what library you used and how you liked it?

read more

Truly asynchronous workflows are more difficult. For example, you might want to notify someone when your server is created, or rerender a movie you downloaded so it fits in your ipod. Sadly, the Java Future object has very little to offer for scenarios like these. It doesn't have a hook to chain events. However, jclouds uses an alternate means compliments of google's guava library: ListenableFuture.

Last month, the German magazine T3N published an article that I wrote in English and which my colleague Torsten translated to German. Here is the original text I wrote before translation.

Working with a cloud infrastructure is not yet a common practice in the development community, and it is even less so for a local, on premises, private cloud infrastructure.  Using a cloud infrastructure service requires to understand a few new paradigms.  Having this infrastructure ready to service your developer's needs is not yet understood, but has much goodness to offer.  This article tries to give a few pointers on how to use it and what to expect from it.

read more

Here’s my current recipe for how to build an Ubuntu 9.10 Karmic AMI, either the new EBS boot or the standard S3 based, using the Ubuntu vmbuilder software. The Ubuntu vmbuilder utility replaces ec2ubuntu-build-ami for building EC2 images and it can build images for a number of other virtual machine formats as well.

There is a lot of room for simplification and scripting in the following instructions, but I figured I’d publish what is working now so others can take advantage of the research to date. Happy New Year!

Some sections are marked [For EBS boot AMI] or [For S3 based AMI] and should only be followed when you are building that type of AMI. The rest of the sections apply to either type. It is possible to follow all instructions to build both types of AMIs at the same time.

1. Run an instance of Ubuntu 9.10 Karmic AMI, either 32-bit or 64-bit depending on which architecture AMI you wish to build. I prefer the c1.* instance types to speed up the builds, but you can get by cheaper with the m1.* instance types. Make a note of the resulting instance id:

   # 32-bit
   instanceid=$(ec2-run-instances   \
     --key YOURKEYPAIR              \
     --availability-zone us-east-1a \
     --instance-type c1.medium      \
     ami-1515f67c |
     egrep ^INSTANCE | cut -f2)
   echo "instanceid=$instanceid"
   
   
   # 64-bit
   instanceid=$(ec2-run-instances   \
     --key YOURKEYPAIR              \
     --availability-zone us-east-1a \
     --instance-type c1.xlarge      \
     ami-ab15f6c2 |
     egrep ^INSTANCE | cut -f2)
   echo "instanceid=$instanceid"
   

   Wait for the instance to move to the “running” state, then note the public hostname:

   while host=$(ec2-describe-instances "$instanceid" | 
     egrep ^INSTANCE | cut -f4) && test -z $host; do echo -n .; sleep 1; done
   echo host=$host
   

2. Copy your X.509 certificate and private key to the instance. Use the correct locations for your credential files:

   rsync                            \
     --rsh="ssh -i YOURKEYPAIR.pem" \
     --rsync-path="sudo rsync"      \
     ~/.ec2/{cert,pk}-*.pem         \
     ubuntu@$host:/mnt/
   

3. Connect to the instance:

   ssh -i YOURKEYPAIR.pem ubuntu@$host
   

4. Install the image building software. We install the python-vm-builder package from Karmic, but we’re going to be using the latest vmbuilder from the development branch in Launchpad because it has good bug fixes. We also use the EC2 API tools from the Ubuntu on EC2 ec2-tools PPA because they are more up to date than the ones in Karmic, letting us register EBS boot AMIs:

   export DEBIAN_FRONTEND=noninteractive
   echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
     sudo tee /etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list &&
   sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873 &&
   sudo apt-get update &&
   sudo -E apt-get upgrade -y &&
   sudo -E apt-get install -y \
     python-vm-builder ec2-ami-tools ec2-api-tools bzr &&
   bzr branch lp:vmbuilder
   

   You can ignore the “Launchpad ID” warning from bzr.

5. Fill in your AWS credentials:

   export AWS_USER_ID=...
   export AWS_ACCESS_KEY_ID=...
   export AWS_SECRET_ACCESS_KEY=...
   export EC2_CERT=$(echo /mnt/cert-*.pem)
   export EC2_PRIVATE_KEY=$(echo /mnt/pk-*.pem)
   

   Set up parameters and create files to be used by the build process. The bucket value is only required for S3 based AMIs:

   bucket=...
   codename=karmic
   release=9.10
   tag=server
   if [ $(uname -m) = 'x86_64' ]; then
     arch=x86_64
     arch2=amd64
     pkgopts="--addpkg=libc6-i386"
     kernelopts="--ec2-kernel=aki-fd15f694 --ec2-ramdisk=ari-c515f6ac"
     ebsopts="--kernel=aki-fd15f694 --ramdisk=ari-c515f6ac"
     ebsopts="$ebsopts --block-device-mapping /dev/sdb=ephemeral0"
   else
     arch=i386
     arch2=i386
     pkgopts=
     kernelopts="--ec2-kernel=aki-5f15f636 --ec2-ramdisk=ari-0915f660"
     ebsopts="--kernel=aki-5f15f636 --ramdisk=ari-0915f660"
     ebsopts="$ebsopts --block-device-mapping /dev/sda2=ephemeral0"
   fi
   cat > part-i386.txt <<EOM
   root 10240 a1
   /mnt 1 a2
   swap 1024 a3
   EOM
   cat > part-x86_64.txt <<EOM
   root 10240 a1
   /mnt 1 b
   EOM
   

6. Create a script to perform local customizations to the image before it is bundled. This is passed to vmbuilder below using the --execscript option:

   cat > setup-server <<'EOM'
   #!/bin/bash -ex
   imagedir=$1
   # fix what I consider to be bugs in vmbuilder
   perl -pi -e "s%^127.0.1.1.*\n%%" $imagedir/etc/hosts
   rm -f $imagedir/etc/hostname
   # Use multiverse
   perl -pi -e 's%(universe)$%$1 multiverse%' \
     $imagedir/etc/ec2-init/templates/sources.list.tmpl
   # Add Alestic PPA for runurl package (handy in user-data scripts)
   echo "deb http://ppa.launchpad.net/alestic/ppa/ubuntu karmic main" |
     tee $imagedir/etc/apt/sources.list.d/alestic-ppa.list
   chroot $imagedir \
     apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BE09C571
   # Add ubuntu-on-ec2/ec2-tools PPA for updated ec2-ami-tools
   echo "deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main" |
     sudo tee $imagedir/etc/apt/sources.list.d/ubuntu-on-ec2-ec2-tools.list
   chroot $imagedir \
     sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9EE6D873
   # Install packages
   chroot $imagedir apt-get update
   chroot $imagedir apt-get install -y runurl
   chroot $imagedir apt-get install -y ec2-ami-tools
   EOM
   chmod 755 setup-server
   

7. Build the image:

   now=$(date +%Y%m%d-%H%M)
   dest=/mnt/dest-$codename-$now
   prefix=ubuntu-$release-$codename-$arch-$tag-$now
   description="Ubuntu $release $codename $arch $tag $now"
   sudo vmbuilder/vmbuilder xen ubuntu       \
     --suite=$codename                       \
     --arch=$arch2                           \
     --dest=$dest                            \
     --tmp=/mnt                              \
     --ec2                                   \
     --ec2-version="$description"            \
     --manifest=$prefix.manifest             \
     --lock-user                             \
     --part=part-$arch.txt                   \
     $kernelopts                             \
     $pkgopts                                \
     --execscript ./setup-server             \
     --debug
   

   [For S3 based AMI] include the following options in the vmbuilder command above. This does not preclude you from also building an EBS boot AMI with the same image. Make a note of the resulting AMI id output by vmbuilder:

     --ec2-bundle                            \
     --ec2-upload                            \
     --ec2-register                          \
     --ec2-bucket=$bucket                    \
     --ec2-prefix=$prefix                    \
     --ec2-user=$AWS_USER_ID                 \
     --ec2-cert=$EC2_CERT                    \
     --ec2-key=$EC2_PRIVATE_KEY              \
     --ec2-access-key=$AWS_ACCESS_KEY_ID     \
     --ec2-secret-key=$AWS_SECRET_ACCESS_KEY \
   

8. [For EBS boot AMI] Copy the image files to a new EBS volume, snapshot it, and register the snapshot as an EBS boot AMI. Make a note of the resulting AMI id:

   size=15 # root disk in GB
   volumeid=$(ec2-create-volume --size $size --availability-zone us-east-1a |
     cut -f2)
   instanceid=$(wget -qO- http://instance-data/latest/meta-data/instance-id)
   ec2-attach-volume --device /dev/sdi --instance "$instanceid" "$volumeid"
   while [ ! -e /dev/sdi ]; do echo -n .; sleep 1; done
   sudo mkfs.ext3 -F /dev/sdi
   ebsimage=$dest/ebs
   sudo mkdir $ebsimage
   sudo mount /dev/sdi $ebsimage
   imageroot=$dest/root
   sudo mkdir $imageroot
   sudo mount -oloop $dest/root.img $imageroot
   sudo tar -cSf - -C $imageroot . | sudo tar xvf - -C $ebsimage
   sudo umount $imageroot $ebsimage
   ec2-detach-volume "$volumeid"
   snapshotid=$(ec2-create-snapshot "$volumeid" | cut -f2)
   ec2-delete-volume "$volumeid"
   while ec2-describe-snapshots "$snapshotid" | grep -q pending
     do echo -n .; sleep 1; done
   ec2-register                   \
     --architecture $arch         \
     --name "$prefix"             \
     --description "$description" \
     $ebsopts                     \
     --snapshot "$snapshotid"
   

9. Depending on what you want to keep from the above process, there are various things that you might want to clean up.

   If you no longer want to use an S3 based AMI:

   ec2-deregister $amiid
   ec2-delete-bundle                     \
     --access-key $AWS_ACCESS_KEY_ID     \
     --secret-key $AWS_SECRET_ACCESS_KEY \
     --bucket $bucket                    \
     --prefix $prefix
   

   If you no longer want to use an EBS boot AMI:

   ec2-deregister $amiid
   ec2-delete-snapshot $snapshotid
   

   When you’re done with the original instance:

   ec2-terminate-instance $instanceid
   

In the above instructions I stray a bit from the defaults. For example, I add the runurl package from the Alestic PPA so that it is available for use in user-data scripts on first boot. I enable multiverse for easy access to more software, and I install ec2-ami-tools which works better for me than the current euca2ools.

I also set /mnt to the first ephemeral store on the instance even on EBS boot AMIs. This more closely matches the default on the S3 based AMIs, but means that /mnt will not be persistent across a stop/start of an EBS boot instance.

Explore and set options as you see fit for your applications. Go wild with the --execscript feature (similar to the ec2ubuntu-build-ami --script option) to customize your image.

The following vmbuilder options do not currently work with creating EC2 images: --mirror, --components, --ppa. I have submitted bug 502490 to track this.

As with much of my work here, I’m simply explaining how to use software that others have spent a lot of energy building. In this case a lot of thanks go to the Ubuntu server team for developing vmbuilder, the EC2 plugin, the ec2-init startup software, and the code which builds the official Ubuntu AMIs; especially Søren Hansen, Scott Moser, and Chuck Short. I also appreciate the folks who reviewed early copies of these instructions and provided feedback including Scott Moser, Art Zemon, Trifon Trifonov, Vaibhav Puranik, and Chris.

Community feedback, bug reports, and enhancements for these instructions are welcomed.

"Basically, by moving these services out of your data center and into the cloud, you no longer need to have your own data center and supporting staff. Also, you save money in taxes as you transform your capital expenditure to operational expenditure."

I’m polishing up an article about how to build images from scratch with Ubuntu vmbuilder, both for S3 based AMIs and for EBS boot AMIs. Since nobody is paying any attention this new year’s weekend (except for you seven and you know who you are) I figured I’d wait until Monday or so to publish the article.

However, if you have nothing better to do this long weekend and you’d like a preview copy of the article, drop me a note with your email address. All I ask for in return is that you review (and perhaps even test) the instructions and send me feedback where things aren’t clear or don’t work.

RabbitMQ 1.7.0 preinstalled on Ubuntu 9.10, 64-bit (amd64)