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.4 KiB
Markdown
57 lines
1.4 KiB
Markdown
# Demonstration: Answering the Five Questions For Real
|
|
|
|
## OBSERVE
|
|
|
|
This Lab's own terminal is served by a real running service: nginx.
|
|
|
|
```
|
|
$ pgrep -x nginx
|
|
906
|
|
```
|
|
|
|
Something with PID 906 is running.
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: where would nginx's configuration file be, and where would its logs be?
|
|
|
|
## INSPECT
|
|
|
|
```
|
|
$ cat /etc/nginx/nginx.conf | head -5
|
|
worker_processes 1;
|
|
error_log /var/log/nginx/error.log warn;
|
|
pid /run/nginx.pid;
|
|
...
|
|
$ ls /var/log/nginx/
|
|
access.log error.log
|
|
```
|
|
|
|
## CHANGE
|
|
|
|
Confirm it's actually listening on the port you'd expect:
|
|
|
|
```
|
|
$ ss -lnt | grep :80
|
|
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
|
|
```
|
|
|
|
## VERIFY
|
|
|
|
All five questions answered with real evidence, not assumptions: it's running (PID 906),
|
|
listening on port 80, configured at `/etc/nginx/nginx.conf`, logging to `/var/log/nginx/`. This
|
|
exact sequence — process, port, config, logs — is what you'll repeat for almost any unfamiliar
|
|
service on any real system.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Show the five-question checklist answered end-to-end against a real, already-
|
|
running service the students are themselves using right now — more convincing than an
|
|
abstract example.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** stopping here at "PID exists" without also confirming it's
|
|
actually listening on the expected port — a process existing and a service actually being
|
|
reachable are two different facts, both worth checking.
|