RE: Reading archives..
Hi Brian,
Thanks for the input, much appreciated. Suggestions below:
1) SSH Username: 'debian' is an obvious choice. Ec2-user is the other. Time for an informal vote here?
2) Old AMI retention: absolutely have to be careful because of this. So much notice about deprecation, and possible notification of deletion?
3) cloud-init - yes, but it's going to be some years for stable/main. Charles - your thoughts?
4) CLI tools - not initially here. There's lots to discuss with regards to packages of it; who should maintain it, what is the copyright, and where should the repo be. I would love to, but I don't have answers for those questions right now.
5) CFN support - definitely high on my priority list. But again, see 4.
6) resize2fs - Anders, I think that's a plugin perhaps for ec2debian-build-ami?
7) That's adding a lot more work - which we can script, but I don't know how useful it would be generally. My goal is low hanging fruit first; but HVM and cluster is probably useful.
8) That's also why I am thinking of leaving 4 and 5 out of band, or to packages from backports.
9) It was not a Debian security issue - but an image generation that left a X509 key visible in the block device. Anders is adding some updates in the ec2debian-build-ami scripts right now, and I'll regenerate some fresh images tonight, will retest, and then re-release with new AMI IDs. A kind soul inside AWS found and reported to me, and took the time to telephone me immediately from the US (I am in Australia).
10) Absolutely - we want to get this right. I place a high degree of trust in generating something that is secure, and trusted, and universally useful. We can always add more AMIs (such as HVM, etc - #7) when we have everything else agreed.
11) I have been looking at that for a few weeks; I have one approach, but I am conscious of costs if it were used outside of AWS/EC2. Hence the current images will use generate source.list file using a 'close' mirror to that Region; after we have this sorted then changing the mirror structure for the next release is something we can look at. I was looking at using S3 as a mirror, and recently S3 Redirects means that it may be possible to copy our a mirror into S3, symlinks and all (that become HTTP redirects).
I think a key thing is going to be documentation of how you can take a base Debian image, and do something more powerful. Even just telling users that they can paste the following in the web console as UserData :
#!/bin/sh
apt-get update && apt-get install -y unattended-updates
Likewise for getting CLI tools, we can show snippets of scripts that do that as one liners.
I'll ping the list with fresh AMIs after they are available; likely to be a few hours as I have to head home and attend to life. ;)
James
JEB@debian.org
PS: DDs, email me directly for access to the AWS account.
--
James Bromberger | Solution Architect - Western Australia| Amazon Web Services
-----Original Message-----
From: Brian Gupta [mailto:brian.gupta@brandorr.com]
Sent: Thursday, 8 November 2012 5:45 PM
To: debian-cloud@lists.debian.org
Subject: Reading archives..
So I am a long time user of EC2 (since 2008), and wanted to give some feedback on some of the questions being raised, and some additional thoughts. Please forgive me if I missed any emails in the threads:
1) default user. There is no standard across distros. For example:
Ubuntu -> ubuntu
RHEL -> root (violates the Amazon recommendation, but follows RHEL standards)
Amazon Linux (CentOS based) -> ec2-user
I like "debian" as initially proposed.
(This user needs to accept and install the ssh public key handed by Amazon API as part of spinup process, and of course password login should be disabled)
2) Retention of AMIs.
Generally there is an expectation that "Official" Public AMIs will not go away, as people bake these things into highly automated infrastructures. I see we are discussing a purging policy, I would be very careful here. (One should stop advertising the depricated AMIs, but generally they should be kept available for those users that have them baked into their automation.)
3) Very happy to see cloud-init support being added to Debian
4) Are we going to be adding the ec2 cli tools to the AMIs? or at least packaging them to make it easier to install?
A full list with locations can be found here:
http://alestic.com/2012/09/aws-command-line-tools
5) Same question for the cfn-helper tools? (Cloudformation helper)
Currently I install like so, but packaging it and baking it into the AMI would be great:
apt-get -y install python-setuptools
easy_install
https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-1.0-6.tar.gz
6) Now that EC2 supports overriding the default root EBS volume size, doing a conditional resize2fs upon boot is incredibly useful.
7) So in addition to 32 bit EBS and 64 bit EBS we are going to want to maintain a number of other permutations in each region. Full list:
- 32-bit instance store
- 64-bit instance store
- 32-bit PVM EBS
- 64-bit PVM EBS
- 64-bit HVM EBS (For cluster nodes, which are currently only available in us-east)
8) AWS services change during the life of a stable release, I believe we are going to have to consider how to allow some EC2 specific packages to get updated beyond just security patches.
9) Not sure I understand the security issue that required the AMIs to be pulled. Is there an explanation somewhere that I missed?
10) Gonna take a little while to get this right.. Please don't rush to label them as "Official", as once you do, you lose quite a bit of flexibility when it comes to users' expectations.
11) At some point, we may want to consider running repos inside of the AWS cloud.
If I have time I'll try to do some testing this weekend. (No promises.)
--
To UNSUBSCRIBE, email to debian-cloud-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] CACFaiRwn8wmhPBaagyH4JfZJLM9QjQyXDzsjdj9s_HnN_Sgb3Q@mail.gmail.com">http://lists.debian.org/[🔎] CACFaiRwn8wmhPBaagyH4JfZJLM9QjQyXDzsjdj9s_HnN_Sgb3Q@mail.gmail.com
Reply to: