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,64 @@
+# Linux System Administration
+
+## Five questions every administrator asks
+
+Whenever you're handed an unfamiliar running system, you're really always answering the same
+five questions: **What is running? Who started it? Where is its configuration? Where are its
+logs? How do I verify its state?** This module builds the vocabulary and tools for all five.
+
+## Packages: how software gets installed
+
+A **package manager** (`apt` on Debian/Ubuntu, `dnf`/`yum` on Fedora/RHEL) installs, updates, and
+removes software along with tracking what depends on what — the alternative (manually downloading
+and compiling everything) is exactly the kind of unreproducible mess package managers exist to
+prevent. You won't install packages by hand often in this Lab, but recognizing `apt install` /
+`apt list --installed` matters for reading real systems.
+
+## Services: long-running background programs
+
+A **service** is a program meant to run continuously in the background, outliving any single
+terminal session — a web server, a database, a log collector. Unlike a command you run and wait
+for, a service starts, keeps running, and is expected to still be there when you come back.
+
+## systemd and systemctl (the concept — not available in this Lab)
+
+On most real Linux servers, **systemd** is the process manager (PID 1) responsible for starting,
+stopping, and supervising services, and `systemctl` is the command you'd use to control it
+(`systemctl status nginx`, `systemctl restart nginx`, `journalctl -u nginx` for its logs).
+**This disposable Lab container does not run systemd** — its PID 1 is a boot script that starts
+k3s directly, the same way a real container almost never runs a full init system. This is worth
+knowing honestly rather than pretending otherwise: the CONCEPTS below (a running process, its
+config file, its logs, verifying its state) are identical whether the supervisor is systemd or
+something else — this module's Labs teach those concepts against a service you CAN directly
+inspect and control in this environment.
+
+## Configuration files and environment variables
+
+Most services read their settings from either a config file (a specific path, usually under
+`/etc/`) or **environment variables** (`env` lists every variable in your current shell;
+`export NAME=value` sets one). Knowing WHERE a service's configuration lives is exactly the
+"where is its configuration" question from this lesson's opening — you'll answer it for real in
+this module's first Lab.
+
+## Logs: where a service tells you what happened
+
+A well-behaved service writes what it's doing to a log — usually a file under `/var/log/`.
+Reading logs (with `cat`, `tail`, `tail -f` — from ROOT 01) is almost always the first real step
+in figuring out why something isn't working, which Module 6 builds into a full framework.
+
+## Instructor Notes
+
+**Lesson goal:** Establish the five-question mental model (running/started-by/config/logs/
+verify) as the organizing frame for the rest of this module, and be explicit and honest that
+systemd isn't available in this specific Lab environment rather than silently working around it.
+
+**Approximate timing:** 15 minutes read; 10 minutes live.
+
+**Common misconception to watch for:** students who've used systemd elsewhere may expect
+`systemctl` to exist here — address this directly and early rather than letting them discover
+the error on their own.
+
+**Discussion question:** "If you SSH into an unfamiliar production server and need to figure out
+what's running and whether it's healthy, what's the very first command you'd run?" (There's no
+single right answer — the point is getting students to articulate their own process before this
+module hands them formal tools for it.)
@@ -0,0 +1,56 @@
+# 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.
@@ -0,0 +1,39 @@
+# Knowledge Check: Linux System Administration
+
+---
+
+**1. What are the five questions this module opened with?**
+
+*Answer:* What is running? Who started it? Where is its configuration? Where are its logs? How
+do I verify its state?
+
+---
+
+**2. Why doesn't this Lab environment have `systemctl`?**
+
+*Answer:* This Lab's container doesn't run systemd as PID 1 — its boot script starts k3s
+directly instead, the same way most containers don't run a full init system. The concepts
+(inspecting a running service's process/config/logs/state) are the same regardless of which
+supervisor manages it.
+
+---
+
+**3. A process exists (`pgrep` finds a PID) but the service seems unreachable. What's the next
+thing to check?**
+
+*Answer:* Whether it's actually listening on the expected port (`ss -lnt`) — a running process
+and a reachable service are two separate facts; the process could have started but failed to
+bind its port.
+
+---
+
+**4. Where does a well-behaved Linux service typically write what it's doing?**
+
+*Answer:* A log file, usually under `/var/log/`.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth confirming explicitly if any student has prior systemd
+experience — set the expectation before the Lab, not after a confusing error.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,32 @@
+# Guided Exercise: Plan Your Inspection Before You Type Anything
+
+This is a paper exercise — commit to a plan before running commands in the Lab.
+
+## Your task
+
+You're told "the payments service seems slow." Before touching a keyboard, write down, in
+order, which of these five questions you'd check FIRST, SECOND, and so on, and the one command
+you'd use for each:
+
+- Is it running at all?
+- Is it listening on its expected port?
+- What does its configuration say?
+- What do its recent logs say?
+- Has anything changed recently?
+
+## A worked shape to check yourself against
+
+A reasonable order: (1) is it running — `pgrep`/`ps`; (2) is it listening — `ss -lnt`; (3) recent
+logs — `tail -n 50 <logfile>` (recent activity is usually more informative than config for a
+sudden "slow" complaint); (4) configuration — only if logs point at a config-driven cause; (5)
+recent changes — depends on context (deployment history, `ls -la` timestamps on config files).
+There's no single correct order, but "running, then listening, then logs" before jumping to
+config is a defensible default — you're checking the cheapest, fastest-answering questions
+first.
+
+## Instructor Notes
+
+**Facilitation:** There's genuine room for disagreement on ordering here — the value is in
+students defending their reasoning, not converging on one "correct" sequence.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,27 @@
+# Reflection: You Now Have a Repeatable Checklist
+
+## Reflection questions
+
+1. Before this module, if someone said "check whether the service is healthy," what would you
+   have actually done? How does that compare to the five-question checklist now?
+2. You started and stopped a service you fully controlled this module. What's different about
+   doing the same thing to a service you DIDN'T start, on a machine you don't fully understand
+   yet?
+
+## Real Ops takeaway
+
+**The five-question checklist works on ANY unfamiliar Linux system, not just this Lab.** Running
+process, listening port, config location, logs, and current state — this is genuinely how
+experienced engineers approach a machine they've never touched before. You'll use this exact
+checklist again in ROOT 04 when a container "doesn't seem to be working," and again in
+Kubernetes when a Pod isn't behaving as expected — the tools change, the checklist doesn't.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 is worth real discussion time — the
+honest answer is "you should be more careful and inspect more before acting," a good early
+seed for the least-privilege/caution habits ROOT 09 formalizes much later.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.