archipelagoandClaude Opus 5
408b328c39
The rootfs is a container image exported to a tar and extracted verbatim onto every disk flashed from the ISO, and the ISO is published. It baked two things nobody asked for: Debian's openssh-server postinst generates /etc/ssh/ssh_host_* during the container build, and the `openssl req` layer writes the TLS keypair. Both were therefore identical on every node and known to every downloader. Add a final RUN layer to Dockerfile.rootfs that removes /etc/ssh/ssh_host_*, removes the archipelago TLS keypair (keeping the ssl directory so the first-boot staging swap has somewhere to land), truncates /etc/machine-id to systemd's documented "regenerate on next boot" state, and drops a non-shared /var/lib/dbus/machine-id if one exists as a real file rather than a symlink. It also writes /opt/archipelago/rootfs-identity-stripped so a node can answer after the fact whether its rootfs came from a stripped build; no timestamp, so the RECIPE_HASH cache stays reproducible. This is what makes 10-03's fail-closed regeneration structural instead of procedural: with the material gone, a regeneration failure degrades to "no key, service refuses to start" rather than "fleet-shared key, silently". The `openssl req` layer is deliberately left in place — it keeps proving openssl is present and keeps the SAN template next to its consumer; the strip layer is what makes the output non-shared. Two comment corrections that follow from the strip: - The installer's TLS block is no longer a rarely-taken safety net; it now fires on every install. It is per-install and never image-wide, so it does not reopen F-03, but it does mean a first-boot failure still leaves the web UI with a cert while SSH has nothing. Comment updated to say so. - The first-boot script header overstated the fail-closed cost for TLS for the same reason; corrected to claim certainty only for SSH. This edit is inside the RECIPE_HASH region, so the next build is forced to rebuild the rootfs tar — required for the C-4 evidence to mean anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Archived ISO build recipes
These scripts built the Archipelago auto-installer ISO (bundled and
unbundled variants). As of v1.7.43-alpha, ISOs are no longer part of the
release deliverable. Releases ship as tarballs consumed by
scripts/self-update.sh on existing nodes.
Archived here rather than deleted so they can be resurrected if ISO distribution is reintroduced.
Contents
build-auto-installer-iso.sh— orchestrator, bundles container images into squashfsbuild-unbundled-iso.sh— thin wrapper that sets BUNDLE_IMAGES=0 and delegatestest-iso-qemu.sh— smoke-tests a built ISO under QEMUscripts/convert-iso-to-disk.sh— converts an ISO to a raw disk imageBUILD-ISO-STATUS.md,ISO-BUILD-CHECKLIST.md— contributor guidesbranding/isohdpfx.bin— isolinux MBR hybrid image.gitea-workflows/build-iso-dev.yml— CI workflow that ran the build+smoke-test
To resurrect
git mv image-recipe/_archived/* image-recipe/(adjust paths back)- Restore
.gitea/workflows/build-iso-dev.yml - Re-add release-process references (see
scripts/create-release.sh,docs/BETA-RELEASE-CHECKLIST.md,docs/hotfix-process.md,README.md).
Why archived
The release flow is simpler and faster as tarball-only:
releases/vX.Y.Z-alpha/archipelago(backend binary)releases/vX.Y.Z-alpha/archipelago-frontend-X.Y.Z-alpha.tar.gz(frontend + AIUI + filebrowser UI assets)releases/manifest.json(pointers + changelog)
Nodes pull these via scripts/self-update.sh from either Gitea mirror.
Filebrowser and AIUI remain bundled inside the frontend tarball and deployed
atomically by self-update.sh.