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]>
65 lines
3.6 KiB
Markdown
65 lines
3.6 KiB
Markdown
# 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.)
|