[ec2-beta] document: EC2 Ubuntu sudo Guide

[Mark V]

On Wed, Mar 11, 2009 at 6:08 PM, Jim Cheetham <jim at inode.co.nz> wrote:
> 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)

If decided, this point could be worth emphasizing on the EC2-Ubuntu
pages. One of the Aelastic AMI's was a Desktop AMI, and the NX/VNC
threads in AWS's EC2 forum was quite popular.
I still occasionally use a Desktop AMI, albeit non-Ubuntu for the moment.

> 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 ...

By vmbuilder stuff you mean Puppet, Chef, Cfengine, etc. sys
admin/integration frameworks, or something else?

If so then would the above become:
* Start the "LiveAMI+current updates+recipe script(via AMI's user-data)"

In which case ec2-ubuntu becomes an AMI with baked-in Puppet, Chef,
etc. EC2/Ubuntu specific recipes ready to be invoked.
Issues will remain, e.g
 - Puppet v Chef v ?,
 - using local vs remote Puppet/Chef master, etc.

/But/, from the sounds of how a 'good' Ubuntu install has sudo
working, perhaps this wouldn't eliminate any of the steps above?
Rather it might just change what a user invokes in the start-up script
passed in via the AMI's user-data (discussed in another mail list
thread)?

This way users can decide just what recipes get run at start-up, e.g.
Ubuntu-sudo, Ubuntu-user, fwknop, etc, etc. by passing in a simple
script via the AMI's user-data.

Another 2c

Mark

>
> -jim
>
> --
> Ec2-beta mailing list
> Ec2-beta at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ec2-beta
>