Files
rootnode-academy/content/root/root-02-linux-administration-networking/m04-linux-network-inspection/02-demonstration-five-commands-five-questions.md
T
ced4568andClaude Sonnet 5 e007bcf000 feat(root02): author Linux Administration & Networking
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]>
2026-08-26 17:07:46 -05:00

57 lines
1.3 KiB
Markdown

# Demonstration: The Same Five Questions, Answered Live
## OBSERVE
```
$ ip -4 addr show eth0
inet 172.17.0.2/16 ...
```
"What address do I have?" — answered.
## HYPOTHESIS
Predict what `ip route` will show before running it — specifically, predict whether there will
be a `default` line.
## INSPECT
```
$ ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 ...
```
Confirmed — a `default` route exists, meaning traffic to anywhere outside `172.17.0.0/16` has
somewhere to go.
## CHANGE
```
$ ss -lnt
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
```
"What's listening?" — port 80, confirmed.
## VERIFY
```
$ curl -sf http://localhost/ -o /dev/null -w '%{http_code}\n'
200
```
The full chain, verified end to end with real evidence at each layer — not "the network seems
fine," but five specific, falsifiable answers.
## Instructor Notes
**Demo goal:** Chain all five commands together as ONE continuous diagnostic narrative, not
five disconnected syntax examples.
**Approximate timing:** 8 minutes live.
**Common mistake to watch for:** running `curl` first and stopping at "it worked" without ever
having separately confirmed address/route/port — fine when things work, but the WRONG habit for
when they don't (Module 5's Lab requires the full sequence).