RED HAT ENTERPRISE LINUX

DNF Package Management

Download, Install, Update, and Manage Software

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this comprehensive module on DNF package management in Red Hat Enterprise Linux. DNF, which stands for Dandified YUM, is the package manager used in RHEL 9 and later versions. It is your primary tool for installing, updating, and managing software on RHEL systems. Understanding package management is essential for system administration. You need to install new software, keep systems updated with security patches, remove unnecessary packages, and troubleshoot dependency issues. DNF handles all of this through a consistent, powerful command-line interface. In this module, you will learn how packages and repositories work, how to search for and install software, how to keep your system updated, how to manage repositories, and how to troubleshoot common package management issues. These skills are fundamental for maintaining healthy, secure RHEL systems.

Learning Objectives

Understand packages and repositories

RPM packages, dependencies, and Red Hat repositories

Search and query packages

Find packages, view information, and check what is installed

Install and remove software

Install packages, package groups, and remove software safely

Update and maintain systems

Apply updates, security patches, and manage package history

Configure repositories

Enable, disable, and add software repositories

We have five main learning objectives. First, you will understand the package ecosystem - what RPM packages are, how dependencies work, and how Red Hat organizes software in repositories. This foundation helps you understand what DNF does behind the scenes. Second, you will search and query packages - finding software you need, viewing package information, and checking what is already installed on your system. Third, you will install and remove software - adding packages and package groups, handling dependencies, and safely removing software you no longer need. Fourth, you will update and maintain systems - applying security updates, upgrading packages, viewing transaction history, and rolling back changes when needed. Fifth, you will configure repositories - enabling additional Red Hat repositories, disabling repositories, and understanding how to add third-party software sources when necessary.

What is a Package?

A package is an archive containing software files, metadata, and installation scripts. In RHEL, packages use the RPM (Red Hat Package Manager) format.

httpd-2.4.57-5.el9.x86_64.rpm

name version release dist arch

Package contains:

Binary executables
Configuration files
Documentation
Dependencies list
Install/uninstall scripts

Common architectures:

x86_64 - 64-bit Intel/AMD
aarch64 - 64-bit ARM
noarch - Architecture independent
i686 - 32-bit (legacy)

A package is a bundle of software in a standardized format. In RHEL, packages use the RPM format, which has been the standard since the early days of Red Hat Linux. Understanding RPM package naming helps you identify software versions. The name comes first - httpd for the Apache web server. The version number follows - 2.4.57 is the upstream software version. The release number indicates Red Hat's packaging iteration - 5 means the fifth time Red Hat packaged this version. The distribution tag shows which RHEL version - el9 means Enterprise Linux 9. The architecture indicates what hardware it runs on - x86_64 for standard 64-bit systems. Inside a package you find the actual files - binaries, libraries, configuration files, and documentation. You also find metadata including a list of dependencies - other packages required for this software to work. Pre and post installation scripts handle setup tasks. This packaging system ensures consistent, reliable software installation across all RHEL systems.

What is a Repository?

A repository (repo) is a collection of packages stored on a server. DNF downloads packages from configured repositories, handling dependencies automatically.

Red Hat Repos

→

DNF

→

Your System

# List enabled repositories
[root@host ~]# dnf repolist
repo id                              repo name
rhel-9-for-x86_64-baseos-rpms        Red Hat Enterprise Linux 9 - BaseOS
rhel-9-for-x86_64-appstream-rpms     Red Hat Enterprise Linux 9 - AppStream

# List all repositories (including disabled)
[root@host ~]# dnf repolist all

Red Hat repositories require subscription. Your system must be registered with subscription-manager to access official packages.

A repository is essentially a library of packages hosted on servers. When you tell DNF to install software, it contacts the configured repositories, finds the package and its dependencies, downloads them, and installs everything. Red Hat provides several repositories for RHEL. BaseOS contains the core operating system packages - kernel, shells, basic utilities. AppStream contains applications and developer tools, often with multiple versions available. CodeReady Builder has additional development packages. To use Red Hat repositories, your system must be registered with Red Hat Subscription Manager and have valid entitlements. This is how Red Hat provides support and ensures customers have access to updates. The dnf repolist command shows your enabled repositories. Add 'all' to see disabled repos too. Repository configuration files live in /etc/yum.repos.d/ - we will explore these later.

