-
-
Notifications
You must be signed in to change notification settings - Fork 27
RHEL 9 Image Extensions
Status: Current Documentation baseline: v4.03.2
This page distinguishes the RHEL-family 9+ image extension that exists in the v4.03.2 source from a separate runtime-only packaging extension that is still planned. Do not infer availability from a design boundary.
| Extension | v4.03.2 status | Source | Qualified boundary |
|---|---|---|---|
| Offline RPM image staging | Available | extensions/rhel-image |
Fresh, extracted and unmounted RHEL-family 9+ image root |
| Runtime-only Go with package-owned host integration | Not implemented | No source path yet | No installation or release claim |
The offline RPM staging extension is the only currently available RHEL 9+ image extension. The runtime-only, package-owned system-integration extension is not available in v4.03.2. The second row records an accepted future design boundary, not an operator procedure.
The available extension installs one exact, checksum-bound SysWarden RPM into a fresh image root with RPM plugins, package scripts and triggers disabled. It does not enter the root, execute a SysWarden binary, call a service manager, change firewall policy, signal a process or use the network during staging.
The image recipe, not the extension, must prepare dependencies and the selected
firewall frontend before staging. After payload verification, the extension
publishes a marker-guarded first-boot unit. The real target then runs the normal
install and reload commands. A retained marker makes a failed first boot
retryable.
Use the complete optional RHEL-compatible image staging procedure. The repository extension reference defines the exact path, RPM database, interruption-recovery and adversarial test contracts.
The minimum release boundary is:
- run the read-only root preflight before any image mutation;
- prepare all RPM dependencies inside the disposable image root;
- authenticate the public Release and verify the exact RPM SHA-256;
- invoke the extension only on a fresh, unmounted and canonical image root;
- publish image-owner configuration and policy lists as separate bounded transactions;
- complete the normal SELinux relabel, package inventory, bootloader and image signing stages;
- boot a disposable target and validate services, configuration, firewall, first-boot marker removal and recovery access.
Offline staging does not establish runtime readiness or widen the qualified package matrix. ISO assembly, signing, bootloader integration and target-host qualification remain image-builder responsibilities.
The planned extension has no shipped source, package selector or supported operator command in v4.03.2. Its accepted design constraints are:
The future extension must keep the Go binaries runtime-only while the RPM owns firewall and systemd configuration.
- Go code performs product runtime work only and does not configure the host firewall or service manager;
- the selected package owns firewall integration, service installation, enablement and removal behavior;
- systemd and OpenRC unit sources are maintained as reviewable, flat files in dedicated repository directories;
- the extension is additive and opt-in for RHEL-family 9+ image construction;
- normal installation, update, reload and the available offline staging extension remain unchanged when the new profile is not selected;
- package scripts fail closed on ambiguous firewall ownership, service state, unsupported init systems or partial transactions;
- install, first boot, upgrade, rollback, final erase, SELinux enforcing mode and interruption recovery require native target-host evidence before the extension can be documented as available.
The implementation lot must first define package ownership and file layout, add the flat unit sources, isolate the Go runtime entry point, build RPM scriptlets, and add adversarial package lifecycle tests. Only after those changes pass protected qualification may this page gain operator commands for the second extension.
Use only an extension marked available for the exact published release. Do not combine the two models, copy planned unit layouts into an image manually or use the planned boundary to bypass current package scripts. Stop if the source revision, package inventory and wiki baseline do not describe the same release.