阅读时间约15分钟 | 建议收藏后再看

本文适合：Linux运维工程师 / SRE / DevOps / 后端开发 / 在校学生

写在前面

你有没有遇到过这些场景：

• yum install 半天没反应，或者报依赖错误，一脸茫然；
• 手动下了个 .rpm 包，装上去发现版本不对，卸载又怕删出问题；
• 换了台机器，原来的软件源配置全失效，只能在网上翻东翻西地找；
• rpm -e 和 yum remove 到底用哪个？傻傻分不清楚……

这些问题的本质，是对 Linux 包管理体系没有形成系统认知。

今天这篇文章，我把自己这些年踩过的坑、整理出的方法论，完整地梳理给你。读完之后，不管面试还是生产环境，你都能做到心里有底。

一、先建立大局观：Linux 包管理的两大体系

在深入命令之前，先搞清楚一件事——Linux 的软件包管理，本质上分成两大阵营：

Linux 包管理体系
├── RPM 体系（Red Hat 系）
│   ├── 底层工具：rpm
│   ├── 中层工具：yum（经典）
│   └── 新一代：dnf（Fedora/CentOS 8+）
│
└── DPKG 体系（Debian 系）
    ├── 底层工具：dpkg
    └── 高层工具：apt / apt-get

记住这个分层模型，非常重要：

一句话总结：底层工具像是"搬运工"，只管把包装上去；高层工具才是"项目经理"，负责协调依赖关系、从仓库拉取资源。

实战建议：日常安装软件，优先用高层工具（yum/apt）。只有在处理离线包、版本降级、精确卸载时，才动底层工具（rpm/dpkg）。

二、RPM——Linux 包管理的元老级工具

2.1 RPM 是什么？

RPM（RedHat Package Manager），是 Red Hat 在 1997 年推出的包管理格式，历史超过 25 年。它以数据库的形式记录系统中所有已安装软件的元数据，包括：文件列表、版本信息、数字签名、依赖关系。

核心文件只有一个：/var/lib/rpm/（RPM 数据库所在位置）。

2.2 高频命令速查

# ============ 安装 ============
rpm -ivh package.rpm
# -i: install（安装）
# -v: verbose（显示详细过程）
# -h: hash（用 ##### 显示进度条）

# ============ 查询 ============
rpm -qa                        # 列出系统中所有已安装的包
rpm -qa | grep nginx           # 查询指定包是否安装
rpm -ql nginx                  # 查询 nginx 安装了哪些文件，装到哪里了
rpm -qf /usr/bin/python3       # 反查：这个文件属于哪个包

# ============ 升级 ============
rpm -Uvh new-version.rpm       # 升级，若未安装则直接安装

# ============ 卸载 ============
rpm -e nginx                   # 卸载（注意：是包名，不是文件名）
rpm -e --nodeps nginx          # 强制卸载，忽略依赖（谨慎使用！）

2.3 一个必须掌握的查询技巧

场景：你发现系统里有个命令（比如 tree），但你想知道它是随哪个包装进来的，卸载的时候需要卸哪个。

[root@server ~]# rpm -qf /bin/tree
tree-1.6.0-10.el7.x86_64

这就是反向查询。-qf 的 f 代表 file，输入文件路径，输出包名。这个技巧在排查"这个文件是谁安装的"时极其好用。

2.4 卸载用 rpm -e，而不是 yum remove

这是很多人会搞混的点，直接说结论：

• yum remove 会连带删除依赖它的其他软件包，在生产环境极容易误伤；
• rpm -e 只删你指定的那一个包，不会自动清理依赖，更加可控。

⚠️ 生产环境黄金法则：卸载软件用 rpm -e，绝不轻易用 yum remove。

三、YUM——自动解依赖的效率神器

3.1 YUM 的核心价值

RPM 最大的痛点是不处理依赖。你手动装一个软件，它依赖 A，A 依赖 B，B 依赖 C……你得一个个手动找、手动装，噩梦一般。

YUM（Yellowdog Updater Modified）就是为解决这个问题而生的。它能：

• 自动解析所有依赖关系，一次性装齐；
• 从远程仓库（Repository）拉取软件包；
• 提供仓库管理、缓存管理等高级功能。

3.2 两个核心配置文件，必须烂熟于心

① /etc/yum.conf — 全局行为配置

[main]
cachedir=/var/cache/yum/$basearch/$releasever# 缓存路径
keepcache=0        # 0=安装后删除rpm包，1=保留（自建yum源时必须设为1）
gpgcheck=1         # 启用包签名验证，安全必开
logfile=/var/log/yum.log

**重点看 keepcache**：

• 默认为 0，安装完 rpm 包自动清除，节省磁盘；
• 搭建内网 YUM 源时，必须改为 1，否则包下载完就没了，同事访问你的源就会 404。

