如果在Linux环境里混过一段时间大概率听过这么一句抱怨装个软件怎么这么费劲。Windows双击exe手机打开应用商店点安装到了Linux命令行光一个依赖关系就能把人折腾到怀疑人生。其实Linux自己也有“应用商店”只是它不叫商店而是叫yum。yum这套机制早年是Red Hat系发行版CentOS、RHEL、Fedora的标配后来Rocky Linux、AlmaLinux继续沿用再后来国产的银河麒麟、统信UOS这些系统也大量基于它做软件分发。可以说搞懂yum基本上就搞懂了Linux软件安装的半壁江山。这篇文章我想从“为什么需要yum”讲起拆解它的核心机制然后带着你实际配置一次本地yum源和网络yum源最后再把这些年踩过的坑和排查思路一次性聊透。无论你是在自己电脑上折腾CentOS 7还是在公司内网维护一批Red Hat 6.5机器或者刚接触麒麟系统准备离线部署软件这篇内容都应该能给你省下不少时间。1. 为什么Linux需要自己的“应用商店”1.1 没有yum之前装软件到底有多痛很多人第一次接触Linux最不适应的一点就是没有一个统一的“安装入口”。Windows装软件基本就是下载exe双击顶多改个安装路径macOS更简单拖进Applications就算完事。但Linux不一样它一开始的设计哲学是源代码开放软件分发也是“你拿去自己编译”的路线。早期的Linux用户装个软件是这样的先到官网下载源代码压缩包通常是tar.gz解压之后用configure生成Makefile然后make编译再make install安装。这个过程听起来很“极客”实际上非常痛苦。编译一个简单的工具可能要几十秒编译一个复杂的软件比如MySQL、Nginx动辄十几分钟期间还要应付各种编译报错。更麻烦的是很多编译依赖不是系统自带的你得先去装依赖库的源码包而这些依赖库可能又有自己的依赖——一装就是一大串中间任何一个版本对不上整个编译就挂掉。这还只是单机的痛苦。等到你要批量管理服务器的时候问题会更明显几十台机器每台都要手动去编译软件每台都要手工处理依赖生产效率基本为零。所以后来的Red Hat系发行版搞出了RPM包Red Hat Package Manager。RPM把软件的编译结果、配置文件、安装脚本打包好用户拿到.rpm文件跑一条rpm -ivh xxx.rpm就能安装。这比源码编译快多了但RPM模式有个经典问题——依赖关系需要你自己搞。你装一个包系统提示“需要依赖libfoo.so.2”你得自己去光盘或者网上找这个依赖的RPM包装完之后可能又发现它还需要别的依赖一层一层往下这就是传说中的“依赖地狱”。yum的诞生就是为了解决这个“依赖地狱”。1.2 yum到底解决了什么问题yum的全称是Yellowdog Updater Modified最早源于Yellow Dog Linux这个发行版后来被Red Hat采用并持续改进逐渐成为Red Hat系发行版的默认包管理器。它的核心思路一句话概括把软件包和依赖信息统一放在一个“仓库”Repository里安装时自动解析依赖关系联网把需要的包全部拉下来一次性搞定安装。这个思路本质上就是一个应用商店的模型。你打开yum安装一个软件它会自动告诉你需要装哪些依赖、总共要下多少东西、磁盘会占多少空间确认后一次性完成。就像你在手机应用商店装一个App系统会自动帮你把App所需的权限、资源都配好不需要你关心背后的实现。yum的出现让Linux软件安装从“手动编译手工收集依赖”变成了“一条命令完成”这也让Red Hat系的服务器运维效率有了质的提升。后来CentOS、RHEL长期霸占服务器市场yum这套机制功不可没。再后来很多基于Red Hat系的国产Linux发行版比如银河麒麟、统信UOS等也继承了yum体系所以掌握yum的用法在今天依然非常值钱。2. yum的核心机制与设计思路2.1 repo源yum的“货架”yum能自动安装软件前提是它知道从哪里下载软件包。这个“哪里”就是软件仓库在yum的世界里叫reporepository。一个repo可以是一个远程的HTTP/FTP地址也可以是一个本地目录里面存放着一批RPM包和一个描述这些包信息的元数据文件。在Linux系统里repo源的配置通常放在/etc/yum.repos.d/目录下文件名以.repo结尾。每个.repo文件里可以定义多个repo源一个典型的repo配置长这样[base] nameCentOS-$releasever - Base mirrorlisthttp://mirrorlist.centos.org/?release$releaseverarch$basearchrepoosinfra$infra enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7各个字段的含义很简单[base]仓库的ID必须唯一后续在命令行里可以单独指定。name仓库的描述信息给人看的。mirrorlist或baseurl仓库的地址。mirrorlist指向一个动态返回镜像列表的URLbaseurl则直接指定一个固定的仓库地址。enabled是否启用这个源1启用0禁用。gpgcheck是否校验软件包签名建议保留为1安全第一。gpgkey校验签名用的公钥文件路径。每次执行yum安装或更新时系统会读取这个目录下所有启用的repo配置然后通过HTTP、FTP或本地文件路径把仓库里的元数据主要是各个软件包的名称、版本、依赖信息、下载地址拉下来构建成本地缓存。后续的安装操作其实就是“在缓存里查依赖关系然后按地址去下载软件包”。网上经常看到“配置yum源”的说法本质就是修改这些.repo文件把仓库地址指向一个可用的镜像站或者指向本地的RPM包目录。2.2 依赖解析聪明的自动处理yum最核心的能力是依赖解析。它基于RPM包里的“元信息”工作。每个RPM包在构建时都会写入它的名称、版本、依赖什么库、提供什么库这些信息。yum把这些信息汇总成数据库安装时就能精准判断某个软件需要哪些依赖以及这些依赖是否已被满足。我举个实际例子。曾经在CentOS 7上装过Nginxyum install nginx屏幕上先是出现一堆输出显示“正在排查依赖关系”然后列出需要安装的包序列除了nginx主包之外还会自动带上openssl、pcre、zlib这些动态库依赖。整个过程自动完成不需要我手工去搜任何一个rpm包。装完之后nginx直接就能启动。这个能力在日常使用中太关键了。比如你要装一个图形库、一个Python模块、一个加密工具它们依赖的底层库往往有一堆如果手动处理每个库都要去查版本号、找下载地址、确认兼容性耗时不说还容易出错。yum把这一切透明化。有个小概念要区分yum只是处理“rpm包的依赖关系”而Python的pip、Node.js的npm处理的是它们各自语言生态的包。两者层次不同但在Linux里经常会配合使用。比如你想用Python做开发系统级依赖用yum装比如python3-devel这个包提供编译Python扩展需要的头文件项目级依赖再用pip装。这个套路在开发环境里很常见。2.3 缓存与事务yum的两个隐藏设计yum另外两个容易被忽视的机制是缓存和事务回滚。先讲缓存。yum会把下载的软件包和元数据缓存在/var/cache/yum/目录下。默认情况下元数据有一定时效性过了时间会重新拉取但已经下载好的rpm包如果在有效期内安装时不会重新下。刚装完系统那会儿网络不好手动从Windows下载离线rpm包放进本地源用yum会自动校验源里文件的完整性这个缓存机制能帮忙确认哪些包已经拉全。再讲事务。yum在执行安装时会记录操作历史执行yum history可以查看历次安装、卸载、更新的清单。更妙的是它支持yum history undo ID回滚到之前的状态把当时安装或卸载的包全部逆向操作一遍。这个机制在做实验、在新机器上折腾配置时非常有用相当于给包管理装了一个“后悔药”。2.4 为什么还要有本地yum源很多人第一次听到“本地yum源”这个说法会觉得疑惑yum不是用来联网装软件的吗弄一个本地源有什么意义实际场景里本地源的价值体现在三个方面。第一内网离线环境。很多公司的生产网和公网是隔离的服务器无法访问外部的yum镜像站但软件该装还得装。把官方仓库的RPM包批量下载下来放到一台内网服务器上用Nginx或HTTP服务共享或者直接放进本地目录做成file协议的源内网机器就都能安装软件了。第二安装系统后快速起步。新装一台机器系统默认的源可能因为网络原因很慢或者镜像站地址已经失效比如CentOS 8停止维护后老的mirrorlist就经常报错这时候先把软件包放到本地源或者改成可用的镜像源能极大提升后续效率。第三保证软件版本一致性。某些生产环境的软件版本需要严格管控不希望装到一半yum自动把依赖升级到新版本。把特定版本的RPM包放进本地源限制安装来源可以有效控制环境变更。我自己最常干的一类事是“批量下载yum包”。比如在办公网的机器上需要把一批rpm打包拷到离线环境去安装。这时候用yum install --downloadonly --downloaddir/tmp/rpms 包名就能一次性把主包和依赖全部拉下来然后整个目录带走。这个技巧在应急处理时非常救命。3. 实操从零配置一个可用yum源3.1 搭建本地yum源5步搞定本地yum源搭建本质上就两件事准备RPM包目录、生成元数据。下面我用CentOS 7环境演示实际上在RHEL 6.5、Rocky Linux 9、银河V10等系统上流程大同小异。第一步创建目录并把RPM包放进去。如果手头有系统安装光盘或者ISO镜像直接挂载之后把光盘里的Packages目录复制过来是最省事的。假设挂载点是/mnt/cdrommkdir -p /repo/local cp -av /mnt/cdrom/Packages/*.rpm /repo/local/第二步安装createrepo工具。如果系统本身就装有这个工具直接用没有的话要么从系统光盘里找到createrepo相关的rpm先装上要么在能联网的机器上用yum装好再打包过去。生成元数据的命令如下yum install createrepo -y createrepo /repo/local这一步执行完/repo/local目录下会生成一个repodata子目录里面就是yum搜索依赖所需的元数据文件。第三步编写repo配置文件。在/etc/yum.repos.d/下新建一个local.repo[local] nameLocal Repository baseurlfile:///repo/local enabled1 gpgcheck0注意baseurl那里写的是file://协议后边跟的是绝对路径。cifs/sftp等网络文件系统也支持但最简单的是本地目录。如果是在局域网内共享把目录挂载到NFS或SMB之后路径写成对应的挂载点即可。第四步清理并重建缓存yum clean all yum makecache第五步验证。用yum list available | head看看能不能列出软件包或者直接尝试安装一个包yum install -y vim-enhanced如果安装成功说明本地源已经生效。这里有一个细节值得多说一句gpgcheck0在生产环境里我不建议长期开着因为无法校验包签名存在安全风险。如果内网可以确认RPM包来源可靠临时用用可以长期使用还是建议把签名校验打开。3.2 配置网络yum源以CentOS 7和Rocky 9为例网络yum源是最常用的软件来源配置思路本质和本地源一样只是baseurl从本地路径换成了HTTP地址。先说CentOS 7场景。这几年CentOS 7还在大量服役但老的mirrorlist地址经常失效我强烈建议直接指定一个可用的镜像站地址而不是依赖mirrorlist。比如常见的阿里云镜像mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache只要服务器能访问外网这套配置十分钟之内就能完成。关键是换源以后执行一次yum makecache确认元数据能正常拉取否则后续安装一样会报错。Rocky Linux 9的配置方式略有不同。Rocky官方自带了一套默认源速度如果不好同样可以手动改成阿里云镜像地址sed -e s|^mirrorlist|#mirrorlist|g \ -e s|^#baseurlhttp://dl.rockylinux.org/$contentdir|baseurlhttps://mirrors.aliyun.com/rockylinux|g \ -i.bak \ /etc/yum.repos.d/rocky*.repo yum clean all yum makecache关于源地址的选择我的个人经验是优先选离自己网络环境最近的镜像。云服务器在华东就选华东的镜像公司网通就选net地区的源目测速度会大有不同。但镜像站之间偶尔也有同步延迟刚发布的小版本软件包可能在某一个镜像上还没到位遇到版本更新异常时换个镜像源试试往往有效。配置国产系统比如银河麒麟V10的网络源原理也一样。麒麟的仓库地址和CentOS不一样但repo文件格式是通用的。你只需要把baseurl里的地址换成麒麟官方提供的仓库地址再执行缓存重建即可。3.3 常用yum命令实战清单纸上谈兵没意思直接把日常最常用的yum命令列出来每一条都是我在实际工作中反复用到的。# 安装软件-y表示自动确认 yum install -y 包名 # 卸载软件 yum remove -y 包名 # 搜索软件包 yum search 关键词 # 查看某个软件包信息 yum info 包名 # 列出所有可用软件包 yum list available # 查看已安装软件包 yum list installed # 列出所有可更新软件包 yum list updates # 更新全部软件包 yum update # 仅更新指定软件包 yum update 包名 # 只下载不安装并保存到指定目录 yum install --downloadonly --downloaddir/tmp/rpms 包名 # 查看yum操作历史 yum history # 回滚某一次操作 yum history undo ID # 清理全部缓存 yum clean all # 检查是否有可用的组包 yum grouplist # 安装一个软件组 yum groupinstall Development Tools这里简单说一下yum groupinstall Development Tools这个命令。它安装的是一整组编译工具集合包括gcc、gcc-c、make、autoconf、libtool等等。很多从别的地方Copy源码包回来想在本机编译C/C程序的用户第一步就该装这个组包。它相当于把一套完整的编译环境一次性配齐省得逐个安装。另外从CentOS 8开始系统默认包管理器已经切换到了DNF但DNF的命令语法和yum几乎完全一致很多发行版还专门做一个yum软链接指向dnf。所以学会了yum命令切到DNF环境也不会抓瞎。3.4 批量下载与离线分发技巧这一节我想单独展开讲讲因为“批量下载yum包”在中文搜索里出现频率实在太高说明很多人确实遇到了离线安装的痛点。场景一般是这样的内网服务器没有外网访问权限但开发机可以联网。你想在开发机上用yum把目标软件及其全部依赖下载下来拷到内网机器上安装。假设要下载nginxmkdir -p /tmp/nginx-rpms yum install --downloadonly --downloaddir/tmp/nginx-rpms nginx执行完成后/tmp/nginx-rpms目录下除了nginx本身所有依赖的rpm也会一并拉下来。把这个目录拷贝到内网机器上用下面的命令直接安装cd /tmp/nginx-rpms rpm -Uvh *.rpm或者更规范一点把这个目录做成一个临时本地源再用yum安装可以避免rpm命令直接安装时可能出现的依赖顺序报错createrepo /tmp/nginx-rpms vi /etc/yum.repos.d/temp.repo # 写入 [temp] 相关配置baseurlfile:///tmp/nginx-rpms yum install -y nginx注意一个细节使用rpm -Uvh *.rpm时文件名顺序会影响安装顺序虽然rpm会尽量自动处理但难免遇到报错使用yum本地源则完全不用操心顺序yum会根据自己的依赖解析结果决定安装次序。所以能走yum源就尽量走yum源。还有一点--downloadonly这个参数依赖yum-downloadonly插件CentOS 6时代需要额外安装这个插件CentOS 7以后已经集成在主包里直接用就行。如果你用的是dnf则直接支持dnf download命令。4. 常见问题与排查技巧实录4.1 元数据下载失败让人崩溃的“Loading mirror speeds”这是新手遇到最多的问题报错形如Could not retrieve mirrorlist http://mirrorlist.centos.org/?release7archx86_64repoosinfrastock error was 14: curl#6 - Could not resolve host: mirrorlist.centos.org或者errors during downloading metadata for repository base第一行“Could not resolve host”说明DNS解析失败网络不通或者DNS没配好。处理思路是先确认网络ping -c 3 114.114.114.114IP能通而域名不通说明DNS问题查看/etc/resolv.conf文件加一行nameserver 114.114.114.114试试。第二行“errors during downloading metadata”多半是repo源地址失效或者镜像同步有问题。处理思路是检查repo文件里的baseurl是否还能访问通过curl -I测试仓库地址的响应换一个确认可用的镜像源执行yum clean all后重新yum makecache。CentOS 8和CentOS Stream切换默认源是比较常见的场景因为官方源停止维护后老的mirrorlist地址基本不能用了我刚接触Rocky Linux 9时也踩过这个坑后来统一用阿里云镜像问题就解决了。4.2 依赖冲突yum提示“multilib version problems”在64位系统上偶尔会出现这样的信息Transaction check error: file /usr/lib64/libfoo.so conflicts between attempted installs of libfoo-1.2-x86_64 and libfoo-1.2-i686这种问题多发生在同时存在32位和64位rpm包时或者试图像安装一个架构不对的包。解决思路确认当前系统架构uname -m一般是x86_64不需要32位兼容库时不要轻易安装i686包如果误装了不匹配架构的包用yum remove 包名.i686清理冲突实在严重时用yum distro-sync让所有包回到发行版版本库的版本。注意yum distro-sync这个命令会强制把系统里所有包同步到发行版软件仓库里的版本如果你自己手动编译安装过一些软件比如从源码装过新版nginx很可能会被打回仓库里的老版本。用之前一定确认系统里没有需要保留的自编译软件。4.3 GPG签名报错Key已经找不到或者校验失败报错形如The GPG keys listed for the Base repository are already installed but they are not correct for this package.或者Public key for xxx.rpm is not installed这种情况下最常见的原因是源地址换过或者软件包采用了新的签名密钥。解决方式临时关闭校验把repo文件里的gpgcheck1改成gpgcheck0执行安装后再改回来或者安装缺失的密钥yum install epel-release时通常会一并安装对应的GPG key也可以在官方文档里找到key文件的下载地址手动导入rpm --import https://example.com/RPM-GPG-KEY需要说明的是关闭gpgcheck只是应急手段不是长期方案。公网源只要来源正规正常的key都能导入用不着关校验。内网自建源倒是可以默认关掉因为包都是自己人做的风险可控但也要评估安全策略。4.4 yum update 误升级的隐患如何排除特定包“yum update -y --exclude”这个热搜词我猜测是有人手滑全量更新之后发现某些内核模块挂了后来才想到要排除特定包。yum update会默认更新所有已安装包。生产环境我最不建议直接全量更新因为内核、驱动、glibc这类底层组件的升级风险很高。如果系统已经装了一些业务依赖的自定义模块全量更新后很可能会出现兼容性问题。常用的两种控制手段一是临时排除yum update -y --excludekernel* --excludeglibc*二是永久排除在/etc/yum.conf里加一行excludekernel* glibc*那一次我印象比较深有台测试机跑着某个第三方存储驱动某次全量update之后驱动模块和新内核不兼容启动直接进不了系统。从那以后生产机器的更新策略我都改成了“分批指定更新”先yum update常用软件观察两天正常后再更新内核。稳妥永远比激进重要。4.5 大杂烩几个特殊场景的排查备忘再整理几个网上经常有人问的场景快速给结论。本地源搭建好之后yum list看不到包先确认repodata目录是否生成再检查repo配置文件里的baseurl路径是否正确最后yum clean all yum makecache重新拉缓存。用yum install xdotool装X11自动化工具时报错找不到包可能是EPEL源没装。EPEL是Red Hat系最常用的第三方软件仓库装了它才能安装很多不在默认仓库里的软件包。安装方式就是yum install -y epel-release装完之后xdotool这类增强工具就能搜到了。批量从阿里云下载repo文件时提示404检查下载地址是否匹配系统版本。CentOS 7、CentOS 8、Rocky 9的repo文件URL都不相同直接混用肯定报错。解压文件乱码这跟yum没关系多数是zip文件名编码问题用unzip -O GBK或7z可以解决。但这个关键词经常和yum源配置同时出现在搜索里因为很多人在内网离线环境下载源码包时会遇到压缩包乱码导致编译失败顺手就一块儿搜了。遇到这类问题优先确认文件是否完整下载再确认解压工具版本。5. yum之外新一代包管理带来的变化很多人在搜索时会把“yum安装java”“yum安装python”这类问题一起搜。这里有必要说明一下新时代的Linux软件安装yum已经不是唯一答案了。以Java为例早年Red Hat系系统上装Java标准操作是yum install -y java-11-openjdk用yum list | grep java-可以查看具体可用的Java版本包。这种方式安装的Java在系统层面统一管理环境变量通常也已自动配好非常简单。但在开发环境里很多人后来更习惯用SDKMAN、apt或者直接下载官方安装包。yum安装的Java版本往往比较保守对某些要求新特性的项目来说偏低。同样Python也面临类似选择——系统自带的Python版本通常比较旧用yum能装的Python模块也更依赖发行版的更新节奏所以后来pyenv、conda、virtualenv这些工具逐渐流行起来。但这不意味着yum过时了。恰恰相反yum的优势在于它的“系统级包管理”能力。整个系统的基础运行库、服务器软件、编译工具链靠的都是yum这类包管理器在维护。只在操作系统层面的安装和维护上yum仍然是最正统的选择。RHEL 9、Rocky Linux 9上的dnf本质上就是yum的进化形态理念一脉相承。Galaxy Kylin V10这类国产系统也延续了rpm/yum生态。它们提供的“软件商店”图形工具底层调用的往往也是yum/dnf的逻辑。所以即使你面向的是国产化替代环境yum知识依然能直接迁移使用。我觉得对初学者来说最实际的路径是先把yum命令用熟理解repo、依赖、缓存、事务这几个核心概念再去掌握dnf、apt的差异就不会被各种包管理器的名字绕晕。6. 应用场景和运维心得回头看看yum在各个场景里的具体应用其实它的影响力远超“装个软件”这么简单。在个人开发机上yum让环境搭建变得简单。我之前在一台全新的CentOS 7虚拟机里配开发环境从装编译器到装Nginx、MySQL、Redis全程用yum完成半个小时左右就能把一套LNMP环境跑起来。这在源码编译时代是不可想象的。在服务器运维中yum配合脚本批量管理非常顺手。比如给内网几百台机器统一安装监控Agent只需要写一个小脚本遍历主机列表执行yum install -y agent配合配置好的本地yum源整个过程完全自动化不用每台机器手动操作。在紧急排障时yum的缓存和下载功能也能救急。有一次遇到系统glibc版本有问题无法正常启动大部分命令我直接用yum reinstall glibc强制重装了一遍系统就恢复正常了。类似这样的修复操作在包管理器存在之前只能通过重装系统来解决。我个人这些年攒下几条yum的使用心得分享出来生产环境不要轻易yum update -y全量更新升级内核前务必做好备份配置任何源之前先用curl验证一下地址是不是真的能通能用yum官方源的不要用第三方源优先级排列大致是发行版官方源大于知名镜像站大于个人维护的源安装比较重要的软件前可以先用yum info查看一下版本和来源仓库确认supports你的环境内网离线环境最好把常用包的目录经createrepo做成标准源长期维护一套自己的“软件商店”省得每次都要重新下载整理。还有一点yum操作会写日志日志文件在/var/log/yum.log。排查问题时回头看看日志能够知道某个包是什么时候被安装、更新或删除的。这个习惯对定位系统变更引起的问题非常有帮助。多说一句很多人问“yum和apt哪个好”这个问题就像问“锤子和扳手哪个好”没有标准答案。Red Hat系用yum/dnfDebian系用apt他们解决的问题高度相似只是实现细节上各有特色。真正要学的其实是包管理这件事本身的逻辑软件仓库怎么组织、依赖关系怎么描述、事务怎么回滚。理解这些无论到哪个发行版都不会慌。最后再分享一个小技巧给经常做离线环境的人。如果你知道自己常用的软件有哪些可以先把它们全部下载好建一个自用的“万能本地源”以后不管是新装虚拟机还是解决内网依赖直接一条yum命令解决。我自己的服务器上就有一个目录里面放了几百个常用rpm包隔一段时间同步一次。用createrepo更新元数据简单、可靠、不会过期。yum这个Linux自己的“应用商店”看起来只是命令行里不起眼的一环但它承载的软件包管理和依赖解析能力是Linux生态能在服务器市场长期站住脚的重要根基之一。希望你读完这篇能对它有更立体、更完整的理解。
