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]>
34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# Guided Exercise: Diagnose From the Symptom Alone
|
|
|
|
This is a paper exercise — reason through each case using only the mental model, before any
|
|
hands-on Lab work.
|
|
|
|
## Your task
|
|
|
|
For each symptom, name which layer(s) it rules OUT, and which remain genuine suspects:
|
|
|
|
1. `ping 8.8.8.8` succeeds, but `curl https://example.com` fails with "Could not resolve host."
|
|
2. `dig example.com` returns a correct-looking IP address, but `curl https://example.com` times
|
|
out with no response at all.
|
|
3. `curl http://internal-service:8080/` returns "Connection refused," but
|
|
`curl http://internal-service:9090/` (a different port, same host) succeeds.
|
|
|
|
## A worked shape to check yourself against
|
|
|
|
1. Rules out: basic connectivity/routing to the internet (ping succeeded). Remaining suspect:
|
|
DNS specifically — something is preventing name resolution even though raw IP connectivity
|
|
works.
|
|
2. Rules out: DNS (resolution clearly succeeded). Remaining suspects: routing/reachability to
|
|
that specific IP, or a firewall silently dropping the connection — "no response at all" is the
|
|
timeout signature, not the "actively rejected" signature.
|
|
3. Rules out: DNS AND general reachability to that host (port 9090 worked). Remaining suspect:
|
|
narrowed all the way down to "nothing is listening on port 8080 specifically" — the most
|
|
precisely isolated diagnosis of the three.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Item 3 is the strongest example of "isolate one variable" reasoning (same
|
|
host, different port) — worth highlighting explicitly as the gold-standard diagnostic pattern.
|
|
|
|
**Approximate timing:** 10-12 minutes live discussion; 8 minutes self-paced.
|