From nobody Mon Jan 5 23:45:19 2026 X-Original-To: freebsd-cloud@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dlfRQ6RV8z6N7yd for ; Tue, 06 Jan 2026 05:12:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [46.21.153.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dlfRQ2Xp5z3bSc; Tue, 06 Jan 2026 05:12:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1767656717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IVJ6kznwsNqMhSrDlqKeEBNwzqtOyvLED1lrvWcP95s=; b=Hz8fZ37oQbvbWYa/a53y4ZMuM1AEI4LR/t4L6Adbf8aDMKE5QFTqgG9v0yBMmrKhKn6jfS 85Cvkx3X8FkarjrXh0wqQSpdcQPBq8W8wOpvc9vZFkJj+YF4QrEBK9EeqliVt/V3CBrHId GLj4tlZst/29lAklF/bHcfxhuWgPcDI= Received: from [192.168.1.182] (47-143-52-179.fdr01.snmn.ca.ip.frontiernet.net [47.143.52.179]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 2c792ac1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 5 Jan 2026 23:45:15 +0000 (UTC) Message-ID: <61d82ff3-c5b1-45d0-ac55-d5bb10a30498@nomadlogic.org> Date: Mon, 5 Jan 2026 15:45:19 -0800 List-Id: FreeBSD on cloud platforms (EC2, GCE, Azure, etc.) List-Archive: https://lists.freebsd.org/archives/freebsd-cloud List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-cloud@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: EC2 "pre-patched" AMIs To: Colin Percival , "freebsd-cloud@freebsd.org" Cc: FreeBSD Release Engineering Team References: <2b292b81-1912-4914-a4f2-cf3afc5461a3@freebsd.org> Content-Language: en-US From: Pete Wright In-Reply-To: <2b292b81-1912-4914-a4f2-cf3afc5461a3@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29802, ipnet:46.21.153.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dlfRQ2Xp5z3bSc 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.  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.org