Module 1: Linux Foundations

Distributions and Choosing One

Linux is not one product. The Linux kernel is the core that talks to the hardware, and a distribution (or "distro") wraps that kernel with a package manager, system tools, default settings, a release schedule and a support policy. When you administer a server you are really administering a distribution, so knowing which family you are on tells you which commands, file locations and package formats to expect. Choosing well at the start saves you from painful migrations later.

The main families you will meet

Most servers you will work on belong to one of two large families, plus a few specialist options.

• Debian family: Debian and Ubuntu (and Ubuntu-based systems). Packages use the .deb format and are managed with apt. Ubuntu Server is extremely common on cloud providers and in tutorials.
• Red Hat family: Red Hat Enterprise Linux (RHEL) and compatible rebuilds such as AlmaLinux and Rocky Linux, plus Fedora as the fast-moving upstream. Packages use the .rpm format and are managed with dnf (older releases used yum).
• Others: SUSE Linux Enterprise and openSUSE (using zypper), Alpine Linux (very small, popular inside containers, using apk), and Arch Linux (rolling release, popular with enthusiasts but less common on production servers).

The good news is that the skills in this course transfer across all of them. The shell, permissions, processes, systemd, SSH and Bash scripting work the same way. The main differences are the package manager, some configuration file paths and the default firewall tool.

Release models and support lifetimes

For a server, stability and security updates matter more than having the newest features. Distributions follow two broad release models:

• Fixed (point) releases: a version is released, then receives security and bug fixes for a defined period without major changes. Ubuntu marks some releases as LTS (Long Term Support). Debian stable, RHEL, AlmaLinux and Rocky Linux also follow this model with multi-year support windows.
• Rolling releases: packages update continuously (Arch, openSUSE Tumbleweed). You always have recent software, but changes arrive at any time, which is a risk on a production server.

Support periods change and differ between versions, so always check the vendor's official lifecycle page (for example the Ubuntu release cycle page or the Red Hat lifecycle page) before you commit. A server running a release that is past its end of life no longer receives security fixes, which is a serious risk.

How to choose: a practical checklist

1. What does the software require? Check the documentation of the application you will run. If a vendor supports only RHEL-compatible systems, that decides it.
2. What does your team already know? A distro your colleagues understand is safer than a "better" one nobody can fix at 2 a.m.
3. Where will it run? Cloud providers offer ready images. Ubuntu LTS, Debian and RHEL-compatible images are widely available.
4. How long must it run? Pick a release with support that comfortably covers the planned life of the server.
5. Do you need commercial support? Some organisations, such as banks, require a paid support contract, which points to RHEL, SUSE or Ubuntu with a support subscription.

Worked example: identifying a system

Imagine you have just been given SSH access to a server for a Nairobi online shop. Before changing anything, find out what it is running. The file /etc/os-release exists on virtually every modern distribution:

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
ID=ubuntu
ID_LIKE=debian
...

$ uname -r
6.8.0-45-generic

$ hostnamectl
 Static hostname: shop-web-01
 Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-45-generic
    Architecture: x86-64

The ID_LIKE=debian line tells you this is a Debian-family system, so you will use apt. uname -r shows the running kernel version and hostnamectl gives a tidy summary. (Your output will show different version numbers; the ones above are only an example.) Running these three commands on every new server you touch is a good habit.

Setting up your practice environment

You need a Linux system you can safely break. Good options are a virtual machine in VirtualBox or similar, Windows Subsystem for Linux (WSL) on Windows, Multipass on Windows, macOS or Linux, or a small cloud server. For this course, Ubuntu Server LTS is a sensible default because most examples are easy to follow on it. Where commands differ on RHEL-compatible systems, the lessons show both.

Common mistakes to avoid

• Choosing a desktop or rolling distro for production because it is what you use on your laptop.
• Ignoring end-of-life dates. Track them and plan upgrades early.
• Copying commands from a tutorial written for another family, for example running yum on Ubuntu, then "fixing" the error in strange ways.
• Practising on a real production server. Always use a lab machine first.