gpmall-repo.rar离线仓库部署：内网yum源搭建与依赖闭环实战

简介gpmall-repo.rar 是一份面向云计算与分布式系统学习者的离线软件源资源包主要服务于需要在 CentOS 7 环境下搭建电商或日志分析平台的技术人员。包内共收录 173 个文件以 166 个 rpm 安装包为主体涵盖 Java 运行环境、MongoDB、Elasticsearch、Logstash 等常用中间件另含 3 个 gz、3 个 bz2 及 1 个 xml 元数据文件用于构建本地 yum 仓库索引压缩包整体约 304.19MB。目前已有 187 人学习下载适合在无外网或网络受限场景下完成环境部署与依赖安装。借助该资源读者可快速搭建 gpmall 项目所需的软件仓库避免逐一下载依赖的繁琐过程同时便于理解 rpm 包组织方式与仓库元数据生成逻辑为后续服务部署与排错提供稳定基础。1. 从 gpmall-repo.rar 说起一个被低估的云原生本地仓库包如果你在云原生环境里折腾过离线部署大概率遇到过这种场景内网机器没有外网yum install或apt-get全部超时镜像拉不下来连基础依赖都装不上。gpmall-repo.rar 就是为这类场景准备的一个本地软件仓库压缩包解压后是一套完整的 RPM 包集合与仓库元数据可以直接挂载到内网服务器上作为 yum 源使用。它解决的核心问题只有一个让没有外网的环境也能正常安装和更新软件包。这个包适合三类人一是做私有云或混合云交付的运维工程师需要在客户内网完成整套环境搭建二是实验室或教学场景里机器数量多、网络受限需要统一软件源三是自己搭 homelab 的开发者想模拟企业内网的离线部署流程。它不是什么高深的东西但用对了能省掉大量重复下载和依赖排查的时间。下面从仓库结构、挂载方式、依赖处理到常见翻车点一步步拆开讲。2. 拆开 gpmall-repo.rar仓库目录结构与元数据到底长什么样拿到一个仓库压缩包第一件事不是急着解压到生产目录而是先看清楚里面装了什么。gpmall-repo.rar 解压后通常包含两个核心部分一个是Packages/目录存放所有 RPM 包文件另一个是repodata/目录存放仓库的元数据包括repomd.xml、primary.xml.gz、filelists.xml.gz等。元数据决定了 yum 能不能正确识别这个仓库、能不能解析依赖关系。2.1 仓库目录的典型布局与各文件作用解压后你会看到类似这样的结构gpmall-repo/ ├── Packages/ │ ├── nginx-1.20.1-1.el7.x86_64.rpm │ ├── mysql-community-server-5.7.36-1.el7.x86_64.rpm │ ├── redis-6.2.6-1.el7.x86_64.rpm │ └── ...其余 RPM 包 ├── repodata/ │ ├── repomd.xml │ ├── primary.xml.gz │ ├── filelists.xml.gz │ └── other.xml.gz └── RPM-GPG-KEY-gpmallPackages/里放的是实际安装包命名遵循名称-版本-发布号.架构.rpm的规范。repodata/是仓库的索引yum 客户端首先读取repomd.xml从中找到primary.xml.gz的路径和校验值再下载并解析它来获取包列表和依赖信息。RPM-GPG-KEY-gpmall是签名公钥用于校验包完整性。注意如果repodata/目录缺失或损坏yum 会直接报Cannot find a valid baseurl或repomd.xml not found仓库等于废的。所以拿到包后先确认这个目录存在且文件完整。2.2 用 createrepo 重建元数据什么时候需要怎么操作有时候你拿到的是纯 RPM 包集合没有repodata/或者你往Packages/里新增了包元数据没有同步更新。这时候需要用createrepo重新生成索引。常见做法是# 安装 createrepo 工具如果本机有外网 yum install -y createrepo # 进入仓库根目录重新生成元数据 cd /opt/gpmall-repo createrepo -v . # 如果只想更新新增的包用 --update 参数避免全量重建 createrepo --update -v .-v输出详细过程方便确认扫描到了哪些包。--update只处理新增或变化的包速度更快适合日常维护。执行完后repodata/会被刷新repomd.xml的时间戳也会更新。参数说明createrepo默认使用sha256做校验如果客户端是较老的 CentOS 6可能需要加--checksum sha。另外如果包数量很大可以加--workers 4并行处理缩短生成时间。2.3 仓库签名与 GPG 校验别跳过这一步企业内网仓库通常会用 GPG 签名客户端配置里会写gpgcheck1。如果签名不匹配或公钥没导入安装时会报Public key for xxx.rpm is not installed。处理方式是在客户端导入公钥# 导入仓库公钥 rpm --import /opt/gpmall-repo/RPM-GPG-KEY-gpmall # 验证公钥是否导入成功 rpm -qa gpg-pubkey*如果只是内部测试环境也可以在 repo 配置里临时设gpgcheck0但生产环境不建议这么做。签名校验是防止包被篡改的最后一道防线跳过它等于把风险留给未来。3. 把仓库挂到内网HTTP 服务与 yum 源配置的完整链路仓库文件准备好之后下一步是让内网其他机器能访问到它。最常用的方式是用 HTTP 服务暴露仓库目录然后在客户端配置 yum 源指向这个地址。整个过程分三步服务端起 HTTP、客户端写 repo 文件、验证连通性。3.1 用 Nginx 或 Python 快速暴露仓库目录如果服务器上已经有 Nginx直接加一个 location 指向仓库目录server { listen 80; server_name repo.internal; root /opt/gpmall-repo; location / { autoindex on; autoindex_exact_size off; autoindex_localtime on; } }autoindex on让浏览器能直接看到文件列表方便排查。如果只是临时用Python 自带的 HTTP 服务更快# 在仓库根目录启动一个简单的 HTTP 服务监听 8080 端口 cd /opt/gpmall-repo python3 -m http.server 8080这种方式适合临时验证生产环境还是用 Nginx性能和稳定性更好。启动后在本机用curl http://localhost:8080/repodata/repomd.xml确认能返回内容。3.2 客户端 repo 文件怎么写baseurl、gpgcheck、enabled 三个关键参数在客户端机器上创建/etc/yum.repos.d/gpmall.repo[gpmall] nameGPMall Local Repository baseurlhttp://192.168.1.100/gpmall-repo/ enabled1 gpgcheck1 gpgkeyhttp://192.168.1.100/gpmall-repo/RPM-GPG-KEY-gpmallbaseurl指向仓库根目录注意结尾的斜杠不能少否则 yum 可能拼出错误的路径。enabled1表示启用这个源。gpgcheck1开启签名校验gpgkey指向公钥地址。如果内网没有 DNS直接用 IP 即可。写完后执行# 清理缓存并重建 yum clean all yum makecache # 查看仓库是否被正确识别 yum repolist如果repolist里能看到gpmall并且包数量不为零说明配置成功。3.3 验证安装用一个具体包测试整条链路不要只看repolist就认为万事大吉实际装一个包才能确认依赖解析和下载都正常。比如测试安装nginx# 查看 nginx 是否在仓库中可见 yum list available | grep nginx # 尝试安装 yum install -y nginx # 确认安装结果 rpm -qa | grep nginx如果安装过程中报依赖缺失说明仓库里的包不完整需要补充缺失的 RPM 后重新createrepo --update。这一步是检验仓库可用性的硬标准别跳过。4. 依赖地狱与版本对齐离线仓库最容易翻车的几个地方离线仓库最怕的不是包少而是包之间的依赖关系断了。你在有外网的环境里yum install一切正常是因为远程仓库帮你补齐了所有依赖。一旦搬到内网缺一个底层库就可能让整个安装卡住。下面几条是实际交付中反复遇到的坑。4.1 依赖缺失的排查思路从报错信息反推缺哪个包当 yum 报Error: Package: xxx requires yyy时不要急着去网上搜。先在仓库里确认yyy是否存在# 在仓库目录中查找是否包含某个包 ls /opt/gpmall-repo/Packages/ | grep yyy # 如果仓库已配置也可以用 yum provides 查 yum provides */yyy*如果确实没有需要从其他渠道获取对应版本的 RPM放入Packages/后执行createrepo --update。注意版本号要匹配比如libssl.so.10和libssl.so.1.1来自不同的 openssl 版本混用会直接报错。4.2 版本锁定的必要性为什么不能随便混用不同来源的 RPM不同来源的 RPM 可能依赖不同版本的底层库。比如从 A 渠道拿的 nginx 依赖openssl-libs-1.0.2k从 B 渠道拿的 mysql 依赖openssl-libs-1.1.1d两个版本冲突yum 会直接拒绝安装。常见做法是整个仓库的包尽量来自同一发行版和同一批次避免跨版本混用。如果确实需要多版本共存可以考虑用module或者拆成多个仓库让客户端按需启用。但在内网离线场景下最简单的策略就是保持版本一致。4.3 用 yum-utils 工具做仓库完整性检查yum-utils里有个repoclosure工具可以检查仓库中所有包的依赖是否都能在仓库内闭环# 安装 yum-utils yum install -y yum-utils # 检查仓库依赖闭环 repoclosure --repoidgpmall输出会列出所有缺失的依赖。如果结果为空说明仓库自洽可以放心交付。这个检查建议在打包完成后、交付前跑一遍能提前发现大部分问题。5. 避坑记录离线仓库交付中反复出现的五个问题这一章记录的是实际交付中踩过的坑每条按现象、原因、解决三段写。如果你正准备把 gpmall-repo.rar 用到生产环境建议逐条对照检查。现象一yum makecache 报 “Cannot retrieve repository metadata”。原因通常是 baseurl 路径写错或者 HTTP 服务没有正确暴露repodata/目录。解决先用curl在客户端访问baseurl/repodata/repomd.xml确认能返回 XML 内容。如果返回 404检查 Nginx 的 root 路径是否指向仓库根目录而不是上级目录。现象二安装时报 “Public key not installed”。原因是客户端没有导入仓库公钥或者gpgkey地址写错。解决手动rpm --import公钥文件或者在 repo 配置里把gpgkey改成可访问的 HTTP 地址。如果公钥文件本身损坏需要重新从仓库目录复制一份。现象三createrepo 执行后 repodata 目录为空。原因是执行命令时不在仓库根目录或者Packages/目录下没有 RPM 文件。解决确认当前目录下有Packages/且里面有.rpm文件然后重新执行createrepo -v .。如果包在子目录里需要加--dir参数指定。现象四客户端能 repolist 但安装时提示 “No package available”。原因是包名拼写错误或者仓库元数据没有包含该包。解决用yum list available | grep 关键词模糊查找确认包名。如果确实没有检查createrepo是否在添加包之后重新执行过。现象五多台客户端同时安装时 HTTP 服务响应慢或超时。原因是 Python 临时 HTTP 服务并发能力弱或者 Nginx 的 worker 连接数不够。解决生产环境换成 Nginx调整worker_connections和keepalive_timeout。如果仓库文件很大考虑开启sendfile和gzip压缩元数据。6. 进阶把仓库做成可移植的 ISO 与自动化校验脚本当你需要把仓库交付到完全隔离的环境时U 盘拷贝目录的方式容易丢文件或权限错乱。更稳妥的做法是打成 ISO挂载后直接作为本地源使用。另外每次更新仓库后手动检查依赖太累写一个校验脚本能省不少事。6.1 用 genisoimage 打包成 ISO 并配置本地源# 安装 genisoimage yum install -y genisoimage # 打包仓库目录为 ISO genisoimage -o /tmp/gpmall-repo.iso -R -J -V GPMALL_REPO /opt/gpmall-repo # 在目标机器上挂载 mkdir -p /mnt/gpmall-repo mount -o loop /tmp/gpmall-repo.iso /mnt/gpmall-repo-R启用 Rock Ridge 扩展保留 Unix 权限-J启用 Joliet兼容 Windows 读取-V设置卷标。挂载后把 repo 文件的baseurl改成file:///mnt/gpmall-repo/即可。6.2 写一个仓库自检脚本依赖闭环 签名校验 包数量统计#!/bin/bash # gpmall-repo-check.sh # 用途检查仓库依赖闭环、签名和包数量 REPO_DIR/opt/gpmall-repo REPO_IDgpmall echo 包数量统计 ls ${REPO_DIR}/Packages/*.rpm | wc -l echo 依赖闭环检查 repoclosure --repoid${REPO_ID} 21 | tee /tmp/repoclosure.log if [ -s /tmp/repoclosure.log ]; then echo 存在缺失依赖请检查上方输出 else echo 依赖闭环正常 fi echo 签名校验 rpm --checksig ${REPO_DIR}/Packages/*.rpm 21 | grep -i NOT OK echo 存在签名异常包 || echo 签名全部通过这个脚本可以放到 CI 或者交付前的检查清单里每次更新仓库后跑一遍。依赖闭环和签名是两条底线任何一条不过都不应该交付。6.3 版本更新时的增量同步策略仓库不是一次性的后续会有新包加入或旧包升级。全量重建repodata在包数量大时很慢用createrepo --update只处理变化部分。但要注意如果删除了旧包--update不会自动清理元数据里的旧条目需要加--database或者手动删掉repodata后全量重建。我一般会在每次大版本更新后做一次全量重建日常小更新用--update。从那以后我每次交付离线仓库前都会强制走一遍repoclosure和签名校验确认无误再打包。希望帮到你。本文还有配套的精品资源点击获取