DNF vs YUM

DNF (Dandified YUM) replaced YUM as the default package manager in RHEL 8. It offers better performance, improved dependency resolution, and a cleaner codebase.

Feature	DNF (RHEL 8/9)	YUM (RHEL 7)
Performance	Faster, parallel downloads	Slower, sequential
Dependencies	Better resolution algorithm	Older algorithm
Memory usage	More efficient	Higher usage
API	Clean Python API	Legacy API
Modularity	Full support	Not supported

# yum command still works (it's an alias to dnf)
[root@host ~]# yum install httpd
# Same as:
[root@host ~]# dnf install httpd

# Check which is actually running
[root@host ~]# ls -la /usr/bin/yum
lrwxrwxrwx. 1 root root 5 ... /usr/bin/yum -> dnf-3

DNF replaced YUM starting with RHEL 8. The name stands for Dandified YUM - a complete rewrite with modern Python code. DNF offers significant improvements. Performance is better thanks to parallel downloads and optimized metadata handling. The dependency resolution algorithm is more sophisticated, solving complex dependency chains that confused YUM. Memory usage is lower and more predictable. For backward compatibility, yum still works - it is a symbolic link to dnf. Your muscle memory and existing scripts continue to function. However, you should use dnf for new work. Some command syntax differs slightly, and dnf-specific features are not available through the yum alias. In this course, we use dnf commands. Know that yum works identically for basic operations, but dnf is the proper command going forward.

Searching for Packages

# Search for packages by keyword
[root@host ~]# dnf search web server
========================= Name Matched: web server =========================
httpd.x86_64 : Apache HTTP Server
nginx.x86_64 : A high performance web server and reverse proxy server

# Search only in package names
[root@host ~]# dnf search --name-only httpd

# Find which package provides a file
[root@host ~]# dnf provides /usr/bin/vim
vim-enhanced-2:9.0.1712-1.el9.x86_64 : A version of the VIM editor
Repo        : rhel-9-for-x86_64-appstream-rpms
Matched from:
Filename    : /usr/bin/vim

# Find package providing a command (using wildcards)
[root@host ~]# dnf provides */sshd
openssh-server-8.7p1-34.el9.x86_64 : An open source SSH server daemon

Finding the right package is often the first step. dnf search looks for keywords in package names and descriptions. It returns a list of matching packages. For more targeted searches, --name-only searches only package names, ignoring descriptions. dnf provides is extremely useful - it tells you which package contains a specific file. If you need /usr/bin/vim but it is not installed, dnf provides /usr/bin/vim shows you the package to install. The wildcard pattern */sshd finds any package providing a file named sshd anywhere in the filesystem. This is how you figure out what to install when a command is missing. These search commands query repository metadata, so they find both installed and available packages. You can search before installing to make sure you are getting the right software.

Package Information

# View detailed package information
[root@host ~]# dnf info httpd
Name         : httpd
Version      : 2.4.57
Release      : 5.el9
Architecture : x86_64
Size         : 59 k
Source       : httpd-2.4.57-5.el9.src.rpm
Repository   : rhel-9-for-x86_64-appstream-rpms
Summary      : Apache HTTP Server
URL          : https://httpd.apache.org/
License      : ASL 2.0
Description  : The Apache HTTP Server is a powerful, efficient, and extensible
             : web server.

# List all packages (installed and available)
[root@host ~]# dnf list all

# List only installed packages
[root@host ~]# dnf list installed

# List available packages (not installed)
[root@host ~]# dnf list available

# Check if specific package is installed
[root@host ~]# dnf list installed httpd

Installing Packages

dnf install downloads and installs packages along with all required dependencies. It shows what will be installed and asks for confirmation.

