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]>
57 lines
1.8 KiB
Markdown
57 lines
1.8 KiB
Markdown
# Demonstration: Three Failures That Sound Similar But Aren't
|
|
|
|
## OBSERVE
|
|
|
|
All three of these LOOK like "it didn't work" — but each one rules out and rules in completely
|
|
different layers.
|
|
|
|
```
|
|
$ curl http://this-name-does-not-resolve.invalid/
|
|
curl: (6) Could not resolve host: this-name-does-not-resolve.invalid
|
|
```
|
|
|
|
## HYPOTHESIS
|
|
|
|
Which layer does THIS failure point at — DNS, routing, the port, or the application itself?
|
|
|
|
## INSPECT
|
|
|
|
"Could not resolve host" happens BEFORE any network connection is even attempted — it's purely a
|
|
DNS failure. No IP was ever found to connect to.
|
|
|
|
## CHANGE
|
|
|
|
Now a different failure, against a name that DOES resolve:
|
|
|
|
```
|
|
$ curl http://localhost:9999/
|
|
curl: (7) Failed to connect to localhost port 9999: Connection refused
|
|
```
|
|
|
|
DNS/name resolution already succeeded here (`localhost` always resolves). "Connection refused"
|
|
means a TCP packet reached the destination and was ACTIVELY rejected — almost always because
|
|
nothing is listening on that port.
|
|
|
|
## VERIFY
|
|
|
|
A third signature, distinct from both:
|
|
|
|
```
|
|
$ curl http://10.255.255.1:80/
|
|
curl: (28) Failed to connect to 10.255.255.1 port 80: Connection timed out
|
|
```
|
|
|
|
No response at all, not even a rejection — usually means the destination is unreachable
|
|
(no route, or blocked silently), not that something is running but declining you.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Get students to viscerally distinguish these three error MESSAGES as three
|
|
different diagnostic starting points, not interchangeable "it's broken" signals.
|
|
|
|
**Approximate timing:** 10 minutes live.
|
|
|
|
**Common mistake to watch for:** treating every connection failure as "the network is down" —
|
|
each of these three messages should immediately narrow which layer to investigate next, per
|
|
Module 5's troubleshooting exercise.
|