Skip to main content
In this lesson you will learn how DNF uses repositories on Red Hat Enterprise Linux 10 (RHEL 10), how to view and manage repository configuration, and how to create and use a custom repository. Most software on RHEL 10 is distributed as RPM packages and managed with DNF.
A dark presentation slide titled "Software Management on RHEL 10" showing two rounded boxes: one labeled "RHEL 10" with a server icon and an arrow pointing to another labeled "RPM" with a package icon.
Historically administrators used YUM on older Red Hat releases; on modern systems like RHEL 10, DNF is the standard package manager. DNF installs, updates, removes, and searches packages — but it relies on repositories to locate those packages.
A dark presentation slide titled "From YUM to DNF" showing a left panel for legacy YUM (used on older RHEL releases) and a right panel for DNF (standard today, the tool to use on RHEL 10). A blue arrow between the panels indicates the migration from YUM to DNF.
What DNF does:
A dark slide titled "What DNF Does and Where It Looks" showing four outlined panels with icons and labels: Install, Update, Remove, and Search. Each panel contains a simple teal icon representing the respective action.
Because RHEL is subscription-based, systems must be registered with Red Hat to access the official Red Hat repositories. If a system is not registered, package operations such as install or update can fail.
A dark-themed infographic slide that says "Register First, Then You Get Access" and highlights "Register the system with Red Hat" inside a rounded box with a key icon. A downward arrow points toward another box labeled "Official Repositories."
A dark-themed infographic titled "Not Registered? Expect Errors" showing a boxed warning "System not registered" with arrows pointing to two panels labeled "Install fails" and "Update fails."
Register your system with subscription-manager and attach an appropriate subscription using your Red Hat account credentials:
Registering is required to access Red Hat’s official repositories. Without it, DNF cannot retrieve packages from those repositories.

Repository basics

A repository (repo) is a location that stores RPM packages and metadata. Repositories can be:
  • Official Red Hat repositories (requires subscription/registration).
  • Third-party repositories (e.g., Docker, vendor repos).
  • Internal/private repositories hosted inside your organization.
DNF reads repository definitions from files in /etc/yum.repos.d/ (files ending in .repo) or from files managed by subscription-manager (e.g. /etc/yum.repos.d/redhat.repo).

Common repository commands

  • List enabled repositories:
  • List enabled repositories with detailed info including base URL:
  • List all repositories, including disabled ones:
  • Enable/disable repositories with subscription-manager:
  • Toggle repositories without editing files using dnf config-manager (provided by dnf-plugins-core):

Understanding .repo files

Repo definitions use a simple INI-style format. Files belong in /etc/yum.repos.d/ and must end with .repo. A repository stanza looks like:
  • [repo-id] — short identifier (required)
  • name — human-friendly name (recommended)
  • baseurl — URL or local path where packages/metadata are stored
  • enabled — 1 (enabled) or 0 (disabled)
  • gpgcheck — 1 to verify package signatures (recommended)
  • gpgkey — URL or file path to the signing key
Use the table below for a quick reference: Example .repo file (Docker CE):
Knowing how .repo files work is useful even if you primarily use subscription-manager or dnf config-manager.

Demo: create and use a custom repository

The following demo shows how to add a custom repo file, refresh metadata, inspect available packages, and install a package from that repository. Use caution when mixing repositories from different distributions or major releases.
Mixing repositories from a different distribution or a different major release (for example, adding Rocky Linux 9 repositories to a RHEL 10 system) can cause dependency conflicts and break package resolution. Use such cross-distro repositories only for isolated testing. Also, setting gpgcheck=0 disables package signature verification and is insecure for production; prefer gpgcheck=1 with a valid gpgkey.
  1. Create a new repo file:
Add the following contents (example pointing to Rocky Linux 9 BaseOS):
  1. Refresh DNF metadata and cache:
During makecache DNF downloads repository metadata for enabled repositories — you should see the metadata for rocky-baseos if the baseurl is reachable.
  1. Verify the repository is active:
Example truncated output might include:
  1. List available packages from the new repository:
Sample package list (truncated):
  1. Install a package from the repository:
You should see a transaction summary and download progress. Example (truncated):

Notes on repository versions and priorities

  • Package versions and release tags (e.g., .el9, .el10) will vary depending on repository origin. Mixing repos from different major releases can introduce incompatible packages.
  • Consider repository priorities or modular filtering if you need to control which repo provides a package on systems with many enabled repositories. RHEL provides tooling and best practices to manage this in production.

Toggling a repository quickly

You can enable or disable repositories without editing files using dnf config-manager:

Summary

After this lesson you should be able to:
  • Register a system to access Red Hat repositories.
  • List repositories and inspect repository metadata.
  • Enable or disable repositories via subscription-manager or dnf config-manager.
  • Create a .repo file manually and refresh repository metadata.
  • List packages in a specific repository and install packages from it.

Watch Video

Practice Lab