# Install a single package
[root@host ~]# dnf install httpd
Dependencies resolved.
================================================================================
 Package              Arch       Version              Repository          Size
================================================================================
Installing:
 httpd                x86_64     2.4.57-5.el9         appstream           59 k
Installing dependencies:
 apr                  x86_64     1.7.0-11.el9         appstream          127 k
 apr-util             x86_64     1.6.1-23.el9         appstream          105 k
 httpd-core           x86_64     2.4.57-5.el9         appstream          1.4 M
 httpd-filesystem     noarch     2.4.57-5.el9         appstream           17 k
 httpd-tools          x86_64     2.4.57-5.el9         appstream           82 k
 mod_http2            x86_64     2.0.26-1.el9         appstream          172 k
...
Transaction Summary
================================================================================
Install  9 Packages

Total download size: 2.1 M
Installed size: 5.8 M
Is this ok [y/N]: y

Installing Multiple Packages

# Install multiple packages at once
[root@host ~]# dnf install httpd mariadb-server php

# Install without confirmation prompt (-y flag)
[root@host ~]# dnf install -y vim-enhanced

# Install specific version
[root@host ~]# dnf install httpd-2.4.57-5.el9

# Install from local RPM file
[root@host ~]# dnf install ./package.rpm

# Reinstall a package (replaces existing)
[root@host ~]# dnf reinstall httpd

# Download without installing
[root@host ~]# dnf download httpd
httpd-2.4.57-5.el9.x86_64.rpm

Caution: The -y flag skips confirmation. Use carefully - always review what DNF plans to do in production.

DNF handles multiple packages efficiently. List several package names to install them all in one transaction. Dependencies are resolved together, which can be more efficient than separate installations. The -y flag answers yes to confirmation prompts automatically. Useful in scripts, but dangerous if you have not reviewed what will be installed. Use it cautiously, especially on production systems. You can install specific package versions by including the version in the package name. This is important when you need a particular version for compatibility. dnf install with a local .rpm file installs from that file while still resolving dependencies from repositories. This combines local packages with repository-based dependency resolution. dnf reinstall replaces an installed package with a fresh copy. Useful if files got corrupted or modified incorrectly. dnf download fetches the RPM file without installing - useful for offline installation or examination.

Package Groups

Package groups bundle related packages together. Install a group to get a complete set of tools for a specific purpose.

# List available groups
[root@host ~]# dnf group list
Available Environment Groups:
   Server with GUI
   Server
   Minimal Install
   Workstation
Available Groups:
   Development Tools
   Headless Management
   Network Servers
   System Tools

# View group contents
[root@host ~]# dnf group info "Development Tools"
Group: Development Tools
 Mandatory Packages:
   gcc
   make
   autoconf
   automake
 Optional Packages:
   valgrind
   cmake

# Install a group
[root@host ~]# dnf group install "Development Tools"

Package groups simplify installation of related software. Instead of listing individual packages, install a group to get everything needed for a particular purpose. dnf group list shows available groups. Environment groups are larger collections typically selected during installation - Server, Workstation, Minimal Install. Regular groups are smaller collections for specific purposes - Development Tools, System Tools. dnf group info shows what packages are in a group. Mandatory packages are always installed with the group. Default packages install unless you exclude them. Optional packages are not installed unless explicitly requested. dnf group install installs the group. Use quotes around group names with spaces. You can also use @"Development Tools" syntax - the @ symbol indicates a group. Groups make initial system setup faster and ensure you do not miss critical packages for a particular workload.

Removing Packages

dnf remove uninstalls packages. DNF also removes packages that depend on what you are removing - review carefully!

# Remove a package
[root@host ~]# dnf remove httpd
Dependencies resolved.
================================================================================
 Package              Arch       Version              Repository          Size
================================================================================
Removing:
 httpd                x86_64     2.4.57-5.el9         @appstream          59 k
Removing dependent packages:
 mod_ssl              x86_64     1:2.4.57-5.el9       @appstream         151 k
