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]>
2.5 KiB
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.