dnf 是什么
dnf 是 RHEL 8 及之后版本、CentOS Stream、Fedora 的默认包管理器，也是 yum 的继任者——在 RHEL 8+ 上执行 yum 实际就是调用 dnf。它用 libsolv 做依赖求解，把安装、升级、卸载组织成事务，并且每次事务都记录在 dnf history 里，可以按编号回滚。相比旧 yum，它在依赖冲突时的输出更明确，也支持模块流（module stream）这种同一软件多版本共存的机制。
基本信息
| 适用平台 | RHEL 8+、CentOS Stream 8/9/10、Rocky、AlmaLinux、Fedora；CentOS 7 默认仍是 yum，需要自行安装 dnf |
|---|---|
| 命令语法 | dnf [选项] 子命令 包名... |
| 常用子命令 | install、reinstall、update/upgrade、remove、autoremove、search、info、list、provides、repolist、clean、makecache、history、module、downgrade |
| 配置文件 | /etc/dnf/dnf.conf 控制全局行为，仓库定义在 /etc/yum.repos.d/*.repo；缓存位于 /var/cache/dnf |
| 权限要求 | 安装与卸载需要 root 或 sudo；查询类子命令普通用户即可执行 |
典型使用场景
- 装包与服务依赖：dnf install -y nginx，一次把依赖链解好
- 由文件反查包名：dnf provides */ifconfig 找出某个命令来自哪个包
- 安全更新：dnf update --security 只应用安全相关更新，缩小变更面
- 回滚出问题的事务：dnf history 找到编号后 undo，整批恢复
- 锁定版本：用 versionlock 插件或 dnf 配置排除，避免关键组件被意外升级
- 清理与重建缓存：仓库元数据异常时先 dnf clean all 再 makecache
常用示例
常用示例
dnf install -y nginx
dnf update -y
dnf remove -y telnet
dnf list installed | grep nginx
dnf provides */ifconfig # 由文件反查包
dnf info nginx # 版本、来源仓库与依赖
dnf --assumeno install nginx # 只看事务方案，不真正执行
dnf history # 列出事务编号
dnf history info 12 # 某次事务的详情
dnf history undo last # 撤销上一次事务
dnf module list nginx # RHEL 系查看可用的模块流子命令对照
| 子命令 | 作用 | 注意 |
|---|---|---|
| install | 安装包并解析依赖 | 用 --assumeno 先看方案再执行 |
| update / upgrade | 升级已安装包，处理过时替换关系 | 在 dnf 中两者已基本等价 |
| provides | 由文件或能力反查所属包 | 找不到命令时最常用的定位手段 |
| history | 查看与回滚事务 | undo 依赖仓库里仍有旧版本包 |
| module | 管理模块流（同一软件的多个版本通道） | RHEL 系特有机制，切换流会影响版本 |
| clean / makecache | 清理与重建元数据缓存 | 报 404 或依赖异常时先做这一步 |
dnf history undo 能回滚的前提是仓库里还能取到旧版本包，如果已从仓库撤下，回滚会失败。执行升级前先 dnf history 留个记录，或对关键包保留本地 rpm（dnf download 配合离线安装）作为退路。
模块流是 RHEL 8+ 引入的机制：同一个软件可以有多个并行版本通道，例如不同版本的 PHP 或 Node.js。切换流用 dnf module enable 名称:流 再 dnf module install，切换会改变已装版本，操作前先 dnf module list 看清可用流。
在业务机上直接 dnf update -y 是不受控变更：它会连带升级依赖、内核与库文件，可能触发重启或运行时兼容问题。生产环境应先在测试环境验证，或在 dnf.conf 里排除关键包（如 exclude=kernel*）并指定维护窗口。
dnf 与 yum 的关系：RHEL 8+ 上 yum 是指向 dnf 的软链接，老教程里的 yum 参数基本通用；CentOS 7 及更早版本默认只有 yum，看到 dnf 报 command not found 属于系统年代问题，不是配置错误。
本地与离线安装：dnf install ./package.rpm 可直接安装本地 rpm 并尝试解析依赖；从其他机器取包用 dnf download 包名（需要 dnf-plugins-core）；把一批 rpm 用 createrepo_c 生成元数据后用 .repo 文件里的 baseurl 指向 file:// 路径，就构成了内网仓库，适合隔离网络环境。
事务失败的常见处理：依赖冲突时 dnf 会给出候选方案，逐个确认比直接加 --skip-broken 跳过更稳妥；确实卡在版本上可以用 dnf repoquery 的 --requires 与 --whatrequires 看依赖链，或临时用 --nobest 放宽版本选择。不要用 --nodeps 强行安装，那会留下 rpm 数据库与实际文件不一致的隐患，后续升级会持续报错。