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]>
54 lines
1.4 KiB
Markdown
54 lines
1.4 KiB
Markdown
# Demonstration: Two Different Questions, Two Different Commands
|
|
|
|
## OBSERVE
|
|
|
|
```
|
|
$ df -h /
|
|
Filesystem Size Used Avail Use% Mounted on
|
|
overlay 937G 199G 691G 23% /
|
|
```
|
|
|
|
The root filesystem overall: 23% used, plenty free.
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: does this tell you anything about which specific directory is using the most space?
|
|
|
|
## INSPECT
|
|
|
|
```
|
|
$ du -sh /var/log/* 2>/dev/null
|
|
1.2M /var/log/nginx
|
|
850K /var/log/k3s.log
|
|
```
|
|
|
|
No — `df` only ever answers "how full is this filesystem overall." Finding a SPECIFIC large
|
|
consumer requires `du`, pointed at the directories you suspect.
|
|
|
|
## CHANGE
|
|
|
|
Narrow further into a single suspicious directory:
|
|
|
|
```
|
|
$ du -sh /var/log/nginx/*
|
|
600K /var/log/nginx/access.log
|
|
600K /var/log/nginx/error.log
|
|
```
|
|
|
|
## VERIFY
|
|
|
|
You now know both the overall filesystem picture (`df`) AND exactly which files are contributing
|
|
to it (`du`, narrowed progressively) — two genuinely different tools for two genuinely different
|
|
questions, not interchangeable.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Make the df/du distinction concrete by actually needing BOTH to answer a
|
|
realistic "what's using my disk" question.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** running `du -sh /` directly (extremely slow on a large
|
|
filesystem, since it recurses everything) instead of narrowing progressively into suspected
|
|
directories first.
|