Date: Mon, 5 Jan 2026 15:45:19 -0800 From: Pete Wright <pete@nomadlogic.org> To: Colin Percival <cperciva@freebsd.org>, "freebsd-cloud@freebsd.org" <freebsd-cloud@freebsd.org> Cc: FreeBSD Release Engineering Team <re@FreeBSD.org> Subject: Re: RFC: EC2 "pre-patched" AMIs Message-ID: <61d82ff3-c5b1-45d0-ac55-d5bb10a30498@nomadlogic.org> In-Reply-To: <2b292b81-1912-4914-a4f2-cf3afc5461a3@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On 1/5/26 10:09, Colin Percival wrote: > Hi all, > > I'm doing some work, with Amazon sponsorship, to bring "pre-patched" EC2 > AMIs to FreeBSD. The goal here is that soon after any security advisory > or errata notice there will be e.g. FreeBSD 15.0-RELEASE-p2 AMIs available > so that people can launch those and not need to launch the -RELEASE and > then apply updates after the instance boots. > > I have a couple design questions which I'd like input on: > > 1. AMI flavours: We publish four flavours, "base", "small", "cloud-init", > and "AMI Builder". The AMI Builder images (which are what I'll be using to > build updated AMIs) are designed to construct "base" images. How useful > would it be to have other flavours? > I think this is great and it would be helpful to have patched AMI's for all flavors. alternatively a policy stating explicitly that only the builder is getting patched would be helpful too. patched AMI's will reduce 1st boot time for my systems which would be very welcome. > 2. SSM paths: The plan is to publish the updated AMI Ids via the SSM > Parameter > Store; instead of looking up > /aws/service/freebsd/amd64/base/ufs/15.0/RELEASE > you would be able to look up something like > /aws/service/freebsd/amd64/base/ufs/15.0/RELEASE/p1 > to get 15.0-RELEASE-p1, and something like > /aws/service/freebsd/amd64/base/ufs/15.0/RELEASE/latest > to get 15.0-RELEASE-p<whatever the latest patchlevel is>. I'd like > feedback > on the "something like" paths -- are those good ones, or can someone > suggest > better names for the SSM parameters? > short answer the paths seem reasonable to me, although i tend to prefer explicit paths rather than "/latest" just to remove all doubt as to what version i should expect. longer answer... I am not a fan of how AWS implemented SSM, and the tooling is pretty awkward as well imho. it would be super handy to have a page listing all of the AMI's available in an easy to parse method. my current workflow involves using Hashicorp packer to create AMI's for our site. it is at this phase where we apply outstanding patches to the base OS, then on first boot we apply any outstanding ports updates via pkg. having patched AMI's would save some cycles here during build-time, but it would be offset by having to deal with SSM more frequently which i'm not personally a fan of. I appreciate your work on this though colin so hopefully you don't hear this as being ungrateful. i really do appreciate how stable and predictable things have been for some time now. just want to provide honest feedback on my experiences on automating using ssm with 3rd party tooling. -pete -- Pete Wright pete@nomadlogic.orghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61d82ff3-c5b1-45d0-ac55-d5bb10a30498>