ced4568andClaude Sonnet 5
e007bcf000
Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37 activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per its "critical module" designation, with no lab by design — conceptual mastery via knowledge check and guided exercise, matching root-05-m00's own precedent. Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects the platform's own real nginx without touching it — a genuinely safe, real service-inspection target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/ verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection (ip/ss/getent/curl, each framed as answering one specific diagnostic question), linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed), and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested end-to-end via the real scenario-validation API, including negative tests confirming they fail when unsolved. Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.4 KiB
DNS and HTTP
The complete request path
Every time a browser or curl fetches a URL, it walks the entire Module 3 chain in order:
Application (curl / browser)
↓
DNS lookup — translate the name to an IP
↓
IP address obtained
↓
Routing — figure out the path to that IP
↓
TCP connection established — a three-way handshake, underneath curl
↓
HTTP request sent
↓
Server processes it
↓
HTTP response returned
Nothing here is new — this is Module 3's chain and Module 4's commands, just walked start to finish as ONE continuous story instead of five separate checks.
Four distinct failure categories, not one
Given this path, "it doesn't work" always decomposes into exactly one of four categories:
- DNS failure — the name never resolved to an IP at all (
curl's "Could not resolve host"). - Routing/connection failure — the IP was found, but no TCP connection could be established — either refused (something's there but nothing's listening) or timed out (no response at all, usually unreachable or silently blocked).
- TCP succeeded, but the application never responds correctly — a connection was established, but the server hangs, drops the connection, or the request never completes.
- HTTP/application failure — a full HTTP response comes back, but it's WRONG (a 500 error, a 404, unexpected content) — everything below the application layer worked fine.
These are genuinely different problems requiring genuinely different fixes — conflating them (treating a 404 the same as a DNS failure) wastes real diagnostic time.
Instructor Notes
Lesson goal: Make the four-category failure taxonomy explicit and distinct — this is the direct foundation for this module's diagnostic Lab and for Module 6's formal framework.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: treating an HTTP 500 error the same category as "the network is down" — a 500 means the ENTIRE network path worked; the failure is purely in the application's own logic.
Discussion question: "A request returns HTTP 404. Which of the four categories is that, and what does it rule out?" (Answer: category 4, application/HTTP — it rules out DNS, routing, AND TCP connectivity entirely, since a real HTTP response came back at all.)