简介内网环境中为多台Linux服务器搭建本地YUM源是解决软件安装与更新困难的常用方案同时能保证各服务器软件版本的一致性。一份针对Rocky Linux 9.2的实操教程系统讲解了基于HTTP方式搭建局域网YUM源的方法内容覆盖全面服务器端需要挂载ISO镜像建立BaseOS与AppStream两个本地仓库安装并启动httpd服务还要调整防火墙和SELinux策略以允许客户端访问客户端则需要修改repo文件将仓库地址指向服务器IP并执行缓存更新命令完成切换。文档对每个环节都提供了清晰的命令行示例和配置文件代码读者可以逐步对照操作特别适合与互联网隔离的企业内网环境。整个资源为一个docx文档体积只有120KB内容精炼实用。目前已有1691人学习下载对于使用Rocky或同类RPM发行版的运维工程师来说是一份能够直接落地的参考资料。1. 先想清楚为什么 Rocky9.2 的离线机器一定要有自己的 yum 源刚接手一批 Rocky9.2 服务器的时候我第一件事不是装软件而是先 ping 一下公网。结果很现实机房出口就一条专线带宽小得可怜几十台机器同时dnf install的时候装个 gcc 能卡二十分钟。更麻烦的是安全要求生产网段不许直接访问外网yum 仓库地址全被防火墙挡死。这时候如果每台机器都手动去配 mirrorlist、去挂 ISO那运维效率就是灾难。所以局域网内自己搭一个 HTTP 协议的 yum 源是 Rocky9.2 离线环境里最常用、也最稳的方案。它解决的问题很直接把公网仓库同步到一台内网服务器上其他机器把baseurl指向这台机器走 HTTP 拉包。不引入额外的软件不碰数据库一个 web 服务器加一个同步脚本就能跑。适合的场景包括等保要求不能出网的业务区、测试环境批量交付、还有那种装个 EPEL 都要审批的公司。我用的是 Rocky9.2 自带的dnf reposync加nginx来搭全程不装第三方源管理工具。后面几章把从选型、同步、配客户端到排障的完整路径拆开讲按这个流程走一台源服务器撑三四十台客户端没什么压力。2. 用 HTTP 而不是 FTP 或 NFS协议选型与前置准备2.1 为什么 HTTP 是局域网 yum 源的最优解常见的内网 yum 源方案有 HTTP、FTP、NFS 三种。我最早用过 NFS挂载倒是简单但问题在于 NFS 依赖内核 RPC 服务客户端一旦跨网段或者经过防火墙端口协商就让人头疼而且 NFS 的权限模型在多人运维时容易把仓库目录搞乱。FTP 需要单独维护账号体系主动被动模式还经常和防火墙打架我已经很久不碰了。HTTP 的好处是干净nginx监听 80 端口客户端用dnf直接拉取走的就是普通的 TCP 80 连接防火墙规则好写权限可以交给 nginx 的autoindex和系统目录权限来控制。局域网内千兆带宽下HTTP 的传输效率足够而且 Rocky9.2 自带的dnf对 HTTP 源支持最成熟metadata的下载、缓存、校验都是一条龙。如果你的网络环境是纯内网、完全没有出网能力那源服务器本身怎么拿到软件包是另一个问题。常见做法是从同版本 Rocky 的 DVD ISO 里提取BaseOS和AppStream仓库或者在有网的环境用reposync同步完再把目录整体拷进内网。这两种方式后面都会讲到。2.2 源服务器的初始化清单系统、目录与仓库 ID 规划我习惯先把源服务器装成最小化 Rocky9.2不需要图形界面安装时勾选 Minimal Install 就行。装完先做三件事关掉 SELinux 或者在后面为 nginx 放行目录确认防火墙放行 80 端口创建仓库数据目录。# 关闭 SELinux测试环境直接 disabled生产环境建议 setenforce 0 然后单独配策略 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config setenforce 0 # 放行防火墙 80 端口 firewall-cmd --permanent --add-servicehttp firewall-cmd --reload # 创建 yum 仓库的根目录按仓库 ID 分目录管理 mkdir -p /data/yum_repo/{BaseOS,AppStream,EPEL}逻辑说明仓库根目录我统一放在/data/yum_repo下BaseOS和AppStream对应 Rocky9.2 的基础仓库EPEL是后面要同步的扩展仓库。按仓库 ID 分目录是为了让 nginx 的root指令直接指向/data/yum_repo浏览器访问时能清楚看到每个子目录。SELinux 这里提一句如果不想关闭需要给 nginx 设置httpd_sys_content_t上下文不然 nginx 会报 403这个坑在后面避坑章详细说。参数说明防火墙放行的是标准的 80 端口。如果你的 nginx 要改端口比如为了隐藏服务信息用 8080那么firewall-cmd --permanent --add-port8080/tcp更合适。3. 用 dnf reposync 同步公网仓库这是整个源的核心环节3.1 为什么选 reposync 而不是直接下载 ISO同步 yum 仓库的方法有好几种挂载 ISO、用dnf reposync、还有第三方工具createrepo配合脚本。最省事的是直接把 Rocky 的 DVD ISO 挂载到源服务器然后 nginx 指向挂载点。但这个方案有个天然缺陷ISO 只包含发布时的软件包版本你装新机器时通过dnf install拿到的永远不是最新版而且dnf update的时候源里没有新包日志里全是404。dnf reposync是 Rocky9.2 自带的同步工具它的逻辑很简单读取本机配置的 yum 仓库把仓库里的 RPM 包全部下载到本地目录然后用createrepo生成元数据。同步完成后内网客户端看到的仓库和在公网看到的仓库内容完全一致。我第一次跑的时候也担心它会不会把整个仓库的依赖关系搞乱实际跑完发现它就是忠实地做镜像不碰依赖。3.2 同步 BaseOS 和 AppStream 的标准命令在同步之前先确认源服务器的/etc/yum.repos.d/下 Rocky 官方仓库配置存在。Rocky9.2 默认带有rocky.repo文件里面定义了baseos、appstream、extras等仓库。注意dnf reposync默认只同步启用的仓库所以要先确认。# 查看当前可用的仓库 ID dnf repolist # 同步 BaseOS 和 AppStream 到对应目录 dnf reposync --repoidbaseos --repoidappstream -p /data/yum_repo --download-metadata # 生成仓库元数据 createrepo /data/yum_repo/BaseOS createrepo /data/yum_repo/AppStream逻辑说明--repoid指定要同步的仓库 ID多个仓库用空格隔开-p指定同步的目标父目录reposync会在这个目录下自动创建以仓库 ID 命名的子目录--download-metadata表示同步时把仓库的元数据也下载下来这样本地生成的 metadata 会更完整。createrepo负责在同步完的目录里生成repodata文件夹这个文件夹就是 dnf 客户端用来识别仓库的凭据。如果createrepo命令不存在先执行dnf install createrepo_c安装。参数说明--download-metadata是必须的如果没有这个参数某些仓库尤其是 AppStream在客户端上会报Failed to download metadata错误。另外reposync支持--source同步源码包一般不需要加上了会让同步时间翻倍。3.3 同步 EPEL 的思路和注意点EPEL 仓库是 Rocky9.2 上安装第三方软件的重要来源但 EPEL 的包数量比 BaseOS 大得多全量同步可能要几个 GB。如果只是内网需要装某个 EPEL 包我用的是dnf reposync配合--arch和--repoid的方法只同步当前架构的包。# 先安装 EPEL 的 release 包源服务器必须有外网或者手动拷贝 rpm 进去 dnf install epel-release # 同步 x86_64 架构的 EPEL 仓库 dnf reposync --repoidepel -p /data/yum_repo --download-metadata --archx86_64 # 生成 EPEL 的元数据 createrepo /data/yum_repo/EPEL逻辑说明EPEL 仓库默认会启用直接--repoidepel就能同步。--archx86_64限制只同步 x86_64 的 RPMnoarch的包会自动带上不会漏。这里有个细节EPEL 仓库里长期有一些老的debuginfo包如果不需要调试符号可以在/etc/yum.repos.d/epel.repo里临时把debuginfo相关的仓库禁掉不然同步时会尝试拉取大量无用包。参数说明如果你只需要某一个包其实可以不全量同步。使用dnf reposync不支持直接指定包名需要借助dnf download或者先dnf list --available | grep 包名找到完整依赖再手动下载。全量同步 EPEL 的时间取决于带宽内网机器如果是从公网同步建议放到凌晨执行。3.4 同步脚本把 reposync 变成定时任务手动同步一次简单但运维要求是长期保持源和公网一致。我一般会在/usr/local/bin/下放一个同步脚本用 crontab 每周跑一次。脚本的核心思想是同步加生成元数据两个步骤同时做好日志记录。#!/bin/bash # /usr/local/bin/sync_yum_repo.sh # 每周同步 Rocky9.2 yum 仓库到本地 LOG_FILE/var/log/yum_repo_sync.log REPO_BASE/data/yum_repo # 记录开始时间 echo Sync Start: $(date) ${LOG_FILE} # 同步 BaseOS / AppStream / EPEL /usr/bin/dnf reposync --repoidbaseos --repoidappstream --repoidepel \ -p ${REPO_BASE} --download-metadata --archx86_64 \ ${LOG_FILE} 21 # 生成/刷新元数据 /usr/bin/createrepo ${REPO_BASE}/BaseOS ${LOG_FILE} 21 /usr/bin/createrepo ${REPO_BASE}/AppStream ${LOG_FILE} 21 /usr/bin/createrepo ${REPO_BASE}/EPEL ${LOG_FILE} 21 echo Sync Done: $(date) ${LOG_FILE}# 加入 crontab每周日凌晨 2 点执行 crontab -e # 0 2 * * 0 /bin/bash /usr/local/bin/sync_yum_repo.sh逻辑说明脚本里21把错误输出也写入日志这样第二天看日志可以直接定位是网络问题还是磁盘空间问题。--archx86_64加在 reposync 参数里能避免同步一些用不到的架构目录。注意脚本必须用绝对路径调用 dnf 和 createrepocrontab 的环境变量和交互 shell 不一样直接写dnf有可能找不到。参数说明同步时间建议避开工作时段内网带宽虽然不花钱但同步时磁盘 IO 占满会影响其他服务。另外createrepo每次全量重建元数据会比较慢如果仓库特别大可以考虑用--update参数做增量更新但有个前提目录里的包不能手动增删太多否则--update会漏掉变化的文件。4. 用 nginx 把仓库暴露到局域网配置细节决定成败4.1 为什么选 nginx 而不是 httpd做 HTTP yum 源用nginx还是httpd都行。我前几年在 CentOS 7 上搭过 httpd红帽系自带它配置起来也顺。但换到 Rocky9.2 之后我统一改用 nginx原因有两个一是 nginx 处理静态文件的并发能力强yum 仓库全是 RPM 和元数据文件属于典型的静态资源nginx 的sendfile和autoindex配合得很舒服二是 nginx 的虚拟主机配置比 httpd 直观改端口、加目录别名都简单。4.2 nginx 安装与仓库站点配置# 安装 nginx dnf install -y nginx # 创建仓库站点配置 cat /etc/nginx/conf.d/yum_repo.conf EOF server { listen 80 default_server; server_name yum.local; # 仓库根目录 root /data/yum_repo; # 开启目录列表方便人工确认仓库内容 autoindex on; autoindex_exact_size off; autoindex_localtime on; # 日志单独放避免和访问日志混在一起 access_log /var/log/nginx/yum_repo_access.log main; error_log /var/log/nginx/yum_repo_error.log warn; # yum 客户端的 User-Agent 是 dnf 开头可以针对性放开 location / { index index.html; } } EOF # 检查配置并启动 nginx -t systemctl enable --now nginx逻辑说明root /data/yum_repo是站点根目录客户端访问http://源服务器IP/BaseOS/时nginx 会直接映射到/data/yum_repo/BaseOS/。autoindex on开启目录列表浏览器访问时能看到 BaseOS、AppStream 这些子目录方便调试时确认文件是否存在。autoindex_exact_size off让目录列表显示更友好的大小格式。参数说明server_name yum.local这里只是个标识符局域网环境没有 DNS 的话客户端直接用 IP 访问所以这个配置里我特意不限制server_name的匹配。default_server表示这个 server 块作为默认响应避免 nginx 自带的welcome页面干扰。main这个 log format 是 nginx 默认定义的直接引用不需要额外配置。4.3 验证 HTTP 源是否可访问配置完成后先用 curl 验证一下 HTTP 服务是否正常。这一步不要跳过因为很多后续问题都是在这一步暴露出来的。# 本机验证能列出 BaseOS 目录说明 nginx 工作正常 curl http://127.0.0.1/BaseOS/ # 查看 repodata 目录是否存在 curl http://127.0.0.1/BaseOS/repodata/repomd.xml # 如果有其他内网机器直接在客户端上验证 curl http://192.168.10.20/AppStream/repodata/repomd.xml逻辑说明第一个 curl 如果返回 HTML 的目录列表说明 nginx 和目录权限没问题。repomd.xml是仓库元数据的入口文件dnf 客户端第一步就是下载它。如果这一步通了后面的客户端配置基本不会出问题。注意如果 SELinux 没关闭nginx 访问/data/yum_repo会返回 403。这时候检查/var/log/nginx/yum_repo_error.log看到Permission denied的错误就需要给目录打上正确的上下文标签chcon -R -t httpd_sys_content_t /data/yum_repo # 或者用 semanage fcontext 写入策略重启后也不会丢失 semanage fcontext -a -t httpd_sys_content_t /data/yum_repo(/.*)? restorecon -Rv /data/yum_repo逻辑说明chcon是临时修改文件上下文重启系统后可能被restorecon重置semanage fcontext是把规则写进 SELinux 策略库更持久。建议直接用semanage的方式一劳永逸。如果没有semanage命令先装policycoreutils-python-utils。5. 客户端配置把 dnf 指向局域网 HTTP 源5.1 备份并替换官方 repo 文件客户端的操作比源服务器简单得多核心就是修改/etc/yum.repos.d/下的仓库配置文件。我一般不会直接改官方的rocky.repo而是新建一个local.repo然后把官方仓库全部禁用。这样做的好处是如果内网源出问题可以通过--enablerepo临时切回官方仓库如果客户端有外网或者快速改回原配置。# 备份原有的 repo 配置 mkdir -p /etc/yum.repos.d/backup cp /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ # 新建本地源配置 cat /etc/yum.repos.d/local.repo EOF [local-baseos] nameRocky9.2 Local BaseOS baseurlhttp://192.168.10.20/BaseOS/ enabled1 gpgcheck0 [local-appstream] nameRocky9.2 Local AppStream baseurlhttp://192.168.10.20/AppStream/ enabled1 gpgcheck0 [local-epel] nameRocky9.2 Local EPEL baseurlhttp://192.168.10.20/EPEL/ enabled1 gpgcheck0 EOF # 禁用所有官方仓库 sed -i s/^enabled1/enabled0/ /etc/yum.repos.d/rocky.repo /etc/yum.repos.d/epel.repo # 验证配置 dnf repolist逻辑说明baseurl指向源服务器的 IP 和对应目录。gpgcheck0是内网环境下的常见做法因为没有配置 GPG 公钥如果你对 RPM 包的签名校验有硬性要求可以在客户端导入 Rocky 的官方 GPG 公钥然后把gpgcheck1打开同时baseurl里的仓库元数据需要包含gpgkey信息。dnf repolist输出里应该能看到三个新仓库且官方仓库被禁用后不在列表里。参数说明enabled0是禁用的意思。注意我的 sed 命令只改了rocky.repo和epel.repo两个文件如果/etc/yum.repos.d/下还有其他文件比如rocky-devel.repo也要一并禁用。dnf repolist如果显示不出仓库检查local.repo的文件权限是不是 root 可读。5.2 验证客户端能否正常安装软件配置完仓库测试一台干净客户端。最直接的方法是装一个之前肯定没装过的包同时观察它是否从内网 IP 拉取。# 清缓存再测试 dnf clean all dnf makecache # 安装一个测试包 dnf install -y tree # 验证包来源 dnf list installed tree dnf history info 1 | grep -i repoid\|url逻辑说明dnf makecache会从baseurl拉取repomd.xml生成缓存如果这一步报错基本就是网络或配置问题。dnf history info 1可以查看最近一次事务的详细信息里面会显示包的来源仓库 ID比如local-baseos这就能确认包来自本地内网源而不是别的缓存路径。注意如果客户端之前用过外网源dnf clean all是必须的否则残留的元数据缓存可能导致 mismatch 报错。5.3 使用dnf日志做事后确认还有一种情况是内网机器数量很多一台台验证不方便。我习惯在客户端上开启 dnf 的调试日志或者直接看/var/log/dnf.log。在验证阶段把日志级别临时调高记录每个包的实际下载 URL。# 临时开启 dnf 调试日志 dnf -v install -y mc 21 | grep http://192.168 # 或者直接查看历史日志中的 baseurl tail -n 100 /var/log/dnf.log | grep baseurl逻辑说明dnf -v会把详细的请求 URL 打印出来grep 过滤出包含内网 IP 的行一目了然。dnf.log里记录了每次makecache时访问的 baseurl如果里面出现公网地址说明某个仓库没有被禁用干净。这一步能帮你揪出混合源的问题——有的包来自内网有的包来自外网看起来能装但隐患很大。6. 避坑指南我在这条路上踩过的五个常见问题6.1Unexpected status 502 Bad Gateway不是 nginx 挂了是仓库没配上现象客户端执行dnf makecache时报Unexpected status 502 Bad Gateway: unknown error, url: http://127.0.0.1:1572或者直接指向内网 IP 的 502。原因这种 502 有两个常见来源。第一你用了带反代配置的 nginxproxy_pass指向上游但上游没起来第二客户端配置文件里的baseurl写成了带端口号的地址而这个端口根本不是 nginx 在监听前面被其他服务挡了一道。我遇到过最离谱的一次是服务器上装了dnf-plugin的代理插件yum 全局配置里proxyhttp://127.0.0.1:1572还开着导致所有请求都走了本地代理然后 502。解决先curl -v http://127.0.0.1/BaseOS/repodata/repomd.xml直接验证源服务器本身。如果源服务器正常再检查客户端/etc/dnf/dnf.conf里有没有proxy配置有就注释掉。最后确认local.repo里的baseurl没有多余端口号。6.2 客户端报Failed to download metadata for repo BaseOS现象dnf makecache提示Failed to download metadata for repo BaseOS错误详情指向repomd.xml下载失败或解析失败。原因最常见的两个原因一是仓库目录里没有repodata文件夹也就是源服务器上createrepo没有执行成功二是repodata里缺少filelists.xml或other.xml数据库部分 dnf 操作会依赖这些文件。如果是在同步过程中元数据没下全就中断也会出现这个问题。解决回到源服务器确认/data/yum_repo/BaseOS/repodata/repomd.xml存在文件大小不为 0。如果不存在重新执行createrepo /data/yum_repo/BaseOS。如果存在但客户端还是报错用浏览器访问这个文件看是否返回 200。注意检查 nginx 的error.log很多时候是 SELinux 拦截了 nginx 访问仓库目录返回给客户端的是 403 页面而不是 XML 内容。6.3404 Not Found包存在但 baseurl 的路径层级不对现象dnf install时报404 Not FoundURL 里显示http://IP/BaseOS/Packages/xxx.rpm但手动 curl 这个 RPM 路径又确实能访问。原因reposync同步后的仓库结构是/data/yum_repo/BaseOS/Packages/nginx 的root设置为/data/yum_repo那么 URL 应该是http://IP/BaseOS/Packages/xxx.rpm层级是对的。但如果你把同步命令的-p参数写成了-p /data/yum_repo/BaseOS就会出现/data/yum_repo/BaseOS/BaseOS/Packages/这种嵌套目录。客户端要的资源在BaseOS/BaseOS/Packages/下但元数据记录的路径是Packages/xxx.rpm就 404 了。解决在源服务器上ls /data/yum_repo/BaseOS看它的下一级目录是repodata还是BaseOS。如果是嵌套把仓库目录重新整理要么把-p改成-p /data/yum_repo要么把/data/yum_repo/BaseOS/BaseOS下的内容移动到/data/yum_repo/BaseOS然后重新跑createrepo。6.4 客户端互相之间版本不一致源同步太频繁现象A 机器今天能装到gcc 13.1B 机器下周装却装到gcc 13.2但两台机器的系统版本一样锁源也没做。原因这个不是 bug是 yum 源的特性。如果你的同步任务每天跑而客户端没有缓存锁每次dnf makecache都会拿到最新的元数据装出来的版本自然不同。在测试环境这无所谓但生产环境很可能会引发我明明没动代码为什么另一台机器跑不起来的问题。解决一是降低同步频率我建议生产源每周同步一次而不是每天二是在客户端用dnf --setoptlocal-baseos.exclude*或者采用版本锁定插件dnf-plugin-versionlock固定关键软件包的版本号。版本锁定这个习惯一定要养成付费买来的教训。6.5Error: Failed to synchronize cache for repo磁盘空间或权限问题现象dnf makecache时提示Error: Failed to synchronize cache for repo local-baseos但 curl 和浏览器都能正常访问仓库目录。原因客户端/var/cache/dnf/目录的写权限出了问题或者磁盘满了。也有可能/etc/yum.repos.d/local.repo的文件属主不是 root导致 dnf 无法读取。解决df -h /var/cache/dnf看空间chown -R root:root /etc/yum.repos.d/修复权限然后dnf clean all dnf makecache重试。如果还不行检查客户端系统时间是否和源服务器偏差过大dnf 对元数据的时间戳有校验时间差太离谱会拒绝同步。7. 把内网 yum 源做成生产级增量同步与仓库快照习惯如果只是自己用前面六章的内容已经够跑起来了。但如果你要管的是一个长期运维的集群我建议再花半小时做三件事能省掉后面源炸了的后悔药。第一件事是定期打快照。仓库目录虽然就是一堆 RPM 文件但一旦同步中断、磁盘损坏或者误删了repodata恢复起来要重新从公网拉几 GB 的数据。我习惯把/data/yum_repo做成独立的 LVM 逻辑卷每周同步前做一次 LVM 快照保留最近两份。恢复的命令很简单但有没有快照的心态完全不同# 创建 LVM 快照前提是 /data/yum_repo 是独立 LV lvcreate -L 20G -s -n yum_repo_snap /dev/vg_data/yum_repo_lv # 挂载快照检查内容 mkdir /mnt/yum_snap mount /dev/vg_data/yum_repo_snap /mnt/yum_snap # 确认无误后卸载并删除快照 umount /mnt/yum_snap lvremove /dev/vg_data/yum_repo_snap逻辑说明LVM 快照是 LVM 的写时复制特性创建时很快不影响正在进行的同步任务。恢复时直接把快照lvconvert --merge回去比重新同步快一个数量级。-L 20G是给快照预留的存储空间实际占用取决于快照期间有多少数据变更仓库同步的话 20G 足够。第二件事是给客户端做统一的 dnf 配置下发。几十台机器不可能一台台手改.repo文件我一般用 Ansible 推送local.repo和/etc/dnf/dnf.conf的keepcache1配置。另外retries和timeout这两个 dnf 参数在局域网环境也值得设一下避免同步时网络抖动导致客户端直接失败# /etc/dnf/dnf.conf 追加以下内容 [main] gpgcheck0 installonly_limit3 clean_requirements_on_removeTrue retries5 timeout15 max_parallel_downloads10逻辑说明retries5是元数据下载失败时的重试次数timeout15是连接超时时间对内网环境都算宽松。max_parallel_downloads10是 dnf 5 支持的多线程下载内网带宽大的时候装大量依赖包能明显感觉到提速。注意gpgcheck0放在[main]段只对未单独指定gpgcheck的仓库生效。第三件事是同步前先拉一次更新源确认没有坏的包被同步进来。我见过一次同步到一半源服务器断电仓库里留下不完整的 RPM客户端安装时报package is not signed或者校验失败。后来我在同步脚本里加了同步后完整性验证的步骤# 校验仓库中的所有 RPM 是否可读、元数据是否一致 cd /data/yum_repo for repo_dir in BaseOS AppStream EPEL; do /usr/bin/createrepo --update ${repo_dir} 2 ${LOG_FILE} /usr/bin/verifytree --check ${repo_dir} ${LOG_FILE} doneverifytree这个命令来自dnf-utils包专门用来检查 yum 仓库的完整性它会逐个校验仓库里的 RPM 文件是否与元数据中记录的 checksum 匹配。有问题的话立刻在日志里标记出来然后我再去公网单独补拉那个 RPM 文件。生产环境不怕慢就怕源里躺着坏包让所有客户端一起踩坑。这套方案从协议选型到避坑再到生产化加固已经是我在多个内网环境落地的标准套路。希望帮到你按这个顺序搭一遍基本不会再被 yum 源的问题拦在半夜了。本文还有配套的精品资源点击获取