6.2 Install and Remove RPM Software Packages

6.2 Install and Remove RPM Software Packages

Quick Answer: On RHEL 10, manage RPM software with dnf (install, remove, update, list, search, info). Use rpm -q / rpm -V to query and verify installed packages. Prefer DNF over raw rpm -i/-e so dependencies resolve. Package state is stored on disk and persists after reboot—always verify with rpm -q packagename before moving on.

Scope of this objective

With repositories configured (Section 6.1), you must install and remove software delivered as RPM packages. EX200 tasks are concrete: “Install httpd and ensure it remains installed,” “Remove telnet,” “Update all packages,” or “Install the package that provides semanage.” You prove success by package presence/absence, not by starting services unless the task also requires it (services are separate objectives).

DNF daily drivers

Search and inspect before you change the system

dnf search httpd
dnf search "web server"
dnf list httpd
dnf list installed httpd
dnf list available httpd
dnf info httpd
dnf provides /usr/sbin/semanage
dnf provides '*bin/semanage'

Exam tip: When a task says “install the package that provides command X” and you forget the name, dnf provides '*/X' or dnf provides /usr/bin/X is faster than guessing.

Install packages

sudo dnf install httpd
sudo dnf install httpd mariadb-server
sudo dnf install ./local-package.rpm          # local file; still resolves deps from repos
sudo dnf install https://server.lab/pkg.rpm  # remote RPM URL when allowed
sudo dnf install -y httpd                    # non-interactive assume yes (use carefully)

DNF will:

1. Resolve dependencies
2. Prompt to import GPG keys if needed
3. Download and install transaction set
4. Run scriptlets (users, units, etc. as defined by packages)

Use -y only when you understand the transaction. On the exam, reading the transaction summary once can catch “wrong package” mistakes before they hit disk.

Remove packages

sudo dnf remove telnet
sudo dnf remove httpd
# Stronger cleanup of unused dependencies (when appropriate):
sudo dnf autoremove

remove erases the named packages. Dependent packages may also be removed if they require what you erased—read the transaction list. Do not autoremove casually in production-like exams unless you know nothing critical will go; stick to explicit removes when the task names packages.

Update / upgrade

sudo dnf check-update          # list available updates (exit 100 if updates exist—normal)
sudo dnf update                # update packages (common operator habit)
sudo dnf upgrade               # modern alias/path for upgrading packages
sudo dnf update httpd          # update one package

On current DNF, update and upgrade are closely related; use what man pages on the exam system document. Tasks may say “update all packages” or “ensure package X is the latest from the repo.”

List and verify install state

dnf list installed | grep httpd
rpm -q httpd
rpm -q httpd firewalld bash
rpm -qa | grep -i cockpit

rpm -q NAME returns the NVR (name-version-release) if installed, or prints “not installed” / exits non-zero if missing—excellent for scripts and quick checks.

RPM query and verify toolkit

DNF changes the system; rpm inspects the RPM database (/var/lib/rpm).

rpm -q httpd                    # is it installed?
rpm -qa                         # all installed packages
rpm -qi httpd                   # package metadata
rpm -ql httpd                   # files owned by package
rpm -qc httpd                   # config files
rpm -qd httpd                   # documentation files
rpm -qf /usr/sbin/httpd         # which package owns this file?
rpm -V httpd                    # verify files against database (see below)
rpm -Va                         # verify all (noisy; use sparingly)

Understanding rpm -V (verify)

rpm -V compares on-disk files to the package metadata (size, mode, digest, user, group, etc.). Output flags mean differences; common markers include:

Empty output from rpm -V httpd generally means files match the database expectations. Config files you edited will often show expected differences—do not “fix” them by reinstalling unless the task wants stock configs.

Exam use: After a broken install or partial restore, rpm -V helps spot missing binaries. For “is package installed?” prefer rpm -q.

Prefer DNF over low-level rpm install/erase

# Avoid as your default on EX200:
sudo rpm -ivh package.rpm      # install without full dep solver like DNF
sudo rpm -e package             # erase; may break deps

Raw rpm is useful for queries, verification, and importing keys (rpm --import). For install/remove of ordinary software, dnf is the correct operator tool because it resolves dependencies and uses repositories. If you rpm -e something critical without understanding reverse dependencies, you can break the system under time pressure.

Exceptions you might still see in advanced admin work: installing a single offline .rpm when DNF is unavailable—still try dnf install ./file.rpm first when DNF works.

Groups and modules (awareness)

dnf group list
sudo dnf group install "Development Tools"
dnf module list                 # deprecated on RHEL 10 (prints a deprecation warning)

RHEL 10 ships no modular content. Red Hat does not distribute Application Streams packaged with modularity in RHEL 10, and the dnf module command is deprecated there. Application Stream versions install as ordinary RPMs with dnf install. For EX200, prioritize named packages the task gives you, and use groups when the task explicitly asks for a group install—do not reach for module streams on RHEL 10.

History and undo (safety net in practice)

dnf history
dnf history info LAST
sudo dnf history undo LAST     # careful: reverses a transaction

History is valuable in labs when you install the wrong package. On the exam, prefer precise installs over relying on undo—but know dnf history exists if you need to audit what changed.

Transaction problems and fixes

sudo dnf clean all
sudo dnf makecache
sudo dnf install --refresh httpd

End-to-end exam scenario

Task: Install strace and tcpdump. Remove ntpstat if present. Ensure packages remain correct after reboot.

# Discover
dnf list strace tcpdump ntpstat

# Change
sudo dnf install -y strace tcpdump
rpm -q ntpstat && sudo dnf remove -y ntpstat || true

# Verify
rpm -q strace tcpdump
rpm -q ntpstat   # should fail / not installed

# Persistence mindset: RPM DB is on disk—still re-check after reboot in practice labs

Task: Install a package from a provided local RPM file while using enabled repos for dependencies:

sudo dnf install /root/materials/custom-tool-1.0-1.el10.x86_64.rpm
rpm -q custom-tool
rpm -V custom-tool

Relationship to services and security

Installing httpd does not automatically satisfy tasks that require the service enabled, firewall opened, or SELinux contexts adjusted. Those are separate study points. Conversely, removing a package may remove unit files—do not remove software a later task still needs.

Persistence notes (EX200 scoring)

• Successful dnf install / remove writes to the RPM database and filesystem—survives reboot by design.
• You do not need a special “enable package at boot” step for packages themselves.
• You do need reboot-safe config for services you start with packages—but that is systemctl enable, not DNF.
• Always leave time to run rpm -q on required packages before the final submit mindset; if you removed the wrong dependency tree, fix it before time expires.

Common traps

1. Installing the wrong similar name (httpd vs a docs-only package)—read dnf info.
2. Using rpm -i and missing dependencies—switch to dnf install.
3. Assuming yum is gone—it may still work as a front end; both skills transfer, but learn dnf.
4. Forgetting to verify removal—rpm -q still shows the package if remove failed.
5. Updating blindly in a timed exam—only update when the task asks or when required to fix deps.
6. Confusing package name with binary name—dnf provides / rpm -qf.

Section checkpoint

You should search repositories, install and remove packages with DNF (including local RPM files), update when required, query the RPM database with rpm -q and related switches, interpret basic rpm -V output, and confirm package state that still holds after reboot. That completes the RPM half of EX200 software management before Flatpak.