How to Learn Linux from Scratch: A Plan from the First Command to Server Administration

Learning Linux from scratch is easier than it seems if you follow the right order and practice right away. The main mistake of beginners is reading about commands without typing them, or jumping ahead to Docker and Kubernetes without understanding what a process and permissions are. Below is a plan of nine stages: what to study, what to practice and how to tell that a stage is complete.

As a rough guide, plan for two to four months with an hour of study a day, but everyone's pace is different. What matters more than speed is that after each stage you can do something with your own hands.

Stage 0. Set up your lab

You learn Linux on Linux. Options, from simple to realistic:

• WSL2 on Windows — an Ubuntu terminal in a couple of minutes. Good for commands and scripts, but systemd and networking there do not behave like on a real server.
• Virtual machine (VirtualBox, VMware, UTM on a Mac) with server Ubuntu or Debian. You can break things without consequences and roll back to snapshots.
• A cheap VPS from a cloud provider. A real server with a public IP is the best testing ground for the networking and security stages.

The distribution to start with is Ubuntu Server or Debian: they have the most documentation and answers to questions. A graphical desktop is not needed: servers are administered through the terminal, so get used to it from day one.

Stage 1. Terminal and file system

The goal is to move around the system and work with files confidently without a mouse.

• Navigation: pwd, ls -la, cd, absolute and relative paths, ~, . and ...
• Files: cp, mv, rm, mkdir -p, touch, viewing with cat, less, head, tail -f.
• Search: find, which, locate.
• Help: man, --help. Being able to read man pages is a skill that pays off for life.
• Directory structure: what lives in /etc, /var/log, /home, /usr, /proc, /dev; what mounting and inodes are.
• A text editor in the terminal: nano at first, then basic vim commands — it is present on almost every server.

Practice: find all .conf files in /etc changed in the last week (find /etc -name "*.conf" -mtime -7). Open /etc/os-release and find your system version. Look at what the system writes to /var/log.

Stage 2. Users, groups and permissions

Permissions are the foundation of Linux security and the source of half of all "Permission denied" errors.

• Reading the output of ls -l: type, permissions, owner, group.
• chmod in symbolic and numeric form, chown, umask.
• Special bits: SUID, SGID, sticky bit — and why /tmp is writable by everyone but other people's files cannot be deleted there.
• Users and groups: useradd, usermod -aG, passwd, the files /etc/passwd, /etc/shadow, /etc/group.
• sudo, the rules in sudoers and editing through visudo.

Practice: create two users and a shared project folder where both can create files, while others see nothing. Hint: a group, chmod 2770 and SGID for group inheritance.

Stage 3. Bash and text utilities

Administration is largely about processing text: logs, configs, command output. At this stage the terminal turns from a set of commands into a tool.

• Redirection and pipelines: >, >>, 2>&1, |, xargs.
• Filters: grep (with regular expressions), sort, uniq -c, wc, cut, sed, awk.
• JSON and HTTP from the console: curl and jq.
• Scripts: shebang, variables, quoting, if and [[ ]] conditions, loops, functions, exit codes, set -euo pipefail.

Practice: with one line, count the ten IP addresses with the most requests in a web server log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Then write a script that backs up a directory into an archive with the date in its name, deletes archives older than seven days, and returns a non-zero code on error.

Stage 4. Packages, environment and scheduler

• Package manager: apt update, apt install, apt remove, apt search, dpkg -l. On RHEL-like systems — dnf. Understand what a repository is and why signing keys exist.
• Environment variables: env, export, PATH, the files ~/.bashrc, ~/.profile, /etc/environment — and which one is read when.
• Scheduling: crontab -e, the five-field syntax, and why a command that works in the terminal "does not work" in cron (a different environment and PATH).

Practice: install nginx from the repository, add your own scripts directory to PATH, and set up the backup script from stage 3 to run every night through cron with the output written to a log.

Stage 5. Processes and systemd

Here you start to understand what is really happening in the system.

