Linux & Shell Learning Roadmap

What Linux is, and a place to practise

Linux is a kernel, the core that talks to the hardware. A distribution (distro) bundles the kernel with tools, a package manager and defaults. Most servers run Ubuntu, Debian or the Red Hat family (RHEL, Rocky, AlmaLinux, Fedora). What you learn on one carries over to the others; the main differences are the package manager and a few file locations.

You don't need to replace your operating system. On Windows, WSL gives you a real Ubuntu in a few minutes. On a Mac, use a virtual machine (Multipass or UTM), because macOS is Unix but not Linux. A small cloud VM also works, and is good practice for the later stages.

What to learn

• Kernel vs distribution, and the main distro families (Debian/Ubuntu and Red Hat)
• Install Ubuntu through WSL, a VM or a cloud instance
• Open a terminal, log in and find out which distro and kernel you're on (cat /etc/os-release, uname -r)
• Know what a shell is (Bash, zsh) and which one you're using (echo $SHELL)

Free resources

• Introduction to Linux (LFS101) free course
• Install Linux on Windows with WSL docs
• The Linux command line for beginners tutorial

Practice

Set up Ubuntu in WSL or a VM, then write down your distro version, kernel version, shell and how much disk and memory you have (df -h, free -h).

The terminal and the shell

A command is a program name followed by options (-l, --all) and arguments (usually file names). The shell finds the program in the directories listed in $PATH, runs it and shows the output. When you're stuck, the answer is almost always in man or --help.

A handful of keys save hours: Tab completes names, ↑ and Ctrl+R search your history, Ctrl+C stops a command and Ctrl+A/E jump to the start or end of the line. Environment variables such as HOME, PATH and EDITOR configure programs, and your ~/.bashrc sets them up each time you open a shell.

What to learn

• Command structure: name, options, arguments, and quoting with '…' and "…"
• Getting help: man, --help, type, which, apropos
• Tab completion, history (history, Ctrl+R, !!) and line-editing shortcuts
• Environment variables, export, $PATH, and aliases in ~/.bashrc
• Exit status: $?, and running commands with &&, || and ;

Free resources

• Learning the Shell tutorial
• The Missing Semester: the shell MIT lecture
• explainshell: paste a command to see what each part does tool
• tldr pages: short, example-first man pages reference

Practice

Add an alias ll='ls -lah' and a folder ~/bin to your PATH in ~/.bashrc, open a new terminal and check both work. Then find a command you ran yesterday with Ctrl+R.

Files, directories and the filesystem layout

Everything in Linux lives in one tree that starts at /: there are no drive letters. Your files are in /home/you (~), settings in /etc, programs in /usr/bin, logs and data in /var, and /tmp is cleared out regularly. Paths are either absolute (start with /) or relative to where you are.

You'll create, copy, move and delete files constantly, so learn the commands well, including the dangerous ones: rm has no recycle bin. find searches by name, size, age or type, and tar packs folders into a single archive for backups and transfers.

What to learn

• The main directories (/etc, /home, /var, /usr, /tmp, /proc) and absolute vs relative paths
• pwd, cd, ls -la, mkdir -p, cp -r, mv, rm -r, touch
• Viewing files: cat, less, head, tail -f, file
• Wildcards (*, ?, [ ]) and hidden dotfiles
• find by name, type, size and age, and -exec
• Hard and symbolic links (ln -s), and archives with tar -czf / tar -xzf

Free resources

• Filesystem Hierarchy Standard 3.0 spec
• Navigation and looking around tutorial
• find(1) man page

Practice

Play the first ten levels of OverTheWire Bandit. Then find every file over 50 MB in your home folder and every .log file changed in the last day under /var/log.

Pipes and redirection

Each program has three streams: standard input, standard output and standard error. Redirection sends them to files (> overwrites, >> appends, 2> for errors), and a pipe (|) feeds one command's output into the next. Small tools joined by pipes are the heart of the Unix way of working.

For example, ps aux | grep nginx | wc -l counts nginx processes. Command substitution, $(date +%F), puts a command's output inside another command, which is how you name a backup after today's date.

What to learn

• stdin, stdout and stderr, and file descriptors 0, 1 and 2
• >, >>, 2>, 2>&1, &>, <, and /dev/null
• Pipes, and tee to write to a file and the screen at once
• Command substitution $( ) and xargs

Free resources

• I/O redirection tutorial
• Bash manual: Redirections docs

Practice

Run a command that prints both output and errors (for example ls /etc /nope), and send the output to one file and the errors to another. Then save a sorted, de-duplicated list of the shells in /etc/passwd with a single pipeline.

