[ec2-beta] document: EC2 Ubuntu sudo Guide

[Soren Hansen]

On Tue, Mar 10, 2009 at 08:21:23PM -0500, Michael Greenly wrote:
>> How do you use rsync differently on EC2 compared to a regular Ubuntu
>> Server install? Also, what is the particular difficulty here? Do you
>> have a specific use case?
> The problem exists when you are trying to use rsync to push files up
> to the server and preserve permissions and ownership.

You only need root on the destination host. You can just run rsync there
to *pull* instead of pushing from the source host. Again: Do you have a
specific use case?

> The same problem exists on a regular server setup.

In that case, I don't see what you meant by: 

   > The advantage is that rsync as root would work and that's an
   > extremely likely activity given what this AMI is and how it will be
   > used.

> So now we've found a difference about what we think this AMI is...
> 
> The user has to customize their instance if they don't it serves no purpose
> except to make money for Amazon.

That is quite simply not true.

There's plenty of useful stuff you can do with the AMI as is. You can
put a couple of simple commands in your user-data and very quickly come
from "basic instance" to "useful server" (to the tune of "apt-get
install apache2 bzr; rm -rf /etc/apache2 ; bzr export /etc/apache2
http://example.com/bzr/apache2-server-conf ; bzr export
/var/www/example.com http://example.com/bzr/www-content', for instance).
There's *very* little value in rebundling for the sole purpose of
putting that in an init script.

I, as an Ubuntu developer, can use it for testing how certain packages
work together if I weren't in the mood to run tests on my own systems,
or if the tests needed to be exposed to the Internet. Since these are
things I usually need to do only once and with many different package
installation combinations, there's absolutely no need to rebundle.

It's also useful to demo what Ubuntu Server is.  What people will see is
almost exactly identical to what they'll see after they finish a regular
Ubuntu Server installation.

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

Yes, of course, since this AMI doesn't come with any of that stuff
preconfigured.

> The users in the second category are not prepared to cope with all the
> backup/recovery issues that must be dealt with when running an EC2
> instance.  You can't just do a tasksel and end up with a production
> environment.  Those packages are not configured to run in a this
> environment.  They don't know the machine is guaranteed to evaporate.
> They don't assume that the root partition is limited to 10GB.  Etc...
> 
> I certainly hope you guys are not trying to encourage that kind of thinking?

I'm not sure I follow completely. No, I don't believe we're doing
anything to trick users into thinking that their EC2 instances are going
to live forever or are anything other than what they are. Does that
answer your question?

> This AMI is for the first kind of user I described.  That user will
> create a customized AMI for some specific applicaiton, maybe a LAMP
> stack, and will deal with all of those complexities.  Once they've
> done this they will bundle it into a customized AMI so that they don't
> have to re-do all that work later when there instance needs to be
> restored.

You yourself mentioned that you've begun to setup a lot of stuff by
using scripts rather than doing so interactively. If you have all of
this scripted, you could just do that on first boot, couldn't you? You'd
save the trouble of rebundling, wouldn't have to use S3 space to store
the AMI, etc., etc.

> 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.  In this situation there's
> no advantage to sudo and there are disadvantages.  I'm not the one
> failing to evolve.  You guys are all stuck in "that's how we do it"
> mode and can't look beyond that.

I'm perfectly happy to discuss the merits, benefits and drawbacks of
using sudo instead of direct root logins. I'm less happy to do so if the
primary "drawback" is that "everyone else does it differently".

-- 
Soren Hansen                 | 
Lead Virtualisation Engineer | Ubuntu Server Team
Canonical Ltd.               | http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/mailman/private/ec2/attachments/20090311/d559e14c/attachment-0002.pgp