Removing unused dependencies:
 apr                  x86_64     1.7.0-11.el9         @appstream         290 k
 apr-util             x86_64     1.6.1-23.el9         @appstream         220 k

Transaction Summary
================================================================================
Remove  4 Packages

Is this ok [y/N]:

# Remove without removing unused dependencies
[root@host ~]# dnf remove --noautoremove httpd

Warning: Removing packages can break dependent software. Always review the removal list before confirming!

dnf remove uninstalls packages. But here is the critical thing to understand - if other packages depend on what you are removing, they get removed too. This cascading removal can be surprising. In the example, removing httpd also removes mod_ssl because mod_ssl requires httpd. It also offers to remove apr and apr-util since nothing else needs them anymore. Always review the removal list carefully. You might intend to remove one package but end up removing critical software that depends on it. This is especially dangerous with low-level libraries. The --noautoremove flag prevents automatic removal of dependencies. The removed package goes away, but its dependencies stay even if nothing else uses them. This can leave orphaned packages but is safer when you are unsure. For cleaning up orphaned dependencies later, use dnf autoremove. But again, review what it plans to remove.

Updating Packages

dnf update (or upgrade) downloads and installs newer versions of installed packages. Critical for security patches!

# Check for available updates
[root@host ~]# dnf check-update
kernel.x86_64                   5.14.0-362.18.1.el9      baseos
openssl.x86_64                  1:3.0.7-25.el9           baseos
vim-enhanced.x86_64             2:9.0.2081-1.el9         appstream

# Update all packages
[root@host ~]# dnf update
# or equivalently:
[root@host ~]# dnf upgrade

# Update specific package only
[root@host ~]# dnf update openssl

# Update with security fixes only
[root@host ~]# dnf update --security

# See what security updates are available
[root@host ~]# dnf updateinfo list security

Best practice: Regularly run dnf update to keep systems patched against security vulnerabilities.

Keeping systems updated is critical for security. dnf check-update shows available updates without installing anything. This is your preview of what needs attention. dnf update downloads and installs all available updates. In DNF, update and upgrade are synonymous - they do the same thing. The transaction summary shows every package that will be upgraded. Review it, especially in production environments. You can update specific packages by naming them. This is useful when you need a particular fix but want to minimize changes. The --security flag limits updates to only those flagged as security fixes. This is useful when you want critical patches but want to avoid other changes that might affect application behavior. dnf updateinfo provides information about available updates, including security advisories with CVE references. Regular patching is essential. Unpatched systems are vulnerable to known exploits.

Managing History

DNF keeps a transaction history. You can review past operations and undo changes if needed.

# View transaction history
[root@host ~]# dnf history
ID  | Command               | Date and time    | Action(s) | Altered
--------------------------------------------------------------------
 15 | update                | 2024-01-20 10:30 | Upgrade   |   23
 14 | install httpd         | 2024-01-19 14:22 | Install   |    9
 13 | remove vim-enhanced   | 2024-01-18 09:15 | Removed   |    1

# View details of specific transaction
[root@host ~]# dnf history info 14
Transaction ID : 14
Begin time     : Fri 19 Jan 2024 02:22:15 PM
Packages Altered:
    Install httpd-2.4.57-5.el9.x86_64  @appstream
    Install apr-1.7.0-11.el9.x86_64    @appstream
    ...

# Undo a transaction (reverse the changes)
[root@host ~]# dnf history undo 14

# Redo a transaction (repeat it)
[root@host ~]# dnf history redo 14

DNF maintains a complete history of package transactions. This is invaluable for troubleshooting and recovery. dnf history shows all transactions with their IDs, what command was run, when, and how many packages were affected. Each transaction has a unique ID. dnf history info followed by the ID shows exactly what happened in that transaction - every package installed, removed, or upgraded. This helps you understand what changed and when. The powerful feature is dnf history undo. If an update broke something, undo that transaction to revert to the previous state. DNF figures out how to reverse the changes - downgrading packages that were upgraded, reinstalling packages that were removed. dnf history redo repeats a transaction. Useful if you undid something and want to redo it, or to apply the same changes on another system. This history-based rollback is simpler than trying to manually figure out what to change.

