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]>
1.5 KiB
Knowledge Check: Linux Troubleshooting
1. What's the difference between OBSERVE and GATHER EVIDENCE?
Answer: OBSERVE names the specific symptom (what actually failed, precisely). GATHER EVIDENCE collects the raw facts (logs, config, process/port state) needed to understand WHY, before guessing at a cause.
2. Why does FORM HYPOTHESIS come before TEST, rather than jumping straight to REPAIR?
Answer: A hypothesis is a specific, falsifiable guess at the cause based on evidence already gathered — testing it BEFORE repairing confirms you're about to fix the right thing, rather than making a change that might not address the actual cause at all.
3. A fix works, but the same failure happens again a week later. Which framework step was most likely skipped?
Answer: PREVENT RECURRENCE — the immediate symptom was resolved, but whatever allowed the underlying cause to occur in the first place was never addressed.
4. Why is "repair the minimal confirmed cause" better than "try several things until it works"?
Answer: A minimal, confirmed repair means you actually know what fixed it and can prevent recurrence deliberately. Trying multiple things at once means even success leaves you unable to say WHICH change mattered — and unable to reliably prevent the same failure next time.
Instructor Notes
Facilitation: Question 3 is a good real-world check-in — ask if anyone has a personal example of a fix that didn't actually stick.
Approximate timing: 5 minutes.