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
[email protected]
