企业官网建设流程全解析

简介：CentOS 7.9离线镜像源是一份适用于无互联网环境的企业级Linux系统安装与更新工具包，面向系统运维、实施工程师及需要本地化软件仓库的团队。压缩包共150个文件，大小155.55MB，核心为143个rpm安装包，配合3个gz与3个bz2压缩的元数据及1个xml索引文件，可完整支撑YUM仓库的建立与依赖解析。镜像内部涵盖repodata元数据、x86_64架构软件包以及kernel-ml、ansible、ceph等常用组件，说明该镜像源已预先集成多类运维场景所需软件。已有1834人学习下载，适合在离线或内网环境中快速搭建本地YUM源，实现批量安装、更新与版本管控。使用时可结合--disablerepo/--enablerepo切换仓库，并注意包版本兼容性与定期备份，以便获得安全稳定的系统运维基础。 接到过不少需求，都是同一个套路：生产网段与公网隔离，yum 源一断，装个 nginx 都费劲。CentOS 7.9 的离线镜像源，说白了就是在内网搭一个“只要局域网能通，就能yum install一切”的仓库。这篇文章就把我从同步镜像、生成 repodata、部署 Nginx、到客户端配置和踩坑排查的全过程写出来，给准备做离线源或者正被内网环境折磨的朋友一份可以直接抄作业的参考。

1. 为什么一定要靠自己搭离线源

1.1 什么场景下绕不开这个活

先别急着敲命令，得先搞清楚你的环境到底卡在哪一环。我在实际项目里见过几类最常见的诉求：

• 核心生产网和互联网物理隔离，服务器只开放内网端口，运维想装tcpdump、vim、lsof这类基础工具都只能靠 RPM 包一路手动传依赖。
• 安全审计要求，不允许生产节点直接访问公网，也不允许从外部下载未经验证的二进制，所有软件包必须从内部统一来源分发。
• 临时大规模交付，几十台新机器要批量装 agent、装系统补丁，每台都去外网拉包既慢又不稳定，还容易污染机房出口带宽。

这三种场景的共性就是：yum 需要一个稳定的、可控的、可以随时断网复用的软件源。你从外网下载再手动rpm -ivh一次两次还能忍，一旦涉及批量环境，没有离线源就是灾难。

1.2 离线源的构成，没你想的那么玄乎

所谓“离线镜像源”，不是把整张系统 ISO 扔内网就算完事。它的本质是两件事：一是仓库数据（RPM 包 + repodata 元数据），二是分发通道（HTTP/FTP 服务）。客户端通过baseurl指向内网的这个 HTTP 服务，然后 yum 就能像访问公网源一样解析依赖、校验签名、正常安装。

我通常把它拆成三层来理解：

CentOS 7.9 在 2024 年 6 月 30 日已经 EOL（生命周期结束），官方 mirror 仓库已经整体迁移到了 vault。所以你在公网拉包的时候到底是拉mirror.centos.org的常规目录，还是拉vault.centos.org的归档目录，要提前想清楚。我的建议是：直接以 vault 作为最终稳定源，因为常规 mirror 链接随时可能被清掉或者变慢，vault 是归档地址，反而更适合长期离线快照。

1.3 先算账：磁盘、带宽和目录规划

别一上来就全量同步，先把规模估算一下。CentOS 7 的仓库如果只保留x86_64架构，base加updates加extras加起来大概 10GB 左右；如果再带上epel，又是 10GB 起步。debuginfo、source 这种目录动辄几十 GB，内网场景基本用不上，同步时要主动排除。

服务器磁盘至少预留 50GB，别卡在 30GB 这种尴尬位置。同步是个长时间任务，建议放在/data/centos-mirror这类独立挂载目录下，别放根分区，否则后续扩容很麻烦。带宽方面，如果是千兆内网，同步一晚上也能完成；如果上游源带宽有限，那就用rsync断点续传分几次拉完。

2. 在公网机器上把仓库同步下来

2.1 先把工具备齐，否则后面全卡住

同步过程要用到yum-utils（提供reposync）、createrepo（生成元数据）、rsync（增量同步）、nginx（作为内网分发服务）。如果你手头这台机器能上网，直接：

yum install -y yum-utils createrepo rsync nginx

如果你这台“公网代理机”本身也处于受限网络，那就用另一台能联网的虚拟机下载这几个 RPM 和依赖，用rpm -Uvh *.rpm手动装一遍。我在现场就遇到过连yum-utils都装不上的蛋疼情况，所以这句话不是废话。

2.2 用 reposync 还是 rsync？我的选择

同步 CentOS 官方仓库有两个流派：reposync和rsync。我的经验是：

