Re: Downloadable image files
> This would also make it easier for others to download, untar, customize, snapshot, register to create their own private AMIs.
This shouldn't be a problem. The AMIs can be recreated with one simple
command and three parameters, published on the wiki.
I would encourage to always start fresh when creating a private AMI.
The script supports plugins, meaning everything can be automated and
is reproducible, which reduces human error (leftover cachefiles,
temporary stuff).
> The images could probably be built outside of EC2 if somebody cared, as they should be usable on other non-EC2 platforms.
True, besides the volume operations and the AMI registration, there is
nothing really AWS specific about the bootstrapper.
The bootstrapper is quite flexible and portable to other cloud
providers. The unique features about it are actually the architecture
and all the itty bitty details that need fixing after debootstrap has
run.
> There are security risks with block device copies as they can contain deleted files
Taken care of (to the best of my abilities). The only thing that
really needs shredding are the ssh host keys. The bash history is not
even created when bootstrapping. Can you think of any other problems
one should be aware of?
Anders
On 20 November 2012 23:15, Eric Hammond <ehammond@thinksome.com> wrote:
> [I was asked to copy this feedback from #debian-cloud to the list for
> general consumption. Edited for the list.]
>
> One problem I think I see is that the AMI is being created first, then the
> block device is being copied for the downloadable image.
>
> The downloadable image would better be a tar.gz of the file system. That
> could be untar'd onto an EC2 volume, snapshot, and registered as an AMI.
>
> This would also make it easier for others to download, untar, customize,
> snapshot, register to create their own private AMIs.
>
> The images could probably be built outside of EC2 if somebody cared, as they
> should be usable on other non-EC2 platforms.
>
> There are security risks with block device copies as they can contain
> deleted files. Here are a couple articles I've written on this:
>
> http://alestic.com/2011/06/ec2-ami-security
>
> http://alestic.com/2009/09/ec2-public-ebs-danger
>
> --
> Eric Hammond
>
>
> --
> To UNSUBSCRIBE, email to debian-cloud-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: [🔎] 50AC00E6.50203@thinksome.com">http://lists.debian.org/[🔎] 50AC00E6.50203@thinksome.com
>
Reply to: