0164: a setting names the file it lands in (issue 198's leak between one module's files); 190 notes the fourth machine now has the resolver

2026-10-02 12:23:28 +02:00
parent 967c793eaa
commit 17ca9a262b
2 changed files with 18 additions and 0 deletions
@@ -33,6 +33,13 @@ The machine without the resolver module shows the other half. Its runtime still
 resolver and `live-restore` off, because the only module that sets them is a DNS server. A machine
 gets a correct container runtime only as a side effect of being given a resolver.

+> **Later the same day, 2026-10-02.** The resolver module and its sibling for the resolver file were
+> assigned to the fourth machine ([issue 198](../198-the-lans-dns-server-ran-outside-the-mesh-and-its-filter-closed-it/00-report.md)),
+> so all four now have the resolver writing into the runtime's file, and the predecessor's
+> `live-restore: false` there is gone. The same work made the runtime's file, as the resolver declares
+> it, take no settings: a setting meant for the resolver's own configuration had reached it. The
+> collision and the ownership question above are unchanged.
+
 ## Why this is here

 The operator ruled it a defect, not a design: **a module does not write another software's