Package Management (dnf)

Skill Level: Fundamental

1. Overview

Software packages in RHEL 10 are managed with a tool called dnf.

Introduced in 2013, dnf was a significant improvement to its predecessor yum. Landing in RHEL 8, dnf replaced yum while still maintaining a great deal of compatibility.

When compared to YUM, DNF offers:

  • better functionality

  • better performace and scalability

  • better dependency resolution

  • consistent (strict) API adherence

  • compatibility with YUM

2. Getting Started

For these exercises, you will be using the host node1 as user root.

From host bastion, ssh to node1.

ssh node1

Use sudo to elevate your privileges.

[[ "$UID" == 0 ]] || sudo -i

Verify that you are on the right host for these exercises.

workshop-dnf-checkhost.sh

You are now ready to proceed with these exercises.

3. Core Concepts

Software in Red Hat Enterprise Linux is bundled into something called an 'rpm'. At a highlevel an 'rpm' file includes both

  • the files (payload) of a specific installation

  • as well as metadata about what’s getting installed

The metadata includes (but is not limited to):

  • common name

  • version

  • where and when it was built

  • digital/security signatures

  • checksums

Next, rpm packages get organized into structures called repositories (or repos for short) which are then published as sources to distribute content. More on this topic in the Intermediate Package Management unit.

Working with rpms directly can be challenging. Luckily tooks like dnf exist to abstract that complexity and replace it with simple, intuitive commands and processes.

Let’s get started!

4. List packages

Simple command to list all available packages. This includes all configured and available repos.

dnf list

Command to list only the installed packages.

dnf list --installed

Command to list available packages.

dnf list --available

A quick comparison of how many packages are installed vs available.

dnf list --installed | wc -l
dnf list --available | wc -l

You should see roughly 623 packages installed compared to 4759 available for installation.

Last, let us identify packages that are installed but do not belong to any known repository. Meaning, someone downloaded and installed it manually.

dnf list --extras

5. Package Details

Command to list a specific package.

dnf list bash-completion

Let us get some detailed information about this package.

dnf info bash-completion
Available Packages
Name         : bash-completion
Epoch        : 1
Version      : 2.11
Release      : 16.el10
Architecture : noarch
Size         : 457 k
Source       : bash-completion-2.11-16.el10.src.rpm
Repository   : rhel-10-for-x86_64-baseos-beta-rpms
Summary      : Programmable completion for Bash
URL          : https://github.com/scop/bash-completion
License      : GPL-2.0-or-later
Description  : bash-completion is a collection of shell functions that take advantage
             : of the programmable completion feature of bash.

6. Install Packages

Installing a package is simple. (The "-y" tells dnf to answer "yes" to any "are you sure" questions.)

dnf install -y bash-completion

Installing multiple packages from a single command is also easy.

dnf install -y  httpd mariadb mariadb-server php

Some of the pacakges listed above were likely already installed on the host, thus the ouput may have been very underwhelming. This set of packages is collectively known as the traditional LAMP stack: Linux, Apache, MySQL and PHP.

the MySQL project got forked long ago and its successor is MariaDB

7. Remove Packages

To remove a package from the system you can run dnf as follows.

dnf remove -y php

8. Upgrade Packages

To upgrade packages on a host you use the 'upgrade' operand. For the purposes of this lab, we don’t want to use up your time performing an actaul upgrade. However, there is something to be learned by performing a dry-run (or a harmless test).

dnf upgrade -y --setopt tsflags=test
If the system is fully patched then the output will yeild no results. The output shown here is for example only and probably won’t match what you see. 
<...snip...>
(54/56): python3-perf-6.12.0-55.7.1.el10_0.x86_64.rpm                       12 MB/s | 1.8 MB     00:00
(55/56): yggdrasil-0.4.5-2.el10_0.x86_64.rpm                                32 MB/s | 5.6 MB     00:00
(56/56): nvidia-gpu-firmware-20250314-15.el10.noarch.rpm                    41 MB/s |  38 MB     00:00
-----------------------------------------------------------------------------------------------------------
Total                                                                       64 MB/s | 320 MB     00:04
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

From this output, we can determine that 56 packages were evaluated for the upgrade and that all the transaction tests completed. As part of the test, the software was also downloaded and staged in the cache directories in /var/lib. Thus when the time comes to actaully install the upgrades, you can save that initial download time by running a test like this in advance.

9. Security Upgrade Only

dnf upgrade --security
Updating Subscription Management repositories.
Last metadata expiration check: 0:36:21 ago on Mon 07 Apr 2025 04:34:43 PM UTC.
No security updates needed, but 56 updates available
Dependencies resolved.
Nothing to do.
Complete!

RHEL 10 is still very early in its life (we may still be using the BETA for this lab). Here we see that there are no security updates currently available for our release.

10. Clean All

Performs cleanup of temporary files kept for repositories. This includes any such data left behind from disabled or removed repositories as well as for different distribution release versions.

dnf clean all

11. What About Reboots?

dnf is not tasked with understanding what packages may require a reboot in order to complete an installation or upgrade.

To answer "when?" really requires a deep understanding of how Linux works. The "safe" answer is always, but that certainly is not practical nor a reality.

Advanced technologies like 'kpatch' were developed in order to improve the security response without ALWAYS requiring a reboot. Even then, with kpatch one cannot SKIP a reboot, one can only DELAY the reboot. More about that in the advanced kpatch unit.

12. Conclusion

This concludes the first exercises related to dnf.

Time to finish this unit and return the shell to its home position.

workshop-finish-exercise.sh

13. Further Reading