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]>
33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# Guided Exercise: Plan Your Inspection Before You Type Anything
|
|
|
|
This is a paper exercise — commit to a plan before running commands in the Lab.
|
|
|
|
## Your task
|
|
|
|
You're told "the payments service seems slow." Before touching a keyboard, write down, in
|
|
order, which of these five questions you'd check FIRST, SECOND, and so on, and the one command
|
|
you'd use for each:
|
|
|
|
- Is it running at all?
|
|
- Is it listening on its expected port?
|
|
- What does its configuration say?
|
|
- What do its recent logs say?
|
|
- Has anything changed recently?
|
|
|
|
## A worked shape to check yourself against
|
|
|
|
A reasonable order: (1) is it running — `pgrep`/`ps`; (2) is it listening — `ss -lnt`; (3) recent
|
|
logs — `tail -n 50 <logfile>` (recent activity is usually more informative than config for a
|
|
sudden "slow" complaint); (4) configuration — only if logs point at a config-driven cause; (5)
|
|
recent changes — depends on context (deployment history, `ls -la` timestamps on config files).
|
|
There's no single correct order, but "running, then listening, then logs" before jumping to
|
|
config is a defensible default — you're checking the cheapest, fastest-answering questions
|
|
first.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** There's genuine room for disagreement on ordering here — the value is in
|
|
students defending their reasoning, not converging on one "correct" sequence.
|
|
|
|
**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
|