在不少内网、涉密网段或者完全断网的机房里最让人头疼的事就是装个软件却四处找不到依赖包。Kylin v10 x86_64 这套系统的 Yum 源里躺着成百上千个 RPM 包平时联网一条命令就能装的东西一旦挪到隔离环境就得想办法把这些安装包全部搬到本地。把整个 Yum 源的所有安装包下载到本地指定目录说白了就是给自己造一个离线仓库之后不管装 PostgreSQL、JDK17还是补一个不认识的小依赖都能指着本地目录直接装再也不用抱着 U 盘一个包一个包地扛。这套做法适合谁内网运维、需要在银河麒麟上批量部署软件的工程师以及任何被cannot find a valid baseurl for repo报错折腾过的人都值得把它吃透。1. 整源下载的需求拆解与方案选型1.1 到底什么场景需要把整个源搬回家先别急着敲命令。整源下载这个动作本身有点重先想清楚自己的场景属于哪一类不然很可能用大炮打了蚊子。常见的三种情况是这样的内网隔离环境。生产网段和互联网物理隔离机器上有 Yum 命令但没有可达的源任何一次yum install都会以Cannot find a valid baseurl收场。批量部署。手上有几十台同款 Kylin v10 x86_64与其每台都逐个补包不如搭一个本地源一次到位后续统一指向。版本锁定。有些老系统依赖特定版本的包公网源更新后老版本下架离线仓库能把当时那批包装的状态原样冻住。我见过有人图省事只挑几个常用包装进移动硬盘结果到了现场发现缺了个底层的.so依赖硬是又跑一趟。整源下载的价值就在这里——把要装什么这个未知数直接归零依赖关系在源内部是自洽的怎么解都能解出来。1.2 三种下载方式的取舍把源搬本地主流的思路有三条各有脾气方式命令工具优点缺点适用场景reposync 逐包下载yum-utils 里的 reposync只拉 RPM 包体积可控可增量下载慢元数据要自己生成内网源、离线仓库最常用rsync 镜像同步rsync完整镜像连元数据一起同步需要镜像站支持 rsync体积大有专门镜像站对接yumdownloaderyum-utils 里的 yumdownloader按需精确下载只解决单个包不成体系补个别包大多数内网场景reposync 是最优解。原因很直接它认的是系统当前配置好的仓库下载的是 RPM 本体不带一堆用不上的索引和元数据冗余体积更友好再配合 createrepo 本地重建索引就得到一个功能完整的私有源。1.3 为什么我最终锁定 reposync 加 createrepo 这条链路reposync 的定位很清晰——它按 repo 为单位把远端每个包拉到本地目录同时保留包的原始层级。真正让它成为主角的是后面那一环createrepo生成的元数据。没有元数据你下载下来的只是一堆散装 RPM有了元数据这堆文件才被激活成一个可以被 Yum 识别的源。我选这条链路的另一个原因是可控性。reposync 支持-n只拉最新版本、--download-path自定义落盘目录、-d清理远端已删除的本地包这些开关组合起来既能做一次性全量也能做日后的增量同步。相比之下 rsync 更适合和镜像站做字节级镜像对我只想要一个自己能用的源这种诉求反而过重。注意reposync 默认会下载仓库里所有版本、所有架构的包如果不加限制一个完整 OS 仓库轻松就能吃掉 20GB 以上。动手前先估好盘别等下到一半 dd 报警。2. 动手前的环境准备与源确认2.1 确认系统版本与 CPU 架构第一步永远是认清自己在什么系统上。Kylin v10 有几个发行分支SP1、SP2、SP3 等不同分支自带源地址和包集合都有差异架构也分 x86_64 和 aarch64。先跑几条命令把底细摸清cat /etc/.kyinfo cat /etc/os-release uname -m rpm -q --qf %{ARCH}\n kernel/etc/.kyinfo是麒麟系统特有的版本标识文件里面能直接看到发行版本号比通用的os-release更准。uname -m返回x86_64就说明架构没错。这一步看着简单但我踩过一次坑在一台 arm64 机器上照着 x86_64 的文档操作源地址对了、命令也对但下载回来一堆x86_64包一个都装不上白折腾半天。2.2 先把现有的 Yum 源修通整源下载的前提是当前系统的 Yum 源本身能正常工作否则 reposync 无从下手。看看现在配了哪些源yum repolist all ls -l /etc/yum.repos.d/yum repolist all会列出所有启用的和禁用的仓库重点关注enabled那一列。如果输出里全是Cannot find a valid baseurl for repo: base/7/x86_64这类红色报错说明源的baseurl指错了或者网络压根不通。麒麟系统的源配置一般放在/etc/yum.repos.d/下形如kylin_aarch64.repo、ks10-adv-os.repo这类文件。打开看看里面baseurl指向哪里grep -E baseurl|name|enabled /etc/yum.repos.d/*.repo如果baseurl是个内网地址而那台服务器又连不上就得先换成可用的源。企业环境通常会有自己的内部镜像站直接找运维要地址如果是能联网的临时机器也可以临时指向公共开源镜像站点把包先拉下来。这里多句嘴源地址的改动最好先备份原文件cp /etc/yum.repos.d/xxx.repo /etc/yum.repos.d/xxx.repo.bak改完源文件务必刷新缓存确认通了yum clean all yum makecache yum repolistyum repolist能正常打印出仓库名和包数量才算真正准备好。2.3 装上 reposync 和 createrepo 两把工具默认系统不一定带yum-utils而 reposync 和 yumdownloader 都在里面createrepo 则是单独的包。一次性装齐yum install -y yum-utils createrepo装完后验证一下两个命令都要能查到版本reposync --help createrepo --helpreposync的--help里参数不少先别被吓到常用的就那么几个下一章逐个拆。装工具这步有个小陷阱如果系统最小化安装且源不通yum install会直接失败那就得回到 2.2 先把源弄通别死磕。实操心得在准备下载的目标机器上我习惯建一个专门的目录比如/data/offline-yum并且把它挂在数据盘而不是系统盘。系统盘根分区往往只有几十 G整源下载分分钟把它撑爆最后连带系统都起不来。3. reposync 整源下载完整实操3.1 reposync 核心参数逐条拆解reposync 的用法是reposync [选项]不加参数时它会按当前所有启用的 repo 挨个同步。关键选项我列一下并且说说各自解决什么问题-r repoid或--repoid只同步指定仓库。这个 repoid 是yum repolist里显示的那个方括号里的名字比如ks10-adv-os。想分仓管理就靠它。-p path或--download-path指定下载落盘根目录。省略的话它会默认扔到/var/cache/yum或当前目录容易撞上系统盘。-n或--newest-only只下载每个包的最新版本。整源里同一个包常存在多个版本加上它体积能省一大截。-d或--delete把远端已删除、本地还留着的包清掉做增量同步时必开。-l或--urls不下载只把 URL 列出来。可以先跑一次看看规模心里有数。-a arch指定架构比如-a x86_64避免拉到别的架构的包。--norepopath不把仓库名作为子目录直接铺在下载根目录下。先干一件事把要下的仓库名字和大致规模摸清楚yum repolist reposync -l -r ks10-adv-os | wc -l第二条命令只在终端打印包 URL 个数不会真下载几秒钟就能告诉你这个仓里有多少个包。3.2 落盘路径规划与磁盘空间估算路径这块要有规划别随手一个reposync -r xxx就开始下。我的习惯是按仓库分目录一个源一个文件夹mkdir -p /data/offline-yum/kylin-os mkdir -p /data/offline-yum/kylin-updates然后用-p指到父目录reposync 会自动为每个 repoid 建子目录。空间估算是必须的可以用列 URL 的方式粗估reposync -l -r ks10-adv-os | wc -l df -h /data一个包平均按 1MB 到 3MB 估几万个包的 OS 仓加上 updates20GB 是保守数字实际见过 30GB 以上的。看下df -h可用空间至少留出估算值的 1.5 倍做缓冲。宁多勿少磁盘这事上犯不着抠。这里补一个我自己的目录结构参考方便后期维护/data/offline-yum/ ├── kylin-os/ # 操作系统基础包 ├── kylin-updates/ # 更新包 └── repodata-cache/ # 元数据操作的临时目录3.3 分批下载与断点续传的实战做法整源下载动辄几个小时一口气跑完风险不小——网络抖动、SSH 断开、磁盘写满都会让前功尽弃。我的做法是分仓、分阶段下并且用nohup挂到后台nohup reposync -r ks10-adv-os -p /data/offline-yum -n -a x86_64 /tmp/reposync-os.log 21 命令行解释一下-r ks10-adv-os锁定那个基础仓-p /data/offline-yum指定落盘根目录-n只下最新版-a x86_64限定架构最后把输出重定向到日志。挂后台后可以随时看进度tail -f /tmp/reposync-os.log如果中途断了reposync 的好处是可以重复执行——已下载的包它会识别跳过续着下。这点比 yumdownloader 友好得多后者断了得重头来。全部下完后对着日志检查有没有 Failed 之类的字眼grep -iE fail|error|timeout /tmp/reposync-os.log无输出才算干净。注意事项-n只下最新版看着省空间但如果你的目标是任何老版本都能装那就别加-n它会把仓库里全部历史版本一起拉下来。选哪个完全取决于你是要够用还是全量留档。3.4 下载过程中的状态监控下载跑起来之后别当甩手掌柜。几个监控点磁盘水位watch -n 60 df -h /data每隔一分钟看一眼防爆盘。目录大小du -sh /data/offline-yum/kylin-os看增长趋势估算剩余时间。进程存活ps -ef | grep reposync确认后台进程还在。网络吞吐iftop或nload需要装能看出是卡了还是在跑。这几个观察里磁盘水位最要命。reposync 不会因为盘满而优雅停止它往往写到一半报个No space left on device留下一堆半截文件还得手动清理。4. 把下载目录变成可用的本地 Yum 源4.1 createrepo 生成元数据RPM 包下完了这一堆文件还只是一堆文件。Yum 认源认的是元数据也就是repodata目录里的repomd.xml及其索引文件。用 createrepo 给每个仓库目录生成索引createrepo -v /data/offline-yum/kylin-os createrepo -v /data/offline-yum/kylin-updates-v是 verbose会打印处理过程。命令跑完对应目录下会多出一个repodata/文件夹。看一眼ls -l /data/offline-yum/kylin-os/repodata/能看到repomd.xml、*-primary.xml.gz等文件就对了。如果后续再往目录里补包不用整个重跑用--update增量刷新createrepo --update /data/offline-yum/kylin-os--update只处理变化的包速度比全量重建快很多。这一步是整条链路的关键——很多人卡在包都下好了为什么 yum 不认十有八九就是漏了 createrepo。4.2 编写本地源配置文件接下来让 Yum 认识这个本地目录。在/etc/yum.repos.d/下新建一个local-offline.repo[kylin-local-os] nameKylin Local OS Repo baseurlfile:///data/offline-yum/kylin-os enabled1 gpgcheck0 priority1 [kylin-local-updates] nameKylin Local Updates Repo baseurlfile:///data/offline-yum/kylin-updates enabled1 gpgcheck0 priority1几个字段说明一下。baseurl用file://加绝对路径指向 createrepo 生成的目录gpgcheck0关掉签名校验因为自己搭的源没有验签体系但生产环境若在意可保留拷贝来的 GPG key 并开启校验priority1让本地源优先级最高避免优先去连不通的公网源。如果本地目录还想通过 HTTP 给其他机器共用那就在本机起个 httpdyum install -y httpd systemctl enable --now httpd再把目录软链或配置到/var/www/html/下baseurl改成http://本机IP/...即可。不过对单机使用来说file://方式最省事不需要额外服务。4.3 清理缓存并验证本地源改完配置刷新缓存并验证yum clean all yum makecache yum repolistyum repolist应该能看到kylin-local-os和kylin-local-updates并且它们的状态是 enabled。接下来找一个之前装不上的包实测yum install --downloadonly 某个包 -y # 或者直接装 yum install -y 某个以前缺的依赖如果能正常解析并安装说明本地源彻底活了。验证时有个小技巧先把公网源禁掉enabled0只留本地源这样能确认包确实是本地源提供的而不是偷偷连了公网。测试完再把公网源按需恢复。提示如果yum repolist报repomd.xml找不到八成是 createrepo 的目录和 baseurl 指向的目录对不上或者 createrepo 没跑成功回去检查两步。5. 常见问题排查与维护经验5.1 高频报错与对应处理速查干这活踩坑是家常便饭我把最常撞上的几类整理成表遇到先对号入座报错信息常见原因处理办法Cannot find a valid baseurl for repo源地址错、网络不通、源被禁检查baseurl和enabledping 通源地址repomd.xml: [Errno 256] No more mirrors本地 repodata 缺失或路径不对重跑 createrepo核对 baseurl 目录No space left on device磁盘写满清理后换数据盘重新续传package is not signed / GPG 校验失败gpgcheck1 但无对应 key导入官方 key 或临时设 gpgcheck0repomd.xml 404createrepo 未执行完或目录被移动检查 repodata 目录是否存在Nothing to do包已装或包名拼错换包名或确认是否已安装这几条覆盖了九成以上的现场报错。碰到新问题先别慌yum -v加 verbose 看详细输出或者翻/var/log/yum.log。5.2 磁盘被撑爆后的抢救方法真要下满盘了先别重启系统静静处理du -sh /data/offline-yum/* # 看哪个仓最占地方 find /data -name *.tmp -delete # 清掉下载中的临时文件reposync 断了留下的半截文件通常带.part或临时后缀清掉这些不完整的再重新执行 reposync 续传。如果确实是总量超出预期那就得做取舍了比如加上-n只留最新版或者只下os和updates这两个核心仓把体积大的额外仓如果有排除。我在一个客户现场就遇到过磁盘只有 40G 却想全量下源的情况最后改成只下最新版 只下核心仓体积从预估的 35G 压到 12G刚好放下。5.3 增量更新与长期维护离线源不是搭一次就完事了源会更新本地也得跟。维护动作是这样的# 1. 同步新增/更新的包顺带删除远端已下架的 reposync -r ks10-adv-os -p /data/offline-yum -n -d # 2. 刷新本地元数据增量 createrepo --update /data/offline-yum/kylin-os # 3. 清缓存让 Yum 重新识别 yum clean all yum makecache-d是关键它让本地目录和远端保持一致不会越积越乱。如果把这套动作写成脚本挂到定时任务里就得到一个自动跟票的私有源。脚本大致长这样#!/bin/bash set -e BASE/data/offline-yum for repo in kylin-os kylin-updates; do reposync -r ks10-adv-os -p $BASE -n -d createrepo --update $BASE/$repo done yum clean all yum makecache挂到 crontab 每周跑一次即可。维护这块最容易被忽略很多人的离线源搭好后半年不动等到急着装包时才发现里面全是过期版本。5.4 几个用血换来的实操心得聊几个文档里不会写、但实际很值钱的经验。第一别在业务高峰期跑 reposync。它很吃网络和磁盘 IO把生产机的带宽占满业务请求会被拖慢。挑夜里或维护窗口做。第二下载前先yum clean all。这是很多人想不到的一点——reposync 会读取 Yum 的缓存元数据来决定下什么如果缓存是旧的下到的包版本可能是过期的。先清缓存再同步拿到的是最新状态。第三验证要断网验证。搭好源之后把网线逻辑断开或临时禁用公网源再装一个包试试。不然你没法确定装成功是本地源的功劳还是网还通着走了公网。我见过一次源其实配错了但因为网还通测试时一直能装等搬到内网才全露馅。第四定期检查.repo文件的priority。系统里如果有多个源优先级没设好Yum 可能优先去连那个连不上的公网源然后一切失败。本地源永远给最高优先级数字最小。实操心得如果目标是长期维护离线源我强烈建议把它做成 HTTP 服务而不是每台机器都拷一份file://目录。一台机器搭源、全内网通过baseurlhttp://源机IP/...访问更新一次所有人都受益省下的磁盘和人力不止一点点。这套整源下载到本地 createrepo 激活 本地源指向的组合实际用下来非常稳。我自己维护的那套源已经跑了两年多从最初的 PostgreSQL、JDK17 手动补包到现在任何内网机器一句yum install就能解决中间省下的反复折腾时间难以计数。要说还有什么可以继续深挖的方向那就是把 yumdownloader 也纳进来——当只需要个别包、又不想动整个源的时候yumdownloader --resolve --destdir/path 包名连依赖一起打包会比整源下载轻快得多适合临时补漏的场景。