• Processes: ps aux, top/htop, PID and PPID, states, priorities (nice), signals and kill.
• Load: load average, memory and swap (free -h), what a "process in state D" means.
• Debugging: lsof — which files and ports a process has open; strace — which system calls it makes and where it hangs.
• systemd: units, systemctl status/start/enable, your own unit file with Restart=on-failure, timers instead of cron.
• Logs: journalctl -u, -f, -b, -p err, rotation, rsyslog; performance statistics with sysstat (sar, iostat).

Practice: set up a small application (at least python3 -m http.server) as a systemd service running under a separate user, kill the process with kill -9, and confirm that systemd brought it back. Find the restart entry in the journal.

Stage 6. Disks, LVM and RAID

• Devices and partitions: lsblk, blkid, fdisk or parted, the ext4 and XFS file systems, mkfs.
• Mounting: mount, /etc/fstab with UUIDs, checking with mount -a.
• Space: df -h, df -i, du -sh, finding what fills the disk.
• LVM: physical volumes, volume groups, logical volumes and growing a partition without stopping the system.
• Software RAID with mdadm — understanding levels 0, 1, 5, 10 and that RAID is not a backup.

Practice: add two disks to a virtual machine, build LVM on them, create a volume, mount it through fstab, and then grow it with lvextend -r.

Stage 7. Networking

• The TCP/IP model at the level needed for diagnostics: IP, mask, gateway, port, TCP and UDP.
• Commands: ip a, ip r, ss -tlnp, ping, traceroute/mtr, curl -v, nc.
• DNS: how resolution works, /etc/hosts, /etc/resolv.conf, dig, resolvectl.
• Network configuration in your distribution (netplan in Ubuntu, NetworkManager in others).
• Traffic capture: tcpdump for the cases where everything else has failed.

Practice: find out which process listens on each open port of your server. Work out why a service listening on 127.0.0.1 is unreachable from outside, and fix it.

Stage 8. Remote work: SSH and file transfer

• SSH: keys (ssh-keygen -t ed25519, ssh-copy-id), the ~/.ssh/config file, ssh-agent, port forwarding (ssh -L), a bastion through ProxyJump.
• Copying: scp and rsync -avz --delete — and why rsync is better for synchronization.
• Network file systems: NFS between Linux servers, SMB (Samba) for exchanging files with Windows.

Practice: set up login to a VPS by key only, describe it in ~/.ssh/config under a short name, and set up daily synchronization of a directory to the server with rsync.

Stage 9. Server security

• Firewall: the principle "deny everything that is not allowed", ufw for simple cases, nftables — to understand what happens under the hood.
• fail2ban: banning an IP after a series of failed logins, checked with fail2ban-client status sshd.
• sshd configuration: disable password login and root login.
• Security updates and their automatic installation (unattended-upgrades on Debian and Ubuntu).
• GPG: verifying package and file signatures, encrypting backups.

Practice: open only ports 22, 80 and 443 in the firewall, enable fail2ban, and a day later look at its status to see how many addresses have already been blocked.

Final project: build a whole server

The best test of whether you have really learned Linux is to build a server from scratch without hints:

1. A new VPS, your own user with sudo, SSH key login, passwords and root login disabled.
2. A firewall and fail2ban, automatic security updates.
3. A web server and an application as a systemd service with automatic restart.
4. A separate disk or volume for data, mounted through fstab.
5. Backups on a schedule (cron or a systemd timer) to another machine through rsync, with a log and a restore check.
6. A short instruction: how to rebuild all of this from scratch.

If you can go through this list and explain every step, you have the foundation for working as an administrator or a DevOps engineer. The natural next steps are containers, configuration automation and monitoring.

How to learn more effectively

• Type the commands yourself. Copying from an article is not remembered; typing and making mistakes are.
• Break things and fix them. Damage fstab or the permissions on ~/.ssh in a virtual machine and restore the system. This experience is valued in interviews.
• Keep notes. Your own command notebook with examples is more useful than anyone else's cheat sheet.
• Read the logs. Almost any problem in Linux is explained by the log — make a habit of looking there first.

Summary

The answer to how to learn Linux from scratch is to move in layers: the terminal and files, permissions, bash, packages, processes and systemd, disks, networking, SSH, security — and at each stage solve a practical task on your own lab. The final goal is to set up and secure a server with a working service on your own. This is exactly the route our Linux course follows, from the introductory lecture to the final project.