Learn › RHCSA (EX200) › Deploy, Configure, Maintain
dnf - a hands-on Linux lab on a real virtual machine.
Drive the RHEL 10 package manager end to end. See where software comes from with dnf repolist, install a package and its dependencies with dnf install -y (needs root), confirm it with rpm -q package, remove it with dnf remove -y, and find or read packages with dnf search and dnf info. Then teach the machine a new repository by hand-writing a .repo file in /etc/yum.repos.d/ with an id, name, baseurl, enabled=1, and gpgcheck, or generate one with dnf config-manager --add-repo. RHEL 10 dropped AppStream module streams, so the work is plain installs plus repo files. Serves EX200 deploy-configure: install and update packages and configure systems to use package repositories.
A task hands you one line: install lsof so you can see which process is holding a file open. You type lsof and the shell answers command not found. The program is not on the machine. On a Linux server you do not download an installer or drag an icon; you ask the package manager to fetch the software from a repository and lay it down for you. If you do not know how to drive that package manager, a one-minute task turns into a wall.
On RHEL 10 that package manager is dnf. This lesson walks the whole loop a real task needs. You will see which repositories the machine can pull from, search for and read about a package, install it, confirm it landed, and remove it. Then you will teach the machine about a brand-new repository by writing a repo file by hand. That last skill, pointing a server at a repository it did not ship with, is a graded exam objective on its own.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2, the RHEL 10 rebuild used for capture). A few values depend on the exact build, so the repo NAMES read AlmaLinux 10 - BaseOS where a Red Hat box would read Red Hat Enterprise Linux 10 - BaseOS, and a package version like 4.98.0-7.el10 moves as updates ship. Treat those as illustrative. What is stable everywhere is the SHAPE: dnf repolist prints an id-and-name table, dnf install fetches and lays down a package, and rpm -q confirms it by name and version.
dnf is the package manager on RHEL 10. A package manager is the program that installs, updates, and removes software for you, and just as importantly, tracks every file each piece of software owns. Think of it as the warehouse clerk for the whole system: you name what you want, and the clerk finds it, checks that nothing else breaks, brings it in, and writes down exactly what arrived and where.
The unit it works in is a package: one bundle that holds a program, its libraries, its config files, and a manifest of everything inside. The name dnf stands for Dandified YUM, the modern replacement for the older yum command. On RHEL 10 yum still works as a compatibility alias, but the real tool underneath is dnf, and that is the name to learn.
You reach for dnf any time software needs to arrive on, or leave, a server. A web team needs the nginx package. A troubleshooting session needs lsof or tcpdump. A hardening pass needs an unused package gone. In every case dnf is the front door.
It does two jobs a manual download never could. First, it resolves dependencies: if the package you asked for needs three other libraries, dnf pulls those in automatically so you never chase a missing piece. Second, it works from repositories, central catalogs of packages the machine trusts, so you get a known-good, version-matched copy every time instead of a random file off the internet. Understanding repositories is half of this lesson, so that is where the hands-on begins.
Before you can install anything you need to know where packages come from. A repository, or repo, is a server-hosted catalog of packages the machine is configured to trust and pull from. dnf repolist prints every enabled repository the machine knows about, one per row, with its short id and its human-readable name.
Reading a repo list is a read-only query, so it needs no special privilege. Ask the machine which repositories it can pull from:
dnf repolist
prompt: [student@servera ~]$ answer: dnf repolist output: repo id repo name appstream AlmaLinux 10 - AppStream baseos AlmaLinux 10 - BaseOS crb AlmaLinux 10 - CRB extras AlmaLinux 10 - Extras hint: The list-repositories command is dnf repolist, no arguments needed.
Two columns. The left one, repo id, is the short handle you use in commands and config, like baseos or appstream. The right one, repo name, is the human description. Four repos show here. baseos holds the core operating system packages. appstream holds applications and language runtimes; on RHEL 10 it is a plain package repository, since the old module streams that used to layer on top of AppStream are essentially gone. crb (CodeReady Builder) and extras hold developer and add-on packages. If a repo you expect is missing from this list, the machine cannot install from it yet. That absence is your signal to add or enable one, which is exactly what the last step teaches.
Your repo NAMES will differ from the capture. This machine is AlmaLinux 10, so the names read AlmaLinux 10 - BaseOS. A Red Hat Enterprise Linux 10 box reads Red Hat Enterprise Linux 10 for x86_64 - BaseOS, and an exam machine points at a local classroom mirror with its own names. The ids (baseos, appstream) and the two-column shape are the constant. Read the id, not the marketing name.
Now the core move. dnf install <package> fetches a package and everything it depends on, then lays it all down. Installing changes the system, so it needs root: on the exam you run it under sudo or from a root shell. dnf normally pauses to show what it will do and asks you to confirm with y; add -y to answer yes in advance, which is how you script it and how most exam tasks expect it.
Install lsof, the tool that lists open files:
dnf install -y lsof
Then confirm it actually landed. The lowest-level way to ask is rpm -q <package>, which queries the package database and prints the exact name and version that is installed, or tells you it is not installed at all:
rpm -q lsof
prompt: [root@servera ~]# answer: rpm -q lsof output: lsof-4.98.0-7.el10.x86_64 hint: The query-a-package command is rpm -q, then the package name: rpm -q lsof
rpm -q lsof prints one line, lsof-4.98.0-7.el10.x86_64, and that single line is proof the install worked. Read it in pieces: lsof is the name, 4.98.0-7 is the version and release, el10 marks it as built for Enterprise Linux 10, and x86_64 is the architecture. If the package were NOT installed, rpm -q would instead say package lsof is not installed, so this one command is your yes-or-no answer. rpm -q reads the local package database only; it never touches the network, which is why it is the fast, honest confirmation after any install.
rpm -q and dnf install are not interchangeable. rpm -q only asks a yes-or-no question about the LOCAL database; it cannot fetch anything and it does not resolve dependencies. dnf install is what reaches out to the repositories, pulls the package plus every dependency, and updates that database. The classic mistake is trying to install software with a bare rpm -i package.rpm and getting stung by missing dependencies. Reach for dnf to install, and reach for rpm -q only to verify.
Install is one verb. Three more finish the daily toolkit, and all follow the same dnf <verb> <package> shape.
dnf search <keyword> scans package names and summaries for a word, which is how you find the package when you know what it does but not what it is called. dnf info <package> prints one package's full record: its version, size, license, and a paragraph describing it, so you can read before you install. dnf list installed shows everything currently on the machine, and you usually pipe it into grep to find one entry. To confirm a specific package without the network, you already have the sharper tool from the last step: rpm -q <package>.
Removing is the mirror image of installing. dnf remove <package> takes a package back off the machine, and like install it needs root and offers -y to skip the prompt. Remove the lsof you just installed:
dnf remove -y lsof
Then prove it is gone with the same query command as before. This time rpm -q reports the package is not installed:
prompt: [root@servera ~]# answer: rpm -q lsof output: package lsof is not installed hint: Same query command as before, rpm -q lsof; after a remove it answers that the package is not installed.
The very same rpm -q lsof now answers package lsof is not installed, which is the exact opposite of the version line you saw after installing. That symmetry is the point: one query command tells you the truth in both directions, so install-then-verify and remove-then-verify use the identical check. On the exam, whenever a task says install or remove a package, this rpm -q line is how you confirm you actually moved the needle before you walk away.
The final skill is the one exams love because it separates people who memorized dnf install from people who understand where packages come from. Sometimes the machine has no repository for the software you need. You have to add one. Every enabled repository you saw in dnf repolist is defined by a small text file that lives in the directory /etc/yum.repos.d/, and each such file ends in .repo. To add a repository, you write one of those files.
The file is plain text with a tiny structure. Create /etc/yum.repos.d/demo.repo with exactly these four keys under a section header. The command below writes the file in one shot; it prints nothing when it succeeds, which is normal:
cat > /etc/yum.repos.d/demo.repo
prompt: [root@servera ~]# answer: cat > /etc/yum.repos.d/demo.repo output: hint: Redirect a heredoc or typed lines into the file with cat > /etc/yum.repos.d/demo.repo
No output means the file was written. The four lines you put inside it are the whole anatomy of a repo:
[demo]
name=Demo Repo
baseurl=http://content.lab.example.net/rhel10/BaseOS
enabled=1
gpgcheck=0[demo] in square brackets is the repo id, the short handle that will show up in dnf repolist. name= is the human description. baseurl= is the address dnf fetches packages from, the single most important line, since a wrong URL means an empty or broken repo. enabled=1 turns the repo on (a 0 would define it but leave it off). gpgcheck=0 tells dnf not to verify package signatures for this repo, which is fine for a trusted classroom mirror but something you would set to 1 in production. Run dnf repolist again and demo now appears in the list, ready to install from.
You do not always have to hand-write the file. dnf config-manager --add-repo <url> generates a basic .repo file for you from a URL in one command. Hand-writing is still worth practicing. It is the only way to get every field exactly right when a task dictates a specific id, baseurl, and gpgcheck value. It also teaches you to read and fix any repo file you find in /etc/yum.repos.d/.
Scaffolding off. No command is printed this time. You have every piece you need.
A task drops you at a root prompt: the lsof tool is not on this machine, and you need it to inspect open files. Put it on the system from the repositories, answering yes to the confirmation prompt in advance so nothing blocks, then be ready to prove it landed. Which single command fetches a package and its dependencies and installs them without stopping to ask?
prompt: [root@servera ~]# answer: dnf install -y lsof ||| dnf -y install lsof ||| yum install -y lsof output: Installed: lsof-4.98.0-7.el10.x86_64
Complete! hint: The installer is dnf install, the package is lsof, and -y answers yes for you: dnf install -y lsof
dnf install -y lsof fetches lsof plus anything it depends on and lays it all down, and the -y answers the confirmation prompt in advance so the command runs to completion on its own. The Installed: block naming lsof-4.98.0-7.el10.x86_64 followed by Complete! is dnf telling you it finished. To confirm outside of dnf, you would run rpm -q lsof and read back that same version line. Install, then verify: that pairing is the whole rhythm of package tasks on the exam.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: dnf installs and removes and resolves dependencies, rpm -q is your fast yes-or-no verify, and every repository is just a .repo file in /etc/yum.repos.d/ with an id, a baseurl, and enabled=1.
RHEL 10 quietly dropped the old AppStream module streams that RHEL 8 used, so you will rarely touch dnf module on a modern exam. If you trained on RHEL 8 material and remember dnf module enable, set it aside. On RHEL 10 the answer to almost every install task is a plain dnf install, and the repo work is a plain .repo file.
The practice terminal walked you through the whole software-management loop. dnf repolist to see where packages come from, dnf install -y to lay one down, rpm -q to prove it landed and later that it is gone, dnf remove -y to take it back off, and a hand-written .repo file in /etc/yum.repos.d/ to teach the machine a repository it did not ship with. Every one of those you typed yourself.
The deploy-configure module mission, Operation Rollout, is where you run these against a real RHEL 10 machine. A full VM boots for you, with real repositories configured and a work order of objectives to hit. The mission asks you to install named packages, point the system at a repository it does not yet trust by writing a .repo file, and confirm each change stuck. One difference from this lesson: the mission shows no commands. You read the objective, recall the dnf install and rpm -q and repo-file forms, and type them. That recall is what makes it hold on exam day.
Finish the other deploy-configure lessons, then go run Operation Rollout and configure a real machine.
Practice dnf Repositories and Packages in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.