Editing files in the terminal: nano and vim

On a server there is no graphical editor, so you need one that runs in the terminal. nano is the easiest: the shortcuts are listed at the bottom. vim (or vi) is on almost every system, so learn at least enough to edit and save a file, and to escape it.

Vim has modes: you start in normal mode, press i to type, Esc to stop typing, and :wq to save and quit (:q! quits without saving). Thirty minutes of vimtutor, which comes with vim, is enough to get going.

What to learn

• Open, edit, save and exit with nano (Ctrl+O, Ctrl+X)
• Vim modes, :w, :q, :wq, :q!
• Moving, deleting, copying and searching in vim (dd, yy, p, /word, u to undo)
• Set your default editor with EDITOR (used by crontab -e, git commit, visudo)

Free resources

• The Missing Semester: editors (vim) MIT lecture
• nano cheat sheet reference
• Vim help files docs

Practice

Run vimtutor to the end of lesson 2. Then use vim to edit your ~/.bashrc: add a comment line, delete it again, and save.

File permissions and ownership

Every file has an owner, a group and three sets of permissions: for the owner, the group and everyone else. Each set is read (r, 4), write (w, 2) and execute (x, 1), so -rwxr-x--- is 750. On a directory, x means "may enter it" and w means "may create and delete files in it".

Get into the habit of the least permission that works. chmod 777 "fixes" errors by letting everyone write, and is how servers get compromised. SSH keys must be 600 or SSH refuses to use them.

What to learn

• Read ls -l output: type, permissions, owner, group
• chmod in octal (640) and symbolic form (u+x, go-w)
• chown user:group and chgrp, including -R
• What r, w and x mean on a directory
• umask, and the special bits setuid, setgid and the sticky bit (/tmp)

Free resources

• Permissions tutorial
• File permissions and attributes ArchWiki

Practice

Create a script, try to run it (permission denied), fix it with chmod u+x. Then make a folder that your group can read but not change, and check it as another user.

• chmod calculator (octal ⇄ symbolic, umask)

Users, groups and sudo

Users are listed in /etc/passwd, password hashes in /etc/shadow and groups in /etc/group. The root user can do anything, so you work as a normal user and use sudo for the few commands that need more power. Who may use sudo is set in /etc/sudoers, which you edit with visudo so a typo can't lock you out.

Services such as web servers and databases run as their own unprivileged system users (www-data, postgres). If one is broken into, the attacker gets only that user's access, not the whole machine.

What to learn

• whoami, id, and the files /etc/passwd, /etc/shadow, /etc/group
• Create, change and remove users and groups (useradd/adduser, usermod -aG, userdel)
• passwd, password ageing (chage) and locking accounts
• sudo, sudo -i, su -, and editing rules with visudo
• System users for services, and why they have no login shell

Free resources

• Users and groups ArchWiki
• sudo ArchWiki
• useradd(8) man page

Practice

Create a user deploy and a group webteam, add the user to the group, and give deploy permission to restart one service with sudo but nothing else.

• Password generator
• Hash generator

Processes, signals and jobs

Every running program is a process with a process ID (PID), a parent, an owner and a state. ps takes a snapshot, top and htop show it live. You stop processes with signals: SIGTERM (15) asks politely and lets the program clean up, SIGKILL (9) can't be ignored but loses unsaved work.

In the shell, Ctrl+Z pauses a job, bg resumes it in the background and fg brings it back. A command that must keep running after you log out belongs in a systemd service (stage 4), or at least in tmux or nohup.

What to learn

• ps aux, pgrep, top/htop, and reading CPU and memory columns
• Signals: kill, kill -9, pkill, killall, and when to use each
• Foreground and background jobs: &, jobs, bg, fg, nohup
• Process priority with nice and renice
• The /proc filesystem (/proc/<pid>/, /proc/cpuinfo)

Free resources

• Job control tutorial
• signal(7) man page
• The Missing Semester: command-line environment MIT lecture

Practice

Start sleep 1000, pause it, move it to the background, find its PID with pgrep, and stop it with SIGTERM. Then find the three processes using the most memory.

Installing software: package managers

Linux installs software from repositories through a package manager, which also handles dependencies and updates. Debian and Ubuntu use apt with .deb packages; Fedora, RHEL and Rocky use dnf with .rpm packages. Always prefer the repository version over downloading random install scripts.

Keep systems patched: sudo apt update && sudo apt upgrade on Ubuntu, sudo dnf upgrade on Fedora. Ubuntu servers can install security updates automatically with unattended-upgrades.

