Thomas Cameron email@example.com
To be clear, there are a LOT of ways to use Fedora on AWS.
The quickest/easiest way is just just use a Fedora image provided
by the Fedora project and then customize it. When you launch your
EC2 instance, go to community AMIs, and choose one from the Fedora
project and you're good to go! Or, you can use the Amazon EC2
Image Builder at https://aws.amazon.com/image-builder/.
That's a quick and painless way, as well.
I did this as a thought exercise/education thing. I wanted to
understand for myself what was involved in setting up an
image myself and making it work on AWS. I'm definitely not saying
this is the best way. It's strictly a case of my nerding
out to figure out a thing, and sharing that thing with the
internet. And to be clear, while I work for AWS, this is not an
AWS supported or even recommended thing. This is purely me
learning, and sharing it on my own time without anything to do
with AWS. There is no warranty for this, and if it breaks, you get
to keep all the pieces.
You can use cockpit or virt-manager. I used virt-manager and
kickstarted a Fedora 37 instance on a 3GB virtual disk.
Here's the kickstart file I created, and shared from a web server
on my homelab network:
# Use text install
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
# Use network installation
# Use update repository so that the system has the latest versions of everything
repo --name "Updates" --baseurl=https://mirrors.kernel.org/fedora/updates/37/Everything/x86_64/
# Run the Setup Agent on first boot
# Generated using Blivet version 3.5.0
# Partition clearing information
clearpart --all --initlabel
# Disk partitioning information
part biosboot --fstype="biosboot" --ondisk=vda --size=1
part / --fstype="xfs" --ondisk=vda --size=1 --grow
part /boot --fstype="xfs" --ondisk=vda --size=512
# System timezone
timezone America/Chicago --utc
# Root password
rootpw --iscrypted [redacted]
echo set enable-bracketed-paste off > /root/.inputrc
echo set enable-bracketed-paste off > /etc/skel/.inputrc
yum -y install cloud-init
systemctl enable cloud-init
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
rm -rf aws*
dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
# NOTE: could not make next line work during kickstart, must be done after first boot!
# dracut -f --add-drivers "nvme xen-netfront xen-blkfront"
openssl passwd -6Copy and paste the resultant password string into your ks.cfg file.
Verifying - Password:
I'm going to write this for anyone who can't kickstart and you
need to do these things manually. After you install Fedora in a VM
selecting only Fedora Custom Operating System, you need to do a
couple of things. We'll install cloud-init,
the latest version of the AWS CLI, the AWS SSM Agent, and we'll
set up the initial ramdisk using dracut.
To install cloud-init, you can just do it from the command line.
dnf -y install cloud-init
systemctl enable cloud-init
To install the latest version of AWS CLI, v2, run this command in
the virtual machine:
I know, I know, I wish there were an RPM for this, but there's
not as of February 24th, 2023.
To install the AWS SSM Agent, use DNF:
dnf install -y
Note that it also enables the service as part of the RPM
Your Fedora instance KVM instance may not have all the required
modules built into the initial ramdisk to boot in AWS. To add
them, use dracut with the -f argument to force a rebuild of the
dracut -f --add-drivers "nvme xen-netfront
It will create a new initramfs file. In this screenshot, I've
shown that the initramfs file is created when you run the command:
You will want to clean up any stuff you have left behind. I
recommend cleaning up your bash history, your ssh key files, and
any log files which could leak any information about your homelab
I'm going to assume you ran the commands to set up this instance
as root. Removing your bash history is pretty easy. You should
also remove the zip file you created and the installation source
for the AWS CLI. In this screenshot, I show that the dot files are
left, but nothing else.
rm -f ~/.bash_history
rm -f ~/*
rm -f *key*
In this screenshot, I show what files are there, what files to
remove, and then what files remain:
You can remove all the files which could potentially leak
information about your homelab setup. Don't worry, when the AMI
boots, it will create new files with the correct ownership and
find . -type f | xargs rm -f