1. yum 命令到底解决了什么问题yum 命令大概是每个碰过 Linux 服务器的人都绕不开的东西。你拿到一台干净的机器想装个 nginx、装个 vim、装个 gcc第一反应多半就是敲yum install。它属于 linux 常用命令里出场率排前几的那一档也是 linux 常用命令大全类文章里被反复抄来抄去的一条。但大部分资料只告诉你这么敲就行很少有人把 yum 背后的机制、参数的取舍、报错怎么排讲透。我在运维一线待了十来年遇到过因为一条 yum 命令敲错导致生产环境依赖崩掉的事故也见过内网没源、几百台机器全靠手工拷 rpm 的惨状。这篇东西就是把这些年攒下来的经验摊开讲清楚。先给不熟悉的朋友一个定位yum 是 RPM 系发行版RHEL、CentOS、Rocky、AlmaLinux、Fedora 这些上的包管理器它以 RPM 包为基础但做的事比 rpm 命令多得多——它要去找包在哪、要算清楚这个包依赖哪些别的包、要按什么顺序装、装完要不要更新缓存。你能用它做的事包括装包、卸包、升级、降级、查包、查文件属于哪个包、管理软件组、回滚一次操作、搭内网源。适合谁看刚入行的运维、被部署脚本搞得头大的后端、需要给团队维护基础镜像的 SRE以及所有想从会敲进阶到懂为什么这么敲的人。下面我不按命令手册那种 A-Z 罗列而是按为什么这么设计—怎么用—踩过什么坑的顺序讲。1.1 从 rpm 手动装包的痛说起很多人学 yum 之前先学了rpm -ivh然后很快就被依赖关系教做人。你装一个 A 包它报error: Failed dependencies: libb.so.1 is needed by A你去找 libb 装完它又告诉你 libb 依赖 libclibc 又依赖 glibc 的某个具体版本……这种剥洋葱式的依赖地狱在 2000 年代初是真的靠人工一层层剥的。而且更阴险的是版本问题系统里可能已经有 libb 了但版本低了或者架构不对rpm -ivh直接拒绝或者强行装进去搞出两个版本打架。yum 的出现就是为了终结这套玩法。它把包从哪来依赖谁先装谁这三件事全部交给程序去算。你只要说我要 nginxyum 会自动列出它需要拉下来的一串包算出安装顺序然后一次事务全部提交。更关键的一点是yum 引入仓库这个概念之后包来源统一了全公司几十台机器指向同一个源装出来的东西就是一致的这比人工拷 rpm 可靠太多。理解这层动机你才能理解后面那些参数为什么存在——它们都是在处理包从哪来和事务怎么提交这两件事的边界情况。1.2 yum 的三个核心角色仓库、元数据、依赖求解把 yum 拆开看它其实由三块拼起来。第一块是仓库repository就是一个存放 RPM 包的目录或者 HTTP 站点加上一个描述这些包的索引。第二块是元数据metadata这是 yum 的灵魂——仓库里不只是丢着一堆 .rpm 文件还有一个repodata/目录里面放着 primary、filelists、other 这几类 XML 索引描述了每个包的名字、版本、架构、依赖关系、包含哪些文件。第三块是依赖求解器它读取元数据在你的安装请求和系统现状之间做一次求解得出一个可执行的包集合和操作顺序。这个分层的意义在哪在于元数据可以独立更新。仓库管理员新传了一个包只需要重新跑一次createrepo元数据变了但所有 .rpm 文件不用动。客户端这边只要让本地缓存过期下次 install 就能看到新包。你也会因此遇到一个典型现象明明文件已经传上去了客户端却死活No package xxx available十有八九是元数据没重建或者客户端还在用旧缓存。把这三个角色的边界记住后面九成的报错你都能自己定位。1.3 什么时候你该用 yum什么时候不该用yum 不是万能的这点要先说清楚。系统自带的软件、发行版仓库里有的软件nginx、redis、mysql、python3 这类能用 yum 就用 yum因为升级、卸载、依赖追溯都省心。但以下场景我建议绕开第一种是要跑非常新版本的软件发行版仓库里的版本常年落后好几年这时候要么找官方提供的独立源要么就用容器跑别硬去混装第三方源混源是生产事故的高发区。第二种是自己编译的程序源码装的东西 yum 管不到卸载也不干净这类建议统一放到/usr/local下并留好安装记录。还有个常见误区要提前破除有人说我用 yum 装了 python结果把系统 python 升级了然后 yum 自己都跑不起来了。这就是典型的混源 升级系统基础包。系统 python、openssl、glibc 这类基础组件除非你清楚后果否则不要用第三方源去升级。真要新版本用虚拟环境、用 conda、用容器都比动系统 python 安全。记住一个原则系统包优先用系统源业务软件用隔离方式跑这条守住了你的机器寿命会长很多。2. 仓库配置与 yum 的工作机制知道 yum 在干什么之后接着要搞明白它从哪读配置。yum 的行为由两处配置决定全局的/etc/yum.conf以及/etc/yum.repos.d/目录下的一堆.repo文件。前者管通用行为缓存放哪、日志写哪、超时多少后者管去哪个源找包。这两个地方任何一处写错都会让你在报错里绕圈。我见过最离谱的一次是某台机器的 repo 文件里 baseurl 写了个内网域名而 DNS 换了结果批量部署全卡住排查了两个小时才发现是解析问题。2.1 .repo 文件里每个字段到底在管什么一个标准的 repo 文件长这样我拿一个内网源举例[company-base] nameCompany Base Repo baseurlhttp://repo.internal/centos/$releasever/os/$basearch/ enabled1 gpgcheck1 gpgkeyhttp://repo.internal/keys/RPM-GPG-KEY-company priority1 metadata_expire90m timeout30 retries5 excludekernel* docker*[]里的方括号名是这个源的唯一标识--enablerepo--disablerepo参数用的就是它所以起名字要短、要有辨识度。name只是给人看的描述。baseurl是核心指向 repodata 的父目录注意必须是能直接列出目录的地址不能少一层路径。这里用到了两个变量$releasever会被替换成系统主版本号比如 7 或 8$basearch替换成基础架构x86_64、aarch64。这两个变量非常有用同一份 repo 文件能适配多种系统版本。gpgcheck1表示下载的包要做签名校验gpgkey指定公钥位置。生产环境我强烈建议保持开启关掉它等于谁往源里塞个包你都会照装不误。priority是优先级数值越小越优先这在你同时挂了多个源、同一个包出现多份的时候决定用哪个——注意这个字段在部分老版本上需要装yum-plugin-priorities插件才生效。exclude用于排除某些包比如你不想让自动更新把内核升掉就写excludekernel*这是很实用的一招。2.2 yum.conf 里值得手改的几个参数/etc/yum.conf默认内容不多但有三个参数我几乎每台机器都会调。第一个是keepcache默认是 0意思是装完包就把下载的 rpm 删掉省磁盘如果你在带宽紧张的环境里或者经常重装同样的包把它改成 1下过的包留在缓存里下次直接复用。第二个是installonly_limit默认 5控制同时保留几个只能多版本共存的包典型的就是 kernel保留几个内核意味着你出问题还能回退到旧内核启动别设成 1。第三个是超时和重试相关的timeout和retries。默认timeout不长遇到慢的内网源或者跨机房访问很容易一个元数据下载就超时失败。我一般把 timeout 设到 30 到 60 秒retries 设到 5 到 10 次。另外debuglevel调到 2 到 4 能让出错时日志更详细排查完再调回来即可。这里插一句改完/etc/yum.conf不用重启任何服务下一条 yum 命令就生效但已经被缓存的元数据不会自动刷新必要时yum clean expire-cache一下。2.3 元数据缓存为什么第一次慢后面快这句第一次慢后面快背后就是缓存机制。yum 下载的元数据存在/var/cache/yum/$basearch/$releasever/仓库名/下面包含repomd.xml和几个 xml.gz。判断缓存是否还有效看的是metadata_expire默认通常 90 分钟也有配置成 6 小时的加上仓库返回的 repomd 时间戳。没到期就不重新下载直接拿本地算所以速度飞快。这也解释了几个常见现象。你刚清空重装系统第一次yum install要等十几秒甚至几十秒是在下载元数据隔一会儿再装就秒出结果。如果你刚往源里传了包客户端这边死活搜不到要么等过期要么用yum clean expire-cache强制标记过期再查。缓存目录体积有时候会很大特别是元数据多的源磁盘紧张时可以用yum clean metadata清索引、yum clean packages清已下载的 rpm、yum clean all一把清空。清理是安全的下次用会自动重下只是第一次会慢。3. 高频命令逐条拆解附真实场景这一节是实战重点。我不会把所有参数都罗列一遍那种清单你搜linux 常用命令 60 条能搜到一百份但没告诉你什么时候用哪个。我按真实工作场景来组织先查、再装、再更新、出问题回滚。3.1 查询类先看清楚再动手动手之前先查这是运维的铁律。我见过太多人直接yum install xxx然后发现装的是个同名但完全不是他想要的东西。查询类的命令里yum list是最常用的可以带三个关键后缀yum list installed看已装的、yum list available看源里可装但没装的、yum list updates看有更新的。直接yum list nginx会显示这个包在各个源里的版本注意看输出里带前缀的是已安装的带源名的是可用的。# 看某个包的情况 yum list nginx # 只看已安装的配合 grep 快速定位 yum list installed | grep -i python # 看有更新但没装的包 yum check-updateyum search适合你不确定包名的时候。生产上经常遇到这个你要装某个命令行工具但不知道包名叫什么比如sz这个命令直接 install 肯定失败。yum search rzsz或者yum provides */sz就能反查出包名是lrzsz。我个人更推荐yum provides它能按文件路径、按命令、按库名反查精度比 search 高。比如某个程序报error while loading shared libraries: libssl.so.1.1你用yum provides */libssl.so.1.1就能知道该装哪个包。# 反查某个命令或文件属于哪个包 yum provides */ifconfig yum provides */libssl.so.1.1 # 看一个包的详细信息包括大小、来源、依赖 yum info nginx # 看这个包依赖了谁 yum deplist nginxyum info看详情重点看 Version 和 Size装之前对一下版本对不对得上你的预期能避免很多装完发现版本太老的返工。这里给个小技巧yum list输出太长的时候配合-q或者直接管道 grep比翻屏高效得多。3.2 安装、卸载、重装装包是最简单的操作但坑也不少。基础用法yum install nginx它会问你确认加-y直接确认。这里要说清楚-y的风险如果你命令拼错了比如想装nginx打成了nginx-full或者某个名字相近但用途完全不同的包-y会毫不犹豫地装下去。所以在不确定包名的场景我建议先不带-y跑一次看清楚它要装什么再确认。# 常规安装 yum install nginx -y # 重装修复文件被误删或损坏的情况 yum reinstall nginx -y # 装本地下载好的 rpm不依赖源但仍会解析依赖 yum localinstall ./some-package.rpm -yreinstall这个命令特别值得记住。有时候某个包的文件被意外覆盖或者删了包管理记录还在remove再install会把配置文件也带走虽然一般是 .rpmsave而reinstall更干净适合修配置类文件被改坏的情况。卸载用yum remove但要注意它会连带卸载依赖这个包的东西——比如系统里某些组件依赖 python你 remove python-y一确认一串东西全没了。所以卸载前务必看一遍它列的将被删除的清单尤其注意那些你没主动装、但被连带删除的包。提示yum remove的连带删除很容易误伤建议卸载前用yum autoremove --setoptclean_requirements_on_remove0先做一次模拟或者直接加--assumeno只看不删。3.3 更新与降级更新分两个层次yum update nginx只更新指定包yum update不指定包名则会更新全部可更新的包包括内核。这两个完全不是一回事别搞混。生产环境我基本不用裸yum update因为一次可能升级几百个包风险不可控。比较稳的做法是先yum check-update看清单评估影响再选中必要的包逐个更新。# 只更新指定包 yum update nginx -y # 先看有哪些包能更新 yum check-update # 只更新安全相关的补丁需要插件支持 yum update --security -y # 降级到指定版本 yum downgrade nginx-1.20.1-1.el7 -y降级这个操作现实中用得比想象中多。某次自动更新把 nginx 升到了新版本结果和新配置不兼容服务起不来最快的恢复方式就是降级到之前能用的版本。前提是旧版本还在源里。如果源里已经把旧版本删了就得靠yum history回滚或者去归档仓库找。这也是我坚持在源里保留最近几个版本的原因——磁盘不值钱出事时能救命。yum history是很多人忽略的宝藏功能。yum 会把每一次事务记到数据库里你能查历史、看详情、甚至回滚# 看最近的事务列表 yum history list # 看某次事务具体干了什么 yum history info 15 # 撤销第 15 次事务会生成一次新的事务来反向操作 yum history undo 15 # 回到某个时间点的状态 yum history rollback 15history undo和rollback的区别要分清undo 是撤销指定的那一次rollback 是把之后的所有操作都回滚到那个状态。区别在于依赖包的处理undo 更精细rollback 更激进。我一般优先用 undo。3.4 组、模块与历史记录软件组group是一次装一批相关包的功能。比如你想装一个开发环境yum groupinstall Development Tools会把 gcc、make、autoconf 这一堆一次性装好比逐个装省事。查有哪些组用yum grouplist但注意组名在不同版本里可能带引号也可能不带报错说找不到组的时候试试加引号。CentOS 8 之后还可以用yum group install写法略有差异实际用的时候两个都试试。# 列出所有组 yum grouplist # 装开发工具组 yum groupinstall Development Tools -y # 查一个组里包含哪些包 yum group info Development Tools模块module是 RHEL 8 之后引入的概念用于在同一个系统里提供同一个软件的多个版本流。典型场景是你要用某个特定版本的 nodejs 或 php模块流能让你切换。用法是yum module list nodejs看有哪些流yum module enable nodejs:14启用再yum install nodejs装的就是 14 系列。这块在 CentOS 8 及以上才用得到CentOS 7 没有。很多人搞不明白为什么同一个包有nodejs:12和nodejs:14就是因为模块流。3.5 参数真正影响结果的那几个除了常见的-y、-q、-v有几个参数是真能改变命令行为的值得单独拎出来说。--enablerepo和--disablerepo控制本次命令启用或禁用哪些源。这个非常有用比如你临时想从某个平时禁用的源装一个包yum --enablerepoextras install xxx就行不用去改 repo 文件再改回来。反过来怀疑某个源干扰了结果--disablerepo*能临时全禁掉。--downloadonly --downloaddir/data/offline是离线安装的利器只下载不安装把 rpm 都放到指定目录。断网机器上的部署全靠这个。老版本可能需要装yum-plugin-downloadonly新版一般内置。--setopt用来临时覆盖配置项最常用的就是--setopttimeout60这种。临时调大超时、临时修改 gpg 检查比改配置文件灵活。# 临时启用某源 yum --enablerepoepel install htop -y # 只下载不安装 yum install nginx --downloadonly --downloaddir/data/offline # 临时覆盖超时 yum --setopttimeout60 makecache # 排除某些包 yum update -y --excludekernel* --excludedocker*--exclude在批量更新时几乎必备把内核和那几个升级必炸的包排除掉剩下随便升。--nogpgcheck能不检查签名但只建议在完全可控的内网源上用公网场景别开。另外还有个可能被忽略的点--assumeyes是-y的长写法脚本里用长写法可读性更好。4. 实操从零搭一个可用的内网仓库公网源不稳定、机房限流、几十台机器同时下载把带宽打满——这些都是逼着你搭内网源的理由。搭内网源其实不难难的是选对方案和把细节收干净。我给三种常见方案各说一遍你按自己环境挑。4.1 方案选型ISO 挂载 vs 本地镜像 vs 自建 RPM 目录第一种ISO 挂载最省事。你手里有发行版安装镜像挂载到本地就直接能当源用适合给少量机器装基础包、修系统。缺点是镜像里的包是发布时的快照后续的更新补丁没有。第二种完整镜像同步用 rsync 或者专门的同步工具把上游源整份同步到内网再对内提供服务。优点是包全、能更新缺点是占空间一个完整源几十 GB同步要花时间对带宽也有要求。第三种自建 RPM 目录你和团队自己编译或者下载了一批业务专用包放到一个目录里用 createrepo 生成索引客户端配上去就行。适合发内部工具、发定制包体积小、可控性强。实战里这三种往往混用基础包走 ISO 或者镜像源业务包走自建目录优先级排好互不打架。4.2 用 createrepo 生成元数据自建目录的关键工具是createrepo新系统上是createrepo_c两者命令兼容。先把 rpm 都收集到一个目录然后生成索引# 装工具 yum install -y createrepo # 建目录放包 mkdir -p /data/repo/mypkgs cp /root/rpms/*.rpm /data/repo/mypkgs/ # 生成元数据第一次用完整模式 createrepo -v /data/repo/mypkgs # 之后新增了 rpm用增量更新 createrepo --update /data/repo/mypkgs这里有个必须记住的点只要目录里的 rpm 变了增、删、覆盖就必须重新生成元数据。删包之后要用--update让索引感知到删除否则客户端可能还能看到已经删掉的包。删包前先yum clean客户端缓存删完再 update不然容易出现客户端认为包存在、实际下载 404 的诡异状况。还有个细节如果同一个包有多个版本createrepo 会把它们都收录客户端默认装最新的。这也是保留多版本的实现方式。如果你想让某个版本优先靠 repo 的 priority 或者直接清理掉不需要的版本。4.3 客户端 repo 配置与验证服务端准备好之后用 nginx 或 httpd 把目录暴露出去即可server { listen 80; server_name repo.internal; root /data/repo; autoindex on; location / { try_files $uri $uri/ 404; } }注意autoindex on只是方便你用浏览器看目录真正需要的是 nginx 能正确返回repodata/下的文件并且不要给 xml.gz 加奇怪的压缩或者改写 Content-Type。我踩过一次坑中间的代理给Content-Encoding: gzip加了一层结果 yum 下载 repomd.xml 解压失败报错信息含糊得让人抓狂。所以在前面挂代理的环境里务必确认 xml.gz 是原样透传的。客户端这边写 repo 文件然后验证# 写 repo cat /etc/yum.repos.d/company-base.repo EOF [company-base] nameCompany Base baseurlhttp://repo.internal/mypkgs/ enabled1 gpgcheck0 priority1 EOF # 刷新缓存并验证 yum clean all yum makecache yum repolist allyum repolist all会列出所有源以及它们的状态能直接看出源是否有元数据、是否启用。这一步是排错第一步源有问题这里会显示 0 packages 或者报错。4.4 离线批量下载yumdownloader 的正确用法最后说离线场景。给断网机器装包标准流程是在有网的机器上把包和依赖一起下下来拷过去装。工具是yumdownloader在 yum-utils 里。yum install -y yum-utils # 下载包连同所有依赖到指定目录 yumdownloader --resolve --destdir/data/offline nginx # 或者在系统上直接只下载不装 yum install --downloadonly --downloaddir/data/offline nginx--resolve是关键不加它只会下载你指定的那个包依赖一个都不带拷到离线机器上照样装不上。加了解析依赖它会把整条依赖链的包全拉下来。把/data/offline整个拷到离线机器上然后yum localinstall /data/offline/*.rpm或者先 createrepo 再配成本地源安装。这里注意两台机器的基础环境要尽量一致系统小版本不同、已装的依赖不同下载下来的包集合可能不匹配这是离线安装最常见的失败原因。5. 常见报错排查速查表yum 的报错信息有的写得很清楚有的含糊到让人想砸键盘。我把这些年遇到的按类型分一分给你一套排查思路。5.1 网络与源相关Could not resolve host是 DNS 问题先去ping repo 域名验证解析cat /etc/resolv.conf看 DNS 配置nslookup确认能不能查出来。内网源换了域名、DNS 换了服务器都很容易触发。如果域名能解析但连不上用curl -v http://repo地址/repodata/repomd.xml直接测能一眼看出是 404、超时还是证书问题。Cannot retrieve repository metadata (repomd.xml)通常是 baseurl 路径写错、源没启动、或者权限不对。用浏览器或者 curl 访问 baseurl看能不能列出 repodata 目录。如果路径是 HTTPS 的还要注意证书是否受信任、系统时间是否准确——时间偏差太大证书校验必然失败这个坑很隐蔽date一看就露馅。5.2 依赖与冲突No package xxx available先别怀疑人生按顺序排查源是否启用yum repolist、包名是否正确yum search、是否需要额外的源比如很多第三方软件在扩展仓库里需要先装扩展仓库的 release 包把源配好。还有一种情况是你搜的包确实存在但版本不匹配当前系统架构输出里会显示架构不对。Error: Package: A requires: B是缺依赖。如果 B 在现有源里找不到说明你的源不全需要补源。Transaction check error: file ... conflicts between attempted installs是文件冲突通常是两个包都提供了同一个文件多见于混源场景。解决思路是排查这两个包是不是来自不同源用 priority 决定用哪个或者干脆卸掉其中一个再装。5.3 GPG 与证书Public key for xxx.rpm is not installed是签名校验失败。稳妥的办法是把对应的 GPG 公钥导入系统再用gpgcheck1装而不是简单粗暴地关掉校验。导入公钥用rpm --import /path/to/KEY或者rpm --import http://repo地址/keys/KEY。如果你确认内网源完全可控图省事关掉 gpgcheck 也行但要在团队内部说明白别让所有人都以为这是标准做法。5.4 数据库与锁Another app is currently holding the yum lock是并发冲突两个 yum 进程在打架另一个可能还没跑完。看一下/var/run/yum.pid里的进程号ps确认它是不是真的在跑是就等不是就删掉这个 pid 文件。千万别在没确认的情况下直接删 pid如果进程真在跑删了会出乱子。rpm 数据库损坏报的表象很多比如rpmdb: BDB0113 Thread/process ... failed、Error: rpmdb open failed。处理方式是rpm --rebuilddb重建数据库。这个操作有一定风险执行前最好备份/var/lib/rpm/目录重建过程中如果断电可能丢数据别在关键业务机上裸操作。5.5 一张速查表报错关键字大概率原因处理方向Could not resolve hostDNS 解析失败检查 resolv.conf 和内网域名repomd.xml 下载失败baseurl 错 / 源没启动 / 证书curl 直接访问验证No package available源未启用 / 包名错 / 缺源repolist search 补源Failed dependencies依赖包缺失补源或下载依赖包conflicts between installs文件冲突 / 混源排查源优先级卸一个再装Public key not installedGPG 校验失败导入公钥或调整 gpgcheckholding the yum lock并发进程确认进程后再清 pidrpmdb open failedrpm 数据库损坏备份后 rebuilddbNothing to do包已装 / 条件不满足换包名或加参数重试磁盘不足缓存或元数据占满clean 清理或扩容这张表建议存下来遇到报错先对号入座。但要强调一点报错信息里往往有更具体的行号和原因先读完整报错再查表别看到关键字就跳结论。6. 长期使用习惯与性能调优零散的排查技巧有了最后说说怎么把 yum 用得更稳更省心。这部分是经验层面的东西手册里不会写。6.1 cache 与日志缓存目录/var/cache/yum/会随使用慢慢变大特别是元数据多的源和开了 keepcache 的机器。我一般定期yum clean metadata清索引、保留已下载的包或者干脆用yum clean all清空重来。清理前确认没在跑安装任务否则会把正在用的缓存删掉导致失败。日志在/var/log/yum.log记录了每次安装、卸载、更新的包名和时间。这文件在排昨天到底谁动了这台机器类问题的时候非常好用。它默认会一直追加长期运行后可能变大可以配合日志轮转工具管理。6.2 少踩坑的几条规则第一生产环境别裸跑yum update。要更新就明确列出包名先 check-update 再动手必要时先在测试机验证。第二内核和 docker、glibc、openssl 这类基础组件单独决策别混在批量更新里用 exclude 把它们挡在外面。第三装包前先yum list installed看看是不是已经装了尤其是接手别人的机器重复装、版本冲突是常见坑。第四脚本里所有 yum 命令都写清楚参数别依赖默认行为。-y该加就加但要配合包名准确--exclude该挡就挡关键操作加--setopttimeout防网络抖动。第五给机器留一个能回退的路。内核保留多个版本、源里保留近几个版本的包、重要变更前yum history记一下当前状态这几件事做了出事时能省下大把时间。6.3 yum 与 dnf 的取舍如果你用的是 CentOS 8、RHEL 8 及以上的系统实际执行的是dnfyum只是个指向 dnf 的软链接命令大部分兼容但底层实现不同。dnf 的依赖求解更快、内存占用更优报错信息也更清晰模块功能是它原生的。日常用两者差别不大但要注意几个细节dnf 的历史数据库不是同一个文件所以从 yum 迁移到 dnf 时历史记录不会接续个别老参数在 dnf 里被废弃了某些第三方源对 dnf 的支持不如 yum 成熟遇到怪问题时可以试试显式用 dnf 或者反过来。RHEL 7 及更早的系统上就是纯 yumPython 2 写的不会遇到这个问题。如果你的机器上yum --version显示的是 dnf 的版本号那说明你已经在用新栈了模块、历史这些新特性可以放心用。搞清楚自己在哪一套栈上排错时能少走很多弯路。我个人的做法是把内网源、priority、exclude 这套配置固化到基础镜像里新机器起来就是统一的状态然后写几个常用查询的 alias比如yl对应yum list --showduplicates日常效率提升明显。yum 这东西看着简单真正把它用出稳定性和可维护性靠的就是这些配置化和习惯性的细节而不是记住了多少条命令。
