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]>
2.5 KiB
Linux Network Inspection
Every command below is really a question
Module 3 gave you the model. This module gives you the commands — but treat each one as ANSWERING a specific question, not as syntax to memorize.
"What addresses does this machine have?" — ip addr
$ ip -4 addr show eth0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
This machine's IPv4 address is 172.17.0.2, on a /16 subnet.
"Where will this machine send traffic?" — ip route
$ ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
The second line says: anything in 172.17.0.0/16 is reachable directly. The first line (the
default route) says: everything else goes through 172.17.0.1 — the default gateway from
Module 3, now a real line in a real table.
"What TCP ports are listening?" — ss -lnt
$ ss -lnt
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
Something is listening on port 80, on every interface (0.0.0.0 as a BIND address, exactly the
convention Module 3 flagged). ss replaced the older netstat on modern Linux — same idea.
"What does DNS say this name resolves to?" — getent hosts / dig
$ getent hosts example.test
10.0.0.5 example.test
getent hosts checks the same resolution path the rest of the system uses (local /etc/hosts
entries first, then DNS) — a reliable first choice. dig <name> queries DNS directly and shows
more detail, useful once you specifically suspect a real DNS server issue rather than a local
override.
"Can the application actually respond?" — curl
$ curl -sf http://localhost:80/ -o /dev/null -w '%{http_code}\n'
200
Everything before this point (address, route, port, DNS) can be perfect, and the APPLICATION
itself can still be broken — curl is the only one of these tools that actually tests the full
chain end to end, including the application's own response.
Instructor Notes
Lesson goal: Convert Module 3's mental model into muscle-memory commands, each explicitly framed as answering one specific diagnostic question.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: treating all five commands as redundant ways to "check the network" — reinforce that each answers a DIFFERENT layer's question, and a real diagnosis usually needs more than one.
Demo idea: run all five in sequence against this Lab's own nginx, narrating which Module 3 layer each one answers.