I’ve been testing Rocky 9 in AWS EC2 with the official AMIs. I’ve come across a problem where the expected default user (via cloud-init) changes from ‘rocky’ (expected) to ‘cloud-user’ (not so).
I attach a complete log showing what happens if I launch the “Rocky-9-EC2-Base-9.1-20221123.0.x86_64” AMI and perform a “yum update”. The short version is:
I can ssh into the instance as the ‘rocky’ user, and the /etc/cloud/cloud.cfg file shows ‘rocky’ as the default user:
system_info:
This will affect which distro class gets used
distro: rocky
Default user name + that default users groups (if added/used)
default_user:
name: rocky
I then perform a ‘yum update’, which applies many updates - including cloud-init. The package version before upgrade is: cloud-init-22.1-5.el9.noarch. After upgrade, it is: cloud-init-22.1-5.el9.0.1.noarch
After the upgrade, the /etc/cloud/cloud.cfg default user has changed:
system_info:
This will affect which distro class gets used
distro: rocky
Default user name + that default users groups (if added/used)
default_user:
name: cloud-user
This is a big problem for us. We’re actually creating golden-image AMIs that are pre-patched. So after the AMI build, the default user is wrong, and doesn’t match the original image. Also doesn’t match the default user for Rocky-8 either.
Why is it doing this? Why would it not either keep the same user, or at least write the incompatible version to a .rpmnew file? I can’t find a change log that suggests that the default should change in a point release.
Red Hat issued a patch that removed all derivatives from being Red Hat distributions. This caused the default user to be “rocky” among other breaking changes.
Part of the above was fixed upstream and fixed downstream (in our own package). The exception is we change rocky back to cloud-user as this is expected by users making their own AMI’s in most scenarios and it also fixes tests/images being performed in openstack.
Our kickstarts have histortically changed cloud-user to rocky. See here. But because the cloud.cfg file is technically unchanged on an update, the user was changed in your case.
I asked @neil to look into generating updating AMI’s.
Thanks for the reply. Was considering doing the same as in your kickstarts. Although I’m pretty concerned if someone runs a yum update in the future it’ll hose - hope that it’ll think the changed-back-to-rocky file is custom and won’t overwrite.
-Alan
Right yeah, we’re going to try to put in some mitigation steps to sidestep this in the future. We’re making an additional changes to cloud.cfg so it shouldn’t overwrite again in our AMI’s.
New AMIs have been published to address these concerns. Please check them out on the marketplace (or under our account ID) aws ec2 describe-images --owners 792107900819 --region us-east-1
The website will be updated with the new AMI IDs shortly.