nTh among all

Alt: Documenting the process of getting Fedora onto a GCE instance.

Unlike EC2, there are no official Fedora images for use on GCE. CentOS7 is a reasonable alternative, but I was used to having the latest and greatest packages, pretty much by default. Which meant that I wanted to get Fedora.

Thankfully, there’s a way to import images into GCE. Fedora publishes cloud-ready images. People have done it before. Which means it should be quick and easy.

Importing the image

Most of this is CLI driven, so we can use the GCP Cloudshell to do most of this – that little command icon on the top right of the console. Download the script, or copy individual commands.

Once the image is created, we can add the SSH key metadata. Annoyingly, cloud-init will only “merge project/attributes/sshKeys and instance/attributes/ssh-keys“, so if you’re creating multiple instances from a single image, you should add your SSH key to the sshKeys metadata entry. The project level ssh-keys (the dedicated SSH Keys section in the Console) aren’t used.

Also, you should specify the user fedora on the SSH Key comment, so cloud-init will correctly map the key to the (only?) existing account – fedora.

Create an instance with the image, wait for it to start, then connect to it with your SSH client.

Getting the Google Helpers

Part of the nice thing about GCP is that it provides a bunch of nice helpers. I particularly like the connect via SSH option in the console – which needs the helper. Google provides packages for CentOS 7, which is just similar enough to Fedora that we can install 2 of the 3 packages without  modification, and the other package only needs a single character change.

Why a change?

The underlying package json-c had API changes, so the version changed: 2 to 3, and then 3 to 4. CentOS didn’t pick up the version changes – but Fedora did. This is possibly a good example of the API incompatibility that CentOS prevents between major versions.

First, we’re going to setup the repo. We can just use the repo spec in the installation instructions, and hardcode the CentOS version to 7.

(Dump this to the correct location with sudo curl -L -o /etc/yum.repos.d/google-cloud.repo https://gist.github.com/kyl191/de7d5a937f91b03898363832d4e7e19f/raw/5d03819294a5e48e6e023e3ea713699f1ec6ba5b/google-cloud.repo)

Next, to avoid dnf dying with a message about being unable to install libjson-c.so.2, we’re going to patch the package to change the requirement to libjson-c.so.4, and then lock the package to prevent future upgrades breaking it.

Connect to the instance and run

sudo dnf install python-google-compute-engine
sudo dnf install rpmrebuild 'dnf-command(versionlock)'
dnf download google-compute-engine-oslogin
rpmrebuild -ep *google-compute-engine-oslogin-*.el7.x86_64.rpm
# Change  libjson-c.so.2 to  libjson-c.so.4.
sudo dnf install rpmbuild/RPMS/x86_64/google-compute-engine-oslogin-*.el7.x86_64.rpm
sudo dnf versionlock add google-compute-engine-oslogin
sudo dnf install google-compute-engine
# Fudge the actual link so it doesn't die during runtime due to the file not being found
sudo ln -s /usr/lib64/libjson-c.so.4 /usr/lib64/libjson-c.so.2

Optionally, upgrade everything, and then reboot. You should now be able to use the Connect to SSH option in the GCP Console, and verify the expected console logs.

You might also get a warning about the host key changing, I haven’t figured out what makes that happen, but it only happens on the first reboot. I suspect it has something to do with the sshd-keygen.target systemd unit, but haven’t dug in to figure out what exactly.

What’s next?

At this point, the instance is pretty much good to go, perfect as a base system to further configure. Google actually has docs on stuff they suggest doing, like changing NTP to use Google NTP, and changing SSH KeepAlives to 7 minutes (since Google times out connections after 10 minutes of inactivity).