archipelagoandClaude Opus 5
210430967d
The first-boot per-device secret regeneration was fail-open: both branches logged a warning and continued, and `touch "$MARKER"` ran unconditionally outside both `if` blocks. Combined with the unit's ConditionPathExists=! and the script's own marker fast-path, one transient failure left that node on the image-wide shared SSH host key and TLS private key permanently and silently — and the ISO is a published artefact, so every downloader holds those keys. - Retry each generator 3 times with backoff (D-05), so a transient first-boot condition recovers inside the same boot instead of being terminal. - Write the completion marker ONLY when both TLS and SSH succeeded, so a failed boot leaves the unit eligible to run again on the next boot. - On terminal failure: durable record at /var/lib/archipelago/first-boot-secrets.failed naming which generator failed, plus console + logger + stderr, and exit 1 so the unit lands in `failed` rather than `active`. The record is cleared on a later success. - Add FIRST_BOOT_SECRETS_ROOT / FIRST_BOOT_SECRETS_BACKOFF seams. Unset in production the behaviour is byte-identical; set, they let the fail-closed property be asserted rather than claimed. - Order the unit After=systemd-random-seed.service (no-op today, correct if a seed file is ever baked). - State the operational trade in the script header: after the rootfs strip, a terminal failure means no SSH and no TLS and needs the physical console. That was chosen deliberately over running on fleet-shared keys. tests/first-boot-secrets/run-tests.sh extracts the shipped heredoc body from the builder and drives it against a temp root with stubbed generators: both succeed, openssl fails every attempt, ssh-keygen fails twice then succeeds. Moving the marker touch back outside the success branch makes case 2 fail with MARKER-SET-ON-FAILURE, which is the regression this pins. 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.