Revision 8 as of 2010-08-20 17:29:09

Clear message

Intro

The term 'UEC Images' refers to the Official Ubuntu images that are available at http://uec-images.ubuntu.com . These images are built by Canonical. They are then registered on EC2, and compressed tarfiles are made available for download. The downloaded content can be used as a starting point for creating your own image, or published unmodified to your own UEC.

Daily and Released Images

"Daily" builds are made available for testing and continuous integration. The daily builds are not tested at all. However, the content of the images has already been through the SRU process, so in general the daily builds for stable releases are stable. Quality of daily builds for the development release will vary.

Prior to a milestone or release, a daily builds is selected, tested and then promoted. Only a limited number of daily images are kept around (see the removal policy). Any build that is marked as 'released' will never be deleted.

Daily builds are available under http://uec-images.ubuntu.com/server/<codename> . For example, daily builds of lucid (10.04 LTS) are available at http://uec-images.ubuntu.com/server/lucid/ . Released builds are available under http://uec-images.ubuntu.com/server/releases/<codename> .

To use the images on EC2, simply start an instance with the command line tools using command lines given at uec-images, or launch one of these from the Amazon EC2 Console.

Features of the Images

Version Controlled Build Process

Its not really an end user feature, but a reliable build process in place. Images are built on a 10.04 LTS host from a 0.11 branch of vmbuilder. The build scripts are available under the automated-ec2-builds, and published to uec-images and EC2 using ec2-publishing-scripts.

CloudInit

The images contain CloudInit. CloudInit allows for dynamic run-time customization of images via user-data.

Run Images locally without a Cloud

Images after 10.10 can now be run outside of the cloud environment without any difficult setup, and even provide an easy way to provide metadata to the instance.

  • download a suitable image from http://uec-images.ubuntu.com/server/maverick/current/ . The file name will vary. For this example, it is "maverick-server-uec-amd64.tar.gz". 

    $ tarball=maverick-server-uec-amd64.tar.gz

  • extract the tar file and set some variables names for its contents 

    $ contents=${tarball}.contents
$ tar -Sxvzf ${tarball} | tee "${contents}"
maverick-server-uec-amd64.img
maverick-server-uec-amd64-vmlinuz-virtual
maverick-server-uec-amd64-loader
maverick-server-uec-amd64-floppy
README.files
$ base=$(sed -n 's/.img$//p' "${contents}")
$ kernel=$(echo ${base}-vmlinuz-*)
$ floppy=${base}-floppy
$ img=${base}.img

  • boot the image in kvm 

    # make a qcow image just to keep the original pristine
$ qemu-img create -f qcow2 -b ${img} disk.img
$ kvm -fda ${floppy} -drive if=virtio,file=disk.img -boot a

  • get the password for 'ubuntu' and log in
    The default selection in the grub menu will result in a randomly generated password for the 'ubuntu' user on first boot. The password is written two places, the console and the serial device. On the console, you will see lines like: 

    [    1.820549] EXT4-fs (sda): re-mounted. Opts: (null)
::uncloud-init: settting ubuntu pass = qlnYZTSy
::uncloud-init: changing ubuntu user's password!
::uncloud-init: enabled console on ttyS0

    The password is also written to the kvm serial console. You can see the kvm serial console by hitting ctrl-alt-3. On first boot, you will see lines like 

    ===                                                                             
ubuntu_pass = PhAKp1kx                                                          
===

