Now why would you do THAT?

  I like my old Sun machines , but they have a small weakness in their design.  The older machines use a real-time clock known as an "IDPROM".  This device, originally made by Dallas Semiconductor has RAM, Clock, Crystal and a Battery all in one package.  If you read that back, you will see the problem: "Battery" The battery has a lifetime in years, but when it goes, the machine loses everything stored in the IDPROM.  The problem is that this data includes the MAC address, Host ID, Serial Number and even system type.  Without this data, your machine won't boot; and if it does, you won't have network access in all likelihood. Now, the chip is in a socket, because Sun knew it would fail and need replacement in the field, and while some devices (M48T02 and M48T58) are still available, other common devices, especially the M48T59 are no longer available, and there aren't and pin-compatible alternatives that I can find.   There are instructions online showing

This is for my benefit as much as anybody else, because it took me a while to figure things out: Most of the time when you write for AWS ImageBuilder, the docs tell you to create separate YAML files containing your components.  That's fine, but what if you want to do dynamic substitutions on path and file names?  In that case you probably want to do the definition in the HCL language.  That is, within the actual Terraform code itself. Using S3 One of the more fiddly bits is pulling things from S3 to install on your new instance.  You need to do two things: Have an IAM policy which allows access; and Write the component to do the job Writing the IAM Create a policy resource that looks something like this: resource "aws_iam_policy" "s3_policy" {     name = "s3-policy"     policy = jsonencode(       {           Version = "2012-10-17"           Statement = [             {               Effect = "Allow"               Action = [