Working with Repositories

# List all repos (enabled and disabled)
[root@host ~]# dnf repolist all
repo id                              status
rhel-9-for-x86_64-baseos-rpms        enabled
rhel-9-for-x86_64-appstream-rpms     enabled
codeready-builder-for-rhel-9         disabled

# Enable a repository
[root@host ~]# dnf config-manager --enable codeready-builder-for-rhel-9

# Disable a repository
[root@host ~]# dnf config-manager --disable codeready-builder-for-rhel-9

# Temporarily use a disabled repo for one command
[root@host ~]# dnf install package --enablerepo=codeready-builder-for-rhel-9

# Temporarily disable a repo for one command
[root@host ~]# dnf update --disablerepo=epel

# View repository details
[root@host ~]# dnf repoinfo rhel-9-for-x86_64-baseos-rpms

Managing repositories controls where DNF gets packages. dnf repolist all shows all configured repositories and their status - enabled or disabled. Some repositories are disabled by default to prevent accidental installation of packages intended for specific use cases. dnf config-manager modifies repository configuration. Use --enable to enable a disabled repository, --disable to disable one. CodeReady Builder, for example, is disabled by default but contains development packages you might need. You can temporarily enable or disable repos for a single command without changing the permanent configuration. The --enablerepo and --disablerepo flags apply only to that one dnf command. This is useful for installing a single package from a disabled repo without leaving it enabled permanently. dnf repoinfo shows detailed information about a repository - its URL, enabled status, and metadata.

Repository Configuration

Repository definitions are stored in /etc/yum.repos.d/ as .repo files. Each file can define one or more repositories.

# List repository configuration files
[root@host ~]# ls /etc/yum.repos.d/
redhat.repo

# Repository file structure
[root@host ~]# cat /etc/yum.repos.d/example.repo
[example-repo]
name=Example Repository
baseurl=https://repo.example.com/rhel9/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-example

# Key fields:
# [repo-id]     - Unique identifier
# name          - Human-readable name
# baseurl       - URL to repository
# enabled       - 1=enabled, 0=disabled
# gpgcheck      - 1=verify signatures, 0=don't
# gpgkey        - GPG key for verification

Security: Always enable gpgcheck=1 for production systems. This verifies packages are signed and unmodified.

Repository configuration lives in /etc/yum.repos.d/ as .repo files. On a registered RHEL system, redhat.repo contains the official Red Hat repositories managed by subscription-manager. Each repository definition starts with a unique ID in brackets. The name is a human-readable description. The baseurl points to where packages are stored - usually an HTTPS URL for remote repos or file:// for local repos. enabled controls whether DNF uses this repository. Set to 1 for enabled, 0 for disabled. gpgcheck controls signature verification. With gpgcheck=1, DNF verifies each package is signed with the appropriate GPG key, ensuring packages have not been tampered with. Never disable this in production. gpgkey points to the GPG public key used for verification. You can add third-party repositories by creating .repo files here. Be cautious - only add trusted repositories, and always enable GPG checking.

Adding Third-Party Repos

# Example: Adding EPEL (Extra Packages for Enterprise Linux)
[root@host ~]# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

# This installs the EPEL repository configuration and GPG key
[root@host ~]# dnf repolist
repo id                              repo name
epel                                 Extra Packages for Enterprise Linux 9
rhel-9-for-x86_64-baseos-rpms        Red Hat Enterprise Linux 9 - BaseOS
rhel-9-for-x86_64-appstream-rpms     Red Hat Enterprise Linux 9 - AppStream

# Now you can install packages from EPEL
[root@host ~]# dnf install htop

# Add repository using config-manager
[root@host ~]# dnf config-manager --add-repo https://example.com/repo.repo

