YUM/DNF 包管理器
字数: 12213 字 时长: 45 分钟
YUM（Yellowdog Updater Modified）是一个基于 RPM 的软件包管理器，用于自动处理 Linux 系统中软件包的安装、更新和卸载。YUM 是 Linux 发行版，尤其是 Red Hat、CentOS 和 Fedora 等基于 Red Hat 的系统上的标准工具。YUM 的主要目标是简化软件包管理过程，并自动解决软件包之间的依赖关系。
NOTE
YUM 可以类比为 Windows 上的软件管家，因为它提供了一键安装、升级和卸载软件包的功能。YUM 是一个基于 RPM 的软件包管理器，它能够自动下载 RPM 包并且安装，可以自动处理依赖性关系，并且一次安装所有依赖的软件包，无须繁琐地一次次下载、安装。
而 DNF（Dandified YUM）可以被看作是 YUM 的升级版。DNF 是为了解决 YUM 中的一些长期存在的问题而开发的，这些问题包括性能差、内存占用过多、依赖解析速度变慢等。DNF 使用 libsolv 进行依赖解析，由 SUSE 开发和维护，旨在提高性能，并且它的 API 有完整的文档，支持更多的扩展。
DNF 是在 CentOS 8 及更高版本中取代了 YUM 作为默认包管理工具的，因此在较新的 Linux 发行版中，DNF 的兼容性更好。YUM 在旧版本的 Linux 发行版中广泛使用，如 CentOS 7 及之前的版本，对于这些系统，YUM 仍然是主要的包管理工具。
YUM 和 DNF 在命令上非常相似，许多命令可以直接互换使用。例如，安装、更新、移除和列出软件包的命令在 YUM 和 DNF 中都是相同的。但是，DNF 引入了一些新的命令和选项，提供了更好的性能和更多的功能。
DNF 源
DNF 源，是指存放软件包的服务器位置，这些服务器通常被称为软件仓库或镜像源。这些服务器包含了大量的 RPM 软件包，供用户根据自己的需要进行下载和安装。在 Linux 系统中，软件包管理器（如 DNF）通过访问这些仓库来搜索、安装、更新和卸载软件包。
镜像源
镜像源是指在互联网上用于同步和存储特定数据集的服务器。当使用 DNF 这样的包管理器时，它会从配置的镜像源服务器下载和安装软件包。这些镜像源服务器通常会同步上游源（如发行版的官方仓库）的软件包，以确保用户可以获取到最新的软件和安全更新。
例如，对于基于 Red Hat 的系统，官方的软件包仓库可能位于美国的服务器上，但为了提高在亚洲地区的访问速度，可能会有镜像源服务器同步官方仓库的内容，并提供给亚洲地区的用户使用。这样，用户就可以从距离自己更近的服务器上下载软件包，从而获得更快的下载速度和更好的体验。
在默认情况下，DNF 使用系统预配置的仓库，这些仓库通常包含在 Linux 发行版的安装介质中，或者由发行版维护者提供。用户也可以添加额外的仓库，例如第三方仓库或者自定义仓库，以获取更多的软件包或者访问特定版本的软件包。
DNF 仓库的配置通常在 /etc/yum.repos.d/ 目录下的 .repo 文件，其包含了 Linux 发行版中用于 dnf 包管理器的仓库配置信息。每个 .repo 文件通常对应一个特定的软件仓库，包含了该仓库的 ID、名称、URL、是否启用、GPG 密钥等信息。这些配置告诉 DNF 去哪里查找和安装软件包。
[root@localhost ~]# ll /etc/yum.repos.d/
total 20
-rw-r--r--. 1 root root 6610 May 1 08:29 rocky-addons.repo
-rw-r--r--. 1 root root 1165 May 1 08:29 rocky-devel.repo
-rw-r--r--. 1 root root 2387 May 1 08:29 rocky-extras.repo
-rw-r--r--. 1 root root 3417 May 1 08:29 rocky.repo这四个 .repo 文件分别对应不同的软件仓库：
rocky-addons.repo：这个文件可能包含了 Rocky Linux 的附加软件仓库的配置信息，这些仓库可能提供了一些额外的软件包，这些软件包不在主要仓库中。rocky-devel.repo：这个文件可能包含了 Rocky Linux 的开发版软件仓库的配置信息，这些仓库可能包含了正在开发中的软件包，或者是一些实验性的软件。rocky-extras.repo：这个文件可能包含了 Rocky Linux 的额外软件仓库的配置信息，这些仓库可能包含了一些不那么常用或者不是由 Rocky Linux 官方提供的软件包。rocky.repo：这个文件包含了 Rocky Linux 的主要软件仓库的配置信息，这是安装和更新大多数软件包时会用到的仓库。
每个 .repo 文件通常包含了一个或多个仓库的配置信息。这些仓库可以是不同的软件包集合，它们可能包含不同类型的软件包，比如基础操作系统包、应用程序包、开发工具包等。一个 .repo 文件中的多个仓库部分（sections）可以指向不同的 URL，或者为不同类型的软件包提供不同的配置。例如：
……
[baseos]
name=Rocky Linux $releasever - BaseOS
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever$rltype
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/
gpgcheck=1
enabled=1
countme=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
……
[appstream]
name=Rocky Linux $releasever - AppStream
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=AppStream-$releasever$rltype
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/AppStream/$basearch/os/
gpgcheck=1
enabled=1
countme=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
……其中，[baseos] 部分配置了基础操作系统（BaseOS）的仓库，而 [appstream] 部分配置了应用程序流（AppStream）的仓库。每个部分都可以有自己的 mirrorlist 或 baseurl，这意味着它们可以指向不同的服务器或镜像地址。.repo 文件中其他几个参数：
name：这个配置项为仓库指定了一个名称。这个名称在用户界面和日志中用于标识仓库，使其更易于识别和引用。例如，在配置文件中，name=Rocky Linux $releasever - BaseOS表示这个仓库是 Rocky Linux 的基础操作系统仓库，其中$releasever是一个动态变量，会根据实际的发行版版本号进行替换。mirrorlist：这个配置项提供了一个动态镜像列表的 URL。当系统需要更新或安装软件包时，它会根据这个 URL 获取一个镜像列表，并选择最佳的镜像源进行下载。这种方式通常基于地理位置和其他因素来优化下载速度。#baseurl：：这是一个被注释掉的配置项。在.repo文件中，可以用#来注释掉某些行，这样这些行就不会被包管理器执行。baseurl 指定了仓库的静态 URL 地址。与 mirrorlist 不同，baseurl 不会根据地理位置选择最佳的镜像。如果网络环境访问 mirrorlist 有困难，或者希望使用特定的镜像，可以取消注释 baseurl 行，并指定一个合适的 URL 地址。gpgcheck：这个配置项用来决定是否对仓库中的软件包进行 GPG 签名验证。如果设置为 1，则启用签名验证，这有助于确保软件包的来源和完整性。如果设置为 0，则禁用签名验证，这通常不推荐，因为它会降低安全性。启用 GPG 签名验证是确保系统安全的推荐做法。enabled：这个配置项用来控制仓库是否被启用。如果设置为 1，仓库将被启用，包管理器可以从中安装或更新软件包。如果设置为 0，仓库将被禁用，包管理器将忽略这个仓库中的所有软件包。这个设置允许用户根据需要启用或禁用特定的仓库。countme：这个配置项用于控制仓库的计数。在某些情况下，仓库的计数会影响包管理器的行为。例如，DNF 会根据仓库的计数来决定是否启用某个仓库。countme=1 表示这个仓库会被计入总数，从而可能影响仓库的启用状态。这个配置项的具体作用可能因不同的包管理器和发行版而异。metadata_expire：这个配置项指定了仓库元数据的过期时间。元数据是指关于软件包的信息，比如软件包的名称、版本、依赖关系等。metadata_expire=6h表示这些元数据在 6 小时后会过期，DNF 包管理器会在元数据过期后重新从仓库获取最新的元数据。这样可以确保用户获取到最新的软件包信息，但同时也会增加网络流量和服务器负载。设置合适的过期时间可以平衡这两者。gpgkey：这个配置项指定了用于验证软件包 GPG 签名的密钥文件的位置。这个密钥文件包含了仓库维护者的公钥，用于验证软件包的签名，确保软件包在传输过程中没有被篡改。
更换 DNF 源
更换为国内源是解决因网络问题导致国外源无法正常访问的常见方法。国内源通常会提供更快的下载速度和更高的稳定性，因为它们通常位于地理位置更近的服务器上，并且更有可能优化了对中国用户的访问。中国有许多知名的国内镜像源，它们由不同的高校、大型公司和其他组织提供：
基本每个镜像网址都会介绍如何更换源，例如，这里将默认的软件源地址更换为国内的阿里云镜像源地址，https://developer.aliyun.com/mirror/rockylinux?spm=a2c6h.13651102.0.0.732c1b112z0Wt3，可以直接执行执行以下命令替换默认源：
sed -e 's|^mirrorlist=|#mirrorlist=|g' \
-e 's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g' \
-i.bak \
/etc/yum.repos.d/[Rr]ocky*.repo这个命令的目的是将配置文件中的 mirrorlist 行注释掉，并启用一个指定的 baseurl，以便使用阿里云的镜像源。命令中的 -i.bak 选项表示对文件进行原地编辑，并且会生成一个带有 .bak 后缀的备份文件：
s|^mirrorlist=|#mirrorlist=|g：搜索以mirrorlist=开头的行，并将其替换为#mirrorlist=，实际上是将其注释掉。\：反斜杠用作命令行中的续行符，表示命令会在下一行继续，实际上是一个连续的命令。这在编写较长的命令时非常有用，可以提高命令的可读性。s|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g：搜索被注释掉的 baseurl 行，并将其替换为新的 baseurl，指向阿里云的镜像源。-i.bak：表示对文件进行备份编辑，原文件会被修改，同时会生成一个带有。bak 后缀的备份文件。/etc/yum.repos.d/R[r]ocky-*.repo：指定了要编辑的文件路径和模式。[Rr]ocky-*.repo 中的 [Rr]是一个小技巧，用于匹配以Rocky-开头的文件名，无论文件名中是否包含小写的r。
NOTE
由于 RockyLinux 不同版本的原因，其 /etc/yum.repos.d/ 目录下的 .repo 配置文件也有所不同，之前版本有类似 Rocky-* 的配置文件，所以在上面命令中匹配 [Rr]，这样可以兼容不用版本。
然后可以使用 ll 命令再次列出它们：
[root@localhost ~]# ll /etc/yum.repos.d/
total 40
-rw-r--r--. 1 root root 6610 Oct 27 15:32 rocky-addons.repo
-rw-r--r--. 1 root root 6610 May 1 08:29 rocky-addons.repo.bak
-rw-r--r--. 1 root root 1165 Oct 27 15:32 rocky-devel.repo
-rw-r--r--. 1 root root 1165 May 1 08:29 rocky-devel.repo.bak
-rw-r--r--. 1 root root 2387 Oct 27 15:32 rocky-extras.repo
-rw-r--r--. 1 root root 2387 May 1 08:29 rocky-extras.repo.bak
-rw-r--r--. 1 root root 3417 Oct 27 15:32 rocky.repo
-rw-r--r--. 1 root root 3417 May 1 08:29 rocky.repo.bak并且可以看到默认的地址被修改为阿里云的镜像站地址了：
……
[baseos]
name=Rocky Linux $releasever - BaseOS
#mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever$rltype
baseurl=https://mirrors.aliyun.com/rockylinux/$releasever/BaseOS/$basearch/os/
gpgcheck=1
enabled=1
countme=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
……更换源之后执行 dnf clean all 和 dnf makecache 命令：
[root@localhost ~]# dnf clean all
[root@localhost ~]# dnf makecachednf clean all：当更换软件源后，系统中可能仍保留着旧源的缓存数据（如软件包索引、元数据等）。删除 DNF 本地缓存的所有临时文件（包括软件包元数据、已下载的 RPM 包等），确保后续操作基于新源的最新数据。dnf makecache：从新配置的软件源下载最新的软件包元数据（如包名称、版本、依赖关系等），并存储在本地。
如果想还原默认的配置文件，可以通过 mv 命令来重命名备份文件，使其替换掉当前的 .repo 文件即可。
URL 变量
仓库基础 URL 变量是用于在 Linux 发行版的软件仓库配置文件中指定仓库位置的占位符。这些变量允许仓库配置文件动态地适应不同的系统版本和架构，而不需要为每个特定的版本或架构手动编辑 URL。
例如，在 rocky.repo 文件中，看到 baseurl=https://mirrors.aliyun.com/rockylinux/$releasever/BaseOS/$basearch/os/ 这里的 $releasever 和 $basearch 就是变量：
$releasever：它通常代表着操作系统的发行版本号。以 CentOS 或 Rocky 为例，对于 CentOS 8 或 Rocky 8 系统，$releasever 的值就是 8；对于 CentOS 9 或 Rocky 9 系统，其值为 9。这个变量的作用是确保软件包是从与操作系统版本匹配的仓库分支中获取的，因为不同版本的操作系统可能需要不同版本的软件包来保证兼容性。$basearch：这个变量代表了系统的基础架构，比如 x86_64 或者 aarch64。它使得仓库能够根据系统的硬件架构提供正确的软件包。因为 x86_64 架构的软件包不能在 aarch64 架构的系统上正确安装，反之亦然。
当使用 yum 或 dnf 命令时，包管理器会读取 .repo 文件中的仓库配置，并在处理这些配置时替换这些变量。这个替换过程是基于系统的实际发行版和架构信息的，这些信息通常可以从系统的发行版文件（如 /etc/os-release）和系统架构检测中获得。
在 .repo 文件中，除了 $releasever 和 $basearch 之外，还有其他一些变量可以用于构建仓库的 URL。这些变量提供了一种灵活的方式来指定仓库的位置和配置，使得仓库管理更加自动化和适应不同的环境。以下是一些其他可能使用的变量：
$contentdir：用于指定仓库内容的目录路径。这个变量通常用于构建完整的仓库 URL，指向包含软件包的目录。$infra：代表基础设施版本，这个变量在某些仓库配置中使用，特别是在那些区分基础设施版本的仓库中。$rltype：这是一个特定于 Rocky Linux 的变量，用于区分不同的仓库类型，如 AppStream、BaseOS 等。这个变量允许仓库 URL 根据仓库类型动态变化。
本地 DNF 源
本地 DNF 源通常指的是在本地服务器或本地网络中设置的软件包仓库。这种设置允许用户和系统管理员从一个快速且可靠的地方安装、更新和下载软件包，而不是从远程服务器下载。这对于以下情况特别有用，例如在没有互联网连接的环境中，本地源是管理和更新系统的唯一方式。
DNF 命令
dnf 是一款功能强大的命令行工具，专为基于 RPM 的 Linux 发行版设计，用于高效管理软件包。作为 YUM 的新一代继承者，DNF 带来了更快的依赖解析能力、更低的内存占用以及更优的性能表现。通过 dnf 命令，用户可以轻松执行以下操作：
- 安装新软件包，确保系统具备所需的应用程序和工具。
- 更新现有软件包，保持系统安全和性能的最佳状态。
- 删除不再需要的软件包，维护系统整洁。
- 查询软件包信息，了解可用的软件资源及其详情。
- 在安装或更新软件包的过程中自动解决依赖问题，确保软件包能够顺利安装或升级。
dnf [options] COMMAND package-spec...| 常见主命令 | 作用 |
|---|---|
install | 在系统中安装一个或多个指定的软件包。如果软件包有依赖关系，dnf 会自动解决这些依赖并安装所需的依赖包。 |
groupinstall | 用于安装软件包组。软件包组是一组逻辑上相关的软件包，通常用于简化安装多个相关软件包的过程。例如，如果需要安装一系列用于开发的工具，而不是单独安装每个软件包，可以安装一个名为 Development Tools 的软件包组。 |
remove | 用于从系统中删除指定的软件包。这个操作不会删除软件包的配置文件，如果需要删除配置文件，可以使用 dnf autoremove 或 dnf clean。 |
upgrade | 用于升级系统中的一个或多个软件包到最新版本。如果没有指定软件包，它会升级所有可升级的软件包。 |
search | 用于在软件包详细信息中搜索指定字符串，即搜索与指定字符串有关的软件包。这个命令可以帮助用户快速找到需要安装的软件包。 |
info | 用于显示关于一个或一组软件包的详细信息，包括软件包的描述、版本、大小、依赖关系、提供的功能等。这有助于用户在安装或升级前了解软件包的具体情况。 |
list | 用于列出用户系统上的所有来自软件库的可用软件包和所有已经安装在系统上的软件包。它可以根据需要列出已安装的包、可供安装的包或所有包。 |
download | 用于从软件仓库下载 RPM 包而不安装它们。 |
groupinstall | 用于列出所有已知的软件包组。这个命令可以帮助用户查看系统中可用的和已安装的软件包组，以及它们的相关信息。 |
makecache | 用于生成仓库元数据的缓存。这可以加快后续的 dnf 操作，如搜索和安装软件包，因为 dnf 可以直接从缓存中读取软件包信息，而不需要每次都从网络获取。 |
provides | 用于查找提供特定文件、包名或能力的软件包。这个命令特别有用，当需要找出哪个软件包包含了特定的文件或提供了特定的功能。 |
autoremove | 用于删除所有最初作为依赖关系安装的、现在不再需要的软件包。这些软件包通常是为了满足其他软件包的依赖而被安装的，但随着系统配置的变化，可能已经不再被任何软件包所依赖。可以清理这些不再需要的「孤立」软件包。 |
check | 用于检查本地包数据库中存在的问题。packagedb 是 DNF 维护的软件包数据库，记录了系统中已安装的软件包信息。使用该命令可以发现并报告数据库中的不一致或错误，例如损坏的依赖关系或缺失的软件包。 |
check-update | 用于检查系统中所有已安装软件包的更新。它会查询所有已配置的软件仓库，比较仓库中软件包的版本与系统中已安装版本，列出那些有新版本可用的软件包。这个命令不会实际进行更新，只是告诉哪些软件包可以更新。 |
clean | 用于清除 DNF 缓存的数据，包括下载的软件包和仓库元数据。这可以帮助释放磁盘空间，并确保后续的软件包操作基于最新的仓库元数据。例如，dnf clean all 会清除所有缓存的包和元数据。 |
reinstall | 用于重新安装已安装的软件包。如果软件包文件被修改或损坏，这个命令可以恢复软件包到原始状态。 |
repolist | 用于显示系统中可用的 DNF 软件库（软件仓库）。这个命令可以显示每个仓库的 ID、名称和状态。 |
插件命令是扩展 dnf 核心功能的一些额外命令。这些命令提供了额外的或特定的功能，它们不是 dnf 的核心部分，而是由插件提供的。这些插件可以由社区或第三方开发者创建，以满足更专业或特定的需求。
| 常见插件命令 | 作用 |
|---|---|
builddep | 用于安装构建某个 RPM 软件包所需的依赖。这个命令通常用于开发环境中，当需要从源代码编译一个软件包时，该命令可以自动安装所有必需的构建依赖。 |
config-manager | 用于管理 DNF 配置选项和软件仓库。它允许启用或禁用仓库，以及添加新的仓库。这个命令本质上是对 /etc/yum.repos.d/ 目录下的文件进行增删改查。 |
download | 用于从远程仓库下载软件包到本地目录，但不进行安装。这对于需要离线安装软件包的情况非常有用。 |
repomanage | 用于管理 RPM 软件包目录。它可以显示目录中最新或最旧的软件包，方便进行进一步的操作，如安装或删除。 |
repoclosure | 用于读取一个或多个 YUM 仓库的软件包元数据，检查所有依赖关系，并显示具有未解决依赖的软件包列表。这个命令有助于诊断仓库中的依赖问题。 |
system-upgrade | 用于准备系统的升级。这个命令通常用于升级系统到一个新的发行版。 |
repograph | 用于生成仓库中软件包的完整依赖关系图，并以 dot 格式输出。这个命令可以帮助用户理解软件包之间的依赖关系，对于分析和解决复杂的依赖问题非常有用。 |
| 常见选项 | 作用 |
|---|---|
-y | 这个选项用于自动回答所有提示问题为「是」。在使用 dnf 进行软件包安装、更新或删除时，系统会询问用户是否确认执行操作。使用该选项后，dnf 将自动回答所有这些提示为「是」，从而无需手动确认，使操作自动化。 |
-q | 静默操作模式。使用该选项后，dnf 将减少输出的信息量，只在必要时显示错误或关键信息。这在脚本或自动化任务中非常有用，可以避免不必要的输出干扰。 |
--nogpgcheck | 这个选项用于禁用 GPG 签名检查。在软件包安装或更新过程中，dnf 默认会检查软件包的 GPG 签名以确保软件包的完整性和来源。使用 --nogpgcheck 选项可以禁用这一检查，但出于安全考虑，通常不推荐这样做。 |
--installroot | 这个选项用于设置安装根目录。dnf 可以使用这个选项来指定一个不同的根目录进行安装，这对于系统管理员在进行 chroot 操作或在非当前根目录进行软件包管理时非常有用。 |
--nodocs | 这个选项用于防止安装文档。默认情况下，dnf 可能会安装软件包的文档。使用该选项可以阻止文档的安装，从而节省空间。 |
--releasever | 这个选项用于覆盖配置和仓库文件中的 $releasever 变量的值。这在您需要指定特定版本的软件包时非常有用。 |
--skip-broken | 这个选项用于在遇到依赖问题时跳过无法解决的软件包。默认情况下，如果 dnf 无法解决所有依赖关系，它会停止操作。使用该选项可以跳过这些软件包，继续其他操作。 |
--allowerasing | 这个选项允许 dnf 在解决依赖关系时删除已安装的软件包。默认情况下，dnf 不会删除已安装的软件包，除非它们是作为其他软件包的依赖项安装的。 |
| 参数 | 作用 |
|---|---|
package-spec | 表示一个或多个与命令相关的软件包规格参数。例如，使用 groupinstall 命令安装一个软件包组时，可以指定组标识符：dnf groupinstall "Development Tools" |
软件查询
如果想要查询一个软件包的信息，可以使用 dnf 的查询命令。以下是一些常用的 dnf 查询命令：
列出所有可用的软件仓库
使用
dnf repolist命令可以列出系统上所有可用的软件仓库，包括已经启用和禁用的。这个命令会显示每个软件仓库的 ID、名称、状态和软件包的数量。例如：shell[root@localhost ~]# dnf repolist repo id repo name appstream Rocky Linux 9 - AppStream baseos Rocky Linux 9 - BaseOS extras Rocky Linux 9 - Extras这个命令可以快速了解当前系统中配置的软件仓库情况。
除此之外，还可以使用
dnf repolist all命令可以显示系统中所有启用/禁用的仓库。这个命令提供了一个全面的视图，可以看到所有配置的仓库，无论它们是启用还是禁用状态。例如：shell[root@localhost ~]# dnf repolist all repo id repo name status appstream Rocky Linux 9 - AppStream enabled appstream-debuginfo Rocky Linux 9 - AppStream - Debug disabled appstream-source Rocky Linux 9 - AppStream - Source disabled baseos Rocky Linux 9 - BaseOS enabled baseos-debuginfo Rocky Linux 9 - BaseOS - Debug disabled baseos-source Rocky Linux 9 - BaseOS - Source disabled crb Rocky Linux 9 - CRB disabled crb-debuginfo Rocky Linux 9 - CRB - Debug disabled crb-source Rocky Linux 9 - CRB - Source disabled ……可以看到大部分仓库的状态是 disabled，只有少数几个（如 appstream、baseos、extras）是 enabled，并不是所有的仓库都被默认启用。
如果想要启用其中一个仓库，可以使用
dnf命令来启用特定的仓库，例如，需要启用 crb 这个仓库：shell[root@localhost ~]# dnf config-manager --set-enabled crb启用仓库后，需要更新仓库缓存以确保系统知道从新启用的仓库中获取软件包：
shell[root@localhost ~]# dnf makecache然后，可以通过再次运行
dnf repolist或者dnf repolist all命令来检查仓库的状态：shell[root@localhost ~]# dnf repolist repo id repo name appstream Rocky Linux 9 - AppStream baseos Rocky Linux 9 - BaseOS crb Rocky Linux 9 - CRB extras Rocky Linux 9 - Extras如果想关闭某个仓库执行
dnf config-manager --set-disable [repo id]将[repo id]替换为想要关闭的仓库的 ID 即可。查询可用的软件包
shelldnf search <package>例如，查询 nginx 相关的软件包，这么命令会搜索软件仓库中的软件包，返回与查询关键词相关的软件包列表：
shell[root@localhost ~]# dnf search nginx Last metadata expiration check: 1:21:33 ago on Wed Oct 30 09:56:55 2024. ================================================= Name Exactly Matched: nginx ================================================= nginx.x86_64 : A high performance web server and reverse proxy server ================================================ Name & Summary Matched: nginx ================================================ collectd-nginx.x86_64 : Nginx plugin for collectd munin-nginx.noarch : NGINX support for Munin resource monitoring nextcloud-nginx.noarch : Nginx integration for NextCloud nginx-all-modules.noarch : A meta package that installs all available Nginx modules nginx-core.x86_64 : nginx minimal core nginx-filesystem.noarch : The basic directory layout for the Nginx server nginx-mod-fancyindex.x86_64 : Nginx FancyIndex module nginx-mod-http-image-filter.x86_64 : Nginx HTTP image filter module nginx-mod-http-perl.x86_64 : Nginx HTTP perl module nginx-mod-http-xslt-filter.x86_64 : Nginx XSLT module nginx-mod-mail.x86_64 : Nginx mail modules nginx-mod-modsecurity.x86_64 : ModSecurity v3 nginx connector nginx-mod-stream.x86_64 : Nginx stream modules nginx-mod-vts.x86_64 : Nginx virtual host traffic status module pcp-pmda-nginx.x86_64 : Performance Co-Pilot (PCP) metrics for the Nginx Webserver python3-certbot-nginx.noarch : The nginx plugin for certbot sympa-nginx.x86_64 : Sympa with nginx这个命令成功地搜索到了与 nginx 相关的软件包。这些软件包提供了 Nginx 的核心功能以及各种扩展和监控工具，可以根据需要选择安装。
查询已安装的软件包
shelldnf list installed这个命令会列出系统中所有已安装的软件包。
查询特定软件包的详细信息
shelldnf info <package>这个命令会显示指定软件包的详细信息，包括版本、大小、依赖关系等。
查询软件包是否在仓库中可用
shelldnf list <package>如果软件包在仓库中可用，该命令将列出软件包的详细信息，包括版本号、仓库名称等。如果软件包不在仓库中，命令将返回错误信息，提示没有找到匹配的软件包。
查询所有可用的软件包
shelldnf list available这个命令会列出所有可用的软件包。
查询特定软件包的依赖关系
shelldnf repoquery --requires <package>这个命令会显示特定软件包的依赖关系。例如：
shell[root@localhost ~]# dnf repoquery --requires nginx Last metadata expiration check: 0:43:22 ago on Thu Oct 31 10:32:24 2024. /bin/sh /usr/bin/sh nginx-core = 1:1.20.1-16.el9_4.1 nginx-filesystem = 1:1.20.1-16.el9_4.1 pcre system-logos-httpd systemd
软件安装
dnf install <package>使用 dnf install 安装软件包时，DNF 会自动解决依赖关系。这意味着如果尝试安装一个依赖于其他软件包的软件包，DNF 会自动识别这些依赖关系，并尝试从配置的仓库中安装所有必需的依赖项。这一特性使得 DNF 非常适合用于自动化脚本和批量安装，因为它减少了手动解决依赖问题的需求。
例如安装 nginx：
[root@localhost ~]# dnf install nginx
Last metadata expiration check: 1:05:19 ago on Thu Oct 31 10:32:24 2024.
Dependencies resolved.
================================================================================================================================
Package Architecture Version Repository Size
================================================================================================================================
Installing:
nginx x86_64 1:1.20.1-16.el9_4.1 appstream 35 k
Installing dependencies:
nginx-core x86_64 1:1.20.1-16.el9_4.1 appstream 565 k
nginx-filesystem noarch 1:1.20.1-16.el9_4.1 appstream 8.1 k
rocky-logos-httpd noarch 90.15-2.el9 appstream 24 k
Transaction Summary
================================================================================================================================
Install 4 Packages
Total download size: 633 k
Installed size: 1.8 M
Is this ok [y/N]:在这部分输出中，dnf 明确指出了将要安装的软件包（Installing）以及这些软件包的依赖项（Installing dependencies）。具体来说：
- nginx 是尝试安装的软件包。
- nginx-core、nginx-filesystem 和 rocky-logos-httpd 是 nginx 需要的依赖软件包，
dnf会自动安装它们以满足 nginx 的安装要求。 这些依赖软件包被列在 Installing dependencies 下面，这就是dnf显示依赖关系的方式。
dnf install 命令支持安装多个软件包的：
dnf install <package1> <package2> <package3>...默认情况下，dnf 在安装软件包时会提示用户确认，要求输入 y（表示「是」）来确认安装，或者输入 N（表示「否」）来取消安装。这主要是为了防止误操作，确保用户对即将安装的软件包及其依赖关系有所了解。
如果想要自动安装软件包而不需要每次确认，可以使用 -y 选项来自动回答 yes：
dnf install -y <package>除此自外，还可以使用 dnf download 命令下载单个包或者一组包，包括它们的依赖。这对于在没有互联网连接的环境中安装软件包非常有用，因为可以在有网络的环境中下载所有需要的包和它们的依赖，然后将它们传输到没有网络的环境中进行安装。
dnf download --resolve --downloaddir=/path/to/ <package>--resolve：解析并下载软件包的依赖项。--downloaddir：指定下载软件包的目标目录。
例如，下载 docker 软件和其相关依赖并不安装：
[root@localhost ~]# dnf download --resolve --downloaddir=/root/ docker[root@localhost ~]# ls
aardvark-dns-1.12.1-1.el9.x86_64.rpm
conmon-2.1.12-1.el9.x86_64.rpm
container-selinux-2.232.1-1.el9.noarch.rpm
containers-common-1-93.el9_5.x86_64.rpm
criu-3.19-1.el9.x86_64.rpm
criu-libs-3.19-1.el9.x86_64.rpm
crun-1.16.1-1.el9.x86_64.rpm
fuse-common-3.10.2-9.el9.x86_64.rpm
fuse-overlayfs-1.14-1.el9.x86_64.rpm
fuse3-3.10.2-9.el9.x86_64.rpm
fuse3-libs-3.10.2-9.el9.x86_64.rpm
libnet-1.2-7.el9.x86_64.rpm
libslirp-4.4.0-8.el9.x86_64.rpm
netavark-1.12.2-1.el9.x86_64.rpm
'passt-0^20240806.gee36266-2.el9.x86_64.rpm'
'passt-selinux-0^20240806.gee36266-2.el9.noarch.rpm'
podman-5.2.2-9.el9_5.x86_64.rpm
podman-docker-5.2.2-9.el9_5.noarch.rpm
protobuf-c-1.3.3-13.el9.x86_64.rpm
shadow-utils-subid-4.9-9.el9.x86_64.rpm
slirp4netns-1.3.1-1.el9.x86_64.rpm
tar-1.34-7.el9.x86_64.rpm
yajl-2.1.0-22.el9.x86_64.rpm软件升级
dnf 软件升级通常是指将系统中已安装的软件包更新到软件仓库中提供的更高版本的过程。这个版本是由系统配置的软件仓库中提供的。如果软件包的新版本已经发布，但软件仓库中没有更新，那么 dnf 也不会提示有更新可用。
NOTE
例如，如果 nginx 官网已经发布了 1.30 版本，但是使用 dnf install 安装的版本只有 1.20，并且软件仓库中没有提供更新的版本，那么 dnf 将不会提示有新的版本可以更新。这是因为 dnf 只能从配置的软件仓库中获取可用的软件包和版本。
使用 dnf update 命令可以升级系统中的一个或多个软件包。
如果不指定具体的软件包，那么 dnf update 命令会升级所有已安装的软件包到最新版本：
dnf update如果指定了具体的软件包，dnf 会只升级那些指定的软件包：
dnf update <package>除此自外，还提供了 dnf upgrade 命令，这个命令与 dnf update 相似，但通常 upgrade 用于交互式升级，而 update 用于非交互式环境。
dnf upgrade <package>在任何情况下，dnf 都会根据仓库中可用的软件包版本来决定升级到哪个版本，并处理所有必要的依赖关系。
软件卸载
软件卸载是指使用 dnf 命令行工具从 Linux 系统中移除不再需要的软件包。当卸载一个软件包时，dnf 会删除该软件包及其所有配置文件，但不会删除该软件包的依赖项，除非这些依赖项不再被其他已安装的软件包所需要。
dnf remove <package>强制卸载
如果想要强制卸载一个软件包，即使它被其他软件包所依赖，可以使用
--nodeps选项。这通常不推荐，因为它可能会破坏依赖关系：shelldnf remove --nodeps <package>自动移除依赖
如果一个软件包的依赖项不再被任何其他已安装的软件包所需要，
dnf会自动移除这些依赖项。这个行为可以通过--autoremove选项来控制：shelldnf remove --autoremove <package>最佳匹配
如果提供了一个不完整的软件包名称，
dnf会尝试找到最佳匹配。使用--best选项可以确保dnf只考虑最佳匹配：shelldnf remove --best <package>查看将要执行的操作
使用
--dry-run选项可以模拟卸载过程，显示将要被删除的软件包，但不实际执行卸载：shelldnf remove --dry-run <package>
EPEL
EPEL（Extra Packages for Enterprise Linux）是一个由 Fedora 特别兴趣小组（Special Interest Group）维护的项目，它为 Red Hat Enterprise Linux（RHEL）及其衍生版，如 CentOS、Rocky Linux、Scientific Linux 等，提供额外的软件包。这些软件包不是由 Red Hat 官方提供的，但它们被认为对企业用户是有价值的补充。
EPEL 仓库是独立于操作系统官方仓库的。它和官方仓库相互补充，官方仓库侧重于提供操作系统运行所必需的基础软件包，并且这些软件包经过了严格的兼容性和稳定性测试，通常更新速度相对较慢。而 EPEL 仓库则提供更多种类的软件，更新速度可能会更快，尤其是对于一些新兴的或者特定领域的软件。
例如，如果在系统上需要安装一些比较新的开发库，像 Python 的某些高级库或者一些网络测试工具，而这些工具在官方仓库中不存在，就可以从 EPEL 仓库中寻找并安装。
EPEL 仓库的主要特点包括：
- 高质量软件包：EPEL 仓库中的软件包经过了严格的测试和审查，以确保它们在企业级 Linux 发行版上能够稳定运行。
- 非冲突性：EPEL 软件包被设计为不会与发行版默认提供的软件包发生冲突，它们可以作为补充，提供更多的选择。
- 开源：EPEL 项目本身是开源的，任何人都可以贡献软件包或者改进现有的软件包。
- 安全和合规：EPEL 软件包遵循 Red Hat 的安全和合规标准，适合在企业环境中使用。
- 广泛的软件支持：EPEL 提供了许多在默认仓库中不可用的软件包，包括一些流行的开源项目和工具。
- 社区支持：EPEL 是由社区驱动的，这意味着它依赖于社区的贡献和维护。
要使用 EPEL 仓库，需要先在系统中启用它。这通常涉及到下载并安装 EPEL 仓库的配置文件（通常是 .repo 文件），然后使用 dnf 更新仓库缓存。一旦启用，就可以使用 dnf 命令来安装 EPEL 仓库中的软件包了。
例如，可以使用 dnf 命令直接安装 EPEL 仓库的配置包：
[root@localhost ~]# dnf -y install epel-release安装完成后，可以使用以下命令来检查 EPEL 仓库是否已经正确启用：
[root@localhost ~]# dnf repolist
repo id repo name
appstream Rocky Linux 9 - AppStream
baseos Rocky Linux 9 - BaseOS
crb Rocky Linux 9 - CRB
epel Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras Rocky Linux 9 - Extras也可以通过查看 /etc/yum.repos.d/ 目录下的 .repo 文件来检查 EPEL 仓库的配置：
[root@localhost ~]# ll /etc/yum.repos.d/epel*
-rw-r--r--. 1 root root 1142 Aug 28 2023 /etc/yum.repos.d/epel-cisco-openh264.repo
-rw-r--r--. 1 root root 1552 Aug 28 2023 /etc/yum.repos.d/epel-testing.repo
-rw-r--r--. 1 root root 1453 Aug 28 2023 /etc/yum.repos.d/epel.repoepel-testing.repo 和 epel-cisco-openh264.repo 是 EPEL 仓库的两个特殊部分：
- epel-testing.repo：这个仓库包含了尚未被标记为稳定的软件包。通常，这些软件包是新加入 EPEL 的，或者版本较新，可能还没有经过广泛的测试和验证。使用 epel-testing 仓库的系统管理员和开发者可以提前获得新的软件包，但同时也需要承担潜在的稳定性风险。
- epel-cisco-openh264.repo：这个仓库是由 Cisco 提供的，专门用于分发 OpenH264 编解码器的软件包。OpenH264 是一个开源的 H.264 视频编解码器，广泛应用于视频会议和流媒体服务中。由于某些法律和专利原因，这个编解码器可能不会包含在标准的 EPEL 仓库中，因此通过 epel-cisco-openh264.repo 提供。
EPEL 默认的软件包仓库地址是国外的，对于国内用户来说，从国外地址下载软件包可能会遇到网络速度慢、下载中断甚至无法访问的情况，也需要更换为国内镜像源，以阿里云为例，可以执行以下命令：
sed -e 's!^metalink=!#metalink=!g' \
-e 's!^#baseurl=!baseurl=!g' \
-e 's!https\?://download\.example/pub/epel!https://mirrors.aliyun.com/epel!g' \
-i /etc/yum.repos.d/epel{,-testing}.repo由于大多数国内镜像站不包含 EPEL Cisco OpenH264 仓库，可以手动将其禁用：
[root@localhost ~]# sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/epel-cisco-openh264.repo修改配置后，需要清除 dnf 的缓存并重建，以确保系统使用新的镜像源：
[root@localhost ~]# dnf clean all
[root@localhost ~]# dnf makecacheDNF 模块
WARNING
Rocky 10 开始 DNF 模块化支持弃用，未来可能通过 RPM 包、软件集合或 Flatpak 提供更多应用版本。
从 RHEL8/CentOS8 开始，dnf 取代 yum 作为 RPM 包管理工具。与之而来的还有模块 moduler。该功能主要用于切换不同版本的软件，其主要用于快速替换升级当前使用软件版本，让在同一个 OS 上安装不同版本的软件或者开发语言的工作比之前容易多了。例如，用户可以通过 DNF 模块来切换不同版本的 PHP、Nginx 或 Node.js 等软件。模块功能类似于 Windows 下的 phpMyAdmin 中的一键切换 PHP 版本功能。
DNF 模块的使用包括启用模块、查询模块信息、卸载模块、查询模块提供的软件库信息、列出模块详细信息、更新模块、安装模块、重置模块和禁用模块等操作。用户可以通过 dnf module list 命令来查询有哪些模块流，通过 dnf module info 命令来显示模块的详细信息。此外，如果用户尝试安装一个由模块流提供的软件包，DNF 会自动解析所需的模块流，并在安装软件包时自动启用它。
模块的基本概念：
- 模块（Module）：模块是一组相关的软件包，它们共同提供特定的功能或应用程序。
- 流（Stream）：流是模块内的一个版本线，代表软件的一个特定版本，例如，Nginx 模块可能包含 1.22 和 1.24 等多个流。
- 配置文件（Profile）：配置文件是模块内预定义的一组软件包，它们提供了不同的安装选项，以满足不同的使用场景。
DNF 模块是一个强大的工具，它提供了一种灵活的方式来管理软件的不同版本，使得在 Linux 系统上进行软件版本切换变得更加简单和直接。
查询当前模块
dnf module list 用于列出在基于 RPM 的 Linux 发行版（如 Fedora、Rocky Linux、CentOS 等）上可用的软件模块。这个命令是 DNF 包管理器的一部分，用于管理软件包的安装、更新和删除。
当在终端中执行 dnf module list 命令时，它会显示所有可用的模块及其相关信息，包括模块名称、流（Stream）、配置文件（Profiles）和模块的简短描述（Summary）。模块是一组软件包，它们一起提供特定的功能或应用程序的特定版本。
这个命令的输出还包括一些标记，以指示模块的状态：
- [d]efault：表示这是模块的默认版本。
- [e]nabled：表示模块当前被启用。
- [x]disabled：表示模块当前被禁用。
- [i]nstalled：表示模块已经被安装。
[root@localhost ~]# dnf module list
Last metadata expiration check: 0:13:13 ago on Wed Nov 6 08:12:17 2024.
Rocky Linux 9 - AppStream
Name Stream Profiles Summary
mariadb 10.11 client, galera, server [d] MariaDB Module
maven 3.8 common [d] Java project management and project comprehension tool
nginx 1.22 common [d] nginx webserver
nginx 1.24 common [d] nginx webserver
nodejs 18 common [d], development, minimal, s2i Javascript runtime
nodejs 20 common [d], development, minimal, s2i Javascript runtime
php 8.1 common [d], devel, minimal PHP scripting language
php 8.2 common [d], devel, minimal PHP scripting language
postgresql 15 client, server [d] PostgreSQL server and client module
postgresql 16 client, server [d] PostgreSQL server and client module
redis 7 common [d] Redis persistent key-value database
ruby 3.1 common [d] An interpreter of object-oriented scripting language
ruby 3.3 common [d] An interpreter of object-oriented scripting language
Rocky Linux 9 - CRB
Name Stream Profiles Summary
swig 4.1 common [d], complete Connects C/C++/Objective C to some high-level programming languages
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled可以看到：
- 模块名称：列出了系统中支持的模块，例如 mariadb、maven、nginx、nodejs、php、postgresql、redis、ruby 和 swig。
- 流（Stream）：每个模块后面跟着的是流的版本，例如 nginx 有对应的 1.22 和 1.24 版本；php 有 8.1 和 8.2 版本。
- 配置文件（Profiles）：某些模块提供了不同的配置文件，mariadb 模块提供了 client、galera、server 三个配置文件，每个配置文件对应不同的使用场景；nginx 只有一个 common 配置文件，common 配置文件包含了大多数用户安装 nginx 时所需的基本软件包和默认配置。
- 默认和启用状态：方括号中的标记 [d]efault 表示默认模块，[e]nabled 表示启用的模块，[x]disabled 表示禁用的模块，[i]nstalled 表示已安装的模块。
- 摘要（Summary）：每个模块后面的简短描述提供了模块的概要信息。
安装指定模块流
首先，可以使用 dnf module list 命令来查看系统中可用的模块以及它们的流和配置文件。例如，如果想查看 Nginx 模块的详细信息：
[root@localhost ~]# dnf module list nginx
Last metadata expiration check: 1:45:05 ago on Wed Nov 6 08:44:55 2024.
Rocky Linux 9 - AppStream
Name Stream Profiles Summary
nginx 1.22 common [d] nginx webserver
nginx 1.24 common [d] nginx webserver
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled要安装模块列表中显示的 Nginx 版本，需要明确指定模块流。例如，要安装 Nginx 的 1.24 版本，可以使用以下命令：
[root@localhost ~]# dnf module install nginx:1.24除了指定模块流之外，还可以先启用对应的模块流，那么在安装软件时，默认下载和安装的将是指定版本的软件包，例如：
[root@localhost ~]# dnf module enable nginx:1.24
Last metadata expiration check: 0:04:58 ago on Wed Nov 6 14:53:24 2024.
Dependencies resolved.
==================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================
Enabling module streams:
nginx 1.24
Transaction Summary
==================================================================================================================================
Is this ok [y/N]: y
Complete!再通过 dnf module list nginx 命令查看：
[root@localhost ~]# dnf module list nginx
Last metadata expiration check: 0:05:22 ago on Wed Nov 6 14:53:24 2024.
Rocky Linux 9 - AppStream
Name Stream Profiles Summary
nginx 1.22 common [d] nginx webserver
nginx 1.24 [e] common [d] nginx webserver
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled可以看到 1.24 流被标记为 [e]nabled，意味着它已被启用。如果现在安装 Nginx，系统将从这个流中安装 Nginx 软件包。
模块流切换
模块流切换是指在使用基于模块的包管理系统（如 DNF）的 Linux 发行版中，用户可以切换软件包的不同版本或不同版本的集合的过程。在 Red Hat Enterprise Linux 8 及更高版本、Fedora 和一些其他基于 RPM 的发行版中，软件包被组织成模块，每个模块可以包含多个流，每个流代表软件的不同主要版本。
模块流切换的目的：
- 版本管理：用户可以根据需要切换到不同版本的流，以使用软件的新功能或安全更新。
- 兼容性：在某些情况下，旧版本的软件可能与系统其他部分更兼容，用户可能需要切换回旧版本。
- 测试和开发：开发人员可以在不同的版本之间切换，以测试软件的兼容性和新功能。
dnf module switch-to 这个命令的设计目的就是为了方便用户在不同的模块流之间进行切换。该命令的便利之处在于，它简化了模块流之间的切换过程，用户无需手动启用目标流，命令会自动处理这些步骤。这样，用户可以更快捷、更方便地在不同的软件版本之间进行切换，而无需担心复杂的依赖和配置问题
例如，服务器通过模块安装了 Nginx 1.24 版本，现在需要降级到 1.22 版本：
[root@localhost ~]# nginx -v
nginx version: nginx/1.24.0[root@localhost ~]# dnf -y module switch-to nginx:1.22[root@localhost ~]# nginx -v
nginx version: nginx/1.22.1