MAAS composed the machine, PXE-booted it, commissioned it, and DEPLOYED Ubuntu 24.04.4 onto it --
an LXD VM inside voffice1, inside vcloud, which is itself a KVM guest. NetBox 4.6.4 (Django 6.0.6)
runs on it and its API returns HTTP 200. The D-114 chain is complete in its final form.

FOUR FINDINGS. TWO ARE NOW GUARDED IN CODE.

1. MAAS-DISCOVERED SUBNETS HAVE NO GATEWAY (FIXED). MAAS discovers the compose subnet from lxdbr0's
   interface, and that discovery carries no gateway_ip. The first deploy produced a machine that
   LOOKED healthy -- it had an address and DNS even resolved (MAAS's bind9 is link-local) -- but had
   NO default route and NO egress. It only surfaces when the first apt install hangs.
   scripts/site-headend-install.sh now sets gateway_ip on the compose subnet; the harness asserts it
   (19/19). office1-netbox was released and REDEPLOYED to prove the fix rather than hand-patching a
   route onto the running box.

2. NETBOX 4.6 v2 TOKENS: THE WIRE FORMAT IS `nbt_<key>.<plaintext>`, NOT THE API's `token` FIELD.
   NetBox 4.6 hashes tokens: `key` is a 12-char PREFIX, plus `plaintext` and an hmac_digest.
   Authentication infers the version FROM A PREFIX (TOKEN_PREFIX = 'nbt_') and splits on '.'. So the
   57-char assembled form is what authenticates. POST /api/users/tokens/provision/ returns `key` and
   `token` as SEPARATE fields, and the `token` field alone is NOT usable -- present it raw and NetBox
   parses it as a legacy v1 token and returns 403 "Invalid v1 token", an error that names v1 while
   you are holding a v2 token. Anything scripted against this NetBox (including
   netbox/dc-dc-prefixes-import.py and any pynetbox client) must ASSEMBLE the token.
   Also: netbox-docker's SUPERUSER_API_TOKEN env is NOT honored on this version, and hand-building a
   Token row trips the DB's enforce_version_dependent_fields constraint. Call the interface; do not
   re-implement it -- the same lesson this repo already learned minting OPNsense API keys, which I
   proceeded to re-learn the hard way.

3. A WRONG HYPOTHESIS, RECORDED BECAUSE THE MISTAKE IS REUSABLE. When the token kept 403-ing I
   concluded that rotating SECRET_KEY after NetBox had initialised must have broken the token HMAC
   pepper, and I WIPED THE DATABASE (docker compose down -v) to re-init. That was WRONG -- the 403
   was purely the wire format above. The wipe was harmless because the DB was empty, but the
   reasoning was not: on a populated NetBox it would have been destructive. "Invalid v1 token" is a
   FORMAT error, not a crypto or key-rotation error. Read the auth code before reaching for a
   destructive reset.

4. netbox-docker ships a PUBLIC default SECRET_KEY (it is in the public repo) -- session-forgery
   material on any reachable instance. Rotated to a generated value. (SKIP_SUPERUSER=true is the
   shipped default, so no default admin/admin exists.)

All secrets (SECRET_KEY, admin password, API token) generated ON the VM, stored 0600 under
/root/netbox-secrets/, never printed into the session.

REACHABILITY CAVEAT, not solved: NetBox is on 10.10.1.201, behind voffice1's NAT. Reachable from
voffice1, NOT from office1-local or a workstation. Making it reachable needs a static route for
10.10.1.0/24 via 10.10.0.20 on the OPNsense edge -- a live edge change, deliberately NOT done
unilaterally.

NEXT: import the D-115 carve into this NetBox.

repo-lint 0 fail. tests/site-headend-install 19/19 PASS.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>