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]>
3.6 KiB
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.)