• 同步 CentOS 基础仓库，用rsync更好，因为上游 mirror 已经维护好了完整的repodata，直接同步就可以用，不需要本地再生成。
• 同步 EPEL、自定义仓库，用reposync更灵活，它直接按 yum 仓库定义去拉包，到本地后自己跑createrepo。

先看标准做法。比如同步 CentOS 7.9 的base、extras、updates，直接指定架构为x86_64：

BASE_URL="https://vault.centos.org/7.9.2009" LOCAL_DIR="/data/centos-mirror/7" rsync -avH --delete \ --exclude="*.src.rpm" \ --exclude="debug/" \ --exclude="source/" \ --exclude="aarch64/" \ --exclude="i386/" \ --exclude="ppc64/" \ --exclude="ppc64le/" \ ${BASE_URL}/os/x86_64/ ${LOCAL_DIR}/os/x86_64/

参数解释一下：-a归档模式，保留权限和时间戳；-H保留硬链接，RPM 仓库里不少包有硬链接，这个参数能省不少空间；--delete保证本地和上游完全一致，避免残留过期包。

extras和updates同理，把路径里的os换成extras和updates即可。这里我特意排除了其他架构，内网基本全是 x86_64，没必要浪费磁盘。

2.3 EPEL 仓库的同步姿势

EPEL 不能直接从 vault 拉，它有自己的源地址。我这里演示的是阿里云镜像站的同步方式，因为在国内速度通常是最稳的。如果你在海外，直接用https://dl.fedoraproject.org/pub/epel/7也可以：

LOCAL_EPEL="/data/centos-mirror/epel/7" rsync -avH --delete \ --exclude="*.src.rpm" \ --exclude="debug/" \ --exclude="aarch64/" \ --exclude="ppc64/" \ rsync://mirrors.aliyun.com/epel/7/x86_64/ ${LOCAL_EPEL}/x86_64/

注意：EPEL 的x86_64目录下面还套了一个repodata子目录，同步下来以后一般不用重新生成。但如果下游 yum 报repomd.xml校验错误，多半是同步不完整，重新跑一遍rsync即可。

2.4 拉完之后，等 repodata 确认无误再停手

同步完 CentOS 仓库之后，建议检查一下关键文件是否存在：

ls -lh /data/centos-mirror/7/os/x86_64/repodata/repomd.xml

repomd.xml是 yum 解析仓库的核心入口，客户端发起yum makecache时，第一步就是请求这个文件。没有它，后面全白搭。

如果你后面是把这套东西继续往内网搬运，那搬运过程中千万别漏掉隐藏目录或软链接。我之前遇到过把repodata目录搬没了、客户端反复报 404 的低级错误，排查了半小时才发现是 tar 打包时没带隐藏属性。

3. 用 Nginx 把本地目录变成可访问的软件源

3.1 目录结构规划好，后面省心

同步下来的目录我习惯统一规划成这样：

/data/centos-mirror/ ├── 7/ │ ├── os/ │ │ └── x86_64/ │ │ ├── Packages/ │ │ └── repodata/ │ ├── extras/ │ │ └── x86_64/ │ └── updates/ │ └── x86_64/ └── epel/ └── 7/ └── x86_64/

这种结构对应客户端的仓库定义非常直观：baseurl=http://192.168.1.10/centos/7/os/x86_64/。前后端都能少很多心智负担。

3.2 最小可用的 Nginx 配置

在/etc/nginx/conf.d/centos-repo.conf里写一个 server 块：

server { listen 80; server_name mirrors.local; autoindex on; autoindex_exact_size off; autoindex_localtime on; root /data/centos-mirror; location / { try_files $uri $uri/ =404; } access_log /var/log/nginx/repo-access.log main; error_log /var/log/nginx/repo-error.log; }

autoindex on是必须的，否则客户端在解析仓库时访问目录会拿到 403。try_files确保文件不存在时返回 404 而不是把请求转发到后端。

配置完重启：

nginx -t && systemctl restart nginx systemctl enable nginx

3.3 验证服务端是否就绪

用curl检查关键路径能不能直接访问，这一步能省掉后面排查客户端时报错的时间：

curl -I http://127.0.0.1/centos/7/os/x86_64/repodata/repomd.xml curl -I http://127.0.0.1/epel/7/x86_64/repodata/repomd.xml

返回200 OK就说明服务和文件路径都没问题。如果这里输出 403，查 selinux 和目录权限；如果 404，查 root 和目录层级。

4. 客户端 yum 配置：让每台 7.9 都能用上离线源

4.1 备份原有 repo 并禁用 fastestmirror

客户端机器上先在/etc/yum.repos.d/下面建一个备份目录，把所有官方源文件挪走：

mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/

这一步很多人会忽略，导致后面yum makecache同时在连公网源和本地源，慢不说，报错还很难看。

