Simplifies the primary path from "build a custom ISO" to "install from git and
run one menu", which is what the operator actually asked for. The ISO tooling
stays in the tree as a secondary/optional route and is not removed.
admin/bf-bootstrap.sh -- one command on Ubuntu:
- clones the repo to /opt/blueforce-linux or fast-forwards an existing checkout
(a dirty tree is reported and skipped, never reset or stashed)
- installs git/curl/ansible-core, links admin/bf-* and scripts/*/bf-* into
/usr/local/bin, and finishes with the exact next command
- --check is read-only, works without root, and mutates nothing; the piped form
(curl ... | sudo -S -p '' bash) is guarded against eating the script
admin/bf-menu -- numbered operator console (categories 1-5):
- 1 installs THIS device locally; 2 and 5 drive the fleet through the existing
21 Ansible playbooks; 3 prepares and verifies central integration without
installing a central server; 4 holds local tools
- every operation picks one target: a dealer number or an approved wave group.
Scope is derived from the playbook file itself, so a playbook whose declared
scope disagrees with the console's table is refused rather than run
- the command is always shown before it runs; release-gated operations require
a typed wave token, production requires a second token, and "all" runs
wave-by-wave, stopping at the first failure
- audit log at /var/log/blueforce-console.log (mode 600, falls back to
$XDG_STATE_HOME when not writable), recording sanitized target/command/exit
only: no playbook output, no secrets
admin/bf-creds -- optional credential record, DEFAULT OFF:
- a bare run generates nothing and reports what already exists (device id,
WireGuard public key, private key path only, RustDesk id)
- --generate writes /root/blueforce-credentials.txt (0600) and --fetch delivers
it to admin/secrets/<dealer>.txt (0700/0600, git-ignored). The secret never
reaches stdout, stderr or argv
- this does not change the SSH design: password auth stays off and the
blueforce account stays locked, per docs/06. It is a local delivery aid only
docs/33-OPERATOR-CONSOLE.md -- step-by-step guide for an operator new to Linux
and DevOps: which command to type where, what the screen will ask, both
end-to-end sample sessions, the five most common errors, and the security rules.
Tests: run-all.sh -> 9/9 pass, exit 0 (adds check-admin-static.sh, 159 checks,
with negative controls and mutation-proven non-vacuity).
Adds the Blueforce Field OS provisioning stack on top of the existing fleet
architecture, without rewriting the working systems (installer, diagnostics,
Ansible, WireGuard/SSH/xRDP/RustDesk, Docker policies, monitoring, Docusaurus).
ISO build (the previous builder was a skeleton that produced no medium):
- boot layout is read from the base ISO at build time via
`xorriso -report_el_torito as_mkisofs` and rebuilt with `-as mkisofs`;
`-boot_image any replay` cannot work on Ubuntu live ISOs because the GRUB2
MBR lives in the source image's first 16 sectors and the EFI system partition
is an appended partition, neither of which is a file in the ISO9660 tree
- preflight now asserts El Torito boot metadata positively: xorriso exits 0 on
a non-ISO input, which previously let an arbitrary file pass --check
- artifact produced and verified: dist/Blueforce-Field-OS-1.0.0-amd64.iso,
6 481 917 952 bytes, SHA256 cb0cc56f...d431296, BIOS+UEFI entries preserved,
/autoinstall.yaml at the media root, casper/minimal.squashfs byte-identical
to the base
- recorded baseline deviation: the verified medium on the build host is the
Desktop flavour, so the manifest carries a baseline_deviation block instead
of hiding it; Server remains one flag away
Offline and identity:
- offline APT contract with concrete package requirements, pin format and an
audit table; builds fail closed while pins are UNPINNED
- autoinstall keeps interactive-sections: [storage]: the operator confirms the
target disk, and no automatic wipe is ever performed
- firstboot terminal wizard for the 8-digit dealer id, three-state lifecycle
(PROVISIONED_OFFLINE -> ENROLLED -> READY) with fail-closed gates, so a
missing internet link or WireGuard handshake cannot fail provisioning but can
never produce a false READY
Fleet and migration:
- five read-only Ansible playbooks for Field OS version, provisioning,
enrollment, remote channels and offline readiness, all wave-scoped with a
separate production override
- Windows pre-migration inventory and data export extended to the full brief
scope, read-only, never collecting credentials
Tests: tests/run-all.sh -> 8/8 pass, exit 0. Boot acceptance (UEFI, Legacy
BIOS, Secure Boot), air-gapped install, real enrollment endpoint and Windows
rollback remain LAB work and are listed in IMPLEMENTATION-REPORT.md.
