Re: AWS EC2: Debian Wheezy 7.5 AMIs available
On Thu, May 1, 2014 at 11:49 AM, James Bromberger <james@rcpt.to> wrote:
> 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.
James,
If we go by other distro standards, like Ubuntu, it seems deprecation
is done with utmost care. I believe the reason for this is that these AMI
IDs are generally baked into orchestration and provisioning framework
templates, that might not get updated in a timely fashion, as they
might required extend Q/A by their users to update to a newer AMI of
the same release.
I feel the these are good standards, that I have raised in the past on
this list, but initially didn't push too hard for, because at the time
we didn't even have a functional cloud-init, and the AMIs in general
were under fairly heavy evolution, beyond just the standard
distro/package updates. I also felt that we were starting with a
fairly small user base, and figured it was probably better not to lock
ourselves into maintaining *incomplete* AMIs. (By incomplete, I mean
by example, early AMIs that might not include cloud-init.)
I'll add that although it doesn't cost much to host AMIs, forcing our
users who are using unmodified AMIs to clone ours, to rely on them
being there, doesn't seem ideal.
In the ideal world (assuming things have stabilized on the cloud
tooling side) I feel that we definitely should keep AMIs available if
the release it contains still gets security patches, and can
effectively be brought up to current with an apt-get
update/dist-upgrade. Arguably, we might want to even consider a policy
allowing us to keep older EOLed AMIs available beyond their supported
life. (IE: Perhaps only advertise the latest AMI in a release, but
keep the older AMIs available if people already know the ID and need
to use them.)
Obviously there will likely be exceptional cases where an AMI gets
pulled, but I'd think that it would be a pretty high barrier that even
Heartbleed *might* not have crossed. Where to draw the line here is
grey, but if an instance launched from the AMI is vulnerable to remote
exploits before anything has been configured, then it is a likely
candidate for deprecation. (e.g. - A default ssh misconfiguration that
harbors a known vector of attack.)
I'll add that this may be another area where discussion with Ubuntu
and Amazon Linux contributors about what their formal policy is, may
make sense. (It looks like on the Ubuntu side that even EOLed AMIs are
kept around. Not sure on the Amazon Linux side.)
I'll add that getting granular usage stats may be helpful too, in
making these decisions, since the larger the userbase, the more
careful we should be about deprecation. (With a potential catch-22
being that if we are too cavalier about early deprecation, we may
scare off potential users and never have a large userbase.)
Thanks,
Brian
> 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)
>
> Root filesystem EBS EBS Instance store EBS
> -------------------------------------------------------------------------------
> Architecture i386 x86_64 x86_64 x86_64
> US-East-1 ami-90886cf8 ami-2c886c44 ami-848a6eec ami-86896dee
> US-West-1 ami-6895ad2d ami-5c95ad19 ami-d495ad91 ami-0e95ad4b
> US-West-2 ami-a0760290 ami-40760270 ami-ee7703de ami-10770320
> EU-West-1 ami-510fcb26 ami-630fcb14 ami-a70fcbd0 ami-210fcb56
> AP-Southeast-1 ami-24fba876 ami-22fba870 ami-7cfaa92e ami-dcfba88e
> AP-Southeast-2 ami-24fba876 ami-edc75cd7 ami-0bc65d31 ami-33c65d09
> AP-Northeast-1 ami-c7296cc6 ami-91296c90 ami-b53570b4 ami-112b6e10
> SA-East-1 ami-ffb815e2 ami-c3b815de ami-efb815f2 ami-f5b815e8
> US-Gov-West-1
> CN-North-1 - ami-c6b123ff - ami-38b62401
>
>>
>>
>
>> 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
>
Reply to: