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.3 KiB
Knowledge Check: Linux System Administration
1. What are the five questions this module opened with?
Answer: What is running? Who started it? Where is its configuration? Where are its logs? How do I verify its state?
2. Why doesn't this Lab environment have systemctl?
Answer: This Lab's container doesn't run systemd as PID 1 — its boot script starts k3s directly instead, the same way most containers don't run a full init system. The concepts (inspecting a running service's process/config/logs/state) are the same regardless of which supervisor manages it.
3. A process exists (pgrep finds a PID) but the service seems unreachable. What's the next
thing to check?
Answer: Whether it's actually listening on the expected port (ss -lnt) — a running process
and a reachable service are two separate facts; the process could have started but failed to
bind its port.
4. Where does a well-behaved Linux service typically write what it's doing?
Answer: A log file, usually under /var/log/.
Instructor Notes
Facilitation: Question 2 is worth confirming explicitly if any student has prior systemd experience — set the expectation before the Lab, not after a confusing error.
Approximate timing: 5 minutes.