Kylin V10 x86_64 Yum源整源同步与本地离线源搭建

机房里有几台麒麟服务器网络是物理隔离的每次打补丁都得拿U盘来回拷rpm包时间久了谁都想换个活法。最省事的思路其实很朴素找一台能连外网的 Kylin v10 x86_64 机器把整个 Yum 源里的安装包一次性同步到本地指定目录再打包带进内网配成本地源从此装什么都是一个命令的事。听着简单真上手才发现坑不少——磁盘空间没算准、reposync 参数写错目录嵌套了一层、下完包忘了生成元数据导致本地源用不了。这篇就把Kylin v10 x86_64 系统下载整个 Yum 源的所有安装包到本地指定目录这件事从头到尾讲清楚包括参数为什么这么选、空间怎么预估、踩过的坑怎么绕开。不管你是刚开始接触麒麟运维的新手还是已经搞过 CentOS 本地源的老手都能从里面找到能直接抄的步骤。1. 麒麟 V10 的仓库体系与整源拉取到底解决什么问题1.1 为什么会有把整个源搬到本地的需求先说清楚这个操作存在的理由不然很容易被人当成没事找事。银河麒麟高级服务器操作系统 V10Kylin Linux Advanced Server V10大量部署在政务、金融、能源这类内网环境里物理隔离是硬要求。但这些机器照样要装 JDK、要补安全漏洞、要部署 MySQL 和中间件每次都用rpm -ivh单个安装包手动装依赖关系能把人逼疯——A 依赖 BB 又依赖 C 的特定版本一层层查下去装个 fluent-bit 能折腾一下午。把整个 Yum 源同步到本地本质上是把依赖求解这件事交还给包管理器内网机器只要指向本地源yum install照样能用依赖自动补齐这才是真正省事的地方。另一个场景是批量部署。几十上百台机器同时上线如果每台都去外网拉包带宽扛不住速度也慢。先在一台机器上把源同步下来做成离线仓库再通过内网文件服务分发所有节点都从本地拉速度快、可控、还不怕外网源哪天挂了。这就是为什么整源拉取在麒麟运维里是个高频动作而不是个花哨的技巧。1.2 麒麟 V10 的仓库文件和 CentOS 不像是一回事很多从 CentOS 转过来的人第一反应是去改/etc/yum.repos.d/CentOS-Base.repo结果发现根本没有这个文件。Kylin V10 虽然底层是 RPM 那一套包管理器也是 dnfyum 是它的兼容封装但仓库配置和命名完全走自己的体系。典型的仓库文件会叫kylin_x86_64.repo里面定义的仓库 ID 长这样ks10-adv-os、ks10-adv-updates、ks10-adv-addons。这几个 ID 是你后面 reposync 命令里-r 参数要填的值填错了会直接报找不到仓库。这些仓库的 baseurl 一般指向麒麟官方的更新服务器路径里带$basearch变量在 x86_64 机器上解析出来就是 x86_64。这里有个容易忽略的点ARM 架构的麒麟用的是kylin_aarch64.repo仓库里的包和 x86_64 完全不通用。所以别人分享的同步脚本如果没注意架构直接拿来用会拉错架构的包装到机器上要么装不上要么运行报错。提示动手前先ls /etc/yum.repos.d/看清楚本机到底有哪几个 repo 文件再yum repolist看生效的仓库 ID这两步能帮你避开后面大半的仓库不存在报错。1.3 动手前必须锁死的三个前提第一个是磁盘空间。一个完整的 Kylin V10 x86_64 系统源包含基础包、更新包、附加包加起来动辄几十 GB具体取决于你启用了几个仓库。如果你只同步 os 和 updates 两个大概 15 到 30 GB如果连 addons、SP 补丁包一起拉50 GB 都不一定够。空间没算够下到一半磁盘满了前面下的全白费。第二个是网络稳定性。整源同步是个长时间任务几个 GB 甚至几十 GB 的数据要连续传输中间断一次就可能要重来。同步前最好确认目标机器到源服务器的网络通畅别在同步过程中还要去处理网络抖动。第三个是版本对应。Kylin V10 有 SP1、SP2、SP3 等多个版本不同版本的仓库地址和包内容不一样。你得先确认自己的机器是哪个 SP 版本再决定同步哪个源不然会出现本地源里的包和系统版本对不上装上去依赖冲突的情况。2. 环境核查把版本、架构和当前仓库摸清楚2.1 用两条命令双重确认系统版本麒麟有个自己的版本查看命令叫nkvers这个命令在别的发行版上没有输出信息比os-release更贴合麒麟的命名习惯。实际操作里我习惯两条都跑一遍交叉确认cat /etc/os-release nkvers uname -mos-release里重点看VERSION和VERSION_ID两行会标明类似 Kylin Linux Advanced Server release V10 (Lance) 这样的信息。nkvers会更详细地列出内核、SP 版本号。uname -m返回x86_64就说明架构没问题如果是aarch64那就得换 ARM 的源整篇的操作思路一样但仓库 ID 不同。为什么要这么较真因为麒麟的 SP 版本更新频繁SP1 和 SP3 的包里有些组件版本差异很大如果你拿 SP1 的源给 SP3 的机器用某些库的依赖会解不开。确认清楚版本后面的同步目标才有意义。2.2 列出当前启用的仓库并记录仓库 IDyum repolist -v这个命令会输出每个仓库的 ID、名称、包数量、baseurl。把里面 Repo-id 那一列记下来这就是你 reposync 时要用的-r值。同时看一眼 Repo-status 是不是 enabled如果某个仓库是 disabled 状态reposync 默认也同步不了它需要加--enablerepo显式打开。如果你想搞明白 baseurl 具体指向哪里可以打开仓库文件直接看cat /etc/yum.repos.d/kylin_x86_64.repo重点关注 baseurl 里的路径结构。这个路径决定了 reposync 下载下来的目录层级后面配置本地源时 baseurl 要指向 repodata 所在的目录路径错了本地源就识别不到。我见过有人把本地源 baseurl 写成file:///data/repo/但实际包的元数据在file:///data/repo/ks10-adv-os/差一层目录结果yum makecache一直报 Cannot find a valid baseurl。2.3 空间预算别等磁盘满了才后悔在真正开跑之前先做个空间估算。有两个办法第一个是看yum repolist -v输出里的 Repo-size 字段它会给出每个仓库里包的总体积估算。虽然不一定百分百准但作为参考足够。第二个是去看源的repodata目录里面有primary.xml.gz之类的元数据文件解压后能算出总大小不过这个操作略麻烦一般人用第一个办法就够了。我给个经验参考值仓库类型大致体积x86_64说明os基础包8 - 15 GB系统核心包必下updates更新包5 - 20 GB随补丁累积增长addons附加包1 - 5 GB视业务需要全部启用仓库合计30 - 60 GB留足空间保险记住同步过程中除了包本身还要预留一部分空间给临时文件所以建议最终目录所在分区至少留出估算体积的 1.3 倍。图省事的做法是直接挂一个大盘到/data所有离线源都往那儿放。df -h /data看 Avail 那一列心里有数了再继续。3. 工具链准备reposync 与 createrepo 从哪来3.1 reposync 的归属yum-utils 还是 dnf-plugins-core这是第一个容易迷糊的地方。reposync 不是一个独立命令它属于插件包。在比较老的系统上它在yum-utils里在较新的 dnf 体系里它在dnf-plugins-core里。Kylin V10 用的是 dnf 作为底层yum 是它的兼容命令所以实际操作里我更倾向直接用 dnf 来装dnf install -y dnf-plugins-core createrepo装完之后验证一下命令是否可用reposync --help createrepo --help如果reposync --help能正常输出参数列表说明装好了。这里有个小细节dnf 版本和 yum-utils 版本的 reposync 参数不完全一样比如 dnf reposync 支持--download-metadata而某些老版本的 yum reposync 用-m、--downloadcomps。所以看清楚--help的输出以本机实际支持的参数为准别照搬网上旧教程的参数。注意如果两个包的版本对不上比如用 yum 装了老的 yum-utils又用 dnf 装了 dnf-plugins-core可能出现 reposync 命令冲突或行为不一致。建议统一用一个包管理器安装别混着来。3.2 安装过程中可能遇到的依赖问题正常情况下dnf install dnf-plugins-core createrepo一把过。但如果你的机器本身还没有配好可用的源这一步就会失败报 没有可用的软件包 之类的错误。这时候得先确认外网源能连通yum repolist yum makecache curl -I 你的源baseurlcurl能返回 200 就说明网络到源服务器没问题makecache成功就说明元数据能拉下来。如果这两步都过不了那问题出在网络或源配置先把这关过了再谈同步整源。还有一种情况是 gpgcheck 导致的失败。有些环境的源开了签名校验而本机没有对应的公钥安装插件包时会报签名验证不通过。临时解决是加--nogpgcheck但这是权宜之计正规做法是导入正确的 GPG 公钥。3.3 用 --help 先摸清参数支持情况这一步看着多余实则能省很多时间。因为不同版本的 reposync 参数差异实实在在存在比如参数名、缩写、是否支持并行下载都可能不一样。我一般会重点确认这几个参数有没有-p/--download-path指定下载根目录这个必须有。-r/--repoid指定仓库 ID多仓库可以写多个。-n/--newest-only只下最新版本避免存一堆老包。--download-metadata是否下载元数据决定你后面要不要重新 createrepo。--norepopath控制是否把仓库名作为子目录这个参数坑过一次后面细说。把本机--help输出过一遍对参数心里有底写命令的时候就不会瞎猜。4. 用 reposync 把整个 Yum 源拉到本地目录4.1 从单仓库到多仓库命令的层层拆解先建好目标目录别指望 reposync 帮你全自动创建多层目录mkdir -p /data/kylin-repo最小可用的单仓库同步命令长这样reposync -r ks10-adv-os -p /data/kylin-repo/这条命令的意思是把ks10-adv-os这个仓库的所有包下载到/data/kylin-repo/目录下并且会在里面自动建一个以仓库 ID 命名的子目录也就是/data/kylin-repo/ks10-adv-os/。这个自动建子目录的行为就是--norepopath要控制的东西默认是带仓库名子目录的。如果你要一次性同步多个仓库-r可以写多个reposync -r ks10-adv-os -r ks10-adv-updates -p /data/kylin-repo/这样会在/data/kylin-repo/下生成ks10-adv-os和ks10-adv-updates两个子目录各自独立。这种目录结构最清晰后面配本地源时一个仓库对应一个 baseurl管理起来方便。4.2 关键参数逐个讲清楚为什么这么用光给命令不解释等于没讲。逐个拆-p /data/kylin-repo/指定下载路径。选这个路径有两个考虑一是空间够大二是路径深、容易被记住和备份。千万别选/root或者/tmp前者的系统盘往往空间有限后者重启就可能被清空几十 GB 的包丢一次能让人捶胸。-nnewest-only这个参数要不要加取决于你的用途。如果本地源只是给系统打补丁、装应用用那加上-n只保留每个包的最新版本就够了能省下大量空间一个仓库可能从 20 GB 降到 8 GB。但如果你需要在本地源里保留历史版本比如回滚用那就别加。我一般正式环境不加测试环境加看情况。--download-metadata表示连仓库的元数据一起下。这个和后面要不要 createrepo 直接相关如果你用了这个参数下载下来的repodata目录可能是现成的理论上可以直接当源用但为了稳妥实践里我还是习惯重新 createrepo 一次避免元数据和实际下载的包不匹配因为-n会剔掉老包但元数据里还记着那些老包。-a x86_64显式指定架构。虽然本机是 x86_64 时默认就对了但显式写出来更安全尤其在脚本里避免误跑到别的架构机器上。我的常用组合是reposync -r ks10-adv-os -p /data/kylin-repo/ -n --download-metadata4.3 断点续传与失败重试的处理思路reposync 本身对已下载的文件有断点续传能力——再次执行时已经下好且完整的包会被跳过只下缺的。这个特性非常有用意味着中途断了不用慌重新跑一遍就行。但要注意一个坑如果某个包上次下载到一半被中断留下了一个不完整的.rpm文件reposync 再次运行时可能因为文件已存在就跳过了结果你带着一个损坏的包进了本地源装的时候报校验失败。稳妥的做法是每次重跑前检查一下有没有零字节或者体积明显偏小的 rpm 文件find /data/kylin-repo -name *.rpm -size -1k把这类可疑文件删掉再重跑。养成这个习惯能避免很多莫名其妙装不上的问题。对于网络超时导致的失败可以结合timeout命令和循环重试来加固或者写个简单的重试脚本for i in 1 2 3; do reposync -r ks10-adv-os -p /data/kylin-repo/ -n --download-metadata break echo 第 $i 次失败10 秒后重试 sleep 10 done4.4 大仓库同步到底要多久怎么提速整源同步的耗时不光看包多大更看源服务器的限速和网络带宽。实测下来如果是从官方源直接拉速度可能被限制在几百 KB 到几 MB 每秒一个 20 GB 的仓库可能要跑好几个小时甚至一整晚。这时候有几个提速思路第一换更近的镜像源。很多第三方镜像站清华、阿里等对麒麟或者兼容的 RPM 源有加速速度能比官方源快不少。注意只有仓库内容和你要的麒麟版本兼容时才能用别乱换导致包版本错乱。第二多个仓库并行拉。因为单个 reposync 进程基本是串行的你可以开多个终端每个 terminal 同步一个仓库虽然还是共享带宽但对源服务器来说并发连接有时反而能提升总吞吐。第三避开高峰期。白天源服务器负载高晚上速度往往更稳。这种活儿安排在夜里跑最合适一觉醒来就同步完了。提示可以用nohup或者screen/tmux把同步任务放到后台避免 SSH 断开导致任务中断。nohup reposync ... sync.log 21 是个常用写法日志留下来还能事后排查。5. 下完包还不算完用 createrepo 生成可用元数据5.1 为什么光有 rpm 文件不能当源用很多人第一次做完这一步会懵明明包都下下来了为什么配置本地源还是报 Cannot find a valid baseurl原因在于 yum/dnf 通过repodata目录里的元数据文件来索引包元数据里记录了每个包的名称、版本、依赖、校验值。你只把.rpm文件拷过来没有元数据包管理器根本看不见这些包。所以下完包后生成元数据是必须的一步。即使前面用了--download-metadata带下了原始元数据我也建议重新生成一次。因为如果你用了-n只下最新版或者中途手动删过包原始元数据里记的包和磁盘上实际存在的包就对不上了装包时会报 包在元数据里存在但文件找不到。重新生成元数据能让索引和实际文件严格一致。5.2 createrepo 命令与生成结果验证对每个仓库目录单独执行createrepo -v /data/kylin-repo/ks10-adv-os/ createrepo -v /data/kylin-repo/ks10-adv-updates/-v是 verbose输出详细信息能看到它扫描了多少个包。执行完之后检查目录ls /data/kylin-repo/ks10-adv-os/repodata/里面应该会出现repomd.xml、primary.xml.gz、filelists.xml.gz等文件。其中repomd.xml是入口文件本地源配置正确的话包管理器第一个找的就是它。生成过程中如果报了包校验相关的 warning比如某个包缺少某些标签通常不影响使用但如果有 error 就要留意可能是那个 rpm 文件损坏了需要删掉重下。5.3 用 --update 做增量刷新第一次全量生成后以后每次往目录里加新包不需要重新全量生成用--update只更新变化的部分就行createrepo --update -v /data/kylin-repo/ks10-adv-os/这个在增量维护场景里很有用。比如你定期往本地源里补几个新包用--update几秒钟就刷新完了比全量重建快得多。但要注意--update只处理新增和变更的包如果你删除了包得用--update配合其他处理或干脆全量重建否则元数据里还留着被删包的记录。这也是为什么我更推荐每次同步完就重建元数据的简单策略图的就是省心。6. 把本地目录变成真正可用的源配置与强制校验6.1 新建本地 repo 文件的完整内容在/etc/yum.repos.d/下新建一个kylin-local.repo内容如下[kylin-local-os] nameKylin Local OS baseurlfile:///data/kylin-repo/ks10-adv-os/ enabled1 gpgcheck0 [kylin-local-updates] nameKylin Local Updates baseurlfile:///data/kylin-repo/ks10-adv-updates/ enabled1 gpgcheck0几个关键点baseurl用的是file://协议加绝对路径指向的就是包含repodata的那一层目录路径末尾的斜杠别漏。gpgcheck0是关掉签名校验因为本地源里的包签名不一定齐全临时关掉省事如果安全要求高可以gpgcheck1并配置好gpgkey但前提是你有正确的公钥。注意本地源用file://协议时一定要确认路径拼写完全正确多一层少一层都会导致 Cannot find a valid baseurl 报错。用ls命令一层层核对过去最保险。6.2 禁用外网源避免混用踩坑配置本地源的目的是离线使用如果外网源还开着机器在联网时会优先走外网源或者两个源的包版本打架。所以稳妥做法是把外网源禁用掉yum-config-manager --disable ks10-adv-os ks10-adv-updates或者直接在原来的 repo 文件里把enabled1改成enabled0。也可以临时用参数控制yum --disablerepo* --enablerepokylin-local-* install 包名但每次都加这么一长串参数太麻烦长期用还是改配置文件干净。我个人偏好在离线环境里把所有外网源都设成 disabled只留本地源这样机器一旦接入任何网络也不会意外从外网拉包。6.3 yum clean all 加 makecache 验证改完配置后必须清缓存再加缓存否则 yum 用的还是旧缓存yum clean all yum makecache yum repolistyum makecache成功且不报错yum repolist里能看到你新配的本地源并且有包数量就算搭好了。如果makecache报错多半是 baseurl 路径问题或者元数据没生成好回头检查repodata目录是否存在、repomd.xml是否正常。6.4 拔网线测试证明本地源真能用最后一步是我强烈建议做的——把网卡断开模拟真实离线环境然后装一个之前没装过的包yum install -y sl如果这个命令能成功从kylin-local-*源装包说明整套链路没问题。如果报错说明你还有残留的外网依赖可能是某些包依赖的库只在旧的外网源里需要把对应仓库也同步到本地。这一步能提前暴露问题别等到真进内网了才发现装不上。7. 踩坑实录几个让我重新同步一整晚的问题7.1 磁盘 inode 耗尽导致下载中断这个问题特别隐蔽。一个源里有成千上万个 rpm 小文件有时磁盘容量还剩不少但 inode 已经用光了表现出来就是突然写不进文件、下载中断、甚至已经下好的文件也出问题。排查用df -i /data如果IUse%接近 100%就是 inode 问题。解决办法是换一个 inode 数量更充足的文件系统或者在创建时用更大的 inode 比例。这个坑我踩过一次下了一整晚的包第二天早上一半文件是空的重装文件系统才解决。7.2 源地址中间件限速与超时有些企业内网会在出网口做流量控制或者源服务器本身有单连接限速。表现是 reposync 跑得极慢或者频繁超时断开。遇到这种情况一是可以调大超时时间二是问清楚网络策略看有没有更合适的镜像源。有一回我从官方源拉速度只有几十 KB 每秒换成离得近的镜像站后速度翻了几十倍。7.3 元数据和 rpm 不匹配的诡异报错现象是包明明在目录里yum install却说找不到或者报包损坏。根因通常是元数据是先前的状态而目录里的 rpm 后来被手动增删过。解决就是重新createrepo让元数据和实际文件对齐。这也是我强调下完包一定重新生成元数据的原因。7.4 --norepopath 用错了导致目录嵌套--norepopath这个参数控制是否把仓库名作为子目录。默认不加时reposync 会建/data/kylin-repo/ks10-adv-os/加了之后包会直接下到/data/kylin-repo/里面不带仓库名。如果你同时同步多个仓库又加了这个参数不同仓库的包会混在同一个目录里元数据也会互相覆盖最后整个目录一团糟。所以多仓库场景千万别用--norepopath让它老老实实按仓库名分开目录。报错/现象可能根因处理方式Cannot find a valid baseurlbaseurl 路径错或 repodata 缺失逐层核对路径重新 createrepo磁盘写满但容量显示还有空间inode 耗尽df -i检查换文件系统包存在却提示找不到元数据与文件不一致重新生成元数据下载极慢或中断源限速/网络抖动换镜像源加后台重试多仓库包混在一起误用 --norepopath去掉该参数按仓库分目录8. 打包分发与增量维护把本地源变成长期资产8.1 打包带走并保留权限本地源做好之后如果是要交给内网机器使用通常需要打包。用 tar 打包时记得保留权限和属主信息cd /data tar -cvpf kylin-repo.tar kylin-repo/-p保留权限-v显示进度-f指定输出文件。几十 GB 的包打 tar 很慢可以考虑分卷或者只打包必要仓库。带到内网机器后解压到相同路径tar -xvpf kylin-repo.tar -C /data/解压后本地源文件里的 baseurl 路径要和实际解压路径一致否则又要改配置。所以我在做源的时候就固定用/data/kylin-repo/这个路径到处解压都不变。8.2 定期增量同步的脚本化思路本地源不是一劳永逸的官方源会更新你也需要定期同步新包。把这套流程脚本化每月跑一次#!/bin/bash set -e REPOSks10-adv-os ks10-adv-updates ROOT/data/kylin-repo for r in $REPOS; do reposync -r $r -p $ROOT/ -n --download-metadata createrepo --update -v $ROOT/$r/ done yum clean all yum makecacheset -e保证任何一步出错就停止避免带着错误继续。因为用了-n和--update增量同步只处理新包速度快适合定期跑。日志重定向到文件方便事后看./sync-repo.sh /var/log/repo-sync-$(date %F).log 218.3 系统升级后源的迁移注意事项如果内网机器的麒麟从 SP1 升级到 SP3原来的本地源不一定还能用因为系统期望的包版本变了。这时候要重新在能连外网的对应版本机器上同步 SP3 的源替换掉旧的。迁移时注意几点一是仓库 ID 可能变了本地 repo 文件的 baseurl 要跟着改二是旧源的元数据要清理别和新源混着三是升级前最好做一次快照或备份万一出问题能回退。我个人的习惯是给每个 SP 版本建独立的目录比如/data/kylin-repo/sp3/不同版本互不干扰升级时只切换本地 repo 文件指向即可旧源留着还能给还没升级的机器用。这样管理起来清爽也不会因为一次误操作把整套源搞坏。8.4 顺手留个校验习惯最后分享一个我形成习惯的小动作每次同步完除了yum makecache我还会随手装一个平时不太用的小包比如前面提到的sl验证一下。这个动作花不了几秒钟但能在源出问题的第一时间就发现比等到生产环境要装关键组件时才发现本地源是坏的代价小得多。yum --disablerepo* --enablerepokylin-local-* install -y sl能装上就说明本地源健康。这套流程我从最早的 CentOS 本地源一路用到麒麟 V10核心逻辑没变过——把远程源完整搬到本地、生成元数据、配好 file 协议、断开外网验证。真正花时间的从来不是命令本身而是空间预算、网络稳定性和那些看起来不起眼的路径细节。把这几条牢牢记住下次再遇到Kylin v10 整源同步到本地这种活儿你基本可以闭着眼睛干完。