Run a Linux server with confidence: users and permissions, services, packages, logs, SSH keys, bash scripts and scheduled jobs.

Linux Administration

Choose your option: a local VM (recommended), WSL on Windows (`wsl --install` in an administrator PowerShell, then restart), or a free-tier cloud VM.

Local VM: download the Ubuntu Server LTS ISO from ubuntu.com and create a VM with 2 CPUs, 2–4 GB RAM and a 20 GB or larger disk. Cloud VM: create a billing budget alert first, then launch the smallest free-tier eligible Ubuntu LTS instance.

Install or launch Ubuntu and create a normal user account with a password you will remember.

Log in and run `cat /etc/os-release`, `uname -r` and `hostnamectl`. Note the distro version and kernel version.

Run `free -h` and `df -h`. Note how much memory and free disk space your system has.

Run `sudo apt update` and confirm sudo asks for your password and the package lists download without errors.

Local VM: take a snapshot named "clean install" so you can roll back later. WSL: note that `wsl --export` can back up the distro. Cloud VM: write down every resource you created (instance, disk, public IP).

Cloud VM only: when you finish each study session, stop the instance; when you finish the course, delete the instance, its disk and its public IP, and confirm the billing page shows nothing running.

## Why it matters

Most of the internet runs on Linux. Web servers, databases, cloud virtual machines, containers, network appliances and the GPU machines that train machine learning models are almost all Linux systems. Cloud engineers, database administrators, security engineers and ML engineers spend a large part of their day logged in to Linux machines that have no desktop at all, only a terminal.

You already know the basics of the shell from Git & the Command Line. This course moves from "using a terminal" to "running a system": users and permissions, services, packages, logs, remote access and automation. To practise that safely you need a Linux system of your own that you are allowed to break.

## What a distribution is

Linux itself is only the **kernel**: the core program that talks to the hardware, schedules processes and manages memory. A **distribution** (distro) bundles the kernel with everything else you need: a shell, core tools, a package manager, a service manager and default settings.

Distros come in families that share a package format and most commands:

| Family | Examples | Package tool | Where you meet it |
|---|---|---|---|
| Debian | Debian, Ubuntu, Linux Mint | `apt` (`.deb`) | Cloud VMs, laptops, most tutorials |
| Red Hat | RHEL, Fedora, Rocky Linux, AlmaLinux | `dnf` (`.rpm`) | Enterprise servers, banks, government |
| Others | Arch, Alpine, SUSE | `pacman`, `apk`, `zypper` | Hobbyists, tiny containers, some enterprises |

This course uses **Ubuntu Server LTS** for its examples. "LTS" means long-term support: about five years of security updates, which is why it is so common on servers. Almost everything you learn transfers to the other families; where a command differs (for example `apt` versus `dnf`), the lesson says so.

## Three safe ways to get a practice system

Do all of the work in this course on a practice system, **never on a work laptop, a school machine or any production server**. Administration commands can delete data, lock you out or stop services that other people rely on. On your own throwaway system, a mistake only costs you a reinstall.

1. **A local virtual machine (recommended).** A hypervisor such as VirtualBox (Windows, Linux, Intel Macs) or UTM (Apple silicon Macs) runs a whole computer inside a window. Download the Ubuntu Server ISO from ubuntu.com, create a VM with 2 CPUs, 2–4 GB RAM and a 20–25 GB disk, and install. The big advantage is **snapshots**: save the VM's state before a risky step and roll back if it goes wrong.
2. **WSL on Windows.** The Windows Subsystem for Linux runs a real Ubuntu userland beside Windows. In an administrator PowerShell run `wsl --install`, restart, and create a Linux username and password. WSL is quick to set up. Recent versions support systemd, but a few service lessons behave differently from a full VM, so a VM is still the better choice if your computer can run one.
3. **A free-tier cloud VM.** AWS, Google Cloud, Azure and Oracle Cloud offer small free-tier instances. This is the closest to real work, but it is a machine on the public internet and it can cost money if you pick the wrong size or forget to delete it. If you go this way, set a budget alert first, choose a size labelled "free tier eligible", and delete the instance (and its disk and public IP) when you finish.

## Your first look around

After installing, log in and confirm what you are running:

```bash
cat /etc/os-release     # distro name and version
uname -r                # kernel version
hostnamectl             # hostname, OS, kernel, architecture
whoami                  # your username
free -h                 # memory in human-readable units
df -h                   # disk usage per filesystem
```

On Ubuntu, `/etc/os-release` shows something like `PRETTY_NAME="Ubuntu 24.04.1 LTS"`. The kernel version from `uname -r` is separate from the distro version, because the kernel is a separate project.

### What sudo is

Your user is a normal account. Administrative commands need root privileges, which you get one command at a time with `sudo`:

