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]>
40 lines
1.3 KiB
Markdown
40 lines
1.3 KiB
Markdown
# Knowledge Check: Linux Network Inspection
|
|
|
|
---
|
|
|
|
**1. Which command answers "what TCP ports are listening on this machine"?**
|
|
|
|
*Answer:* `ss -lnt`.
|
|
|
|
---
|
|
|
|
**2. Which command answers "where will this machine send traffic that isn't local"?**
|
|
|
|
*Answer:* `ip route` — specifically, the `default` line in its output.
|
|
|
|
---
|
|
|
|
**3. Why is `curl` the only tool in this module that can confirm the APPLICATION itself is
|
|
working, not just the network path to it?**
|
|
|
|
*Answer:* Address, route, port, and DNS can all be perfectly correct while the application
|
|
behind them still returns an error or wrong content — `curl` is the only one of these tools that
|
|
actually completes an HTTP request and inspects the real response.
|
|
|
|
---
|
|
|
|
**4. `getent hosts` and `dig` both resolve names. When would you reach for `dig` specifically
|
|
instead of `getent hosts`?**
|
|
|
|
*Answer:* When you specifically suspect a DNS server issue and want to query DNS directly with
|
|
more detail — `getent hosts` checks the same path the rest of the system uses (including local
|
|
`/etc/hosts` overrides first), which is usually the right first choice, but doesn't show you as
|
|
much about what the actual DNS server itself said.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 3 reinforces Module 3's "layers can each independently succeed or
|
|
fail" idea with a very concrete example.
|
|
|
|
**Approximate timing:** 5 minutes.
|