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
parent b6516a74db
commit e007bcf000
39 changed files with 1752 additions and 0 deletions
@@ -0,0 +1,50 @@
+# Storage and Filesystems
+
+## Block devices and partitions, conceptually
+
+A **block device** is the kernel's view of a storage device (a disk, an SSD, a cloud volume) —
+`lsblk` lists them. A device can be split into **partitions**, separate sections each formatted
+with their own filesystem, though a single-partition disk is common too. You won't partition
+anything in this Lab, but recognizing `lsblk`'s output (`sda`, `sda1`, `nvme0n1`...) matters for
+reading real systems.
+
+## Filesystems and mount points
+
+A **filesystem** is the format that organizes raw blocks into the files/directories you actually
+interact with (ext4, xfs, and — inside this container — overlay, a filesystem UNIQUE to how
+containers layer their storage). A filesystem becomes usable by being **mounted** at some
+directory path — `/` itself is a mount point, and additional filesystems can be mounted at other
+paths (a separate disk mounted at `/data`, for example).
+
+## Persistent vs. temporary storage — a distinction that matters immediately
+
+Not everything written to disk is meant to last. `/tmp` is conventionally temporary (ROOT 01);
+a container's own writable layer is, by convention and by ROOT 04's design, meant to be
+DISPOSABLE — data written inside a container that isn't explicitly persisted elsewhere disappears
+when that container is destroyed. This distinction — is this data supposed to survive, or not —
+is the single most important storage question you'll carry forward into ROOT 04's volumes and
+eventually Kubernetes' PersistentVolumes.
+
+## Measuring usage: `df` vs. `du`
+
+These answer two DIFFERENT questions, a common point of confusion:
+
+- **`df -h`** — how much space is used/free on an entire mounted FILESYSTEM.
+- **`du -sh <path>`** — how much space one specific DIRECTORY's contents actually use.
+
+A filesystem can show plenty of free space overall (`df`) while one specific directory has
+unexpectedly ballooned (`du`) — you need both questions answered to diagnose "why is disk full."
+
+## Instructor Notes
+
+**Lesson goal:** Build the persistent-vs-temporary distinction explicitly, since it's the direct
+conceptual root of ROOT 04's bind-mount/volume distinction and, later, Kubernetes storage.
+
+**Approximate timing:** 12 minutes read; 8 minutes live.
+
+**Common misconception to watch for:** conflating `df` and `du` — a student surprised that
+`df` doesn't show them "which directory is huge" is a good moment to reinforce they answer
+different questions.
+
+**Demo idea:** `df -h /` then `du -sh /var/log/*` side by side, narrating the different
+question each answers.
@@ -0,0 +1,53 @@
+# 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.
@@ -0,0 +1,31 @@
+# Knowledge Check: Storage and Filesystems
+
+---
+
+**1. `df -h /` shows only 23% used, but you suspect one directory is unusually large. Does
+`df` alone answer that?**
+
+*Answer:* No — `df` reports overall filesystem usage, not per-directory. You need `du -sh <path>`
+pointed at the suspect directory (or directories) to answer that.
+
+---
+
+**2. What makes data in a container's writable layer different from data in `/home`?**
+
+*Answer:* By convention and design, a container's own writable layer is meant to be disposable —
+data there disappears when the container is destroyed, unless explicitly persisted elsewhere
+(a topic ROOT 04 covers directly). `/home` data is expected to persist normally.
+
+---
+
+**3. What does "mounting" a filesystem actually mean?**
+
+*Answer:* Attaching a filesystem so it becomes accessible at a specific directory path — `/`
+itself is a mount point, and additional filesystems can be mounted at other paths.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 previews ROOT 04's volume/bind-mount content directly — worth
+naming that connection explicitly.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,29 @@
+# Guided Exercise: Narrow Down a Disk Problem on Paper
+
+This is a paper exercise — commit to a plan before running commands in the Lab.
+
+## Your task
+
+`df -h /` shows the root filesystem is 95% full. You have three suspect directories:
+`/var/log`, `/srv/cache`, and `/home`. Write the exact sequence of `du` commands you'd run to
+find the actual culprit, narrowing your search efficiently rather than checking everything with
+maximum depth immediately.
+
+## A worked shape to check yourself against
+
+```
+du -sh /var/log /srv/cache /home
+```
+
+— one command, comparing all three top-level suspects at once. Whichever is largest, THEN
+narrow further into it specifically (e.g. `du -sh /srv/cache/*` if that one's the culprit) rather
+than deep-diving into all three from the start — this mirrors Module 1's "cheapest, fastest-
+answering question first" principle.
+
+## Instructor Notes
+
+**Facilitation:** Point out that running `du -sh` separately three times versus once with all
+three paths produces the same information — the point isn't syntax, it's the "compare broadly,
+then narrow" strategy.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,27 @@
+# Reflection: "It's Probably the Logs" Is a Guess, Not a Diagnosis
+
+## Reflection questions
+
+1. Before measuring, which of the three directories in this module's Lab did you guess would
+   be largest? Were you right?
+2. Why does "persistent vs. temporary" matter enough to be worth memorizing as a question you
+   ask about EVERY piece of data, not just during a storage module?
+
+## Real Ops takeaway
+
+**Guessing which directory is consuming disk space, without measuring, is exactly the kind of
+assumption that wastes real incident-response time.** `du`, applied progressively (broad, then
+narrow), replaces guessing with evidence in seconds. And the persistent-vs-temporary question
+you just practiced is the exact same question you'll ask again in ROOT 04 about container data,
+and again much later about Kubernetes storage — a question worth internalizing now, cheaply,
+rather than learning the hard way after data you assumed would persist didn't.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 works well as a quick poll before
+revealing the real answer — the mismatch between guesses and reality reinforces the lesson
+better than stating it directly.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.