② /etc/yum.repos.d/*.repo — 软件源配置

这是 YUM 知道"去哪里下软件"的核心文件，一个 repo 文件的结构如下：

[base]
name=CentOS-$releasever - Base - mirrors.aliyun.com
baseurl=http://mirrors.aliyun.com/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7
enabled=1

3.3 换国内源（必做！官方源太慢了）

标准操作步骤——以阿里云为例：

# Step 1：备份原始配置（重要！出问题可以回滚）
cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak

# Step 2：下载阿里云的 repo 文件
curl -o /etc/yum.repos.d/CentOS-Base.repo \
    https://mirrors.aliyun.com/repo/Centos-7.repo

# Step 3：下载 EPEL 源（扩展包，非常有用）
curl -o /etc/yum.repos.d/epel.repo \
    http://mirrors.aliyun.com/repo/epel-7.repo

# Step 4：清除旧缓存，重建索引
yum clean all && yum makecache

# Step 5：验证
yum repolist

💡 EPEL（Extra Packages for Enterprise Linux） 是 Fedora 维护的扩展软件仓库，很多官方源没有的软件（如 htop、iotop、ncdu 等运维利器），都在 EPEL 里。配完基础源之后，这个必装。

3.4 YUM 命令全景图

# ======== 安装 ========
yum install -y nginx              # 安装，-y 自动确认所有提示
yum install -y --downloadonly nginx  # 只下载不安装（适合离线迁移场景）

# ======== 查询 ========
yum search nginx                  # 在仓库中搜索关键词
yum list installed                # 列出已安装的所有包
yum list available | grep nginx   # 查询仓库中可用的 nginx 版本
yum repolist                      # 查看当前启用的 yum 源列表

# ======== 这个命令超级实用：yum provides ========
yum provides ifconfig             # 查询 ifconfig 命令由哪个包提供
yum provides "*/nginx.conf"# 查询哪个包包含 nginx.conf 文件

# ======== 更新 ========
yum update nginx                  # 更新指定包
yum update                        # 更新所有包（生产环境谨慎执行！）
yum check-update                  # 只检查有哪些更新，不真正执行

# ======== 清理 ========
yum clean all                     # 清除所有缓存（换源后必做）
yum clean packages                # 只清除缓存的 rpm 包
yum makecache                     # 重建元数据缓存

3.5 yum provides ——最被低估的命令

很多人只知道 yum install，但 yum provides 才是解决"命令找不到"问题的终极武器。

真实场景：新机器执行 ifconfig 报 command not found，不知道装哪个包？

[root@server ~]# yum provides ifconfig
net-tools-2.0-0.25.20131004git.el7.x86_64 : Basic networking tools
Repo        : base
Matched from:
Filename    : /sbin/ifconfig

# 直接知道了！装 net-tools 就行
[root@server ~]# yum install -y net-tools

另一个场景：你想知道 netstat、ss、lsof 分别来自哪个包，搭建基础镜像时就知道该预装哪些：

yum provides netstat    # → net-tools
yum provides ss         # → iproute
yum provides lsof       # → lsof

这个命令会扫描整个仓库的元数据，不管文件有没有安装，都能找到。

四、DNF——YUM 的进化形态

4.1 为什么需要 DNF？

YUM 用了将近 20 年，暴露出几个痛点：

• 依赖解析算法陈旧，复杂场景容易失败或计算极慢；
• 内存占用高，性能差；
• Python 2 编写，维护成本高。

DNF（Dandified YUM）从 Fedora 22 开始引入，CentOS 8 / RHEL 8 起已成为默认包管理器，它解决了上述所有问题：

4.2 DNF 命令兼容 YUM

好消息是：DNF 的命令语法与 YUM 几乎完全兼容，直接把 yum 换成 dnf 就行：

dnf install -y nginx
dnf search nginx
dnf repolist
dnf clean all
dnf update

不需要重新学一套命令，迁移成本极低。

五、DPKG + APT——Debian/Ubuntu 阵营的双剑合璧

5.1 与 RPM 体系的对应关系

5.2 DPKG 核心命令

dpkg -i package.deb        # 安装 .deb 包
dpkg -l | grep nginx       # 查询是否安装
dpkg -L nginx              # 查询安装了哪些文件
dpkg -S /usr/bin/nginx     # 反查文件所属包
dpkg -r nginx              # 卸载（保留配置文件）
dpkg -P nginx              # 彻底卸载（包括配置文件）

5.3 APT 核心命令

apt update                 # 更新软件源索引（换源后必做）
apt install -y nginx       # 安装
apt search nginx           # 搜索
apt list --installed       # 列出已安装的包
apt remove nginx           # 卸载（保留配置）
apt purge nginx            # 彻底卸载（清除配置）
apt autoremove             # 清理不再需要的依赖包
apt upgrade                # 升级所有可更新的包

六、生产实战：场景化问题解决手册

场景一：离线环境安装软件

当服务器不能联网时，如何安装软件？

# 方案1：在联网机器上只下载不安装，然后拷贝到目标机器
yum install -y --downloadonly --downloaddir=/tmp/pkgs nginx

# 打包传输
tar czf pkgs.tar.gz /tmp/pkgs

