From 1ce1c3d4e080cde14e2cbc714a61008f67c3f03b Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 11 Sep 2026 00:11:22 +0200 Subject: [PATCH] Lab installation: a path out, and why the daemon having one is not enough MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A container runtime on the same workstation sets the kernel's forwarding policy to drop, and the virtualisation daemon's own accept rules do not override it — both are consulted and a drop anywhere is the answer. The machines then get addresses and resolve names, because the daemon's resolver is on the bridge, and discard every packet to anything real. The sharpest 'available is not adequate' yet: nothing is misconfigured, nothing logs, and it presents as every image pull hanging. A workstation that runs containers is the ordinary case, so it is a prerequisite — verified by reaching something, never by reading a setting. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF --- 03-DESIGN/01-to-be/04-lab-installation.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/03-DESIGN/01-to-be/04-lab-installation.md b/03-DESIGN/01-to-be/04-lab-installation.md index c1bd0cd..5c4944e 100644 --- a/03-DESIGN/01-to-be/04-lab-installation.md +++ b/03-DESIGN/01-to-be/04-lab-installation.md @@ -2,7 +2,7 @@ layer: to-be status: designed code: [mesh-lab] -updated: 2026-08-24 +updated: 2026-09-11 decisions: - 02-DECISIONS/0029-the-labs-first-scenario-has-no-pipeline.md - 02-DECISIONS/0008-a-failed-step-fails-the-job.md @@ -101,7 +101,22 @@ In order, on a machine with nothing: existed. Observed directly: a shell whose process tree predated the grant could not reach the daemon while a fresh lookup showed the membership present. The bootstrap has to say so, or the first thing a person meets is a permission error that looks like a broken install. -5. **Verification**, as above, before anything is raised. +5. **A path out to the internet for the machines that need one.** A scenario's own segments are + isolated on purpose, but a machine that fetches what it starts from is attached to an uplink + the daemon translates. That is the daemon's business and it does it — and then a **container + runtime on the same workstation sets the kernel's forwarding policy to drop**, which the + daemon's own accept rules do not override, because both are consulted and a drop anywhere is + the answer. + + The result is the sharpest instance of *available is not adequate* yet: the machines get + addresses, they resolve names — the daemon's resolver is on the bridge, so that half works — + and every packet to anything real is discarded. Nothing is misconfigured, nothing logs, and + the failure presents as *every image pull hangs*. A workstation that runs containers is the + ordinary case, so this is a prerequisite rather than a quirk: forwarding must be permitted for + the lab's own bridges, and it must be **verified by reaching something**, never by reading a + setting. + +6. **Verification**, as above, before anything is raised. ## Open