getting-started.sh leaves a new machine on the documentation subnet, and reports success #10

New issue

Closed

opened 2026-10-07 16:13:16 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 16:13:16 +01:00

getting-started.sh moves the template's guest addresses onto libvirt's default network by naming the three original machines' last octets in one regex, so a machine added to the template later keeps a 192.0.2.x address that libvirt's network cannot reach — and the step still reports success, because the other machines did move.

Primary goals:

Rewrite the deployment's own machine addresses, whatever they are — the set comes from the machine list, so adding a machine to the template needs no change here.
Touch nothing else on that subnet — the templates deliberately use documentation addresses for things that are not guests, and those must survive untouched.
Fail loudly if a machine is left behind — assert that no machine address remains on 192.0.2., naming the file and the leftover, so this class of miss cannot report success again.

Current state and specifics

The step is Guest addresses on libvirt's default network:

sed -i -E 's/"192\.0\.2\.(2|10|11)"/"192.168.122.\1"/' "${INVENTORY}/flake.nix" "${SECRETS}/identity.nix"

(2|10|11) is the last octet of nexus, allod-dev and privacy-1, the three machines the template had when the step was written. A machine at 192.0.2.12 does not match: after 192\.0\.2\. the regex needs 2, 10 or 11 followed immediately by a quote, and 12" satisfies none.

The miss is silent. The success message is gated on git status --porcelain being non-empty across both repositories, which it still is because the first three machines did change, so it prints moved to 192.168.122.0/24 while leaving a machine on a subnet new-vm reserves no leases on.

Widening the regex to any 192.0.2.<n> is not the fix, and is worse than the bug. The same documentation range is used on purpose for hosts that are not machines of the deployment: secrets/identity.nix carries example-build-cache at .40, example-backup-vps at .30, example-offsite-console at .31 and example-provider-support at .32, under a comment that reads "Never a machine of the deployment or the forge host", and inventory/flake.nix uses .20 inside a check fixture. Relocating those onto the local libvirt subnet turns deliberate examples into addresses that look like local guests, and an assertion that no 192.0.2. address survives would make that wrong rewrite mandatory.

The distinguishing key is not the address's shape but whether it belongs to a machine in the inventory. inventory/flake.nix's machines is the source of that set, and nexus must be included even though vmSpecsJson filters hypervisors out of scripts/vm-specs.json.

Scope

In: the rewrite step and its assertion. Out: the files the step edits — if a later machine fact lands outside allod/inventory and allod/secrets, adding that file belongs to whatever change introduces it.

Part of allod/strategy#65

`getting-started.sh` moves the template's guest addresses onto libvirt's default network by naming the three original machines' last octets in one regex, so a machine added to the template later keeps a `192.0.2.x` address that libvirt's network cannot reach — and the step still reports success, because the other machines did move. Primary goals: - **Rewrite the deployment's own machine addresses, whatever they are** — the set comes from the machine list, so adding a machine to the template needs no change here. - **Touch nothing else on that subnet** — the templates deliberately use documentation addresses for things that are *not* guests, and those must survive untouched. - **Fail loudly if a machine is left behind** — assert that no machine address remains on `192.0.2.`, naming the file and the leftover, so this class of miss cannot report success again. ### Current state and specifics The step is `Guest addresses on libvirt's default network`: sed -i -E 's/"192\.0\.2\.(2|10|11)"/"192.168.122.\1"/' "${INVENTORY}/flake.nix" "${SECRETS}/identity.nix" `(2|10|11)` is the last octet of `nexus`, `allod-dev` and `privacy-1`, the three machines the template had when the step was written. A machine at `192.0.2.12` does not match: after `192\.0\.2\.` the regex needs `2`, `10` or `11` followed immediately by a quote, and `12"` satisfies none. The miss is silent. The success message is gated on `git status --porcelain` being non-empty across both repositories, which it still is because the first three machines did change, so it prints `moved to 192.168.122.0/24` while leaving a machine on a subnet `new-vm` reserves no leases on. **Widening the regex to any `192.0.2.<n>` is not the fix, and is worse than the bug.** The same documentation range is used on purpose for hosts that are not machines of the deployment: `secrets/identity.nix` carries `example-build-cache` at `.40`, `example-backup-vps` at `.30`, `example-offsite-console` at `.31` and `example-provider-support` at `.32`, under a comment that reads "Never a machine of the deployment or the forge host", and `inventory/flake.nix` uses `.20` inside a check fixture. Relocating those onto the local libvirt subnet turns deliberate examples into addresses that look like local guests, and an assertion that no `192.0.2.` address survives would make that wrong rewrite mandatory. The distinguishing key is not the address's shape but whether it belongs to a machine in the inventory. `inventory/flake.nix`'s `machines` is the source of that set, and `nexus` must be included even though `vmSpecsJson` filters hypervisors out of `scripts/vm-specs.json`. ### Scope In: the rewrite step and its assertion. Out: the files the step edits — if a later machine fact lands outside `allod/inventory` and `allod/secrets`, adding that file belongs to whatever change introduces it. Part of allod/strategy#65

vnprc referenced this issue from a commit

2026-10-07 18:28:22 +01:00

getting-started.sh: rewrite the deployment's own machine addresses, not three named ones

allod-agent added the

landed?

label

2026-10-21 22:27:15 +01:00

allod-agent commented

2026-10-21 22:37:17 +01:00

Member

Landed on master by direct commit 4c67732 ("getting-started.sh: rewrite the deployment's own machine addresses, not three named ones"); closing on the owner's instruction.

Landed on master by direct commit 4c67732 ("getting-started.sh: rewrite the deployment's own machine addresses, not three named ones"); closing on the owner's instruction.

allod-agent closed this issue

2026-10-21 22:37:17 +01:00

allod-agent removed the

landed?

label

2026-10-21 23:32:46 +01:00