Issue 194 resolved: the fixed host forgot its former archive on all four machines

2026-10-02 11:31:29 +02:00
3 changed files with 9 additions and 54 deletions
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-02
 located-in: [mesh-host internal/apply (removeOrphan: a former target of a kind with no removal was fatal), mesh-host internal/store (Record keeps a former target for every kind, the host's own archive included)]
-fixed-by:
+fixed-by: mesh-host 65 — a former target of a kind the host cannot remove is left in place, said and forgotten; a dropped archive still refuses
 amended-design:
 ---
@@ -62,3 +62,10 @@ because the alternative was four machines that could apply nothing.
 - Is there a bed that replaces a host under the current rules before the live mesh does
  (the proof row of [ADR 0141](../../02-DECISIONS/0141-the-host-delivers-its-own-successor.md) was
  a single crossover, before former targets existed)?
 ## Resolved, 2026-10-02
 mesh-host 65, merged 07:35Z. Recovered as the record above says: the operator dropped the one
 `@former:` entry from each machine's host record and pushed; the fixed host then ran on all four and
 its first apply said `forgotten mesh-host.next@former:… a former target left in place` and applied the
 rest. The open questions stand as questions for the host's own versions, not as faults.
@@ -1,38 +0,0 @@
 ---
 status: located
 opened: 2026-10-02
 located-in: [mesh-host internal/outward (Links reported only the links carrying a default route)]
 fixed-by:
 amended-design: []
 ---
 # 197 — A physical link that is down is not filtered when it comes up
 ## What was observed
 A sweep of every machine's filter on 2026-10-02. A laptop-class machine connected by its radio has a
 wired port that was unplugged. Its filter guarded the radio and the tunnel, and accepted everything
 arriving on any other link:
 ```
 iifname != { "mesh0", "<radio>" } accept
 ```
 The wired port was not in the list. Plugged in, everything arriving on it would have been accepted,
 every port of the machine open to whatever network the cable reached. That would last until the
 machine reported again and was pushed a new filter.
 ## Why it matters
 **The filter's one rule about links fails open.** [ADR 0140](../../02-DECISIONS/0140-the-filter-constrains-what-arrives-from-outside.md)
 has the filter constrain what arrives from outside, and has the machine say which links face outside.
 Everything not named is treated as the machine's own, its containers and bridges. So a link the machine
 fails to name is not filtered at all. The host named only the links carrying a default route at the
 moment it reported. A cable plugged in later is the ordinary case for a laptop. A second wired network
 that never carries the default route, such as a direct link to a storage box, is never named at all.
 ## Open questions
 - A virtual link that faces outside (a VPN client's interface, a USB tether that appears as a virtual
  device) has no physical device behind it. It is named only while it carries the default route. Is
  that enough?
@@ -1,14 +0,0 @@
 # Diagnosis
 *2026-10-02.*
 **Located in `mesh-host` `internal/outward`.** `Links` read the kernel's routing tables and returned the
 interfaces carrying a default route. An unplugged port carries none, so it was never reported, and the
 controller rendered the filter around the links it was given.
 **The fix.** A link faces outside if it carries a default route **or** has a physical device behind it.
 The kernel lists every interface under `/sys/class/net`, with a `device` entry for one backed by
 hardware. A bridge, a veth, the tunnel and the loopback have none, so they stay the machine's own. The
 wired port is now reported up or down, and the filter guards it before anything is plugged in. Tested
 with a radio carrying the default route and an unplugged wired port beside a bridge, a veth, the docker
 bridge, the tunnel and the loopback: the two physical links are reported, nothing else.