Welcome to Linux for Production Sysadmins

This short lesson introduces every component of the design system and explains how the course is structured. Skim it once; then dive into the curriculum.

What this course is

A practical, production-oriented Linux course for systems administrators. By the end, a systems administrator completing the course should be capable of independently installing, configuring, securing, operating, monitoring, troubleshooting, maintaining, scaling and recovering Linux systems and Linux server clusters supporting mission-critical business services.

The course follows a consistent pattern for every substantial lesson:

1. What is it — a clear definition in the first 100 words
2. Why does a sysadmin care — production framing
3. How does it work — the mental model, often a Mermaid diagram
4. What happens under the hood — the kernel or userspace mechanism
5. How do I configure it — annotated ConfigurationExplorer
6. How do I validate it — real or labelled-illustrative commands
7. How can it fail — failure modes mapped to symptoms
8. How do I troubleshoot it — evidence-based diagnosis
9. What are the security implications — permissions, capabilities, attack surface
10. What are the performance implications — CPU, memory, disk, network
11. What should I do in production — capacity, monitoring, backup
12. How do I safely undo or roll back — not "how do I stop it"

Verified against

Three differences show up often enough to be worth memorising now, because they are the ones that silently break automation rather than producing an obvious error:

The SSH unit name is the one that bites hardest. Sudoers rules match the command line literally, so a grant written for systemctl restart ssh does nothing at all on a RHEL host — the operator gets “command not allowed”, not a helpful error about the unit. Confirm which name a host uses before writing anything against it:

systemctl list-unit-files | grep -E '^ssh'

Where a lesson shows only one form, this table is the translation.

Severity model

Every command example is tagged with a severity badge. This is not decoration — it is a production discipline tool.

$ uname -r

6.6.31-linuxkit

sysctl -w net.ipv4.ip_forward=1

systemctl reload ssh

lvremove /dev/vg0/data

mkfs.xfs -L data /dev/sdc1

pcs cluster stop --all

Lesson anatomy

Every substantial lesson follows the same structure so you always know where to look:

1. A production framing question
2. A mental model and visual explanation
3. Annotated configuration and command examples
4. Failure modes with named symptoms
5. A troubleshooting or investigation path
6. Security and performance implications
7. Production guidance and rollback
8. A knowledge check with 2-4 scenario-based questions

Labs are kept distinct from lessons. A lab is a hands-on exercise with a defined Objective, Architecture, Requirements, Tasks, Validation, Expected Outcome, Troubleshooting, Cleanup, and What You Learned.

How to use this course

1. Skim the welcome lesson and the lesson you are about to start.
2. Read the lesson, paying attention to “Under the Hood” sections that explain the kernel or userspace mechanism.
3. Run the lab in a disposable VM. Destructive commands in lessons are labelled — destructive commands in labs are required to demonstrate the concept and are clearly marked.
4. Take the quiz at the end of each lesson. Quizzes are scenario-based; they are not trivia.
5. Track progress via the sidebar — completed lessons show a checkmark. Progress is stored in your browser’s localStorage under runbook:progress:v2.

What you will be able to do

By the end of this course you should be capable of independently:

• Recover a Linux server that no longer boots.
• Diagnose why a filesystem is full.
• Explain why df and du disagree.
• Recover a degraded RAID array.
• Extend an LVM filesystem safely.
• Diagnose DNS failures.
• Diagnose routing problems.
• Capture and interpret network traffic.
• Configure and troubleshoot systemd services.
• Diagnose OOM conditions.
• Investigate CPU, memory, disk, and network performance.
• Secure SSH and privileged access.
• Understand SELinux / AppArmor rather than disabling them.
• Safely patch hundreds of Linux servers.
• Perform rolling maintenance on a Linux cluster.
• Explain quorum, split brain, and fencing.
• Diagnose a failed Pacemaker resource.
• Recover from loss of a cluster node.
• Monitor Linux infrastructure effectively.
• Centralise logs.
• Detect important security events.
• Perform backup and, more importantly, restore.
• Recover an entire Linux server from loss.
• Recover a Linux cluster following a major failure.
• Operate methodically during a 03:00 production incident.

If any of these would not be answered “yes” after you finish the course, identify the curriculum gap and address it.

Knowledge check

Where next?

The first deep-dive is on the history and ecosystem of Linux, because every later decision (which distribution, which init system, which package manager) depends on those roots. Continue with linux-history-and-ecosystem.