What to learn

• apt update, apt install, apt remove, apt search, apt show
• The dnf equivalents, and which distros use which
• Adding a third-party repository and its signing key safely
• Finding which package owns a file (dpkg -S, rpm -qf)
• Automatic security updates (unattended-upgrades or dnf-automatic)

Free resources

• apt(8) Debian man page
• DNF command reference docs

Practice

Install htop, tree and jq, find out which package installed /usr/bin/ls, then remove tree again and clean up unused dependencies.

Text processing: grep, sed, awk and friends

grep finds lines that match a pattern, sed edits text as it streams past (search and replace), and awk splits lines into fields and does small calculations. Add sort, uniq -c, cut, wc and tr, and you can answer most questions about a log file in one pipeline.

For example, the ten IP addresses with the most requests in a web server log: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head. For JSON output from APIs and cloud tools, jq does the same job.

What to learn

• grep with -i, -v, -r, -n, -E, -o, and basic regular expressions
• sort, uniq -c, cut -d, wc -l, tr, head, tail
• sed 's/old/new/g', in-place editing with -i, and deleting lines
• awk fields ($1, $NF), -F, conditions and totals
• jq for JSON, and comparing files with diff

Free resources

• The Missing Semester: data wrangling MIT lecture
• GNU sed manual docs
• The GNU Awk User's Guide docs
• jq manual docs

Practice

Download a sample web server log (or use /var/log) and find: the 10 busiest IPs, the number of 404 responses, and the requests per hour. Do each with one pipeline.

• Regex tester
• User-agent parser (bulk log lines)
• Text diff
• JSON formatter

Bash scripting