# 目标机器上安装（会自动处理目录内的依赖关系）
cd /tmp/pkgs
rpm -ivh *.rpm

场景二：RPM 数据库损坏修复

某些极端情况下（断电、磁盘满），RPM 数据库可能损坏，导致所有 rpm/yum 命令报错。

# 症状：执行任何 rpm 命令报 "rpmdb: DBRUNRECOVERY: fatal region error detected; run recovery"

# 修复步骤
rm -f /var/lib/rpm/__db.*    # 删除损坏的数据库锁文件
rpm --rebuilddb               # 重建数据库
yum clean all                 # 清除缓存
yum makecache                 # 重建索引

场景三：查看软件包安装历史

# 查看 yum 操作历史
yum history

# 查看具体某次操作的详情（N 是操作编号）
yum history info N

# 回滚某次操作（慎用！）
yum history undo N

场景四：锁定软件版本，防止意外更新

生产环境中，某些软件（如 Kubernetes 组件）需要固定版本，不能被 yum update 更新到新版。

# 安装 versionlock 插件
yum install -y yum-versionlock

# 锁定版本
yum versionlock add kubectl-1.28.0

# 查看已锁定的包
yum versionlock list

# 解除锁定
yum versionlock delete kubectl

场景五：搭建内网 YUM 源（适合企业内网环境）

# Step 1：修改 /etc/yum.conf，开启缓存
sed -i 's/keepcache=0/keepcache=1/' /etc/yum.conf

# Step 2：安装 createrepo
yum install -y createrepo

# Step 3：同步官方仓库（以 base 为例）
reposync -r base -p /data/repos/

# Step 4：生成仓库元数据
createrepo /data/repos/base/

# Step 5：安装 nginx 或 httpd 提供 HTTP 访问
yum install -y nginx
# 配置 nginx 指向 /data/repos/

# 客户端配置 .repo 文件，将 baseurl 指向内网 HTTP 地址即可

七、避坑指南：10 条不得不说的忠告

1. 换源之前必须先备份/etc/yum.repos.d/CentOS-Base.repo，别等出问题了再后悔。

2. yum update 不要随便在生产环境全量执行，大版本更新可能导致内核、glibc 等关键组件升级，引发兼容性问题。

3. **卸载用 rpm -e，不用 yum remove**，后者会删掉依赖，极易误伤其他服务。

4. GPG 验证不要随便关，gpgcheck=0 意味着你安装的软件没有经过签名验证，存在供应链安全风险。

5. **yum clean all 之后要 yum makecache**，否则第一次安装会慢很多（要重新下载元数据）。

6. EPEL 源是必装的，很多常用运维工具（htop、iotop、ncdu、lrzsz 等）只在 EPEL 里有。

7. **安装前先 yum search**，养成习惯，避免装了一堆不需要的包进来。

8. rpm -qf 是排障好帮手，不知道某个配置文件或二进制属于哪个包，直接查。

9. DNF 是未来，如果你的环境是 CentOS 8+ 或 RHEL 8+，请直接使用 dnf，YUM 已是过去式。

10. 生产变更前先在测试环境验证，不管多简单的包操作，先测再上。

八、一张图总结：完整知识体系

                    Linux 包管理全景
┌─────────────────────────────────────────────────────┐
│                                                     │
│   RPM 体系（Red Hat / CentOS / Fedora）              │
│   ┌─────────────────────────────────────────────┐  │
│   │  高层：YUM（CentOS 7及以前） / DNF（CentOS 8+） │  │
│   │  → 自动解依赖、连接远程仓库、版本锁定           │  │
│   │                                             │  │
│   │  底层：rpm                                  │  │
│   │  → 操作 .rpm 文件，查询、安装、卸载           │  │
│   └─────────────────────────────────────────────┘  │
│                                                     │
│   DPKG 体系（Debian / Ubuntu / Kali）               │
│   ┌─────────────────────────────────────────────┐  │
│   │  高层：apt / apt-get                         │  │
│   │  → 自动解依赖、换源、清理                    │  │
│   │                                             │  │
│   │  底层：dpkg                                  │  │
│   │  → 操作 .deb 文件                           │  │
│   └─────────────────────────────────────────────┘  │
│                                                     │
│   使用原则：                                        │
│   日常安装 → 高层工具（yum/apt）                    │
│   精确卸载 → 底层工具（rpm -e / dpkg -r）            │
│   定位来源 → rpm -qf / yum provides                 │
│   离线安装 → rpm -ivh / dpkg -i                     │
└─────────────────────────────────────────────────────┘

写在最后

Linux 包管理这个话题，看起来简单，真正用好其实需要建立体系化认知——知道每一层工具的边界在哪里，什么场景用什么命令，遇到问题从哪个角度切入排查。

希望这篇文章，能帮你把这块知识真正打通，而不是每次遇到问题都去搜索引擎拼凑答案。

如果这篇文章对你有帮助，欢迎点赞 + 在看，你的支持是我持续输出的最大动力 🙏

关注我，持续分享 SRE / 云原生 / Linux 一线实战干货

· END ·

推荐阅读