Warning: Third-party packages are not supported by Red Hat. Use them carefully, especially in production environments.

Sometimes you need software not available in Red Hat repositories. Third-party repositories provide additional packages. EPEL (Extra Packages for Enterprise Linux) is a popular repository maintained by the Fedora Project. It contains many additional packages built for RHEL compatibility. Installing the epel-release package adds the repository configuration and GPG key to your system. Many third-party repos distribute their configuration as an RPM package. This installs the .repo file and GPG key in one step, which is cleaner than manual configuration. You can also use dnf config-manager --add-repo to add a repository from a URL. However, be very cautious with third-party repositories. Packages from outside Red Hat are not covered by your support subscription. They might conflict with official packages, introduce security vulnerabilities, or break during updates. Only add repositories you trust, and prefer EPEL when possible as it follows strict quality guidelines.

Application Streams

Application Streams allow multiple versions of software to coexist in repositories. Choose the version that fits your needs.

# List available modules
[root@host ~]# dnf module list
Name      Stream    Profiles             Summary
nodejs    18        common, development  Javascript runtime
nodejs    20        common, development  Javascript runtime
php       8.1       common, devel        PHP scripting language
php       8.2       common, devel        PHP scripting language
ruby      3.1       common               Ruby programming language
ruby      3.3       common               Ruby programming language

# View module details
[root@host ~]# dnf module info php:8.2

# Enable a specific stream
[root@host ~]# dnf module enable php:8.2

# Install module with default profile
[root@host ~]# dnf module install php:8.2

# Switch to different stream (reset first)
[root@host ~]# dnf module reset php
[root@host ~]# dnf module enable php:8.1

Application Streams, also called modules, solve a traditional problem - repositories could only have one version of each package. If the repo had PHP 8.1 and you needed PHP 8.2, you were stuck. With modules, multiple versions coexist. You choose which stream to enable. dnf module list shows available modules and their streams. Each module can have multiple streams representing different versions. Profiles determine which packages from the module get installed - common for runtime, devel for development tools. dnf module enable activates a stream. After enabling, regular dnf install commands install from that stream. Or use dnf module install to enable and install in one step. To switch versions, first reset the module with dnf module reset, then enable the new stream. You may need to remove and reinstall the packages to complete the switch. This modularity gives you control over software versions without needing multiple repositories.

DNF Cache and Cleanup

# DNF caches repository metadata and downloaded packages
# View cache information
[root@host ~]# dnf repoinfo

# Clean cached metadata (forces refresh on next run)
[root@host ~]# dnf clean metadata

# Clean cached packages (downloaded RPMs)
[root@host ~]# dnf clean packages

# Clean everything
[root@host ~]# dnf clean all

# Force metadata refresh
[root@host ~]# dnf makecache

# Remove packages that are no longer needed (orphaned dependencies)
[root@host ~]# dnf autoremove

# Check cache location
[root@host ~]# ls /var/cache/dnf/

Tip: If you see stale package lists or repository errors, try dnf clean all followed by your command.

DNF maintains caches to improve performance. Metadata cache stores repository package lists so DNF does not have to download them every time. Package cache stores downloaded RPMs temporarily. Sometimes caches cause problems. Stale metadata might not reflect recent repository updates. Corrupted cache can cause errors. dnf clean commands fix these issues. dnf clean metadata removes cached repository information. Next dnf command will download fresh metadata. dnf clean packages removes cached RPM files, freeing disk space. dnf clean all clears everything. This is the sledgehammer approach when you're having problems. dnf makecache proactively downloads and caches metadata. Useful before going offline or to ensure fresh data. dnf autoremove cleans up orphaned dependencies - packages that were installed as dependencies but are no longer needed by anything. Review its output before confirming.

Troubleshooting DNF

# Dependency problems - check what's broken
[root@host ~]# dnf check

# Force reinstall to fix corrupted package
[root@host ~]# dnf reinstall httpd

# View RPM database problems
[root@host ~]# rpm --rebuilddb

