33 lines
1.6 KiB
Markdown
33 lines
1.6 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-22
|
|
located-in: [mesh-controller internal/catalogue (facts)]
|
|
fixed-by: mesh-controller multiple-fixes (the facts take a name as the control plane keys it, internal or bare, and write each machine once); a unit test holds both keyings to the same files
|
|
---
|
|
|
|
# 079 — Every machine is named twice over in the hosts file and the resolver's zones
|
|
|
|
## Symptom
|
|
|
|
The hosts file the mesh writes on every machine, and the zones file it hands a resolver, name each
|
|
machine as `<machine>.internal.internal`, with the intended name `<machine>.internal` in the
|
|
hosts file's second column. Names still resolve on the machine itself, because the second column
|
|
matches, so nothing noticed. A resolver serving the zones answers for `*.<machine>.internal.internal`
|
|
and for nothing under `<machine>.internal`, so a service named under a machine does not resolve
|
|
from anywhere.
|
|
|
|
Found by running the large mesh bed end to end for the first time since the mesh's knowledge became
|
|
a fact a module asks for: its name test read the zones back. No smaller bed reads them.
|
|
|
|
## Why it matters beyond the instance
|
|
|
|
Two functions agreed on a contract nobody wrote down: the caller keyed the map by the internal name,
|
|
the facts appended the suffix to a bare one. Each was tested alone, with its own keying, and both
|
|
passed. A file the mesh writes and nothing reads back in a test is a file that can be wrong for
|
|
as long as it takes someone to look.
|
|
|
|
## What would close it
|
|
|
|
The facts take either keying and write each machine once, held by a test that feeds both. And a bed
|
|
reads the files back — the large mesh bed does now.
|