[ec2-beta] document: EC2 Ubuntu sudo Guide

[Jim Cheetham]

On Wed, Mar 11, 2009 at 2:21 PM, Michael Greenly <mgreenly at gmail.com> wrote:
> I can imagine two types of EC2 user.  The kind who provisions their own
> server from a distribution base image and the kind who just uses an existing
> public application image, maybe an AMI containing a preconfigured LAMP
> stack.
>
> This instance is only really for the first kind of user I described.
> ...
> Everyone in this conversation has entirely missed my point about this.  This
> is not something I'm advocating or ever do with live servers.  This is about
> an EC2 instance on first boot that still has not been configured for use.
> Don't think of it as the Ubuntu distribution image.  Think of it as a
> pre-distribution.

Ah, an excellent point!

What is the expected use-case for these images? I was thinking earlier
that we could imagine these AMIs as basically equivalent to the
LiveCD, and the "Install" icon (yeah yeah, we're not a desktop, I
know) kicks off in exactly the same way; except that instead of a disk
partitioner, we get the EC2 AMI bundler ...

So, you start up the public AMI, connect to it as a privileged user
(i.e. the same as the LiveCD user, which has no password, and requires
no password to get to root via sudo), and run the "create a
personalised AMI" process, scripted to be similar to the existing
installer. That way we preserve the existing Ubuntu security model
idiom ...

Because we can't control physical access to the machine, we could
_consider_ demanding that the privileged user can only run one
session; this helps to prevent the case where a user allows ssh in to
their new instance from inappropriate locations (i.e. "all" because
it's easier than thinking) and an attacker gets in, with the
opportunity to compromise the new bundled AMI that's being configured.
Yes, an unlikely edge case, but it's possible.

So the overall process could be ...
 * Start the "LiveAMI+current updates"
 * Create a new AMI via the installer
 * Stop LiveAMI, start new post-installed instance
 * Site-specific configuration of post-installed instance
 * ... here it seems ugly; we may have to create a new AMI of
"configured post-installed instance"?

In order to make live easy for deployment, step 2's installer would
need to take parameterised input, rather than demand interactive
input. Mmm. Perhaps I should look at the existing vmbuilder stuff
around now ...

-jim