LINUX CADET
TRAINING MANUAL

Welcome aboard, cadet. You're about to embark on a four-hour mission that will take you from "What is Linux?" all the way to writing your own shell scripts and debugging live processes on a remote server. This manual was crafted from the full transcript of the "Complete Linux Course with Networking and Shell Scripting" video series by Abhishek, structured into a single self-paced flight plan that fits in one focused afternoon.

The course itself is split into ten thematic sections across five episodes, plus a bonus shell-scripting tutorial. We've compressed every concept, every demo, every interview question, and every command from that ~10-hour video into a hands-on journey you can finish in 240 minutes. The trick is that we've front-loaded the practical skills — file permissions, process management, networking, and shell scripting get the lion's share of your time, because those are the muscles you'll actually flex in any DevOps, SRE, or backend engineering role.

How to use this manual

Each chapter follows the same cosmic structure so your brain can settle into a rhythm. Read the concept section first — it builds the mental model. Then type out every command in the code blocks in your own terminal. Tackle the Hands-on Lab — these are mandatory, not optional, because Linux lives in your fingers, not in your head. Take the Mini-Quiz to lock the knowledge in. Tick the chapter's checkbox, log your XP, and move on to the next system.

Your 240-minute flight plan

This is the hands-on heavy time allocation. The intro and history chapters are deliberately short — you'll spend your real time on permissions, processes, networking, and scripting, because that's where the actual engineering happens.

Why does an Operating System exist?

Hardware is dumb. A CPU by itself just sits there waiting for instructions. Memory chips store bits. Storage holds files. Network interfaces push electrons. None of these components know how to talk to a human or to an application — they only know how to receive electrical signals and respond with electrical signals. The operating system is the layer of software that sits between the hardware and everything else, translating "save this file" into the specific sequence of disk writes, memory allocations, and CPU instructions that actually make it happen.

The OS has four core responsibilities: process management (deciding which program runs when), memory management (allocating RAM fairly), device management (talking to keyboards, disks, GPUs), and network management (TCP/IP stacks, sockets). Without an OS, every application would have to ship with its own disk drivers and memory allocators — chaos. The OS is the universal translator that lets a Python script, a web browser, and a database server all coexist on the same machine without knowing anything about the underlying hardware.

A brief history of operating systems

In the 1960s, Unix was born at Bell Labs — the first widely-used multi-user operating system, and it was open source in spirit if not always in licensing. In the 1970s, Minix emerged as a small Unix-like teaching OS. In the 1980s, Microsoft released Windows, which revolutionised personal computing by giving the masses a rich graphical interface. Then, in 1991, a Finnish student named Linus Torvalds announced on a Usenet group that he was building a "free operating system" — just a hobby, won't be big and professional. That kernel became Linux, and today it runs roughly 90% of production servers, all Android phones, all Chromebooks, most of the public cloud, and the entire Top500 supercomputer list.

The reason Linux won the server war is straightforward: it's open source (anyone can read, modify, and audit the code), free (no licensing fees), secure (decades of peer review, granular permissions model), and community-backed (thousands of contributors, vast documentation, no single vendor lock-in). Windows still dominates the desktop because of its GUI, but for anything that runs in a datacenter — web servers, databases, AI training clusters, container workloads — Linux is the default.

The structure of a Linux system

Linux is layered, like an onion (or a planetary atmosphere). At the centre is the hardware: CPU, RAM, disk, NIC. Wrapping that is the Linux kernel — the engine room. The kernel talks directly to hardware, schedules processes, manages memory, and exposes system calls. Above the kernel sit system libraries and utilities (the GNU coreutils, glibc, etc.) that wrap raw system calls into usable functions like printf or open(). Finally, at the top, you have the shell and applications — bash, vim, python, your web server. You almost never touch the kernel directly; you talk to it through layers of libraries.

Linux distributions — pick your ship

Because the kernel is open source, anyone can build a complete OS on top of it. These complete packaged OSes are called distributions, or "distros" for short. Companies and communities take the Linux kernel, add a package manager, a set of default utilities, sometimes a GUI, and ship it as a product. The main distros you'll encounter:

For this manual, use Ubuntu. It's the friendliest, comes with apt pre-installed, and matches what the original course uses. Shell scripts written on one distro generally work on every other distro without modification — the kernel and system libraries are common across all of them. The differences are mostly in the package manager (apt on Debian/Ubuntu, yum/dnf on Red Hat, apk on Alpine) and the default configuration.

Package managers — your app store

A package manager is the Linux equivalent of an app store, but older, faster, and more powerful. Instead of downloading installers from random websites (the Windows way), you run one command and the package manager reaches out to a centralised repository, downloads the package, resolves all its dependencies, and installs everything in the right place. On Ubuntu, that manager is apt, and its repos live at archive.ubuntu.com and ports.ubuntu.com.

Setting up your Ubuntu environment

You have three options for getting a Linux shell on your personal machine, ranked from easiest to most involved:

Option A — WSL on Windows (recommended for Windows users)

