Showcase Project

Foreman / Satellite

Foreman running on its own host, paired with an Image Builder golden image: repeatable RHEL deployment, SSH that actually works, a unique identity per clone, and a real VMware import bug found and worked around without touching the source artifact.

Foreman RHEL Image Builder Golden Image Deployment SSH Host Identity VMware OVA / OVF Import

What’s Actually Running

Foreman and the golden image it’s meant to manage

Foreman, for real

foreman.lab runs RHEL 9.8 with Foreman 3.19 and an operational Foreman Proxy over HTTPS. Ansible support is enabled (ansible-core 2.16.14, ansible-runner 2.3.6), with the RHEL lab hosts prepared for it.

Katello deferred on purpose

Katello was intentionally left out for now. The home lab’s physical memory budget doesn’t comfortably support it alongside everything else already running, so this is content management staying out until there’s room for it, not an oversight.

A golden image with a real admin account

RHEL Image Builder, installed on control.lab, produces the golden image this page is built around: a RHEL configuration with a dedicated goldman administrative account, and a requirement that console access alone wasn’t good enough, SSH had to actually work.

Repeatable, and Verifiably Unique

Cloning a golden image safely means more than “it boots”

SSH access into a fresh Goldman deployment was validated using the dedicated key built for it, not an unrelated automation key already lying around. But the real question behind a golden-image workflow is whether repeated clones stay safely distinct from each other.

Two SSH concepts, kept separate

The dedicated Goldman SSH key is an authentication key: it’s what an administrator uses to log in as goldman, and it can deliberately be shared across every Goldman deployment, that’s the intended model. The keys under /etc/ssh/ssh_host_* are a completely different thing: they’re host keys, which identify the individual server itself to any SSH client connecting to it, and those have to be unique per machine.

Proof, not an assumption

A second Goldman deployment (“Goldman 4”) was stood up from the same golden image and its host key fingerprints were pulled and compared directly against the existing deployment’s, rather than just assuming a fresh clone would generate its own.

          
          SSH host key fingerprints · two Goldman deployments
        
Scroll sideways to see the full lines →

          Existing Goldman deployment
  ED25519  SHA256:FkWTBg8tMIdfIm038S2B8C4GT2mFuSCPv2B3jVyw/9c
  RSA      SHA256:FvjYWmaa0VXe2/52973iXJDrzeWcPMb62U8/y4VRJio

Goldman 4
  ED25519  SHA256:3E70OZXJUdS3+3J/u6pdfM4oRqqEdZ6e1qE4ZOmPBHQ
  RSA      SHA256:S75N/r2p+iCmLq+4eg5mvRXlBM7ZjtLT01fICPRTfsc
        

These are SSH host key fingerprints, not the keys themselves. They’re meant to be shared publicly; it’s how SSH clients verify a server’s identity, and they reveal nothing that could be used to access either machine.

Both the ED25519 and RSA fingerprints differ between the two deployments, confirming each Goldman clone presents its own SSH server identity rather than inheriting the golden image’s.

The Import That Looked Like Corruption

A real VMware/OVF interoperability bug, isolated instead of guessed at

A golden image VMware called corrupt

Problem

Importing the golden image’s OVA into VMware Workstation failed partway through transfer with The SHA digest of the file image.vmdk does not match the manifest, as if the exported artifact itself were damaged.

Root cause

It wasn’t. Running VMware’s own ovftool --verifyOnly against the OVA confirmed the manifest validated cleanly, and the hashes for both image.ovf and image.vmdk matched the manifest when checked directly. The failure only showed up during Workstation’s own transfer-time digest check against this particular disk, which Image Builder had exported in VMware’s streamOptimized VMDK format. Deploying the identical, untouched files from a copy of the extracted OVF with just the manifest file removed completed without error, confirming the data itself was fine and the problem was specific to Workstation/OVF Tool’s verification path.

Fix

Deployed from the manifest-stripped copy as a Workstation-side import workaround. The original OVA and its manifest were never touched and remain the preserved, authoritative golden artifact, this was a deployment workaround, not a fix applied to the image itself.

Still Ahead

Foreman and the automation layer aren’t one pipeline yet

What’s next

Foreman is installed and configured with Ansible support enabled, and the RHEL lab hosts are prepared for it, but Foreman isn’t yet orchestrating the VMs Terraform provisions. Wiring Foreman and Ansible into that provisioning pipeline, and bringing Katello online when the lab’s memory budget allows it, are both still ahead. See Overview for how this fits into the rest of the lab.