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

1.8 KiB

Raw Blame History

RustDesk Self-Hosted Server (hbbs + hbbr)

OSS rendezvous + relay server for the Blueforce fleet. Field clients reach the VDS public address directly over the internet, independent of WireGuard: if the tunnel drops, this channel stays up (requires field internet + VDS up).

Prerequisites

A central VDS with a public DNS name (example: rustdesk.example.com). Use your real DNS name; the value below is a placeholder.
TCP/UDP ports 21115-21117 reachable from the internet (see port table in docker-compose.yml). Keep 21118/21119 closed unless the web client is used.
Docker Engine + Docker Compose plugin on the VDS.

Setup

cd rustdesk
docker compose up -d
# First start generates the keypair in ./data (id_ed25519 + id_ed25519.pub).
cat data/id_ed25519.pub   # <-- public key; embed in field clients
docker logs bf-hbbs       # verify hbbs listening
docker logs bf-hbbr       # verify hbbr listening

Key distribution (field clients)

Read the public key: cat data/id_ed25519.pub (single line, no newline issues).
Bake into the golden image / deployment script together with the server address: rustdesk.example.com (replace with the real VDS DNS name).
Client config keys: host = rustdesk.example.com, key = <id_ed25519.pub content>.
Tag each client with its device identity BF-<no> so the RustDesk address book matches the Ansible inventory and MeshCentral names.
Key rotation: deploy the new key alongside the old one, confirm clients connect, then retire the old key.

Health monitoring

Point Uptime Kuma (see ../monitoring) at:

TCP 21116 (hbbs heartbeat)
TCP 21117 (hbbr relay)

Notes

network_mode: host is intentional; do not add port mappings.
Data directory ./data holds the keypair; back it up (see 17-BACKUP-RECOVERY).
Never commit the private key (data/id_ed25519) to Git.

1.8 KiB Raw Blame History