# 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.)