```bash
sudo apt update
```

`sudo` asks for **your** password, logs the command and runs it as root. Use it only when a command needs it, and only on your practice system. A good habit: read the full command before pressing Enter whenever it starts with `sudo`.

## Common mistakes

- **Practising on a real machine.** Even "harmless" changes to permissions or services can break a shared or work system. Use the VM.
- **Skipping snapshots.** Take one right after a clean install, and before any lesson that changes SSH or services. Rolling back takes seconds.
- **Too little disk.** A 10 GB disk fills quickly once you install packages. Give the VM at least 20 GB.
- **Forgetting the cloud VM.** A stopped instance can still bill for its disk and public IP. Delete what you created.
- **Running everything as root.** Logging in as root, or typing `sudo -i` and staying there, removes your safety net. Stay a normal user and use `sudo` per command.

## Recap

- Linux is the kernel; a distribution adds tools, a package manager and defaults.
- Debian/Ubuntu (`apt`) and Red Hat family (`dnf`) cover most servers you will meet.
- Practise on a local VM (best), WSL, or a free-tier cloud VM with a budget alert and a cleanup plan.
- `cat /etc/os-release`, `uname -r`, `free -h` and `df -h` tell you what you are working on.
- `sudo` runs one command as root; use it deliberately and only on your practice system.

## Try it

Open the Do tab and set up the practice system you will use for the rest of the course.


Choose a Linux distribution and set up a safe practice system in a virtual machine, WSL or a free-tier cloud VM.

Distros and installing Linux

How to Install Ubuntu 24.04 LTS on VirtualBox in Windows 11

WSL 2: Getting started

Run `ls /` and match each top-level folder you see to its role from the lesson table.

Find where the `ls`, `python3` and `systemctl` programs live with `which ls python3 systemctl`.

List the SSH configuration folder with `ls /etc/ssh/` and view the start of the hosts file with `cat /etc/hosts`.

Find every file named `*.conf` directly in `/etc` with `find /etc -maxdepth 1 -name "*.conf" 2>/dev/null` and count them by adding `| wc -l`.

Run `ls -lh /var/log` and identify the log that records logins and sudo use (on Ubuntu, `auth.log`).

Read two kernel-generated files: `head -5 /proc/meminfo` and `grep -c processor /proc/cpuinfo`. Compare the numbers with `free -h` and `nproc`.

Check disk use with `df -h /` and find the size of the log folder with `sudo du -sh /var/log`.

Find the three biggest folders inside `/var` with `sudo du -sh /var/* 2>/dev/null | sort -h | tail -3`.

## Why it matters

When a service misbehaves on a server, the questions are always the same: where is its configuration, where are its logs, and which program is actually running? On Linux the answers follow a shared map called the **Filesystem Hierarchy Standard (FHS)**. Once you know the map, you can find your way around almost any Linux machine, including one you have never seen before.

## One tree, starting at /

