Mastering DNF & Repository Management for RHCSA (RHEL 10)

Objectives

Package management is the backbone of Linux system administration. For RHCSA certification, it's a skill you'll use in almost every exam scenario. Whether you're installing software, managing updates, or configuring custom repositories, your proficiency with DNF (Dandified Yum) and repository management directly impacts your ability to complete exam tasks efficiently and correctly. The RHCSA exam for RHEL 10 emphasizes practical package management skills, including configuring repository access, managing package installations and updates, working with package groups, and understanding the newer AppStream module system. More importantly, you may encounter scenarios where the standard Red Hat repositories aren't available, requiring you to configure local or custom repositories to complete installation tasks.

This comprehensive guide walks you through everything you need to know about package management for RHCSA success. You'll learn basic DNF operations, custom RPM repository creation, package group management, and AppStream module configuration. By mastering these concepts, you'll approach package management scenarios with confidence and efficiency.

Why Repository Management Matters for RHCSA Certification

Repository management represents a critical intersection of knowledge and practical skills that RHCSA candidates must master. During the exam, you cannot assume that internet access or standard Red Hat repositories will be available. Many exam scenarios deliberately restrict network access or require you to configure alternative repository sources to complete package installation tasks. Understanding repository configuration goes beyond memorizing commands—it demonstrates your ability to adapt to different enterprise environments. Custom repositories, local mirrors, and isolated networks are common in real-world production environments. Organizations frequently use local repository mirrors to control software versions, reduce external bandwidth usage, and maintain systems in secure, air-gapped networks.

The exam objectives explicitly require candidates to configure access to Red Hat software repositories and manage software installations using DNF. This isn't limited to simple package installations—you need to understand repository priority, troubleshoot repository access issues, work with repository metadata, and configure systems to use local repository sources when standard repositories aren't accessible.

Key Exam Tip: Always verify that your repository configuration persists across reboots. The exam may reboot your system, and configurations must survive to earn full points.

Understanding DNF and the Evolution from Yum

DNF (Dandified Yum) serves as the default package manager in RHEL 10, representing an evolution from the older Yum package manager. While DNF maintains backward compatibility with most Yum commands and syntax, understanding the improvements and architectural changes helps you use it more effectively.

What DNF Brings to RHEL 10

DNF addresses several performance and functionality limitations of Yum while maintaining a familiar command structure for administrators transitioning from RHEL 7 and earlier versions. The underlying dependency resolver in DNF is more sophisticated, handling complex package dependencies more reliably and producing better error messages when dependency conflicts occur. Performance improvements in DNF make repository metadata operations significantly faster than Yum, particularly when working with large repository sets or performing complex queries. DNF also uses less memory during operations, making it more suitable for resource-constrained systems or containers where efficient resource usage matters.

The modular content delivery system, known as AppStream modules, represents one of DNF's most significant new capabilities. This system allows multiple versions of software to coexist in repositories, letting administrators choose specific versions of applications or language runtimes while maintaining a stable base operating system. Understanding modules is essential for RHCSA candidates, as the exam may present scenarios requiring specific software versions that only modules can provide.

Backward Compatibility with Yum

For RHCSA purposes, you'll find that most Yum commands work identically in DNF. The command yum install package-name and dnf install package-name perform the same operation. Red Hat maintains this compatibility intentionally, allowing administrators and scripts to transition gradually from Yum to DNF without immediate rewrites. However, understanding that DNF is the modern, supported tool matters for exam scenarios and professional practice. While you can use yum commands on RHEL 10 (they redirect to DNF), demonstrating knowledge of DNF shows you understand current best practices. On the exam, either command syntax will work, but using DNF aligns with Red Hat's current direction.

Essential DNF Commands for RHCSA

Before diving into custom repository creation, mastering fundamental DNF operations ensures you can complete basic package management tasks efficiently during the exam. These commands form the foundation of daily package management work.

Installing and Removing Packages

Package installation represents the most common DNF operation you'll perform. The basic installation syntax is straightforward:

dnf install httpd

This command installs the Apache web server along with all required dependencies. DNF automatically resolves dependencies, downloads necessary packages from configured repositories, and installs everything in the correct order. During the exam, you might encounter scenarios requiring specific services or applications, and efficient package installation is your first step.