A shell script is a text file of commands with a shebang line (#!/usr/bin/env bash) at the top. Variables, if, loops and functions turn it into a small program. Start every script with set -euo pipefail so it stops at the first error instead of carrying on and doing damage.

The classic bugs are unquoted variables (a file name with a space becomes two arguments) and ignoring exit codes. Run every script through ShellCheck, which catches them for you. When a script grows past a hundred lines or needs real data structures, Python is usually the better tool.

What to learn

• Shebang, making a script executable, and set -euo pipefail
• Variables, quoting ("$var"), arguments ($1, $@, $#) and read
• if, [[ ]] tests (files, strings, numbers), case
• for and while loops, including reading a file line by line
• Functions, return codes, exit, and trap for clean-up
• Lint with ShellCheck and keep scripts in Git

Free resources

• The Bash Guide guide
• Bash Pitfalls guide
• GNU Bash Reference Manual docs
• ShellCheck linter

Practice

Write backup.sh: it takes a folder as an argument, checks it exists, creates backup-YYYY-MM-DD.tar.gz, keeps only the newest seven backups and exits non-zero on any error. Make it pass ShellCheck with no warnings, and commit it to Git (see the Git roadmap).

• .env converter
• Regex tester

Scheduling jobs with cron and systemd timers

cron runs commands on a schedule. Each line in a crontab has five time fields (minute, hour, day of month, month, day of week) and a command: 30 2 * * * /home/deploy/backup.sh runs at 02:30 every night. Edit your own with crontab -e; system jobs live in /etc/cron.d.

Cron runs with a very small environment, so use full paths and redirect output to a log, or failures vanish silently. On modern systems, systemd timers are the alternative, with logging, dependencies and "catch up if the machine was off" built in.

What to learn

• The five cron fields, *, ranges, lists and steps (*/15)
• crontab -e, crontab -l, and system crontabs in /etc/cron.d
• Why cron jobs fail: PATH, missing environment, no output; logging with >> file 2>&1
• systemd timers (OnCalendar=, Persistent=true) and systemctl list-timers

Free resources

• crontab(5) man page
• systemd timers ArchWiki

Practice

Schedule your backup.sh to run nightly with cron, with its output logged. Then convert the same job into a systemd service plus timer and compare the two.

• Cron expression builder
• crontab ⇄ systemd timer converter

tmux: sessions that survive a dropped connection

tmux is a terminal multiplexer: it splits one terminal into panes and windows, and keeps your session running on the server when your SSH connection drops. Reconnect, type tmux attach, and you're back exactly where you were, with a long-running command still going.

What to learn

• Start, detach (Ctrl+B D) and re-attach sessions
• Windows and split panes, and moving between them
• A small ~/.tmux.conf (mouse support, easier split keys)

Free resources

• tmux: Getting Started official wiki
• The Missing Semester: terminal multiplexers MIT lecture

Practice

On a server, start a tmux session, run top in one pane and tail -f on a log in another, disconnect SSH, reconnect and re-attach.

Networking from the command line

Every machine has network interfaces with IP addresses, a routing table and DNS settings. ip addr and ip route show them, ss -tlnp lists which programs are listening on which ports, and ping, dig and curl test reachability, DNS and HTTP. Most "the site is down" problems are one of: DNS, a firewall, nothing listening, or the wrong port.

Learn to work through a problem layer by layer: can I resolve the name, reach the IP, connect to the port, and get a sensible HTTP response? Each step has its own command.

What to learn

• IP addresses, subnets (CIDR), gateways and ports
• ip addr, ip route, and where network config lives (netplan or NetworkManager)
• ss -tlnp to see listening ports and which process owns them
• DNS: /etc/hosts, /etc/resolv.conf, dig, nslookup
• ping, traceroute/mtr, curl -v, nc to test a port

Free resources

• Network configuration ArchWiki
• ss(8) man page
• Everything curl free book

Practice

Install nginx, find which port it listens on with ss, fetch the page with curl -v, then stop nginx and explain the difference in the error you get.

• CIDR / subnet calculator
• IP range checker
• API request tester

SSH: keys, config and secure remote access

SSH is how you log in to servers. Use a key pair instead of a password: the private key stays on your computer (protected by a passphrase), and the public key goes into ~/.ssh/authorized_keys on the server. An Ed25519 key is the modern default: ssh-keygen -t ed25519.

A ~/.ssh/config file saves typing (hosts, users, keys, ports), and scp or rsync copy files over the same connection. On the server, turn off password logins and direct root logins once your key works.

What to learn

• Generate an Ed25519 key with a passphrase, and use ssh-agent
• Install a public key (ssh-copy-id) and check file permissions (700 / 600)
• ~/.ssh/config entries, jump hosts (ProxyJump) and port forwarding (-L)
• Copy files with scp and rsync -avz
• Harden sshd_config: no passwords, no root login; and understand known_hosts warnings

Free resources

• SSH keys ArchWiki
• ssh_config(5) OpenSSH manual
• sshd_config(5) OpenSSH manual

Practice

Create a key, log in to a VM with it, add a Host entry so ssh lab works, then disable password authentication and confirm a password login is refused.

• SSH key and known_hosts decoder (fingerprints, randomart)

Services with systemd

systemd starts the system and manages long-running services. systemctl status nginx shows whether a service runs and its last log lines; start, stop, restart and enable (start at boot) control it. Your own apps become services with a short unit file, which gives you automatic restarts, logging and start-up ordering for free.

A minimal service needs ExecStart=, a User= so it doesn't run as root, Restart=on-failure and an [Install] section. After editing a unit, run systemctl daemon-reload.

What to learn

• systemctl status, start, stop, restart, reload, enable --now, disable
• Write a unit file in /etc/systemd/system/ with User=, WorkingDirectory=, Restart=, Environment=
• daemon-reload, systemctl edit overrides and systemctl list-units --failed
• Targets (the old runlevels) and the basics of the boot order

Free resources

• systemd ArchWiki
• systemd.service official docs

Practice

Write a tiny web app (for example python3 -m http.server), run it as a systemd service under its own user with automatic restart, enable it at boot, kill it with kill -9 and watch systemd bring it back.

• crontab ⇄ systemd timer converter
• .env converter

Logs: journalctl and /var/log

When something breaks, the logs usually say why. systemd collects service output in the journal, which you read with journalctl: journalctl -u nginx --since "1 hour ago" shows one service's recent messages, and -f follows them live. Many programs also write plain files in /var/log, such as auth.log (logins and sudo) and nginx's access.log.

Logs grow forever unless something trims them: logrotate compresses and deletes old log files, and the journal has its own size limit in journald.conf.

What to learn

• journalctl -u, -f, -p err, --since, -b (this boot)
• The important files in /var/log (syslog/messages, auth.log/secure, dmesg)
• Log rotation with logrotate, and journal size limits
• Searching logs with grep, awk and less +F

Free resources

• systemd journal ArchWiki
• journalctl official docs
• logrotate(8) man page

Practice

Find every failed SSH login attempt on your server in the last day and list the source IPs by count. (On an internet-facing VM there will be plenty.)

• User-agent parser (nginx and load-balancer log lines)
• Timestamp converter

Disks, filesystems and mounting

Disks show up as devices such as /dev/sda or /dev/nvme0n1. You partition them, create a filesystem (ext4 or XFS) and mount it on a directory. /etc/fstab lists what to mount at boot; a mistake there can stop the machine booting, so test with mount -a first and use UUIDs rather than device names.

df -h shows free space per filesystem and du -sh * finds what's using it. LVM adds a flexible layer so volumes can grow later, and swap gives the system breathing room when memory runs out.

What to learn

• lsblk, blkid, df -h, du -sh, ncdu
• Partition with fdisk/parted, format with mkfs.ext4/mkfs.xfs
• mount, umount, and permanent mounts in /etc/fstab by UUID
• LVM basics: physical volumes, volume groups, logical volumes, lvextend -r
• Swap files and checking memory with free -h

Free resources

• fstab ArchWiki
• LVM ArchWiki
• mount(8) man page

Practice

Attach a second virtual disk to a VM, partition and format it, mount it at /data through fstab, reboot to prove it comes back, then grow it with LVM.

Basic server security

Most break-ins use the boring routes: weak passwords, unpatched software, services left open to the internet and apps running as root. Close them in order: key-only SSH, automatic security updates, a firewall that allows only the ports you need, and services running as their own users.

ufw (Ubuntu) and firewalld (Red Hat family) are friendly front ends to the kernel firewall. fail2ban bans IPs that keep failing to log in. Check what's listening with ss -tlnp: anything you don't recognise is a question to answer.

What to learn

• A firewall with ufw or firewalld: default deny, allow SSH and HTTP(S)
• Key-only SSH, no root login, and fail2ban for repeated failures
• Automatic security updates and rebooting for kernel updates
• Least privilege: service users, file permissions, sudo rules
• What SELinux and AppArmor do, and how to read a denial instead of turning them off

Free resources

• Firewall (ufw) Ubuntu Server docs
• firewalld documentation official docs
• Security ArchWiki

Practice

Harden a fresh VM: create a sudo user, key-only SSH, no root login, a ufw firewall allowing only 22 and 443, unattended upgrades and fail2ban. Then check from another machine that only those ports answer.

• SSL certificate decoder
• chmod calculator

Performance troubleshooting

When a server is slow, measure before guessing. Is it CPU, memory, disk or network? The load average in uptime counts processes waiting to run, vmstat 1 and free -h show memory and swapping, iostat shows disk saturation and top shows who is responsible.

Brendan Gregg's "first 60 seconds" checklist is a great habit: ten commands that between them point at most problems.

What to learn

• Load average and what it means relative to the number of CPUs
• top/htop, vmstat, iostat, free -h, dmesg
• Memory: page cache, available memory, swap and the OOM killer
• Disk and network throughput: iotop, ss -s, sar

Free resources

• Linux Performance Brendan Gregg
• vmstat(8) man page

Practice

Use stress-ng to load the CPU, then memory, then disk, and for each one note which command shows the problem first.

The boot process and recovery

From power-on to login: firmware (UEFI) loads the boot loader (GRUB), which loads the kernel and an initial RAM disk, which starts systemd, which starts everything else. Knowing the order tells you where to look when a machine won't boot, and how to get a rescue shell to fix a broken fstab or a lost root password.

What to learn

• UEFI, GRUB, kernel, initramfs, systemd: what each step does
• Editing the kernel command line in GRUB and booting into a rescue or emergency target
• Reading boot logs: journalctl -b, dmesg, systemd-analyze

Free resources

• The boot process ArchWiki
• GNU GRUB manual docs

Practice

In a VM you don't care about, break /etc/fstab, boot into emergency mode, fix it and reboot normally.

LFCS exam preparation

The Linux Foundation Certified System Administrator (LFCS) is a hands-on exam: you solve real tasks at a Linux command line rather than answering multiple choice. As of October 2026 it is an online, proctored, performance-based exam of 2 hours, costs US$445 including one retake, and the certification is valid for 2 years. The domains are Operations Deployment (25%), Networking (25%), Storage (20%), Essential Commands (20%) and Users and Groups (10%). Check the official page for current details before booking.

What to learn

• Read the official domains and competencies and map each one to a topic here
• Practise every task without a browser: use man, --help and /usr/share/doc
• Get fast at editing files in vim and checking your work
• Do a timed run of practice tasks on a fresh VM

Free resources

• LFCS exam page official
• Introduction to Linux (LFS101) free course

Practice

Without notes and against a 2-hour timer: add a user with sudo rights, mount a new disk at boot, set up a firewall, schedule a job, configure a static IP and find a process eating CPU.