银河麒麟系统软件源配置实战:在线源、离线本地源与依赖管理
1. 银河麒麟系统为什么一上来就要配源软件源的概念与版本认知刚装好银河麒麟系统第一件事往往不是装软件而是发现装不了任何东西。执行apt install nginx或yum install时报错、卡住、或者提示找不到软件包这种情况我碰到的频率非常高。原因几乎都一样系统默认的软件源地址指向的是安装包厂商的官方源但要么服务器在国外导致连接极慢要么源地址已经变更、停用要么压根就没配置源文件。软件源Repository可以理解为系统的应用商店索引。系统通过源配置文件中记录的地址去下载软件包及其依赖的元数据然后才能安装、升级、卸载软件。银河麒麟沿用了 Linux 生态的两大包管理体系基于 Debian 的桌面系统Kylin Desktop使用 APT和基于 Red Hat 的服务器系统Kylin Server使用 YUM/DNF。配置源的第一件事就是搞清楚你手里这台机器到底是哪一套体系——这决定了后面所有操作的路径。判断方法很简单桌面版V10 桌面版、V11 桌面版执行cat /etc/os-release能看到IDukui或者IDubuntu之类的信息包管理是apt。服务器版V10 SP1、SP2、V11 服务器版等通常能看到ID: kylin包管理是yum或dnf。两者的源配置方式、仓库文件格式、更新命令完全不同。我见过不少人拿 yum 的命令去跑 apt 的环境自然什么都装不上。所以下面我按两套体系分别讲配置。另一个需要注意的点不同版本V10、V10 SP1、V11对应的官方源地址和服务生命周期有所不同。V10 的老版本在 2024 年之后部分源地址已经失效需要在官方迁移页面确认可用地址或者直接切换到镜像源、本地源。2. 在线软件源配置实战备份、修改、验证三步走2.1 APT 系桌面环境配置在线源在 Kylin Desktop V10 的/etc/apt/sources.list文件也可能在/etc/apt/sources.list.d/目录下中默认配置的是archive.kylinos.cn等官方地址。如果发现apt update卡住或 404我的做法是先备份原文件然后替换为官方已更新且能访问的地址。操作步骤备份原配置sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak编辑源文件sudo vim /etc/apt/sources.list对于 Kylin Desktop V10 桌面版一个典型可用的源配置格式如下deb http://archive.kylinos.cn/kylin/KYLIN-ALL 10.1 main restricted universe multiverse需要说明的是银河麒麟 V10 官方源的具体路径和版本号会根据你拿到的授权版本有所不同实际以官网交付文档为准。我在这里给出的是通用的配置思路——把源文件中deb开头的行的地址替换为可访问的官方地址或者镜像地址然后保存。执行更新sudo apt update如果输出的列表中不再出现Err或404说明源已经生效。apt update是刷新软件包索引不是真正升级系统。刷新的过程会把源里所有软件包的版本信息下载到本地缓存之后执行apt install 软件名就能正常解析并安装。2.2 YUM/DNF 系服务器环境配置在线源Kylin Server V10 的 yum 源配置文件位于/etc/yum.repos.d/目录下我用ls /etc/yum.repos.d/查看通常能看到kylin_x86_64.repo或kylin-aarch64.repo之类的文件。配置方式与 CentOS 系完全一致备份原 repo 文件sudo cp /etc/yum.repos.d/kylin_x86_64.repo /etc/yum.repos.d/kylin_x86_64.repo.bak编辑 repo 文件确保存在类似下面的配置段[kylin] namekylin baseurlhttp://archive.kylinos.cn/kylin/KYLIN-SERVER/ enabled1 gpgcheck0清理缓存并重建sudo yum clean all sudo yum makecacheyum makecache的目的和apt update一样就是下载仓库元数据。看到 Metadata cache created 就说明源配置成功。值得注意的细节服务器版的架构分为 x86_64 和 aarch64 两种repo 文件中的 baseurl 一定要跟系统架构匹配。在高版本系统中也可以优先用dnf兼容 yum 的配置。2.3 在线源配置失败的常见原因在线源配置本身不难难的是排查为什么地址对不上。以我处理过的现场经验多半是这几种情况第一系统大版本更新后源路径从KYLIN-SERVER-10-SP1迁移到了KYLIN-SERVER-10-SP2但 repo 文件还保留旧路径自然 404。解决办法很简单对照官方迁移说明把 baseurl 里的版本号改掉。第二gpgcheck1但本机没有导入对应的 GPG 公钥。表现为执行yum makecache时出现public key not available的报错。解决办法是用rpm --import导入源里的公钥文件或者直接在安全的内网环境把gpgcheck0。第三DNS 解析正常但网络策略禁止访问外网。这个是内网服务器最常见的情况此时在线源怎么配都没用直接进入下一节讲的本地源方案。3. 离线环境下的本地源配置挂载镜像、制作本地仓库很多军工、政务、金融现场服务器是纯内网环境不允许访问外网。这时候在线源完全失效配置本地源就成了唯一可行方案。本地源的思路很简单把银河麒麟的完整安装镜像ISO 文件挂载到系统里把 ISO 内的软件包目录作为源地址。3.1 APT 系的本地源配置场景Kylin Desktop V10 桌面版没有外网需要安装离线软件包。步骤将系统安装 ISO 上传到服务器比如/data/kylin-iso/目录下。挂载 ISOsudo mkdir -p /mnt/kylin sudo mount -o loop /data/kylin-iso/kylin-desktop-v10.iso /mnt/kylin挂载后/mnt/kylin下通常有pool目录里面是按字母排序的 deb 软件包。新增本地源配置echo deb file:///mnt/kylin/ stable main | sudo tee /etc/apt/sources.list.d/local-iso.list注意上面的 stable main 占位符只是示例实际要用 ISO 内 dists 目录下实际存在的版本名比如 10.1 main具体以你手里镜像内容为准。更新索引sudo apt update到这里apt install就能从 ISO 本地源安装大部分基础软件了。不过有个明显的限制ISO 里的软件包版本发布较早而且只包含官方随镜像附带的软件想安装某个 ISO 上没有的新版本软件就得用 3.3 节的方法自制软件包仓库。3.2 YUM 系的本地源配置Kylin Server 的 ISO 挂载后/mnt/kylin下会有一个Packages或repodata目录里面全是 rpm 包和仓库元数据。配置成 yum 源只需要两步新建本地 repo 文件/etc/yum.repos.d/local.repo[local-kylin] namelocal-kylin baseurlfile:///mnt/kylin enabled1 gpgcheck0清理缓存并重建sudo yum clean all sudo yum makecache观察执行结果能联想到baseurlfile:///mnt/kylin指向的是包含repodata的目录路径如果你把 ISO 内容拷贝到了别的路径baseurl也要跟着改。这里我强烈建议每台离线服务器的系统版本必须和 ISO 镜像版本一致。如果你用 V10 SP1 的 ISO 给 V10 SP2 的系统当源由于 rpm 包的依赖版本不对大概率会碰到依赖冲突到时候yum install会告诉你需要降级或升级一堆包非常痛苦。3.3 自制离线软件包仓库离线源扩展方案ISO 自带的软件包终究有限。当现场需要批量安装 nginx、Python 依赖库、数据库客户端等 ISO 里没有的软件包你可以在一台能联网的同版本系统上提前下载好需要的 rpm/deb 包再拷贝进离线环境构建自定义仓库。以 yum 系为例在联网机器上只下载不安装sudo yum install --downloadonly --downloaddir/data/nginx yum-utilssudo yumdownloader --resolve nginx将/data/nginx目录里的所有 rpm 拷贝到离线机器放入/data/local-repo/。创建本地仓库索引需要createrepo工具sudo yum install createreposudo createrepo /data/local-repo在/etc/yum.repos.d/下新建本地源baseurl 指向上面目录。yum clean all yum makecache然后yum install nginx。apt 系的做法类似只是用的工具是apt-get download加dpkg-scanpackages。这个方法配置出的自定义离线源几乎能覆盖 90% 的现场离线安装需求比一个个 rpm 包手动装靠谱得多——自动解决依赖是源存在的根本意义。4. 软件源应用实操安装命令对比与离线安装 nginx 完整过程配置好源之后安装软件就回到日常 Linux 操作了但银河麒麟下有几个容易记混的点需要特别说明。4.1 apt 与 yum 常用安装命令对照操作APT 系桌面YUM/DNF 系服务器搜索软件包apt search 关键字yum search 关键字安装软件apt install 软件名yum install 软件名卸载软件apt remove 软件名yum remove 软件名升级所有包apt upgradeyum update查看已安装apt list --installedyum list installed一个常见的困惑是银河麒麟桌面版能不能用 yum答案是不能。桌面版基于 Debian 生态强行执行 yum 只会得到 command not found除非你自己移植了 RPM 包管理器但那是给自己挖坑不推荐。服务器版能不能用 apt也分情况。Kylin Server V10 是基于 RPM 的体系默认没有 apt。但部分新版 Kylin Server V10 SP3 之后引入了双包管理支持可以apt和yum共存。到底支不支持用which apt和which yum验证一下最可靠。4.2 离线安装 nginx 的完整链路以服务器版为例把 nginx 在离线环境中装起来完整过程可以拆成四条路径路径一ISO 本地源直接安装。先执行yum list | grep nginx查一下本地源里有没有 nginx 包。如果镜像版本较老可能没有这个包此时走路径二。路径二自制 rpm 仓库。在联网机器上执行yumdownloader --resolve nginx把 nginx 及其所有依赖比如 openssl、pcre、zlib 的相关库都拉到本机然后拷贝到离线环境用 3.3 节的方法做成本地源再yum install nginx。这个方式能处理的依赖链比较完整是生产环境的首选。路径三手动 rpm 安装。把下载到的 rpm 直接rpm -ivh nginx*.rpm如果系统里缺依赖会报Requires:错误。这时再去找对应的依赖包手动装反复尝试适合软件很少的情况。路径四编译安装。用源码包./configure make make install依赖自行解决灵活性最高但升级和卸载维护成本也高。如果只是为了跑一个 nginx 服务我更推荐前三种因为在源体系覆盖下的软件包后续用yum update就能升级而编译安装的升级全靠手工。4.3 源更新与软件安装的依赖自动处理很多初学者不敢用源安装怕污染系统宁可用rpm -ivh手动装。实测下来源的最大价值其实就在依赖解析上——系统会从所有已配置源中找到依赖包自动下载按顺序安装。以 nginx 为例yum install nginx会自动带上nginx-filesystem、nginx-mimetypes等子包以及libgd、openssl11等动态库依赖整个过程一条命令结束。这在手动安装场景下可能要折腾半小时以上。这也是我为什么一直强调配源是银河麒麟系统运维的底层能力。源配好了装软件、升级补丁、查依赖全部从手工劳动变成一条命令的事。5. 配置源软件安装后最容易踩的坑依赖冲突、仓库缓存与版本锁定配置源只是开始日常运维中那些让人头疼的报错几乎都集中在依赖、缓存、版本三个方向。5.1 依赖冲突与降级报错现象执行yum install 某个软件时提示Error: Package: xxx-1.0-1.el7.x86_64 requires: libxxx.so.1()(64bit)或者提示与已安装的依赖冲突。这种报错我通常按三步排查先看是不是多套源混用。如果系统里同时启用了本地 ISO 源、自制仓库源、在线源不同源里同一软件包的版本可能不同yum 在解析时就会打起来。解决方式yum repolist all查看所有启用的仓库保留必须的那几个其他的用enabled0关掉。再查已安装包版本是否过高。比如已装了高版本 libssl而待装软件需要低版本就会冲突。此时要看能不能升级那个待装软件本身而不是强行降级系统库。最后才是考虑yum downgrade或者加--allowerasing这类隐含破坏性的参数。这两个参数会直接移除或替换冲突的包谨慎使用。5.2 仓库缓存损坏与 makecache 反复失败现象yum makecache执行到一半报Error: Cannot retrieve repository metadata明明源地址能访问。常见原因有两个。一个是本机 DNS 解析正常但源服务器中断导致元数据文件不完整另一个是同步软件包时非正常断电本地的/var/cache/yum缓存目录出现了损坏的元数据文件。解决办法先yum clean all清空本地缓存再yum makecache重建。如果还不行把 repo 文件里的 baseurl 临时指向能访问的镜像地址重试一次。对于 apt 系则执行apt clean后再次apt update。5.3 版本锁定与意外升级生产环境最怕的不是装不上软件而是某天执行yum update把系统里的关键包全都升了一遍结果原本稳定的服务挂了。银河麒麟系统做补丁升级时同样存在这个问题。在源配置完成后我建议对生产环境做两件事用yum versionlock 软件名或用yum-plugin-versionlock插件锁定关键包的版本防止误升级。日常只做安全补丁更新而不是全量yum update。具体到命令yum update --security只升级存在安全公告的软件包。这套锁版本 按需升级的做法能大幅降低因为源更新引起的生产事故。毕竟源机制的初衷是让系统更好维护而不是让人提心吊胆。6. 与配源一起被搜索的高频运维问题密码重置、权限修复、home 目录异常从一线搜索行为也能看出来大家配完源后紧接着遇到的问题往往不完全在源本身而是围绕系统权限和使用体验展开。我把高频问题集中梳理一遍这些问题和源配置的环境背景是强关联的——大多数出现在刚装好的新系统或刚完成离线补丁的机器上。6.1 普通用户密码修改与 root 密码重置普通用户改密码最简单的方式是 root 账号执行passwd 用户名。如果忘记的是 root 密码方法跟大多数 Linux 发行版类似重启系统在 GRUB 菜单界面按e进入编辑模式。找到linux开头的启动行在末尾追加rd.breakRHEL 系或singleDebian 系。按CtrlX启动进入紧急模式挂载根文件系统为可写mount -o remount,rw /sysrootchroot 后执行passwd root重置密码。这里有个细节需要注意银河麒麟桌面版和服务器版的 GRUB 配置不完全一样进入单用户模式的参数后缀也不同。改之前最好先确认一下当前系统是 Debian 系还是 Red Hat 系。如果你是在离线环境里做这个操作别指望系统里有passwd之外的工具chroot /sysroot之后直接敲通配符即可。6.2 chmod 777 误用与权限修复很多人为了省事直接chmod 777某个文件或目录结果导致系统服务起不来或者安全告警。实际上 chmod 777 的隐患已经被安全部门反复强调过尤其涉及配置文件和脚本文件时过于宽松的权限会让攻击者有机会改写关键文件。如果已经误操作导致服务异常第一优先是恢复原有属性和权限。ls -l查看当前状态再用chmod 644 文件名普通文件或chmod 755 目录名/脚本名可执行文件恢复最常见的安全权限。如果是系统文件被改坏了可以通过重新安装对应软件包来恢复比如yum reinstall 软件包名或apt install --reinstall 软件包名这个操作的前提就是配置好的软件源仍然可用——又绕回到源的可靠性上了。6.3 home 目录无法显示文件与磁盘挂载问题这个问题在银河麒麟桌面版上非常典型登录后用户主目录下什么都没有用ls /home/用户名却是正常的或者资料盘挂载在/data下登录后却不在桌面显示。出现这个现象的原因通常是/etc/fstab里配置的挂载点没有正确挂载或者普通用户对挂载目录没有访问权限。排查步骤执行df -h查看磁盘挂载情况重点看用户主目录和自定义数据盘是否成功挂载。如果发现数据盘没有挂载执行mount -a读取/etc/fstab重新挂载并把挂载项的权限和 owner 设置正确。如果用户主目录的 ACL 被误删用setfacl -R -m u:用户名:rwx /home/用户名重建访问控制规则。另外要提醒的是银河麒麟桌面版的文件管理器基于 UKUI偶尔会因为配置缓存损坏导致目录不刷新。处理方式是把/home/用户名/.local/share/Trash下的缓存清掉或者重启ukui-panel进程通常能恢复显示。6.4 国产化环境下的 SSH 升级与虚拟化部署在信创现场经常要求对系统进行安全加固SSH 升级就是高频操作之一。SSH 已经从 OpenSSH 7.x 升级到 9.x在银河麒麟上如果直接用源码包编译升级容易因为 PAM、SSL 版本不匹配导致 SSH 服务起不来。更稳妥的做法是通过源安装yum update openssh-server openssh-clients配置好源之后一条命令完成。如果必须编译升级务必保留旧 SSH 会话不断开并先编译好新版本再替换否则一旦编译失败或配置错误远程就再也连不上了。虚拟化部署方面银河麒麟 V10 上可以安装 KVM/QEMU 虚拟化依赖用源安装的包管理方式能自动拉齐qemu-kvm、libvirt、virt-manager等各组件的依赖比手动按顺序安装省太多事。比如你要在麒麟 V10 上装 Windows 虚拟机先把虚拟化源配好再yum install qemu-kvm libvirt virt-install创建虚拟机用virt-install --location指定镜像整个使用体验和其他主流 Linux 发行版基本一致。7. 配置源的正确心态源不是配一次就一劳永逸配置源这个操作表面上是个一次性工作实际上是需要定期维护的。我自己的维护节奏是每季度检查一次源地址是否还能正常访问尤其是离线环境里的本地源要确认挂载的 ISO 目录没有被误删或未重新挂载。每次系统大版本升级前先完整备份/etc/apt/sources.list和/etc/yum.repos.d/目录升级后逐一核对源配置是否需要更新地址。在关键业务服务器上禁用自动更新改为人工确认后手动执行避免源更新意外升级关键组件。最后讲一个小技巧如果你维护的机器比较多可以把配置源的命令和 repo 文件在你自己的部署脚本库里沉淀下来下次遇到同型号的系统直接执行脚本三分钟搞定。源配置本身不复杂复杂的是对系统版本的准确判断和对不同环境的适配能力。遇到任何源相关的报错第一步永远不是硬试而是先明确这台机器的包管理体系是 apt 还是 yum、系统版本是 V10 还是 V11、架构是 x86_64 还是 aarch64这三个条件确定之后剩下的就是照着文档搬答案了。
上一篇/下一篇内容由系统自动关联
返回资讯列表 →