Open PowerShell as Administrator and run wsl --install. Reboot, then run wsl to drop into a Ubuntu shell. WSL2 is not a virtual machine — it's a real Linux kernel running natively on Windows, with full filesystem integration. You can edit files in Windows Explorer and run them from the WSL terminal.

Option B — Docker container (recommended for Mac/Linux)

Spin up a Ubuntu container with a bind-mounted volume so your files persist after the container is destroyed:

Option C — Cloud VM (last resort)

You can spin up an AWS EC2 or Azure VM, but the instructor explicitly discourages this for learning — cloud billing adds anxiety, and you don't actually need a remote machine to learn Linux. Use this option only if you're already comfortable with cloud consoles and want to practice on a "real" server.

Decoding your prompt

Open a terminal and you'll see something like root@ubuntu:/# or ubuntu@ip-10-0-0-1:~$. That string is packed with information. The part before the @ is the logged-in user (root or ubuntu). The part after the @ and before the : is the hostname of the machine. The character after the colon is your present working directory: / means the root of the entire filesystem, ~ is a shorthand for the current user's home directory, and ~/projects would mean a folder called projects inside the home directory.

The single forward slash / is the most important character in Linux. It is the root of the entire filesystem — there is no C: drive, no D: drive, no drive letters at all. Everything — every file, every folder, every device, every mounted volume — lives somewhere under /. The tilde ~ is a convenience shorthand. For a regular user named ubuntu, ~ expands to /home/ubuntu. For the root user, ~ expands to /root — root is the one exception whose home is not under /home, and this trips up beginners constantly.

The cosmic map of folders

Run ls / on any Linux machine and you'll see roughly twenty top-level folders. Each one has a specific job. Below is the complete map you need to memorise — yes, memorise, because troubleshooting a Linux server without knowing where logs live is like flying blind.

The five /etc files you must know

The /etc folder is the brain of a Linux system. You will return to it constantly when troubleshooting. These five files are the ones you'll touch most often:

Navigation commands

Why user management matters

A Linux server in production is rarely used by one person. Developers deploy code, QA engineers run tests, DevOps admins configure infrastructure, managers occasionally log in to check status. If everyone shared the root password, you'd have zero accountability — when something breaks, you couldn't tell who did it. Worse, every person would have god-mode privileges, so a single typo (rm -rf /) by anyone would destroy the entire system.

The Linux answer to this is per-user identities with permission-based access. Each human (or service) gets their own user account with a unique username. When they perform any action that requires root privileges — installing software, modifying system configs, killing other users' processes — they must explicitly elevate using sudo, which logs who did what. Admins use a naming convention (typically firstname-surname or firstname.lastname) to guarantee uniqueness across thousands of users in a large organisation.

Once you have hundreds or thousands of users, managing permissions one user at a time becomes impossible. That's where groups come in. A group is a named collection of users. Instead of granting access to "alice, bob, charlie, dave, ...", you grant access to the devops group, and add or remove people from that group as they join or leave the team. One change affects everyone in the group instantly.

Creating users — two commands, one big difference

Linux gives you two commands to create a user, and the difference is a classic interview question. useradd is the low-level command — it's fast, non-interactive, and creates the user with minimal configuration. It does NOT create a home directory by default, does NOT prompt for a password, and does NOT ask for any metadata. Use it in shell scripts where you need speed and control. adduser is a higher-level wrapper — it's interactive, prompts you for the user's full name, room number, phone numbers, and password, and creates the home directory automatically. Use it for one-off human users.

The /etc/passwd & /etc/shadow duo

Every user account is recorded in /etc/passwd as a single colon-separated line: username:x:UID:GID:comment:home:shell. The x in the second field is a historical placeholder — it used to contain the hashed password, but that was moved to /etc/shadow for security. The reason: /etc/passwd must be world-readable (lots of programs need to look up usernames), so storing hashes there meant anyone could try to crack them. /etc/shadow is only readable by root, and stores the actual hashes.

Those hashes are one-way — encrypted with SHA-256 (or similar), they cannot be decrypted. When you log in, Linux hashes your typed password and compares it to the stored hash. If they match, you're in. If you forget your password, the only fix is for an admin to set a new one — there is no recovery, no "forgot password" link, no decrypt tool. Any tool that claims to recover a Linux password is lying or unsafe for production use.

Switching users & the sudo privilege

The sudo command (short for "substitute user do") lets a normal user run a single command with root privileges, without switching their entire session. It logs who ran what, which is critical for auditing. sudo su - is the shortcut to drop into a full root shell — useful when you have many admin commands to run in sequence.

Groups — managing permissions at scale

SSH — how humans actually log in

In the real world, you almost never sit at a physical Linux server. You SSH into it from your laptop. The server runs an sshd daemon (a background service) listening on port 22. You install an SSH client on your laptop (Terminal on Mac, Git Bash on Windows, ssh from any Linux shell) and run ssh user@server-ip. The client and server negotiate an encrypted tunnel, then authenticate you with either a password or an SSH key.

Cloud providers (AWS, Azure, GCP) disable password authentication by default — you must use an SSH key file (a .pem file on AWS). This is much more secure than passwords because keys can't be brute-forced. To log in with a key, you'd use ssh -i my-key.pem user@ip. The original course covers key-based auth in more depth in later episodes; for now, understand that the sshd_config file controls everything about how SSH behaves, and changes require a systemctl restart ssh to take effect.