Advanced use of Images

  • command line parameters used by 'cloud-init' and 'uncloud-init'
    By modifying the kernel command line, you can change the behavior of the 2 programs affect the early boot.

    • ubuntu-pass=[password|random]
      On first boot, uncloud-init will set the password to be 'password'. If the string provided is literally the string 'random' then a random pass will be created and written to the console.

    • ds=nocloud;[key=val] or ds=nocloud-net;[key=val]

      • s=<seedlocation> | seedfrom=<seedlocation> [default=""]
        This allows you to set the 'seed location'. The value can be a url of 'file:///' format, or of 'http://' format. If you want to use http or another network based seed, then 'nocloud-net' must be used as the data source, rather than 'nocloud'. meta-data and user-data will be read from <seedlocation>meta-data and <seedlocation>user-data respectively.
        For example I set up the tiny urls http://tinyurl.com/sm-user-data and http://tinyurl.com/sm-meta-data . These redirect to pages on my hosted system, the tinyurl is only used to make the urls shorter. Then, I can pass boot with a command line like:

         "ro init=/usr/lib/cloud-init/uncloud-init root=LABEL=uec-rootfs ds=nocloud-net;s=http://tinyurl.com/sm- ubuntu-pass=random"

        in , and the user-data and meta-data are pulled from the respective URLs. The format of user-data and meta-data is described in cloud-init's documentation doc/examples/seed.

      • h=hostname | local-hostname=hostname [default="ubuntuhost"]
        Set the local hostname for this instance.

      • i=id | instance-id=id [default="nocloud"]
        This sets the the 'instance-id' for the boot. In EC2 or Eucalyptus, this would be something like 'i-abcdefg' and changes for each instance. The cloud-init code uses 'instance-id' to indicate whether this is the first boot. What this means is that, by default, the constant string 'nocloud' as an instance id will on ever initialize once. If youwant to test initialization again, you would have to remove files in /var/lib/cloud/sem or change this string.

  • boot with kvm '-kernel' command line arguments rather than with the boot floppy: 

    kvm -drive file=disk.img,if=virtio,boot=on \
   -kernel "${kernel}" \
   -append "root=/dev/vda ro init=/usr/lib/cloud-init/uncloud-init ds=nocloud ubuntu-pass=ubuntu"

Machine Consumable Data [query]

In order to provide information about what builds are available for download or running on ec2, a 'query' interface is exposed at http://uec-images.ubuntu.com/query . This will allow users of the service to download images or find out the latest ec2 AMIs programmatically.

The data is laid out as follows:

  • There are 2 files in top level director 'daily.latest.txt' and 'released.latest.txt'. Each of these files contains tab delimited data, with 4 fields per record. daily.latest.txt has information about the daily builds, released.latest.tt about released builds: 

       <suite> <build_name> <label>     <serial>
   hardy   server       release     20100128
  • For each record in the top level files another set of files will exist: \

    • File

      Description

      <suite>/<build_name>/daily-dl.txt

      downloadable images data for all daily builds currently available

      <suite>/<build_name>/daily-dl.current.txt

      downloadable images data for the most recent daily build

      <suite>/<build_name>/released-dl.txt

      downloadable images data for all released builds

      <suite>/<build_name>/released-dl.current.txt

      downloadable images data for the most recent released build

      <suite>/<build_name>/daily.txt

      registered ec2 AMI data for all daily builds ever

      <suite>/<build_name>/daily.current.txt

      registered ec2 AMI data for the most recent daily build

      <suite>/<build_name>/released.txt

      registered ec2 AMI data for all released builds

      <suite>/<build_name>/released.current.txt

      registered ec2 AMI data for the most recent released built

  • The downloadable image data files contain 6 tab delimited fields: 

    <suite>  <build_name> <label> <serial> <arch> <download_path>
maverick server       daily   20100819 i386   server/maverick/20100819/maverick-server-uec-i386.tar.gz

    Download path is relative to "http://uec-images.ubuntu.com/"

  • The registered ec2 AMI data contain 10 tab delimited fields: 

    <suite>  <build_name> <label> <serial>    <root-store>   <arch> <region>  <ami>         <aki>        <ari>
maverick server       alpha3  20100803.2  instance-store i386   us-west-1 ami-ebdc8dae  aki-99a0f1dc <ari>


    For many images, there may be no ari registered, so the field may be blank.