|
Hi Nash, Thanks for the question. My standard pattern thus far (after we discussed and confirmed this at DebConf last year) is to only keep the latest point release of AMIs available directly. With situations where there may be default vulnerabilities in the base AMIs (such as in Heartbleed), I think we want to minimise anyone accidentally running an image with known weaknesses. I posted here on 11 Apr that due to the nature, new AMIs were generated, and a that a week later we would remove the older ones - a short time frame, but relatively urgent. I actually left nearly 2 weeks of transition, and then removed public sharing from the older AMIs for a further few days before deleting the 7.4 AMIs (superseded with 7.4a, and now further superseded by 7.5). I haven't yet posted about deprecating 7.4a as there is no immediate rush - but this reminds me that we should. I'll send that over the weekend ins a separate email, clearly marked with an appropriate subject. Since we dont (yet) have a security reason to replace this, we can leave a nice long transition time before removing the older release. I'd be keen to hear how much time you (and other users on list) think we should leave before removing older point releases (when there isn't a known vulnerability, and when there is). If you wish, you can effectively clone the AMIs into your account, and then you can keep them for as long as you want. I'd recommend this for production AutoScale Groups - if you have a copy of the AMI in your account (ie; your snapshot) then they are completely under your control. This is probably a good thing regardless of what operating system AMIs you are using. All OS vendors/distributions update their AMIs from time to time - and each time this is a new AMI I on EC2. My aim is to ensure we get the current point release AMIs out quickly, and give as long transition period as we think is safe. James On 30/04/2014 8:04 AM, nash wrote: > > It looks like you deleted the older AMIs right away. I'm curious if this is the normal procedure. We want to use the Debian images for production but need to have some wiggle room to qa test them before they go away. > > --nash > > On Apr 27, 2014 7:52 AM, "James Bromberger" <james@rcpt.to <mailto:james@rcpt.to>> wrote: > > Hello all, > > Following this weekend's release of Debian Wheezy 7.5 [1], please find the following AMIs now available globally in AWS EC2: > Virtualisation Para-virtualisation (PVM) Hardware Virtualisation (HVM)> > > Please take care to update any CloudFormation templates and AutoScale groups to use these newer AMI IDs (or clone these updated AMIs into your account and use your own AMI IDs). These were generated by the current version of bootstrap-vz as found in github; no additional improvements were made over and above what landed for the impromptu 7.4a release (Console to hvc0, Cloudinit not testing other metadata services, S3 backed AMIs to 4 GB root (from 1GB), and all pending security updates until that point in time which for 7.4a was the heartbleed libssl fix in particular). > > AWS GovCloud and AWS Marketplace updates will be pushed in a few days should no issues arise here. > > For any existing instances, please pay attention to pending security updates (as always) with apt-get update && apt-get upgrade, and please consider installing the unattended-upgrades package to help keep your instance(s) up to date. > > More information is on the Wiki at https://wiki.debian.org/Cloud/AmazonEC2Image/Wheezy > > James > [1] https://www.debian.org/News/2014/20140426 |