novox/hq
3
0
Fork 0
Code Issues Pull Requests 5 Releases Wiki Activity

Merge pull request 'Issue 129: three machines of four trust the mesh, not one' (#201) from issue/129-three-machines-not-one into main

Browse Source
This commit was merged in pull request #201.
This commit is contained in:
jschoubben
2026-09-30 00:30:30 +00:00
parent 5036b927b9 d009c3efef
commit 601d004fcb
2 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md
+3 -1
View File
@@ -139,7 +139,9 @@ written this way until the bed runs.
> Run on the live mesh because that is where a change is verified now
> ([ADR 0149](0149-the-live-mesh-is-the-test-bed.md)), and the bed still cannot raise a foundation. The
> evidence is [issue 129](../04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/02-resolution.md).
> It ran on **one** machine; three others still trust nothing of the mesh's.
> Extended the same day to every converged machine — `novox`, `g14` and `shanks` each hold the anchor
> and verify with a plain client. `ace` is excluded on purpose: it is adopted, so a module assigned
> there is held rather than run, which is right and is not trust.
## Consequences
04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/02-resolution.md
+23 -5
View File
@@ -73,11 +73,29 @@ in the module says this; it is the host's removal order that makes the module's
## What this leaves
- **One machine, not four.** `novox`, `g14` and `ace` still trust nothing of the mesh's. The report's
reasoning — that being on the private network is what makes a machine one that speaks to the mesh's
names — argues for all of them, and ADR 0147 is written for a module assigned per machine rather than
a fact carried to every machine on the network. Whether it should instead arrive the way the roster
and the registry trust do is a real question and is not this record's to answer.
- **Three machines of four** *(extended the same day, after the first was proven)*. `ca-trust` is now
assigned to every converged machine, and each verifies with a plain client:
```
novox mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
g14 mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
shanks mesh CA in trust store: 1 https://git.<node>.internal/ -> 200
```
Before, each of the two that had not been assigned it answered
`curl: (60) … unable to get local issuer certificate (20)` and held no entry for the mesh.
**`ace` is deliberately not among them.** It is the adopted machine, still carrying the
predecessor's resolver and filter, and it is not converged until the network and module-assignment
work is settled. Assigning a module to it would hold rather than run
([ADR 0100](../../02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md)), which is
correct and is not the same as trusting anything.
- **It arrives per assignment, which is a shape worth questioning.** The report's reasoning — that
being on the private network is what makes a machine one that speaks to the mesh's names — argues
for a fact carried to every machine on the network, the way the roster and the registry trust are.
ADR 0147 chose a module assigned per machine, and this record does not reopen it; the cost is that
a machine joining the mesh trusts nothing until somebody remembers a second command.
- **`service-manager` reports `degraded` on this machine** and the module ran anyway. Worth knowing that
the capability gate passes on a degraded service manager, since a module whose whole delivery is a
unit is the kind that would be worst served by one.