Without a solid grasp of package management, you will quickly break a Linux system, turning a stable server into a pile of error messages. This chapter teaches you how to install, update, and remove software on Red Hat Enterprise Linux using the two essential tools: `dnf` and `rpm`, a foundational skill for the EX200 exam and any real-world Linux administration.
Jump to a section
A simple way to picture Managing Software Packages with dnf and rpm
A warehouse manager at a large distribution centre. Their job is to keep the warehouse stocked with exactly the right items, in the right quantities, all working correctly. They don't just throw items onto shelves randomly. They use two key tools: a detailed inventory system and a staff of pickers. The inventory system is a comprehensive catalogue that lists every item in the warehouse, its location, its condition, and its version number. This is like the RPM (Red Hat Package Manager) database on a Linux system. It tracks every piece of software (the item) on your system. When a picker needs to get a new item onto a shelf, they consult a master delivery schedule. This schedule is the DNF (Dandified YUM) repository configuration. It lists where to find the latest versions of items (the software packages). The manager never tells a picker to 'go get a hammer' without specifying the exact model number and version. That would be like using RPM directly to install a package by its filename. It works, but it’s manual and error-prone. Instead, the manager uses the delivery schedule to pull the correct hammer, automatically installing any missing parts (dependencies) it needs to work. The warehouse manager’s real skill is in using the delivery schedule to solve problems: a broken item gets replaced (update), a recalled item gets removed (remove), and a shipment of new items can be added (install). They use the inventory system to check if an item is already present before they try to add another. They know that bypassing the delivery schedule and manually placing items can lead to 'dependency hell' — shelves full of half-finished assemblies where the new hammer doesn’t fit the existing handles. The manager’s efficiency comes from the smooth interaction between the delivery schedule (DNF) and the inventory system (RPM), ensuring the warehouse runs without chaos.
Think of a software package on Linux as a single application you want to run — like a web browser, a text editor, or a database server. On Red Hat Enterprise Linux, these packages come in a specific format called RPM, which stands for Red Hat Package Manager. An RPM file (you’ll see them with a .rpm extension) is a compressed archive that contains all the files needed for a piece of software, plus metadata about the software: its name, version, what other packages it needs to work, and which files it provides. The whole system of dealing with these packages is called package management.
There are two main tools for this: rpm and dnf. rpm is the low-level tool. It can install, upgrade, or remove a package, but it does not automatically handle dependencies. A dependency is another piece of software that the package you want to install relies on to work. For example, a graphics tool might need a library called libpng to save images. If you use rpm to install the graphics tool and libpng is not already installed, rpm will give an error and refuse to continue. This makes rpm powerful but risky for beginners, as it can lead to 'dependency hell': a chain of failed installations. This is why dnf exists.
dnf (Dandified YUM) is the high-level package manager. It is a wrapper that sits on top of rpm. When you tell dnf to install a package, it does far more than just run rpm. First, it checks the configuration files in /etc/yum.repos.d/ to find a list of repositories. A repository (or 'repo') is a server where RPM files are stored. Red Hat’s official repositories contain thousands of signed and tested packages. dnf downloads the repository metadata, which is a list of all available packages and their dependencies. It then works out the entire dependency tree: it calculates the package you want, every single package it depends on, every package those packages depend on, and so on. Only after resolving this complete chain does it download all the necessary RPM files and call rpm to install them in the correct order.
Why does this matter for a beginner? Because when you work on a Red Hat Enterprise Linux server, you will almost always use dnf for installation and updates. rpm is reserved for specific tasks: querying the package database to see if a package is installed, verifying the integrity of an installed package, or installing a single RPM file that you downloaded manually from a vendor. You should physically type sudo dnf install httpd to add the Apache web server, not rpm -ivh httpd.rpm, because dnf will automatically fetch and install the underlying library apr and apr-util that the web server needs.
The rpm database resides in /var/lib/rpm/. It is a local database that records every package installed on the system. dnf always updates this database. When you run dnf remove firefox, it tells rpm to remove the package, and rpm updates its database. If you try to remove a package that another installed package needs, dnf will stop you with a warning, preventing accidental breakage. On the EX200 exam, you must be able to use both tools comfortably. You might be asked to install a package from a local file (using rpm -ivh), to list all installed packages (using rpm -qa), or to find which package provides a certain file (using dnf provides). Understanding the layer between dnf (the dependency resolver) and rpm (the actual installer) is the core concept. dnf replaced the older tool yum, and while some questions still reference 'yum', RHEL 8 and 9 use dnf exclusively. The command yum is actually a symlink to dnf for backward compatibility.
In summary, dnf is your everyday, safe tool for managing software. rpm is the precise, surgical tool for querying and for installing packages outside the repository system. Both are critical for the EX200 exam.
Identifying the Software Need
Determine which package you need. For example, you need the 'Apache HTTP Server'. On a Red Hat system, the package name is usually `httpd`. You can search for it using `dnf search httpd` or `dnf provides */httpd` to confirm the exact package name.
Installing the Package with dnf
Run `sudo dnf install httpd`. `dnf` reads the repository metadata, resolves the dependency tree, and presents a summary of what will be installed. You confirm with 'y'. `dnf` then downloads the RPM files and calls `rpm` to install them in the correct order, updating the RPM database.
Verifying the Installation
After installation, verify that the package is present and correct. Use `rpm -q httpd` to see the version installed. Use `rpm -V httpd` to verify the integrity of its files. A clean verification produces no output. You can also list all files in the package with `rpm -ql httpd`.
Updating the Software
To update the package to the newest version, run `sudo dnf update httpd`. `dnf` checks the repository for a newer version. If found, it downloads and installs the new RPM, preserving your configuration files. If there are configuration changes, a `.rpmnew` file is created next to the original config file.
Removing the Package
To uninstall the software, run `sudo dnf remove httpd`. `dnf` will remove `httpd` and any packages that were installed as dependencies of `httpd` that are no longer required by any other installed package. This keeps the system clean. You can confirm removal with `rpm -q httpd` which should return 'package httpd is not installed'.
Imagine you are a junior system administrator at a small e-commerce company called 'Books & Bytes'. Your manager asks you to set up a new web server on a freshly installed Red Hat Enterprise Linux 9 machine. The company needs to run the Apache HTTP Server (httpd), PHP for dynamic content, and a MySQL-compatible database (mysql-server). Here is what you actually do, step by step, using dnf and rpm.
First, you must connect to the server via SSH. You log in with your user account. To install the web server, you cannot use a graphical interface. You type sudo dnf install httpd. The sudo prefix gives you admin privileges. dnf then reports that it needs to install httpd plus two dependencies: apr and apr-util. It asks you to confirm. You type 'y' and hit Enter. dnf downloads the RPM files, checks their signatures to ensure they haven’t been tampered with, and installs them. This entire process takes about 30 seconds.
Next, you need PHP. Instead of guessing dependencies, you type sudo dnf install php. dnf automatically installs PHP and several additional modules it needs, like php-cli and php-common. You do not have to worry about the underlying library structure. This is the power of dnf. Now, what if a developer sends you a custom monitoring tool as a single RPM file named bookmon-1.0-1.el9.x86_64.rpm? You cannot use dnf directly because this file is not in any repository. You need rpm. You move the file to your home directory and type sudo rpm -ivh bookmon-1.0-1.el9.x86_64.rpm. The flags mean: -i for install, -v for verbose, -h for hash marks showing progress. If the tool requires a library like libcurl that is missing, rpm will complain with a dependency error. At this point, you must install libcurl first using dnf, then retry the rpm installation.
Later, the security team announces a critical vulnerability in libxml2, a library used by PHP. You need to update it. You type sudo dnf update libxml2. dnf checks the repositories, finds a newer version, and replaces the old package while preserving configuration files. If the old configuration is compatible, it is kept. If not, a new .rpmnew file is created. You never manually delete files. At the end of the month, you need to remove the monitoring tool because it was a temporary test. Using dnf remove bookmon will fail because bookmon wasn’t installed via dnf. You must use sudo rpm -e bookmon (the -e flag means erase).
Finally, you want to verify your work. You run rpm -qa | grep httpd to confirm httpd is installed. rpm -qi httpd gives you detailed information about the package. You also use dnf list installed to see everything you’ve added. This workflow—mostly using dnf for installation and updates, and rpm only for local files or detailed queries—is the standard practice in any Red Hat environment.
The EX200 exam tests the objective '5.1: Install, update, and remove software packages from Red Hat and third-party repositories using dnf and rpm' with a heavy emphasis on practical command syntax. You will not be asked to discuss the history of yum vs dnf. You must memorise the exact flags and their common combinations.
The exam loves to test the distinction between dnf and rpm in the context of dependencies. A classic trap question: 'You have downloaded a package file mytool.rpm. How do you install it and ensure its dependencies are also installed?' The incorrect answer is sudo dnf install mytool.rpm without first setting up a repository, or sudo rpm -ivh mytool.rpm if the dependencies are not present. The correct pattern is to check if the file is in a repo, or use dnf localinstall mytool.rpm (which uses dnf to resolve dependencies from repositories while installing a local file). The command dnf localinstall is often tested specifically.
Another key pattern: verifying packages. The flag -V with rpm (e.g., rpm -V httpd) checks for changes to files since installation. If a file has been modified, the output will show a '5' (MD5 checksum failed) or 'S' (file size changed). You must know that a clean verification means no output. The exam also tests querying. rpm -qa lists all installed packages. rpm -qf /bin/bash tells you which package owns the file /bin/bash. rpm -qi bash shows package information. rpm -ql bash lists all files installed by the bash package. The -q (query) flag is combined with many sub-flags.
The exam also tests the concept of 'groups' in dnf. dnf groupinstall 'Web Server' installs a collection of packages. You must know how to list groups with dnf group list and remove a group with dnf group remove.
Common traps include: using yum commands instead of dnf (they work on exam environments but modern commands are expected), forgetting sudo (you will get 'Permission denied'), and trying to remove a package that is a dependency of another installed package (the exam will ask what error message you get). The error message is 'Error: Protected multilib versions' or similar. The correct approach is to use dnf autoremove only for orphaned dependencies, or explicitly remove the parent package first.
You must also memorise the repository configuration files in /etc/yum.repos.d/. The exam might ask you to add a new repository (e.g., for third-party software) and then install a package from it. You need to know the .repo file format: [repo-name], name=, baseurl=, enabled=1. The gpgcheck=1 and gpgkey= lines are also tested.
Finally, the exam will test the dnf update vs dnf upgrade command. They are synonyms in RHEL 8+. Both do the same thing: update all packages. The exam might try to trick you by asking about a historical difference. There is none for exam purposes. The main exam topics are: install, remove, update, list, search, and localinstall using dnf; and install (-i), erase (-e), query (-q with various flags), and verify (-V) using rpm.
Use `sudo dnf install package_name` for installing software from Red Hat or third-party repositories — it handles all dependencies automatically.
Use `sudo rpm -ivh localfile.rpm` to install a single RPM file you have downloaded manually, but only if its dependencies are already installed.
The `rpm -qa` command lists every installed package on the system, and combining it with `grep` helps you find specific software.
The `dnf update` command updates all installed packages to their latest available versions in the enabled repositories.
The `dnf remove package_name` command removes the package and cleans up any dependencies that are no longer needed by other packages.
The `dnf localinstall localfile.rpm` command combines the safety of `dnf` dependency resolution with the ability to install a local RPM file.
The repository configuration files are stored in `/etc/yum.repos.d/` and each `.repo` file defines one or more repositories with a `baseurl` and `gpgcheck` settings.
The `rpm -V` command verifies the installed files of a package against the package’s original checksums, alerting you to unauthorised changes.
These come up on the exam all the time. Here's how to tell them apart.
dnf
High-level package manager; resolves dependencies automatically.
Installs packages from repositories defined in /etc/yum.repos.d/.
Preferred for installing, updating, and removing most software.
rpm
Low-level tool; does not handle dependencies automatically.
Installs individual .rpm files directly from the filesystem.
Used for querying, verifying, and installing local files not in a repo.
dnf install
Installs a package by name from an enabled repository.
Does not work with a local file path; expects a package name.
Fully resolves dependencies from repository metadata.
dnf localinstall
Installs a package from a local .rpm file on disk.
Requires the full path to the file, e.g., /home/user/package.rpm.
Resolves dependencies from repositories but uses the local file as the primary package.
rpm -qi
Queries package information: version, description, install date.
Output is human-readable text about the package itself.
Useful for checking metadata of a package.
rpm -ql
Lists all files installed by the package.
Output is a list of file paths.
Useful for finding where a package placed its files.
dnf update
Updates all packages to the latest version from repositories.
Historically was the same as `dnf upgrade` in older yum versions.
On RHEL 8 and 9, it is functionally identical to `dnf upgrade`.
dnf upgrade
Also updates all packages to the latest version.
In older yum, `upgrade` would remove obsolete packages; `update` would not.
On RHEL 8 and 9, this distinction no longer exists.
Mistake
I should use `rpm -i` for everything because it is the direct package manager.
Correct
You should use `dnf install` almost always because it automatically resolves dependencies. Only use `rpm -ivh` for installing a local file when the dependencies are already satisfied, or when you are certain.
New users learn the word 'package' and think `rpm` is the only thing they need. They don't understand that `dnf` wraps `rpm` to make life easier.
Mistake
When I run `dnf remove httpd`, it only removes the `httpd` package and leaves all its dependencies installed.
Correct
`dnf remove httpd` removes the `httpd` package and all packages that were installed solely as dependencies of `httpd` that are no longer needed. This is called 'autoremove'. However, it won't remove packages that are required by other installed packages.
People think `remove` is like 'uninstall one app on my phone' — just the app. They do not grasp the dependency tree concept.
Mistake
If a repository is disabled, I can still install packages from it by typing the full URL of the RPM file.
Correct
If a repository is disabled (`enabled=0` in its `.repo` file), you cannot install from it using `dnf install pkgname`. You must enable it first with `dnf config-manager --set-enabled repo-name`, or use `dnf install --enablerepo=repo-name pkgname`.
Beginners confuse the concept of a repository (a collection of packages) with a single file. They think they can skip the repository entirely.
Mistake
`yum` and `dnf` are completely different programs, and the exam only tests one.
Correct
On RHEL 8 and 9, `yum` is a symlink to `dnf` for backward compatibility. They are the same command. The exam uses `dnf`, but `yum` will work identically.
Older tutorials still reference `yum`, and candidates worry about memorising two sets of commands. They don't realise the commands have merged.
Mistake
I should never use `rpm` because it is dangerous and breaks dependencies.
Correct
`rpm` is safe when used correctly. It is essential for querying (`rpm -qa`), verifying (`rpm -V`), and for installing local RPM files that are not in a repo. The danger is only when you use `rpm -i` without checking dependencies, which can leave the system in an inconsistent state.
Overcorrection. Beginners hear 'never use rpm' from some online posts and avoid a perfectly useful tool.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`dnf` is a high-level package manager that automatically resolves dependencies by downloading packages from repositories. `rpm` is a low-level tool that installs, removes, and queries individual packages but does not handle dependencies automatically.
Use `dnf provides /path/to/file` or `dnf whatprovides /path/to/file`. For example, `dnf provides /etc/httpd/conf/httpd.conf` tells you that the file belongs to the `httpd` package.
Use `sudo dnf localinstall filename.rpm`. This tells `dnf` to install the local file while resolving its dependencies from your enabled repositories. If the dependencies are satisfied, it will install. If not, it will tell you what's missing.
It updates all installed packages on your system to their latest versions available in the repositories. It is the same as `sudo dnf upgrade` on RHEL 8 and 9. Always run it after a fresh system install to patch security vulnerabilities.
Run `dnf repolist` to see all enabled repositories. Add `--all` to see both enabled and disabled. The repository configuration files are located in `/etc/yum.repos.d/` and you can `cat` a file to see its details.
Yes, you can use `sudo rpm -e package_name` to erase a package. However, `dnf remove` is preferred because it also cleans up orphaned dependencies. Only use `rpm -e` if you installed the package with `rpm -i` and `dnf` does not know about it.
You've finished Managing Software Packages with dnf and rpm. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?