Learning AlmaLinux - Core Concepts & Main Architecture

#Introduction

In the previous episode, Episode 1, we traced the history and background: why AlmaLinux was born from the retirement of CentOS, how it became a community-managed RHEL rebuild, and why 1:1 compatibility is its main promise. In this episode we'll peek inside the machine: how AlmaLinux is built and what its main components are.

Understanding this architecture matters because it determines how you think when managing the system. When a service isn't running, you need to know which of these components is the problem. When you add a repository, you need to know how that repository connects to the system. Let's break it down layer by layer.

#Rebuild Architecture: From RHEL SRPMs to AlmaLinux Repositories

We got to know the term "rebuild" in episode 1, but let's look at the process technically. RHEL publishes its source code as SRPMs (Source RPMs) — packages containing source code and spec files for building binaries. The AlmaLinux project takes these SRPMs, then:

1. Rebuilds each SRPM into binary RPMs using its own build infrastructure.
2. Removes Red Hat branding and replaces it with AlmaLinux branding.
3. Signs the build results with the official AlmaLinux GPG key.
4. Publishes them to public repositories accessible to everyone.

The result is a repository whose contents are identical in binary behavior to RHEL, but hosted and managed entirely by the AlmaLinux OS Foundation.

rpm -qa --qf '%{NAME} %{VERSION} %{RELEASE} %{SIGPGP:pgpsig}\n' kernel
dnf5 repolist

The output of dnf5 repolist shows the active repositories — this is the main gateway for software distribution on your system. We'll cover the full details in episode 4.

#Kernel and ABI Compatibility

Two technical terms you must understand:

• Kernel compatibility — the AlmaLinux kernel is built from the same source as the RHEL kernel, so its behavior and features are consistent.
• ABI (Application Binary Interface) — the binary-level contract between a program and the operating system. Because the ABI is identical, programs compiled for RHEL run on AlmaLinux without recompiling.

This is the most important guarantee for enterprise users: you can build an application once, then run it on RHEL, AlmaLinux, and Rocky without changes. New hardware support also arrives with the 9.x and 10.x releases, so the AlmaLinux kernel can always handle modern devices.

#Main AlmaLinux Components

AlmaLinux isn't one giant program — it's an ecosystem composed of many components working together. Here are the most important ones.

#The Linux Kernel

The core of the operating system: managing processes, memory, hardware, and networking. AlmaLinux uses the kernel from the RHEL kernel branch, thoroughly tested for production stability. You can check the running kernel version with:

uname -r

#GNU Userland

On top of the kernel sits the GNU userland — the collection of standard utilities (ls, cp, grep, bash, and hundreds more) that form your everyday interface. Together with the kernel and the glibc library, this is the foundation of the Linux system you've known since episode 0.

#dnf5

AlmaLinux's modern package manager that handles installation, updates, and repository management. On AlmaLinux 9 it ships as dnf (with dnf5 as an option), and on AlmaLinux 10 it becomes the default. We'll dive deep into this component in episodes 4 and 5.

#systemd

The init system and service manager that runs all system processes — from mounting filesystems at boot to automatically restarting crashed services. Almost every service on AlmaLinux is managed by systemd, and we'll break it down in episode 7.

#SELinux

The Mandatory Access Control layer that restricts what processes are allowed to do — even root. SELinux is active by default on AlmaLinux in enforcing mode, and it's one of the main reasons for the RHEL ecosystem's security. We'll cover it starting from episode 13.

#firewalld

The zone-based dynamic firewall manager that filters incoming and outgoing traffic. It's the default on AlmaLinux, configured with firewall-cmd. We'll cover networking and firewalld in episode 9.

#Cockpit

The system management web server that lets you manage services, users, logs, and updates through a browser. Very useful for admins who like a visual interface. Details in episode 11.

#Core Repositories: BaseOS and AppStream

One of the most important architectural changes in the RHEL 8+ era is the split of the repositories into two main ones:

BaseOS contains the foundation packages: kernel, glibc, systemd, and the like. AppStream contains applications and runtimes such as Python, Node.js, PostgreSQL, and Nginx — and this is where the module concept lives, which allows one application to be available in several versions at once. We'll break that down in episode 5.

Besides those two, there are complementary repositories:

• CRB (CodeReady Builder) — packages for developers and build tooling.
• Extras — additional packages that don't fit into BaseOS/AppStream.
• Devel — AlmaLinux's internal development packages.
• EPEL — a very popular third-party repo from the Fedora ecosystem for additional packages.

dnf5 repolist --all

The output of this command shows all repositories known to the system, including both enabled and disabled ones.

#AlmaLinux-Specific Tools

As a standalone distribution, AlmaLinux ships several unique tools that RHEL doesn't have:

• dnf-almalinux — AlmaLinux's official plugins and tools for distribution needs.
• ELevate — the Leapp-based tool for in-place migration between major versions.
• almalinux-deploy — the tool for converting CentOS to AlmaLinux.

dnf5 repolist --verbose | head
dnf5 config-manager setopt tsflags=test

#Common Pitfalls

1. Thinking the AlmaLinux kernel is the exact same kernel as RHEL's. The source is the same and the behavior is consistent, but the version and naming can differ by a number or two — don't rely on an exact uname -r match.
2. Relying only on the default repositories. EPEL and CRB are often needed for additional software — but enable them deliberately, don't just install carelessly.
3. Thinking AppStream and BaseOS are ordinary repositories. The difference between them determines how you manage software versions — an understanding that will be tested in episode 5.
4. Skipping the security components. SELinux, firewalld, and systemd aren't optional extras — all three are active by default and must be understood as core parts of the architecture.

#Conclusion

In this episode 2 we've broken down AlmaLinux's architecture from the inside: the rebuild process from RHEL SRPMs into AlmaLinux repositories, the kernel and ABI compatibility guarantees, the main components (kernel, GNU userland, dnf5, systemd, SELinux, firewalld, Cockpit), the BaseOS and AppStream repository split, and AlmaLinux-specific tools like dnf-almalinux and ELevate.

Key takeaways:

• AlmaLinux is built from RHEL SRPMs and published as an independent repository with its own GPG signing.
• Kernel and ABI compatibility is the guarantee of binary compatibility with RHEL.
• Core system components: kernel, GNU userland, dnf5, systemd, SELinux, firewalld, and Cockpit.
• Main repositories: BaseOS (core) and AppStream (multi-version apps), plus CRB, Extras, and EPEL.
• AlmaLinux-specific tools: dnf-almalinux, ELevate, and almalinux-deploy.

This architectural understanding becomes the lens for all the following episodes. In the next episode, Episode 3, we'll move into real action: installation & deployment — from the Anaconda installer, software set selection, LVM and Btrfs partitioning, UEFI Secure Boot, to automated deployment with Kickstart and cloud-init. Get your lab ready, because from now on we'll be doing a lot of hands-on practice!