To install multiple packages simultaneously, simply list them space-separated:

dnf install httpd mariadb-server php

This approach is more efficient than multiple individual installations, as DNF resolves all dependencies together and minimizes repository metadata queries.

Package removal follows similar syntax:

dnf remove httpd

By default, DNF removes the specified package but doesn't automatically remove dependencies that were installed with it. If you want to remove unused dependencies after package removal, use:

dnf autoremove

This command identifies and removes packages that were installed as dependencies but are no longer required by any installed software. It's a useful maintenance operation for keeping systems clean and reducing storage usage.

Updating Packages and the System

Keeping systems updated with security patches and bug fixes is a fundamental administrative responsibility. DNF provides several update-related commands that RHCSA candidates must understand.

To update a specific package to its latest available version:

dnf update httpd

This updates Apache to the newest version in your configured repositories. DNF checks dependencies and ensures the update won't break other installed software before proceeding.

To update all packages on the system:

dnf update

This comprehensive update brings all installed packages to their latest available versions. Before applying updates, DNF displays a summary of packages to be updated, upgraded, or installed, along with the total download size. You must confirm before DNF proceeds with the updates.

The command dnf upgrade performs the same operation as dnf update. Red Hat documentation uses these terms interchangeably, and both are acceptable on the exam. Understanding that they're equivalent prevents confusion when you encounter either term.

Querying Package Information

Information queries help you understand what's installed, what's available, and what packages contain. These queries are essential for troubleshooting and completing exam scenarios where you need to identify the correct package to install.

To search for packages by name or description:

dnf search web server

This searches repository metadata for packages containing "web" or "server" in their name or description. Search results help you identify the correct package when you know what functionality you need but not the specific package name.

To get detailed information about a specific package:

dnf info httpd

This displays comprehensive information including the package version, architecture, repository source, installation size, and a detailed description. During troubleshooting, this information helps verify you're working with the correct package version.

To list all installed packages:

dnf list installed

This produces a complete list of everything currently installed on the system. You can filter results by piping to grep:

dnf list installed | grep httpd

To check if a specific package is installed and view its version:

dnf list httpd

If the package is installed, DNF shows the installed version. If it's not installed but available in repositories, DNF shows the available version. This quick check helps verify package status during exam scenarios.

To see which package provides a specific file:

dnf provides /usr/sbin/httpd

This reverse lookup identifies which package contains a particular file. It's invaluable when you know you need a specific command or file but don't know which package provides it. For example, if an exam scenario mentions you need the semanage command but you're unsure which package provides it, dnf provides /usr/sbin/semanage tells you to install policycoreutils-python-utils.

Pro Tip: Use dnf provides */semanage if you don't know the full path. The wildcard searches all paths for files matching the name.

Practice this skill: Install and Update Software Lab

Understanding Repository Configuration Files

Repository configuration in RHEL 10 uses simple INI-style configuration files that define where DNF looks for packages and how it interacts with each repository. Understanding these configuration files is essential for RHCSA scenarios involving custom repositories or repository troubleshooting.

Repository File Location and Structure

Repository configuration files reside in the /etc/yum.repos.d/ directory. Each file with a .repo extension can contain one or more repository definitions. During the exam, you'll create new repository files or modify existing ones to configure access to local repositories or alternative package sources. A basic repository configuration file contains several key elements. Here's an example of a simple repository definition:

[local-repo]
name=Local BaseOS Repository
baseurl=file:///mnt/repo/BaseOS
enabled=1
gpgcheck=0

Let's break down each component:

• [local-repo] - The repository ID (in brackets) must be unique across all repository files on the system and should be descriptive enough to identify the repository's purpose.
• name - Provides a human-readable description displayed when DNF uses the repository. This description helps you identify repositories in DNF output, so use clear, meaningful descriptions.
• baseurl - Specifies where DNF finds repository metadata and packages. This can be a local file path (using file://), an HTTP/HTTPS URL, or an FTP URL. For exam scenarios involving local repositories, you'll typically use file:// URLs pointing to mounted media or local directories.
• enabled - Determines whether DNF uses this repository by default. Setting enabled=1 activates the repository, while enabled=0 disables it. Disabled repositories can still be used explicitly with the --enablerepo option but won't be consulted during normal operations.
• gpgcheck - Controls GPG signature verification for packages. In production environments, you should always enable GPG checking (gpgcheck=1) to verify package authenticity. However, for local exam repositories or testing scenarios, you might set gpgcheck=0 to bypass signature checks.

Important Repository Configuration Options

Beyond the basic parameters, several additional options prove useful in specific scenarios. The gpgkey parameter specifies the location of the GPG key file used to verify package signatures:

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

When gpgcheck=1, DNF uses this key to verify package signatures before installation. The priority parameter controls repository priority when multiple repositories provide the same package. Lower numbers indicate higher priority. This prevents packages from testing repositories from overriding stable versions:

priority=10

The exclude parameter prevents installation of specific packages from this repository:

exclude=kernel* httpd

This protects critical packages from unintended updates or prevents known problematic packages from being installed.

Creating a Local DNF Repository: Step-by-Step

Creating a custom local repository is a core RHCSA skill that you may need to demonstrate on the exam. This process involves organizing RPM packages in a directory structure, creating repository metadata, and configuring DNF to use your custom repository.

Step 1: Organizing RPM Package Files

The first step in creating a local repository is gathering your RPM packages into a directory structure. For exam scenarios, you might mount an ISO image containing RHEL installation media, or you might have a directory containing downloaded RPM files. If working with RHEL installation ISO media, mount it first:

mkdir -p /mnt/rhel-iso
mount -o loop /path/to/rhel-10.iso /mnt/rhel-iso

The -o loop option allows mounting ISO files as if they were physical media. After mounting, the ISO contents become accessible at /mnt/rhel-iso.

RHEL 10 installation media contains two primary repositories: BaseOS and AppStream. BaseOS provides core operating system packages and dependencies, while AppStream contains additional applications, language runtimes, and development tools organized as modules. Both are necessary for a complete repository setup. For a more permanent local repository (rather than mounting ISO media), copy the repository directories to your filesystem:

mkdir -p /opt/local-repo
cp -r /mnt/rhel-iso/BaseOS /opt/local-repo/
cp -r /mnt/rhel-iso/AppStream /opt/local-repo/

Copying repositories to the local filesystem makes them permanently available without keeping ISO media mounted, which is more practical for ongoing use.

Step 2: Creating Repository Metadata

Repository metadata tells DNF what packages are available, their dependencies, and where to find them. The createrepo command generates this metadata, but it's not installed by default on minimal RHEL installations. First, install the repository creation tools:

dnf install createrepo

If you're creating a local repository to solve a dependency problem (you need a repository to install createrepo), you might need to install createrepo from RPM files directly using rpm -ivh with the createrepo package and its dependencies from the installation media. Once createrepo is installed, generate metadata for your repository:

createrepo /opt/local-repo/BaseOS
createrepo /opt/local-repo/AppStream

The createrepo command scans the specified directory for RPM files and creates repository metadata in a repodata subdirectory. This metadata includes package lists, dependency information, file lists, and other data DNF needs to manage packages effectively. If you add new RPM files to your repository later, update the metadata:

createrepo --update /opt/local-repo/BaseOS

The --update option makes createrepo scan only for changes rather than rebuilding metadata from scratch, which is faster for large repositories.

Step 3: Configuring DNF to Use Your Local Repository

With your repository organized and metadata created, the final step is telling DNF where to find your custom repository. Create a repository configuration file:

vi /etc/yum.repos.d/local.repo

Add configuration for both BaseOS and AppStream repositories:

[local-baseos]
name=Local BaseOS Repository
baseurl=file:///opt/local-repo/BaseOS
enabled=1
gpgcheck=0

[local-appstream]
name=Local AppStream Repository
baseurl=file:///opt/local-repo/AppStream
enabled=1
gpgcheck=0

Save the file and verify DNF recognizes your new repositories:

dnf repolist

This command lists all enabled repositories. You should see your local-baseos and local-appstream repositories in the output. If they don't appear, check your configuration file for syntax errors. To verify your repositories work correctly, try installing a package:

dnf install vim

DNF should fetch the package from your local repository. Watch the output to confirm it's using your custom repository rather than external sources.

Troubleshooting Repository Configuration

If your repository doesn't work as expected, several troubleshooting steps can help identify the problem. First, verify the repository metadata exists:

ls -l /opt/local-repo/BaseOS/repodata/

You should see several XML files and a repomd.xml file. If this directory doesn't exist or is empty, run createrepo again. Check for configuration file syntax errors:

dnf repolist -v

The -v (verbose) option displays detailed information about repository loading, including any errors DNF encounters parsing repository files. Clear the DNF cache and rebuild it:

dnf clean all
dnf makecache

These commands remove cached repository metadata and download fresh metadata from all configured repositories. Cache problems can cause DNF to use stale information even after repository configuration changes.

Common Mistake: Forgetting to run createrepo after copying RPM files. Without metadata, DNF cannot use the repository.

Managing Package Groups

Package groups bundle related packages together, allowing you to install entire software collections with a single command. Understanding package groups streamlines installations and demonstrates comprehensive package management knowledge important for RHCSA certification.

Understanding Package Group Types

RHEL organizes packages into two main group types: regular groups and environment groups. Regular groups contain packages for specific functionality, such as "Development Tools" or "System Tools." Environment groups aggregate multiple regular groups into larger collections for specific use cases, such as "Server" or "Workstation." To list all available package groups:

dnf group list

This displays environment groups and regular groups separately. Many groups are hidden by default to reduce list length. To see all groups including hidden ones:

dnf group list --hidden

To see detailed information about a specific group, including all packages it contains:

dnf group info "Development Tools"

This shows mandatory packages (always installed with the group), default packages (installed unless explicitly excluded), and optional packages (not installed by default but available).

Installing Package Groups

Installing a package group brings in all its default packages in a single operation:

dnf group install "Development Tools"

Note the quotes around multi-word group names—these are necessary for the shell to treat the entire name as a single argument. During installation, DNF installs mandatory and default packages but skips optional packages. To include optional packages:

dnf group install --with-optional "Development Tools"

This comprehensive installation ensures you have every package the group offers, which might be necessary for certain development scenarios.

To remove an installed package group:

dnf group remove "Development Tools"

This removes packages that were installed as part of the group. However, packages that are dependencies of other installed software remain on the system.

Quick Reference: Essential DNF Commands

This table provides a quick reference for the most important DNF commands you'll use during RHCSA exam preparation and on the exam itself.

Task	Command	Example
Install a package	dnf install PACKAGE	dnf install httpd
Remove a package	dnf remove PACKAGE	dnf remove httpd
Update all packages	dnf update	dnf update
Update specific package	dnf update PACKAGE	dnf update kernel
Search for packages	dnf search KEYWORD	dnf search web server
Show package information	dnf info PACKAGE	dnf info httpd
List installed packages	dnf list installed	dnf list installed
Find package providing file	dnf provides FILE	dnf provides /usr/sbin/semanage
List repositories	dnf repolist	dnf repolist
Clean cache	dnf clean all	dnf clean all
Install package group	dnf group install "GROUP"	dnf group install "Development Tools"
List modules	dnf module list	dnf module list postgresql
Enable module stream	dnf module enable MODULE:STREAM	dnf module enable postgresql:13
Install module	dnf module install MODULE:STREAM	dnf module install postgresql:13
Reset module	dnf module reset MODULE	dnf module reset postgresql

Key Takeaways for RHCSA Success

Package management and repository configuration form a foundational skill set that touches nearly every other RHCSA objective. Your ability to install software, configure repositories, and manage packages directly impacts your efficiency on the exam and your effectiveness as a system administrator. Practice these skills in a lab environment until they become automatic. Create local repositories from ISO media, experiment with different repository configurations, install and remove package groups, and work with module streams. The hands-on experience builds confidence and speed that translate directly to exam performance.

Remember that the exam may present scenarios where standard repositories aren't available or where you must use local media. Having practiced repository configuration from multiple sources prepares you for whatever the exam presents. Pay attention to details in exam scenarios. If a task mentions specific software versions, consider whether modules are required to provide that version. If network access seems limited, plan to use local repositories. These contextual clues guide you toward the appropriate solution approach. Finally, understand that package management is a means to an end, you install packages to enable other configurations and services. Efficient package management accelerates your progress through exam scenarios, giving you more time to focus on the core objectives each scenario tests.