The daily-driver file commands

Most of your time on a Linux server is spent creating, reading, moving, and deleting files. These commands form the absolute bedrock of everyday work — if you only memorise ten commands from this entire manual, eight of them should be from this chapter. The good news is they're all short and intuitive. The bad news is that one tiny character (> vs >>) can mean the difference between appending a log line and wiping out a 1000-line file. Read carefully.

Note that mv does double duty — it moves files between directories AND renames them. There's no separate rename command in daily use (there is one, but mv is what everyone actually uses). The rm -rf combination is infamous: -r means recursive (descend into subfolders), -f means force (don't ask for confirmation). Together they will happily delete anything you own — including your entire home directory if you point them at ~. Triple-check the path before pressing Enter.

Reading files — five tools, five use cases

Linux gives you many ways to read a file, and each is suited to a different situation. cat dumps the entire file to the terminal at once — great for short files, terrible for 10,000-line logs. less opens an interactive pager where you can scroll up and down with arrow keys, search with /, and quit with q — this is what you want for medium-to-large files. head shows you the first N lines; tail shows the last N. And tac (cat spelled backwards) prints the file in reverse line order — fun, rarely useful.

Writing to files — > vs >> (CRITICAL)

This is the single most important distinction in this chapter, and the one that causes the most beginner tears. The single greater-than > overwrites the entire file — whatever was there before is gone. The double greater-than >> appends — it adds your new content to the end of the file, preserving what was already there. Mix these up and you will destroy data.

Why vi, in 2025?

Every Linux distribution ships with vi or vim installed by default. Every single one. When you SSH into a random server at 3am to fix an outage, vi is the editor that will be there. Nano might be there. Emacs almost certainly won't be. VSCode definitely won't be. If you can't operate vi, you can't operate a production Linux server under pressure. That's the pragmatic reason.

The deeper reason is that vi's modal editing model is extraordinarily efficient once you internalise it. Your hands never leave the home row. There's no reaching for arrow keys, no Ctrl-Alt-Shift combinations. Every editing operation is a few keystrokes. Many senior engineers use vim (the modern fork of vi) as their daily editor even on their powerful local machines, precisely because the modal workflow scales to complex editing tasks better than most "modern" editors.

vi vs vim: vim ("vi improved") is a wrapper over vi with more features (syntax highlighting, plugins, better search). All vi commands work in vim. For learning, install vim: apt install vim (or sudo apt install vim if not root). For the rest of this chapter, "vi" and "vim" are interchangeable.

The three modes — the source of all beginner confusion

vi has three modes, and 95% of "I'm stuck in vi!" panic comes from not knowing which mode you're in. Memorise this table before you touch a file.

The workflow for any edit is: open file → press i → type your changes → press Esc → type :wq! to save & quit. If you only remember one sequence, remember that one. The ! at the end forces the operation — useful when vim complains about read-only files or unsaved changes.

The must-know shortcuts

The save & quit rituals

Beginners always struggle with quitting vim. There's a reason it's a meme. The trick is that you can't quit from Insert mode — you must first return to Normal mode by pressing Esc. Then enter Command mode by pressing :. Then type your command and press Enter. The three commands you'll use 99% of the time:

Why permissions exist

Without file permissions, any user on a Linux system could read, modify, or delete any file — including other users' private keys, the system password hashes in /etc/shadow, the binaries in /sbin, or the entire /etc directory. One careless or malicious user could destroy the entire machine. Permissions are Linux's answer to "who is allowed to do what to which file."

Every file and folder on a Linux system has a permission string attached to it, set by default when the file is created. As an admin, you can read and modify these permissions using chmod (change mode) and chown (change owner). Understanding the model is the difference between a sysadmin who can debug anything and one who's constantly confused by "Permission denied" errors.

Anatomy of a permission string

Run ls -ltr on any file and the first column you see is a 10-character string like drwxr-xr-x or -rw-r--r--. This is the permission string, and it encodes everything about who can do what with that file. Let's decode it character by character.

The first character is the type: - for a regular file, d for a directory, l for a symbolic link. The remaining nine characters split into three groups of three: user (the file's owner), group (members of the file's group), and others (everyone else on the system). Each group has three slots: r for read, w for write, x for execute. If a slot has a dash - instead of a letter, that permission is denied.

What r, w, and x actually mean

Notice that r, w, and x mean different things for files vs directories. This is a common source of confusion. In particular: to enter a directory with cd, you need execute permission on the directory — not read. To list its contents with ls, you need read. To add or remove files inside it, you need write.

The numeric (octal) system — 4, 2, 1

Instead of writing rwx, you can express the same information as a single digit from 0-7 by adding up the values: r=4, w=2, x=1. So rwx = 4+2+1 = 7. r-x = 4+0+1 = 5. r-- = 4+0+0 = 4. --- (no permissions) = 0. Three groups of these digits form the famous three-digit "chmod number" you see in tutorials.