Linux SysAdmin Bootcamp (Free) — 9 Modules

This bootcamp is the curriculum I wish juniors got before someone handed them production root. It’s free. It’s opinionated. It’s meant to be done with a cheap VPS or a VM — not by binge-watching twenty hours of theory.

Author voice: Maruthi Vishnu, sysadmin.co.in — explain it like a senior over chai, not like a brochure.

What you’ll be able to do

  • Explain how a Linux box thinks (processes, files, users, logs)
  • Survive the CLI without fear of special characters
  • Create users, configure SSH safely, recover from key mistakes
  • Debug systemd services and disk-full incidents
  • Trace basic network/DNS failures
  • Know the gateway into automation (cron → Ansible mindset)

Prerequisites

Curiosity and a lab machine. If you need vocabulary first, read What is Linux? and the Linux roadmap for beginners.

Modules

  1. Module 1 — Linux mental model — everything is a file (sort of), processes, logs
  2. Module 2 — CLI survival — navigation, reading, not destroying the server
  3. Module 3 — Users & SSH — accounts, keys, lockout avoidance
  4. Module 4 — Services & disks — systemd, journalctl, df/du/lsof
  5. Module 5 — Networking — ports, DNS, “why can’t it connect”
  6. Module 6 — Automation gateway — cron, config as code, next steps to DevOps
  7. Module 7 — Backups and recovery — restore drills, retention, proving recovery
  8. Module 8 — Observability basics — logs, metrics, healthchecks, alerts
  9. Module 9 — Security baseline — patching, SSH, exposure, defensive only

Start Module 1 →

Suggested pace

One module per weekday evening, or a focused weekend for Modules 1–3. Do the labs. Reading without typing doesn’t stick.

FAQ

Is this really free?

Yes. No email gate required for the curriculum pages. If ads appear later on the site, they fund the writing — they don’t unlock modules.

Which distro should I use?

Ubuntu LTS or Rocky/Alma for familiarity with job markets. Concepts transfer.

Do I need cloud?

A local VM is enough. Cloud helps you practice security groups and serial console break-glass.

What after the bootcamp?

Follow the SysAdmin → DevOps roadmap and keep the troubleshooting posts bookmarked.

Lab setup recommendations

  • Local: VirtualBox/KVM/VMware with a snapshot before each module’s destructive lab
  • Cloud: smallest VM + serial console enabled; budget alerts on
  • Notes: keep a running markdown file of commands that worked — that becomes your personal runbook

Weekly schedule (example)

  1. Mon–Tue: Module 1–2 (mental model + CLI)
  2. Wed: Module 3 (users/SSH) — don’t skip break-glass practice
  3. Thu: Module 4 (systemd/disks)
  4. Fri: Module 5 (networking)
  5. Sat: Module 6 (automation) + review wrong turns

Assessment (honest, not gamified)

You’re “done” when you can, without notes:

  • Explain a failed systemd unit from journalctl
  • Free disk space without deleting the wrong mount
  • Fix a publickey SSH denial via console
  • Find who owns a TCP port
  • Write a cron job that logs and doesn’t overlap

Community norms

Paste sanitized configs when asking for help. Never paste private keys. Prefer lab reproduction steps. That culture is how seniors help juniors efficiently.

Tooling you’ll install along the way

  • An SSH client you like (OpenSSH is enough)
  • A notes app or markdown folder
  • Optional: htop, sysstat, dnsutils/bind-utils

You do not need a fancy IDE to learn sysadmin work. A terminal and curiosity outperform theme packs.

FAQ continued

Can I skip modules?

You can, but Module 1–2 prevent expensive misunderstandings later. If you’re experienced, skim fast and spend time on labs you haven’t done cold.

Is this aligned with certifications?

Indirectly. Concepts help with RHCSA/LFCS-style thinking, but this bootcamp is ops-practical, not exam-prep theater.

Time boxing tips

If a lab exceeds ninety minutes, snapshot, walk away, return tomorrow. Fatigue causes the same class of mistakes we wrote about in the dangerous commands post. Seniors nap; juniors force it and open incident channels.

Pairing with the blog

Each module lists required posts. Read them after the lab, not instead of the lab. The posts are written as production checklists — using them in a calm lab is how you avoid first seeing them during an outage.