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,74 @@
+# Linux Network Inspection
+
+## Every command below is really a question
+
+Module 3 gave you the model. This module gives you the commands — but treat each one as
+ANSWERING a specific question, not as syntax to memorize.
+
+## "What addresses does this machine have?" — `ip addr`
+
+```
+$ ip -4 addr show eth0
+inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
+```
+
+This machine's IPv4 address is `172.17.0.2`, on a `/16` subnet.
+
+## "Where will this machine send traffic?" — `ip route`
+
+```
+$ ip route
+default via 172.17.0.1 dev eth0
+172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
+```
+
+The second line says: anything in `172.17.0.0/16` is reachable directly. The first line (the
+`default` route) says: everything else goes through `172.17.0.1` — the default gateway from
+Module 3, now a real line in a real table.
+
+## "What TCP ports are listening?" — `ss -lnt`
+
+```
+$ ss -lnt
+LISTEN  0  511  0.0.0.0:80  0.0.0.0:*
+```
+
+Something is listening on port 80, on every interface (`0.0.0.0` as a BIND address, exactly the
+convention Module 3 flagged). `ss` replaced the older `netstat` on modern Linux — same idea.
+
+## "What does DNS say this name resolves to?" — `getent hosts` / `dig`
+
+```
+$ getent hosts example.test
+10.0.0.5  example.test
+```
+
+`getent hosts` checks the same resolution path the rest of the system uses (local `/etc/hosts`
+entries first, then DNS) — a reliable first choice. `dig <name>` queries DNS directly and shows
+more detail, useful once you specifically suspect a real DNS server issue rather than a local
+override.
+
+## "Can the application actually respond?" — `curl`
+
+```
+$ curl -sf http://localhost:80/ -o /dev/null -w '%{http_code}\n'
+200
+```
+
+Everything before this point (address, route, port, DNS) can be perfect, and the APPLICATION
+itself can still be broken — `curl` is the only one of these tools that actually tests the full
+chain end to end, including the application's own response.
+
+## Instructor Notes
+
+**Lesson goal:** Convert Module 3's mental model into muscle-memory commands, each explicitly
+framed as answering one specific diagnostic question.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** treating all five commands as redundant ways to "check
+the network" — reinforce that each answers a DIFFERENT layer's question, and a real diagnosis
+usually needs more than one.
+
+**Demo idea:** run all five in sequence against this Lab's own nginx, narrating which Module 3
+layer each one answers.
@@ -0,0 +1,56 @@
+# Demonstration: The Same Five Questions, Answered Live
+
+## OBSERVE
+
+```
+$ ip -4 addr show eth0
+inet 172.17.0.2/16 ...
+```
+
+"What address do I have?" — answered.
+
+## HYPOTHESIS
+
+Predict what `ip route` will show before running it — specifically, predict whether there will
+be a `default` line.
+
+## INSPECT
+
+```
+$ ip route
+default via 172.17.0.1 dev eth0
+172.17.0.0/16 dev eth0 ...
+```
+
+Confirmed — a `default` route exists, meaning traffic to anywhere outside `172.17.0.0/16` has
+somewhere to go.
+
+## CHANGE
+
+```
+$ ss -lnt
+LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
+```
+
+"What's listening?" — port 80, confirmed.
+
+## VERIFY
+
+```
+$ curl -sf http://localhost/ -o /dev/null -w '%{http_code}\n'
+200
+```
+
+The full chain, verified end to end with real evidence at each layer — not "the network seems
+fine," but five specific, falsifiable answers.
+
+## Instructor Notes
+
+**Demo goal:** Chain all five commands together as ONE continuous diagnostic narrative, not
+five disconnected syntax examples.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** running `curl` first and stopping at "it worked" without ever
+having separately confirmed address/route/port — fine when things work, but the WRONG habit for
+when they don't (Module 5's Lab requires the full sequence).
@@ -0,0 +1,39 @@
+# Knowledge Check: Linux Network Inspection
+
+---
+
+**1. Which command answers "what TCP ports are listening on this machine"?**
+
+*Answer:* `ss -lnt`.
+
+---
+
+**2. Which command answers "where will this machine send traffic that isn't local"?**
+
+*Answer:* `ip route` — specifically, the `default` line in its output.
+
+---
+
+**3. Why is `curl` the only tool in this module that can confirm the APPLICATION itself is
+working, not just the network path to it?**
+
+*Answer:* Address, route, port, and DNS can all be perfectly correct while the application
+behind them still returns an error or wrong content — `curl` is the only one of these tools that
+actually completes an HTTP request and inspects the real response.
+
+---
+
+**4. `getent hosts` and `dig` both resolve names. When would you reach for `dig` specifically
+instead of `getent hosts`?**
+
+*Answer:* When you specifically suspect a DNS server issue and want to query DNS directly with
+more detail — `getent hosts` checks the same path the rest of the system uses (including local
+`/etc/hosts` overrides first), which is usually the right first choice, but doesn't show you as
+much about what the actual DNS server itself said.
+
+## Instructor Notes
+
+**Facilitation:** Question 3 reinforces Module 3's "layers can each independently succeed or
+fail" idea with a very concrete example.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,28 @@
+# Guided Exercise: Which Command Answers This Question?
+
+This is a paper exercise — commit to an answer before checking it in the Lab.
+
+## Your task
+
+For each question, name the ONE command you'd reach for first:
+
+1. "Does this machine have a working IP address at all?"
+2. "Is anything listening on port 8080 right now?"
+3. "Does `payments.internal` resolve to an address?"
+4. "Is the web server actually returning a valid response, not just accepting connections?"
+5. "Where does traffic to an address outside my local subnet actually go?"
+
+## A worked shape to check yourself against
+
+1. `ip -4 addr show`
+2. `ss -lnt | grep 8080`
+3. `getent hosts payments.internal`
+4. `curl -sf http://.../ -o /dev/null -w '%{http_code}'`
+5. `ip route`
+
+## Instructor Notes
+
+**Facilitation:** Have students justify WHY their chosen command answers the specific question
+asked, not just that it's "a networking command" — the goal is precision, not familiarity.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,25 @@
+# Reflection: Five Commands, Five Answers, One Diagnosis
+
+## Reflection questions
+
+1. Which of these five commands did you already know before this module? Which was
+   genuinely new?
+2. You now have a real toolkit for Module 3's "where is the failure" question. What's still
+   missing before you'd feel fully confident diagnosing a real production networking issue?
+
+## Real Ops takeaway
+
+**Five specific commands, each answering one specific question, beat one vague instinct that
+"something's wrong with the network."** This is the exact toolkit real engineers reach for
+first, in this order, when handed an unfamiliar connectivity problem. Module 5 puts all five
+into one continuous diagnostic story; Module 6 formalizes the discipline around using them.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2's honest answer is usually
+"experience with real, varied failures" — a good moment to set expectations that fluency
+compounds with practice, not from one module.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.