feat(root02): author Linux Administration & Networking

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]>
2026-08-26 17:07:46 -05:00
parent b6516a74db
commit e007bcf000
39 changed files with 1752 additions and 0 deletions
@@ -0,0 +1,58 @@
+# 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:
+
+1. **DNS failure** — the name never resolved to an IP at all (`curl`'s "Could not resolve
+   host").
+2. **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).
+3. **TCP succeeded, but the application never responds correctly** — a connection was
+   established, but the server hangs, drops the connection, or the request never completes.
+4. **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.)
@@ -0,0 +1,57 @@
+# Demonstration: Walking the Complete Path, Layer by Layer
+
+## OBSERVE
+
+```
+$ getent hosts lab-internal.test
+10.99.99.42  lab-internal.test
+```
+
+DNS: succeeded.
+
+## HYPOTHESIS
+
+Predict: if the next step (TCP connection) fails, what would that specific error look like?
+
+## INSPECT
+
+```
+$ curl http://lab-internal.test:9091/
+curl: (7) Failed to connect to lab-internal.test port 9091: Connection refused
+```
+
+"Connection refused" — DNS already succeeded (ruled out), the failure is specifically that
+nothing is listening on port 9091 at that address.
+
+## CHANGE
+
+Find what IS actually listening, on the correct address:
+
+```
+$ ss -lnt | grep LISTEN
+LISTEN 0 5 0.0.0.0:9095 0.0.0.0:*
+```
+
+The real service is on 9095, not 9091 — a configuration/expectation mismatch, not a DNS or
+routing problem.
+
+## VERIFY
+
+```
+$ curl http://lab-internal.test:9095/
+app running
+```
+
+The full path, once pointed at the CORRECT layer that was actually broken (the port, not DNS),
+succeeds end to end.
+
+## Instructor Notes
+
+**Demo goal:** Show that a real, plausible-sounding complaint ("DNS must be broken") is
+disproven by evidence in seconds, and the REAL cause is one layer downstream.
+
+**Approximate timing:** 10 minutes live.
+
+**Common mistake to watch for:** jumping straight to "restart everything" instead of walking
+the chain layer by layer to find the SPECIFIC broken step — the whole point of this module's
+Lab is resisting that shortcut.
@@ -0,0 +1,40 @@
+# Knowledge Check: DNS and HTTP
+
+---
+
+**1. Name the four failure categories this module introduced.**
+
+*Answer:* DNS failure, routing/connection failure, TCP-succeeds-but-application-never-responds,
+and HTTP/application failure (a full response comes back but it's wrong).
+
+---
+
+**2. A request returns HTTP 500. What does that tell you about DNS and TCP connectivity?**
+
+*Answer:* Both worked completely — a 500 means a full HTTP response was received, so the failure
+is purely inside the application's own logic, not the network path to reach it.
+
+---
+
+**3. Why is "connection refused" a MORE specific diagnosis than "timed out"?**
+
+*Answer:* "Refused" means a packet reached the destination and was actively rejected (almost
+always: nothing listening on that port) — you know the destination is reachable. "Timed out"
+means no response at all, which could mean unreachable, no route, or silently blocked —
+genuinely less specific.
+
+---
+
+**4. A teammate says "DNS must be broken" because a request fails. What should you check
+BEFORE agreeing?**
+
+*Answer:* Whether the name actually resolves at all (`getent hosts` or `dig`) — many failures
+that "feel like DNS" are actually one layer downstream (routing, port, or application), and
+DNS itself may be working perfectly.
+
+## Instructor Notes
+
+**Facilitation:** Question 4 mirrors this module's own Lab almost exactly — a good moment to
+preview it if not already started.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,32 @@
+# Guided Exercise: Categorize the Failure Before You Fix It
+
+This is a paper exercise — commit to a category before checking it in the Lab.
+
+## Your task
+
+For each symptom, name which of the four failure categories (DNS / routing-connection /
+TCP-hangs / HTTP-application) it belongs to:
+
+1. `curl: (6) Could not resolve host: api.internal`
+2. `curl: (7) Failed to connect to api.internal port 443: Connection refused`
+3. A request eventually returns, but with HTTP 502 Bad Gateway
+4. A request just hangs for 30 seconds with no response, then finally times out
+
+## A worked shape to check yourself against
+
+1. DNS — the name never resolved.
+2. Routing/connection — DNS worked, but nothing accepted the connection on that port.
+3. HTTP/application — a full HTTP response came back (502 is a real, complete response), so
+   DNS/routing/TCP all worked; the failure is in the application layer (often a proxy unable to
+   reach ITS OWN backend, which is itself worth investigating further).
+4. TCP-hangs / ambiguous-timeout — this is the least specific signature; it could mean
+   unreachable, silently dropped by a firewall, or an application that accepted the connection
+   but never responds — worth narrowing further with `ss`/`ip route` before concluding.
+
+## Instructor Notes
+
+**Facilitation:** Item 3 (502) is a good one to slow down on — many students initially assume
+any 5xx code means "the network is broken," when it actually proves the OPPOSITE for every
+layer below the application.
+
+**Approximate timing:** 10-12 minutes live discussion; 8 minutes self-paced.
@@ -0,0 +1,26 @@
+# Reflection: You Fixed the Real Problem, Not the Suspected One
+
+## Reflection questions
+
+1. Before running any commands in this module's Lab, what would you have guessed was broken?
+   Was your guess right?
+2. Why does correctly categorizing a failure (DNS vs. routing vs. TCP vs. application) matter
+   more than just "trying things until something works"?
+
+## Real Ops takeaway
+
+**"DNS must be broken" is one of the most common wrong first guesses in real incident response
+— and disproving or confirming it takes seconds, not minutes.** The habit this module builds —
+categorize the failure precisely before attempting a fix — is what separates a five-minute
+diagnosis from an hour of trying unrelated things. This exact reasoning, applied to Kubernetes
+Services/Ingress/DNS later, is one of the most valuable transferable skills in this entire
+program.
+
+This module is complete. Continue to the final module of this course.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 works well as a live poll before
+revealing the Lab's actual root cause — the gap between instinct and evidence is the lesson.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.