Windows has drive letters (`C:\`, `D:\`). Linux has a single tree that starts at the **root directory**, written `/`. Extra disks, USB drives and network shares are **mounted** somewhere inside that tree instead of getting their own letter. Run `ls /` and you will see the top level.

| Directory | What it holds | Example |
|---|---|---|
| `/etc` | System-wide configuration, mostly plain text | `/etc/ssh/sshd_config`, `/etc/hosts` |
| `/var` | Data that changes while the system runs | `/var/log/` (logs), `/var/lib/` (databases, package state) |
| `/usr` | Installed programs and their read-only files | `/usr/bin/python3`, `/usr/share/doc/` |
| `/bin`, `/sbin` | Essential commands (on modern distros, links into `/usr`) | `/bin/ls` |
| `/home` | One folder per normal user | `/home/alex` |
| `/root` | The root user's home folder | |
| `/tmp` | Temporary files, often cleared on reboot | |
| `/opt` | Optional, self-contained third-party software | `/opt/someapp/` |
| `/dev` | Device files for disks, terminals and more | `/dev/sda`, `/dev/null` |
| `/proc`, `/sys` | Virtual files the kernel generates about processes and hardware | `/proc/cpuinfo` |
| `/boot` | Kernel and bootloader files | |
| `/mnt`, `/media` | Mount points for extra or removable drives | |

A useful rule of thumb: **config in `/etc`, changing data and logs in `/var`, programs in `/usr`, people in `/home`.**

## "Everything is a file"

Linux exposes a lot of the system as files. Your disk is `/dev/sda` (or `/dev/vda` in many VMs). `/dev/null` is a black hole that discards whatever is written to it. `/proc/meminfo` is not stored on disk at all: the kernel generates its contents when you read it.

```bash
cat /proc/cpuinfo | grep "model name" | head -1
cat /proc/meminfo | head -3
```

This is why so many admin tasks come down to reading or editing a text file.

## Finding things

### Where is a program?

```bash
which python3          # path of the command your shell would run
type ls                # also shows aliases and shell built-ins
```

`which python3` prints something like `/usr/bin/python3`.

### Where is a config file?

Configuration for a program is usually in `/etc/<program>` or `/etc/<program>.conf`:

```bash
ls /etc/ssh/
ls /etc | head -30
```

When you do not know the name, search by name with `find`. Searching system folders produces "Permission denied" noise for folders you cannot read, so send errors to `/dev/null`:

```bash
find /etc -name "*.conf" 2>/dev/null | head
find / -name "sshd_config" 2>/dev/null
```

### Where are the logs?

Traditional text logs live in `/var/log`:

```bash
ls -lh /var/log
```

On Ubuntu you will see `syslog`, `auth.log` (logins and sudo), `dpkg.log` (package installs) and folders for individual services. Many systems also keep logs in the systemd journal, which a later lesson covers.

### What is using my disk?

```bash
df -h                       # free space per mounted filesystem
du -sh /var/log             # total size of one folder
sudo du -sh /var/* 2>/dev/null | sort -h | tail -5
```

`df` answers "how full is each disk?" and `du` answers "which folder is big?". A full disk is one of the most common causes of a broken server, and `/var/log` is a frequent culprit.

## Absolute and relative paths, again

An **absolute path** starts at `/` and works from anywhere: `/etc/hosts`. A **relative path** starts from your current folder: `../notes.txt`. In scripts and config files, prefer absolute paths, because the "current folder" of a script run by a scheduler is often not what you expect.

## Common mistakes

- **Editing files in `/usr`.** Package updates overwrite them. Put local configuration in `/etc` and your own scripts in `/usr/local/bin` or your home folder.
- **Deleting files in `/var/log` to free space** while a service has them open. The space is not freed until the service restarts. Use the log rotation and journal tools you will meet later instead.
- **Treating `/tmp` as storage.** It can be wiped at reboot.
- **Running `find /` without silencing errors**, then missing the real result in a wall of "Permission denied".

## Recap

- Linux has one tree rooted at `/`; extra drives are mounted into it.
- Config lives in `/etc`, logs and changing data in `/var`, programs in `/usr`, users in `/home`.
- `/proc`, `/sys` and `/dev` expose the kernel and devices as files.
- `which`, `find`, `ls /var/log`, `df -h` and `du -sh` find programs, configs, logs and disk hogs.

## Try it

The Do tab has a scavenger hunt through your practice system's filesystem.


Learn what lives in /etc, /var, /usr, /home and the other top-level folders, and find any config, log or program.

The filesystem hierarchy

Linux Crash Course: Navigating the Linux Filesystem

Linux Directories Explained in 100 Seconds

Run `id` and `ls -l ~` and read your uid, groups and the permission string of one file.

Create a test user and a group: `sudo adduser maria` (any password), then `sudo groupadd webteam`.

Add both users to the group with `sudo usermod -aG webteam maria` and `sudo usermod -aG webteam $USER`, then confirm with `groups maria`.

Create the shared folder: `sudo mkdir -p /srv/webteam`, `sudo chown root:webteam /srv/webteam`, `sudo chmod 2770 /srv/webteam`. Check it with `ls -ld /srv/webteam`.

Log out and back in (or run `newgrp webteam`), then create a file with `touch /srv/webteam/plan.txt` and confirm with `ls -l` that its group is webteam.

Make the file readable by the group but writable only by you: `chmod 640 /srv/webteam/plan.txt`. Verify the string reads `-rw-r-----`.

Switch to the test user with `su - maria`, try `cat /srv/webteam/plan.txt` (should work) and `echo hi >> /srv/webteam/plan.txt` (should fail). Type `exit` to return.

Create a script with `printf '#!/bin/bash\necho hello\n' > ~/hello.sh`, try `./hello.sh` (permission denied), then `chmod u+x ~/hello.sh` and run it again.

Clean up: `sudo deluser --remove-home maria`, `sudo groupdel webteam` and `sudo rm -r /srv/webteam`.

## Why it matters

Linux was built for many users sharing one machine, and that design is still what keeps servers safe. A web server process should be able to read its web files but not your SSH keys. A database's data folder should be writable by the database and nobody else. Most "permission denied" errors you will debug, and many security findings, come down to the ideas in this lesson.

## Users and groups

Every process runs as a **user**, and every user belongs to one or more **groups**.

```bash
whoami          # your username
id              # your user id (uid), main group and all groups
getent passwd alex
getent group sudo
```

- **root** (uid 0) can do anything. Normal users get admin rights through `sudo`, which on Ubuntu is granted by membership of the `sudo` group (`wheel` on the Red Hat family).
- **System users** such as `www-data`, `mysql` or `sshd` have no login and exist so that each service runs with only its own rights.
- User accounts are listed in `/etc/passwd`; password hashes are in `/etc/shadow`, which only root can read.

Creating users and groups (on your practice system):

```bash
sudo adduser maria                 # interactive on Debian/Ubuntu (useradd -m on others)
sudo groupadd webteam
sudo usermod -aG webteam maria     # -a = append; without it you REPLACE her groups
groups maria
```

## Reading permissions

`ls -l` shows the permissions of each file:

```text
-rw-r----- 1 alex webteam 1204 Oct 23 09:12 report.txt
drwxr-x--- 2 alex webteam 4096 Oct 23 09:10 shared
```

Break the first column into four parts:

| Part | `report.txt` | Meaning |
|---|---|---|
| Type | `-` | `-` file, `d` directory, `l` symlink |
| Owner (u) | `rw-` | alex can read and write |
| Group (g) | `r--` | members of webteam can read |
| Others (o) | `---` | everyone else gets nothing |

The letters mean different things for files and directories:

| | File | Directory |
|---|---|---|
| `r` | read the contents | list the names inside |
| `w` | change the contents | create, rename or delete entries inside |
| `x` | run it as a program | enter it (`cd`) and reach files inside |

The directory `x` surprises many people: without it you cannot open a file inside, even if the file itself is readable.

## chmod: changing permissions

**Symbolic mode** adds (`+`), removes (`-`) or sets (`=`) letters for `u`, `g`, `o` or `a` (all):

```bash
chmod u+x backup.sh        # owner may run it
chmod g+w report.txt       # group may edit it
chmod o-r report.txt       # others may no longer read it
chmod u=rwx,g=rx,o= shared # exact set
```

**Octal mode** sets everything at once. Each digit is a sum: read 4, write 2, execute 1.

| Octal | Letters | Typical use |
|---|---|---|
| `644` | `rw-r--r--` | normal files |
| `640` | `rw-r-----` | files only a group may read |
| `600` | `rw-------` | private files, SSH private keys |
| `755` | `rwxr-xr-x` | programs, scripts and normal folders |
| `750` | `rwxr-x---` | a team folder |

```bash
chmod 640 report.txt
chmod 750 shared
chmod -R g+rX shared       # recursive; capital X adds x only to folders
```

## chown: changing owner and group

Only root can give a file to another user, so `chown` usually needs `sudo`:

```bash
sudo chown maria report.txt            # new owner
sudo chown maria:webteam report.txt    # owner and group
sudo chgrp webteam shared              # group only
sudo chown -R www-data:www-data /var/www/site
```

## Worked example: a shared team folder

Goal: alex and maria can both edit files in `/srv/webteam`; nobody else can see inside.

```bash
sudo mkdir -p /srv/webteam
sudo chown root:webteam /srv/webteam
sudo chmod 2770 /srv/webteam      # rwx for owner and group, nothing for others
sudo usermod -aG webteam alex
```

The leading `2` sets the **setgid** bit on the folder, so new files created inside inherit the `webteam` group instead of the creator's personal group. Group changes apply at your next login, so log out and back in (or run `newgrp webteam`) before testing.

## Default permissions: umask

New files do not start at `777`. The **umask** removes bits from the default. With the common umask `022`, new files get `644` and new folders `755`. Run `umask` to see yours.

## Common mistakes

- **`chmod 777` to "fix" a permission error.** It lets every user and every compromised service change the file. Find out which user needs access and grant exactly that.
- **`usermod -G` without `-a`**, which silently removes the user from every other group, sometimes including `sudo`.
- **Forgetting the directory `x` bit**, so a readable file inside an unreadable folder still cannot be opened.
- **Recursive `chmod -R 644` on a folder**, which strips `x` from its subfolders so nobody can enter them. Use `X` or `find -type f`/`-type d`.
- **Testing group changes without logging in again.**

## Recap

- Every process runs as a user; groups share access between users.
- `ls -l` shows type, then owner/group/others permissions as `rwx`.
- `chmod` changes permissions (symbolic or octal: r=4, w=2, x=1); `chown` changes owner and group.
- Grant the least access that works; never reach for `777`.

## Try it

Use the Do tab to build a shared team folder on your practice system and prove who can and cannot get in.


Read rwx permissions, create users and groups, and control access with chmod and chown.

Users, groups, and permissions

Linux Crash Course - Understanding File & Directory Permissions

How to use chmod | Manage File Permissions in Linux

Set up a safe practice system, find your way around the filesystem, and control access with users, groups and permissions.