Amc/Blueforce-Linux
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Blueforce-Linux/provisioning/autoinstall
History
emirhanmamak-blueforce ef102b9657 feat(field-os): provisioning layer, real ISO build, offline contracts 
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.
2026-09-16 11:14:42 +03:00
..
autoinstall.yaml feat(field-os): provisioning layer, real ISO build, offline contracts 2026-09-16 11:14:42 +03:00
meta-data feat(field-os): provisioning layer, real ISO build, offline contracts 2026-09-16 11:14:42 +03:00
README.md feat(field-os): provisioning layer, real ISO build, offline contracts 2026-09-16 11:14:42 +03:00
user-data feat(field-os): provisioning layer, real ISO build, offline contracts 2026-09-16 11:14:42 +03:00

README.md

Autoinstall

Ubuntu Subiquity autoinstall v1 baseline for the Blueforce Field OS medium. It is identity-free and stays operator-assisted.

  • autoinstall.yaml is copied to the root of the installation medium as /autoinstall.yaml, which is where Subiquity reads configuration from the medium itself; build-blueforce-iso.sh also ships a copy under /blueforce-provisioning/autoinstall/.
  • user-data is the NoCloud transport for the V1 "official ISO + seed USB" flow. Its autoinstall block is kept identical to autoinstall.yaml so both flows behave the same.
  • interactive-sections: [storage] is mandatory. The technician selects and confirms the target disk on the installer screen; V1 never wipes a disk automatically.
  • apt.fallback: offline-install is explicit: when no primary mirror is reachable, Subiquity reverts to an offline installation from the medium instead of aborting.
  • late-commands only copy reviewed medium content into the target: the offline APT repository to /opt/blueforce/offline-repo, the firstboot payload to /usr/local/sbin/bf-firstboot, its service unit to /etc/systemd/system/, the release identity to /etc/blueforce-release, and the service is enabled. It stays inert until an operator supplies the dealer ID and the authorised public key on the installed system (ConditionPathExists= guards in the unit).
  • No identity block, user, password, SSH key, dealer id or disk directive belongs here; device identity is collected at firstboot (K-09/K-12). The static test suite enforces this, and build-blueforce-iso.sh re-scans its inputs before it writes a medium.

Flavour note: this configuration is written for the Ubuntu installer's autoinstall contract. The LAB build base is currently the Desktop flavour ISO (see ../iso/README.md); the autoinstall path on that flavour must be accepted in the LAB matrix before production use.