Introduce dnf upgrade

[peterdeme]

Description of the change

Docs: https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades-usage.html

Type of change

• Bug fix (non-breaking change that fixes an issue);
• New feature (non-breaking change that adds functionality);
• Breaking change (fix or feature that would cause existing functionality to not work as expected);
• Documentation (a documentation or example fix not affecting the infrastructure managed by this module);

Checklists

Development

• All necessary variables have been defined, with defaults if applicable;
• The HCL code is formatted;
• An AMI has been created in some AWS account, and the AMI is working as expected;

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached;
• This pull request is no longer marked as "draft";
• Reviewers have been assigned;
• Changes have been reviewed by at least one other engineer;

[eliecharra]

Sound good, but should we freeze it to 2023.5.20240701 instead of latest? Just to prevent future builds to upgrade unwanted packages?

Or maybe scope it to only openssh pkg?

[adamconnelly]

Looks good. I wonder if we should merge this with the dnf-update.sh script so we have all the dnf commands in one place.

Feel free to ignore that - just a thought.

[peterdeme]

@adamconnelly I think that the current structure has a decent ordering and logic:

• dnf-update.sh - fetch remote repositories
• system-deps.sh update + upgrade dependencies
• docker.sh - install docker
• gvisor.sh - gvisor
• cloudwatch-agent.sh - cloudwatch agent
• ssm-agent.sh - ssm agent (installed via dnf)

The logic is that the first step is a prerequisite of the other steps. Following that, I wouldn't merge the first and second step.