Date: Mon, 5 Jan 2026 10:09:06 -0800 From: Colin Percival <cperciva@freebsd.org> To: "freebsd-cloud@freebsd.org" <freebsd-cloud@freebsd.org> Cc: FreeBSD Release Engineering Team <re@FreeBSD.org> Subject: RFC: EC2 "pre-patched" AMIs Message-ID: <2b292b81-1912-4914-a4f2-cf3afc5461a3@freebsd.org>
index | next in thread | raw e-mail
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? 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? The path /aws/service/freebsd/amd64/base/ufs/15.0/RELEASE itself will never change; it's important to have an immutable reference to the original release images. -- Colin Percival FreeBSD Release Engineering Lead & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoidhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b292b81-1912-4914-a4f2-cf3afc5461a3>