> 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 <[email protected]> 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 [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: http://lists.debian.org/[email protected] > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAMcOGXGqGgMKxJp70jy=gsq_3gy+svm09tt84uagce_mype...@mail.gmail.com