# Verbose output for debugging
[root@host ~]# dnf -v install httpd

# Check package file integrity
[root@host ~]# rpm -V httpd
S.5....T.  c /etc/httpd/conf/httpd.conf
# Shows modified config file (expected for configs)

# See which package owns a file
[root@host ~]# rpm -qf /etc/passwd
setup-2.13.7-9.el9.noarch

Common issues: Network problems (check connectivity), stale cache (dnf clean all), subscription issues (subscription-manager status), disk space (df -h).

When DNF has problems, several diagnostic tools help. dnf check scans for dependency problems in installed packages. If something is broken, it tells you what. dnf reinstall replaces a package with a fresh copy from the repository. Useful if package files got corrupted or incorrectly modified. rpm --rebuilddb rebuilds the RPM database. Use this if you get database corruption errors. The -v flag adds verbose output, helpful for understanding what DNF is doing when something fails. rpm -V (verify) checks if installed files match the package. It shows differences in size (S), checksum (5), timestamps (T), and more. Modified configuration files are normal and show c in the output. rpm -qf shows which package owns a file. Helpful for understanding what installed something. Common problems include network issues blocking repository access, stale cache needing dnf clean all, subscription problems needing subscription-manager attention, or disk space preventing downloads.

Best Practices

Do

Review transactions before confirming
Keep systems updated regularly
Test updates in non-production first
Use GPG verification for packages
Document repository changes
Maintain valid subscriptions
Use dnf history for rollbacks
Clean cache when troubleshooting

Do Not

Use -y blindly in production
Disable GPG checking
Add untrusted repositories
Ignore dependency removal warnings
Skip reading transaction summaries
Mix packages from incompatible repos
Force install with --nodeps
Delay security updates

Golden rule: Read what DNF tells you. The transaction summary and warnings exist to prevent mistakes.

Let me share best practices for package management. Always review transaction summaries before confirming. DNF tells you exactly what will change - read it. Keep systems updated, but test updates on non-production systems first to catch problems before they affect users. Never disable GPG checking - it protects against tampered packages. Document any repository changes so you know what was added and why. Maintain valid subscriptions to keep receiving updates. Use dnf history when you need to roll back changes. Clean cache as a first troubleshooting step. Avoid using -y in production without review. Never force installations with --nodeps - it leads to broken software. Do not add untrusted repositories. Do not ignore warnings about dependent packages being removed. Do not delay security updates - vulnerabilities get exploited quickly. Do not mix packages from incompatible repositories - this leads to dependency hell. The transaction summary is your friend. DNF is trying to help you understand what will happen. Pay attention.

Key Takeaways

Repositories: Collections of packages. RHEL uses BaseOS, AppStream, and CodeReady Builder. Enable with dnf config-manager.

Search: dnf search finds packages. dnf provides finds packages containing files. dnf info shows details.

Install: dnf install adds packages with dependencies. dnf group install installs package groups.

Update: dnf update applies updates. dnf history tracks and reverses changes.

Remove: dnf remove uninstalls. Watch for dependent package removal!

Next: Managing Services with systemd

Let me summarize what we have covered about DNF package management. Repositories are collections of packages hosted on servers. RHEL provides BaseOS for core OS components, AppStream for applications with version choices, and CodeReady Builder for development tools. Use dnf config-manager to enable and disable repos. Searching uses dnf search for keywords and dnf provides to find packages containing specific files. dnf info shows detailed package information. Installation with dnf install automatically resolves and installs dependencies. Package groups with dnf group install provide bundles of related software for specific purposes. Updating with dnf update keeps systems patched. Security updates are critical. dnf history tracks all transactions and enables rollback with dnf history undo. Removal with dnf remove uninstalls packages, but watch carefully for dependent packages that will also be removed.

Graded Lab

Search for and install a web server package
View package information before and after installation
Install the "Development Tools" group
Check for and apply available updates
View transaction history and practice undo
Enable the CodeReady Builder repository

Next: Installing and Updating Applications by Using Flatpak