另外，CentOS 7 默认装了yum-plugin-fastestmirror，它会在每次 yum 操作时去探测最快镜像。内网环境下这个插件纯属帮倒忙，等待时间长还很智障。直接禁用：

sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf

4.2 一个完整的 local.repo 长这样

在/etc/yum.repos.d/local.repo里写入以下内容，这里把192.168.1.10替换成你的离线源服务器地址：

[base] name=CentOS-7 - Base baseurl=http://192.168.1.10/centos/7/os/x86_64/ gpgcheck=0 enabled=1 [updates] name=CentOS-7 - Updates baseurl=http://192.168.1.10/centos/7/updates/x86_64/ gpgcheck=0 enabled=1 [extras] name=CentOS-7 - Extras baseurl=http://192.168.1.10/centos/7/extras/x86_64/ gpgcheck=0 enabled=1 [epel] name=EPEL-7 baseurl=http://192.168.1.10/epel/7/x86_64/ gpgcheck=0 enabled=1

4.3 gpgcheck 到底开不开？

很多离线源教程直接gpgcheck=0，图省事。我的建议是：

• 如果内网安全要求高，且你保留了上游的 GPG key，gpgcheck=1更稳妥。CentOS 7 的 key 位置在/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7，EPEL 的 key 在RPM-GPG-KEY-EPEL-7。
• 如果是临时搭一把、后面就销毁的交付环境，gpgcheck=0能省掉导入 key 的环节，也不影响功能。

我一般场景是gpgcheck=0，然后把上游 key 备份到内网机器，理由是：离线源本身就是从可信渠道同步进来的，包完整性在传输层已经有一定保障。当然，长期生产环境还是建议把 key 一起纳入管理。

4.4 客户端验证一把到位

在客户端执行：

yum clean all yum makecache

看到base、updates、epel仓库都显示metadata successfully downloaded就算成功。再随便装一个包试试：

yum install -y htop

能装上，说明整条链路是通的。如果 makecache 阶段报错，看下一步的排查表。

5. 实操中的坑和排查经验

5.1 高频问题速查表

我把现场频率最高的几个问题整理成表格，基本能覆盖 90% 的报错场景：

5.2 独家避坑经验

第一，同步完成后不要急着把上游源删掉。离线源搭建是长期工程，后续补丁和软件包变更需要一个“同步窗口”。我在服务器上留了一个 cron 脚本，每个月最后一天凌晨自动从 vault 增量同步一次，再执行createrepo --update。这样内网机的yum update可以一直跟着补丁节奏走。

第二，CentOS 7 的源别指望用 ISO 版本直接替代。系统装完自带了 BaseOS 和 AppStream 的仓库定义，但离线场景下基 OS 里的软件包很少，不补齐updates和extras的话，yum install很快会遇到依赖缺失。所以还是老老实实同步完整仓库。

第三，客户端执行yum clean all的频率要控制住。离线源的仓库元数据是不会频繁变化的，除非你更新了服务端。没必要每次操作都 makecache，建议在服务端同步完后写一个小脚本，让客户端统一yum clean all && yum makecache一次，其余时间直接用缓存即可。

5.3 内网环境的一些额外注意

如果客户端有某些商业软件在做授权绑定，会用到/etc/machine-id或者hostid这类机器标识，那和 yum 源搭建没直接关系，不用混在一起排查。真正容易混的其实是两个点：

• 客户端配置了代理，导致内网 http 请求被代理转发出去，然后超时。这种情况下curl http://192.168.1.10是通的，但 yum 永远报错。干脆在 yum 配置里显式忽略代理。
• 服务器防火墙只放行了 80/443 端口，Nginx 偏偏监听 8081。这种“服务正常但外部访问不了”的问题，第一反应就是ss -lntp | grep nginx确认监听端口，再查防火墙。

# 确保 80 端口在 firewalld 中放行 firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload

结尾再说几句

离线镜像源这活看起来简单，实际做起来细节不少。我个人体会是：目录结构、同步策略、客户端 repo 定义，这三样一旦定下来就别轻易改，否则内网几十台机器的排查成本会呈指数增长。运维环境里最怕的不是没有方案，而是每个环境都有一套自己的“临时方案”。

如果你后续准备在离线源上做更多文章，可以考虑把这些事顺手一起做了：把epel里的常用包单独导出一个最小包清单、定期对 repodata 做一次哈希校验、再把源服务器的 Nginx 访问日志接入监控。这样整个内网分发体系就不再是个一次性工程，而是可持续维护的基础设施。

最后分享一个小技巧：同步好的仓库目录，用tar打一个快照放在另一块硬盘上。万一源服务器磁盘坏了，拿到一台新机器解压再起个 Nginx，半小时内就能恢复整套源服务。这个备份动作虽然笨，但关键时刻真的能救命。

本文还有配套的精品资源，点击获取