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]>
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Reflection: One Model, Reused Everywhere From Here On
|
|
|
|
## Reflection questions
|
|
|
|
1. Before this module, how would you have described "the network is broken" to a colleague?
|
|
How would you describe it now, more precisely?
|
|
2. This module deliberately avoided subnet math. Do you feel that cost you anything real, given
|
|
the module's actual goal (reasoning about WHERE a failure is, not calculating addresses)?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**Every networking topic for the rest of ROOT_ is this same chain, viewed from a different
|
|
altitude.** A container's published port is still "port," a Kubernetes Service is still "how do
|
|
I reach the right destination via a stable address," Ingress is still "routing decisions," and
|
|
NetworkPolicy is still "which subnets/ports are allowed to reach which." You are not about to
|
|
learn a new mental model in ROOT 04 or ROOT 05 — you're about to see this SAME one applied one
|
|
layer up, repeatedly. That's why this module got extra weight: the investment compounds.
|
|
|
|
This module is complete. Continue to Module 4, where these ideas become real commands.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** question 1 is worth collecting several answers
|
|
before and after — the change in precision is itself the evidence this module worked.
|
|
|
|
**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
|
|
|
|
**Milestone note:** this is the "critical module" this course was built around — consider
|
|
confirming as a group that everyone can walk the full chain (host→interface→IP→subnet→gateway→
|
|
routing→DNS→port→TCP/UDP→application) from memory before moving on.
|