【麒麟服务器系统交付：一个DBA的六年信创实战笔记】

前言：

这篇文章不是官方文档的搬运工。是我在某金融甲方现场，被麒麟V11的NetworkManager坑到SSH断连、被fstab写错导致系统起不来、被镜像架构不匹配白忙活一上午之后，一条条血泪教训攒出来的。如果你正在做信创交付，建议直接对照着检查，别重蹈我的覆辙。

---

一、镜像选择：先看授权书，再下镜像，顺序别搞反

第一次做麒麟交付的时候，我拿到授权书就直接找镜像下载。装完系统重启，黑屏。查了半天，发现客户服务器是飞腾2500（ARM64），我下的是兆芯版（x86_64）。这种低级错误一旦犯了，现场客户看着你重装系统的眼神，能让你记一辈子。

麒麟的镜像版本比你想象的复杂。V11采用新的版本号格式，比如V11 2503，每个版本按CPU架构分不同分支。但最关键的变化是底层：V10基于RHEL 7/8开发，V11改为基于openEuler 22.03 LTS开发。这不是简单换个底座，底层差异很大。

V10的包管理器是yum，V11改成了dnf（虽然yum兼容但底层不同）。V10的网络服务是network-scripts（ifcfg文件），V11全面转向NetworkManager（keyfile格式）。V10内核版本要分情况看：银河麒麟V10多个SP版本存在4.19和5.10两条主线，不能笼统说V10统一都是5.10.x。多数新项目SP3及以后主推5.10，但存量环境大量4.19内核。V11则统一升级到了6.6.x。systemd版本也从239左右升到了250左右。安全框架方面，V10是传统SELinux，V11在保留SELinux基础能力之上，扩展自研了KSAF（Kylin Security Architecture Framework）可编程安全框架，不是直接替代、移除SELinux。日常运维不能简单理解为"换掉SELinux"。

为什么这个差异重要？因为V10那套systemctl restart network的老办法，在V11上直接报错Unit network.service not found。openEuler默认不再提供network这个legacy服务，网络管理全面转向NetworkManager。如果你团队里还有同事按V10的习惯配网，SSH断连是大概率事件。

交付原则很简单：先看授权书确认系统版本号和CPU架构，再去找对应镜像。授权书上的版本必须和镜像版本精确匹配，不然激活的时候会出问题。不确定架构的话，lscpu看一下就清楚了。

CPU架构和镜像关键词对照：

• ARM64：飞腾2000+/2500、鲲鹏920，镜像关键词"飞腾/鲲鹏版（aarch64）"

• x86_64：兆芯、海光、Intel，镜像关键词"兆芯/海光版（x86_64）"

• LoongArch：龙芯3A5000/3C5000，镜像关键词"龙芯版（loongarch64）"

补丁更新：V11的dnf机制

V11的补丁机制和V10完全不同。V10靠upgrade-YYYYMMDD.sh这种离线补丁脚本，V11改为以dnf在线更新为主，每周官方推送安全补丁和Bug修复。

联网环境直接dnf在线更新（V11推荐方式）：

dnf check-update # 先看有哪些可用更新dnf update -y # 执行全量更新

离线环境从官网下载V11 2503对应架构的补丁包，解压后执行官方补丁脚本（脚本名按版本命名，非日期格式）：

sh kylin-patch-v11-2503.sh -c # 先巡检，看看有没有问题sh kylin-patch-v11-2503.sh -a # 确认后执行修复（不动内核）sh kylin-patch-v11-2503.sh -k # 如果需要修复内核，用这个参数

参数说明：

• -a：巡检并修复，不修复内核

• -k：巡检并修复，修复内核

• -c：只巡检不修复

• -r：检测rpmdb并临时修复

注意：V10时代的upgrade-20250207.sh这类日期命名脚本在V11上不再使用。V11的离线补丁包改成了kylin-patch-v11-版本号.sh的命名格式，下载时一定要对应你的V11小版本号（如2503），架构也要匹配。

我的习惯是先dnf check-update看一眼更新列表，确认有需要修复的安全补丁后再dnf update。生产环境对内核升级通常很谨慎，不轻易动内核是对的------内核一升级，很多驱动可能跟着出问题，尤其是第三方硬件驱动。

如果只是修安全漏洞又不想重启，V11还支持kylin-warm热补丁（后面内核升级那节会详细讲）。

V10原地升级：如果你的服务器还在跑V10，麒麟官方提供了kyupgrade原地升级工具，可以不重装系统、不丢业务数据，直接从V10升级到V11。升级前建议做好完整备份，升级过程中会自动处理包管理器从yum到dnf、网络服务从network到NetworkManager等底层变更。不过原地升级有风险，生产环境建议先在测试机上跑通流程再操作。

---

二、启动盘制作：工具选对省一半事

别以为做U盘启动盘是个简单活。我见过不少人用UltraISO直接写麒麟镜像，结果装机的时候报错引导失败，反复折腾半天。原因通常是UltraISO默认的写入方式跟麒麟的引导方式不兼容。

麒麟官方有推荐的启动盘制作工具，建议直接用官方的。如果你习惯用命令行，Linux下用dd也可以：

# 先确认U盘设备名（千万别搞错，搞错就写到系统盘了）lsblk # 用dd写入镜像（假设U盘是/dev/sdb）dd if=Kylin-Server-V11-2503-aarch64.iso of=/dev/sdb bs=4M status=progress # 写完后同步一下sync

注意：dd命令的of参数一定要确认是U盘！写错盘的话数据全没。写之前用lsblk反复确认设备名。

另外有几个细节要注意：U盘容量至少8G以上，有些大版本的镜像加上补丁包可能接近8G。部分服务器对U盘引导兼容性不好，尤其是国产化服务器，建议准备两根不同品牌的U盘备用，别在现场因为一根U盘不识别干等着。

还有个常见坑：有些服务器的BIOS默认开启了Secure Boot，麒麟的某些版本引导签名不被认可，导致U盘引导进去后黑屏。遇到这种情况进BIOS把Secure Boot关掉就行。

---

三、系统安装：分区才是真正的重头戏

装系统本身不难，图形化安装界面跟着走就行。但分区方案才是决定后续系统管理顺不顺心的关键。麒麟建议最少8G内存、30GB磁盘空间，但实际生产环境这点空间远远不够。

推荐分区方案

• /boot：1GB，ext4，引导分区，必须独立

• /boot/efi：512MB，vfat，UEFI引导用，Legacy BIOS不需要

• /：50-100GB，ext4，根分区，系统软件包都在这

• swap：物理内存的1-2倍，swap，交换分区

• /data：剩余空间，xfs，数据分区，按业务需求分

• /tmp：5-10GB，ext4，可选，隔离临时文件

几个关键决策点：

第一，务必手动分区。如果服务器上还有其他系统或数据分区要保留，千万别选自动分区。我见过有人选了自动分区，结果整盘数据被覆盖，客户的业务数据全没了，那个锅背得真叫一个惨。

第二，文件系统选择。麒麟默认支持ext4和xfs。我的建议是根分区用ext4（兼容性好，出问题好修复），数据分区用xfs（大文件性能优，支持在线扩容）。V11基于6.6内核，还新增了bcachefs支持------这个文件系统自带透明压缩和纠错功能，对数据库场景的存储优化有潜力，但目前生态还不够成熟，生产环境建议先观望。

第三，UEFI还是Legacy BIOS？现在的新服务器基本都是UEFI模式，安装时如果出现/boot/efi分区选项，说明当前是UEFI模式，必须分这个分区，不然装完引导不起来。

第四，LVM还是标准分区？生产环境我强烈建议用LVM。虽然标准分区性能略好（差距极小），但LVM的弹性扩容能力在后期管理中价值巨大。想象一下：业务跑了半年，根分区快满了，标准分区你只能干瞪眼，LVM的话加块盘三条命令搞定。

LVM分区实操与底层原理

LVM的核心逻辑是三层抽象：PV（Physical Volume，物理卷）→ VG（Volume Group，卷组）→ LV（Logical Volume，逻辑卷）。

磁盘/dev/sdb → 创建PV → 加入VG → VG里切出LV → LV上建文件系统

为什么LVM能在线扩容？因为LVM的metadata（元数据）存储在PV的头部和尾部，记录了PE（Physical Extent，物理扩展块）到LE（Logical Extent，逻辑扩展块）的映射关系。扩容时只需要往VG里加新的PV（新磁盘），把VG里的空闲PE分配给LV，然后在线扩展文件系统（ext4用resize2fs，xfs用xfs_growfs）。整个过程不需要卸载文件系统，业务零中断。

# 如果安装时选了LVM，系统装完后可以这样查看vgs # 查看Volume Grouplvs # 查看Logical Volumepvs # 查看Physical Volume # 后期根分区不够了，扩容三步走：# 1. 新加磁盘/dev/sdb创建为PVpvcreate /dev/sdb1 # 2. 把PV加入根分区所在的VG（通常是kl_vm）vgextend kl_vm /dev/sdb1 # 3. 扩展LV并在线扩展文件系统lvextend -l +100%FREE /dev/kl_vm/rootresize2fs /dev/kl_vm/root # ext4用这个xfs_growfs / # xfs用这个

LVM扩容的核心逻辑：搞清楚PV→VG→LV这个层级关系，扩容操作就不慌了。PE是LVM的最小分配单元，默认4MB，VG里所有的PV的PE组成一个大的PE池，LV从这个池里按需分配LE。

---

四、系统激活：扫码流程别漏这一步

麒麟系统的激活和传统Linux不一样，它有一套自己的授权体系。我第一次交付的时候以为输个序列号就完事了，结果系统重启后又变成未激活状态，客户验收的时候差点没过。

完整激活流程

第一步：绑定权限。拿到授权后，先关注"麒麟软件"公众号，进入全链服务→产品激活，完善个人信息（单位、姓名、邮箱、联系方式），然后绑定服务序列号。一个序列号只能绑定一个主管理员，绑定后其他人需要通过主管理员分配授权。

绑定有两种方式：直接输入服务序列号+验证码绑定，或者扫描服务序列号上的二维码绑定。两种方式效果一样，选哪种看现场情况。

第二步：扫码激活。在服务器上右键"计算机"→属性→激活→选择二维码激活，用绑定后的微信扫码即可。扫完会提示激活成功。

第三步：授权分配（多台服务器场景）。如果你买了多套授权，主管理员可以在公众号里做权限分配：全链服务→产品激活→扫码激活权限管理→权限分配→选中服务序列号→点击分配权限，根据提示选择需要分配的套数发给对应人员。

离线激活方案

信创交付经常遇到服务器没外网的情况，手机也扫不了码怎么办？麒麟提供了离线激活方案：

激活验证与常见问题

# 查看系统版本和激活状态nkvers # 查看授权详情kylin-system-verify --show # 查看服务序列号cat /etc/.kylin-build

常见问题：

• 激活后重启又变成未激活： 通常是序列号和镜像版本不匹配，检查授权书上的版本号。

• 提示序列号已被绑定： 说明之前有人绑定过了，通过邮箱获取已绑定管理员信息，让其分配授权。

• 激活码输入无效： 注意区分大小写，激活码有时效性，超时需重新获取。

---

五、网络配置：V11下nmcli才是正道

这里要特别强调一个V11的重大变化：V11基于openEuler开发，网络管理全面转向NetworkManager。以前V10时代编辑/etc/sysconfig/network-scripts/ifcfg-ens33然后systemctl restart network的老办法，在V11上可能行不通------openEuler默认不再提供network这个legacy服务，systemctl restart network会报Unit network.service not found。

为什么NetworkManager取代了network-scripts？底层原因是RHEL 8/9和openEuler 22.03开始，systemd-networkd和NetworkManager成为主流，传统的ifcfg-legacy脚本维护成本高、功能有限。NetworkManager使用keyfile格式存储配置，路径在/etc/NetworkManager/system-connections/，不再是老的ifcfg目录。keyfile是INI格式的配置文件，支持更丰富的网络特性（如Bond、Team、VPN等）。

所以V11下网络配置建议直接以nmcli为主，别在ifcfg文件上浪费时间。

方案一：nmcli命令行（生产环境首选，V11官方推荐）

# 设置静态IP（注意掩码用CIDR格式）nmcli connection modify ens33 ipv4.addresses 192.168.1.100/24nmcli connection modify ens33 ipv4.gateway 192.168.1.1nmcli connection modify ens33 ipv4.dns "114.114.114.114 8.8.8.8"nmcli connection modify ens33 ipv4.method manualnmcli connection modify ens33 connection.autoconnect yes # 激活网卡nmcli connection up ens33 # 验证ip addr show ens33ping -c 3 192.168.1.1

nmcli的好处是改完直接connection up就生效，不用重启整个网络服务，影响面小。而且nmcli命令可以写进脚本，批量配置大量机器的网络。V11上nmcli是官方推荐方式，不用再纠结选哪个。

方案二：nmtui文本菜单（适合新手）

执行nmtui进入文本界面，方向键操作：选择"编辑连接"→选目标网卡→编辑IPv4设置→改成手动模式→填写地址、掩码、网关、DNS→确定→返回主界面→"激活连接"→选网卡回车。全程不需要记命令，适合对命令行不熟的同事。

方案三：直接编辑keyfile配置（排查问题时用）

V11的NetworkManager默认使用keyfile格式存储网络配置，路径在/etc/NetworkManager/system-connections/，不再是老的ifcfg目录。需要直接改配置文件时编辑这里：

# 查看网络配置文件ls /etc/NetworkManager/system-connections/ # 编辑对应网卡配置（文件名通常是网卡名.nmconnection）vi /etc/NetworkManager/system-connections/ens33.nmconnection

keyfile格式示例：​​​​​​​

[connection]id=ens33type=ethernetautoconnect=true [ipv4]method=manualaddresses=192.168.1.100/24gateway=192.168.1.1dns=114.114.114.114;8.8.8.8;

改完后重新加载并激活：​​​​​​​

nmcli connection reloadnmcli connection up ens33

方案四：图形化NetworkManager（最直观）

桌面环境下右键右下角网络图标→编辑连接→选网卡→小齿轮→IPv4设置→改成手动→填信息→保存。但服务器一般是最小化安装没图形界面，这个方案只在你装了GUI的时候才用得上。

远程改IP的安全做法：改完配置后先不重启网络，而是在当前会话用nmcli connection up ens33单独激活这张网卡。如果IP没配通，原会话还在，可以马上改回来。

我的推荐：V11下生产环境直接用nmcli（官方推荐、可脚本化、影响面小），应急排查时用keyfile直接编辑（路径在/etc/NetworkManager/system-connections/），新手用nmtui（操作直观不易错）。修改IP前务必跟现场管理员确认IP可用性，避免IP冲突。

网络排障速查​​​​​​​​​​​​​​

# 网卡down了起不来ip link set ens33 upnmcli connection up ens33 # DNS解析不了cat /etc/resolv.conf # 检查DNS配置nslookup www.baidu.com # 测试DNS # 多网卡默认路由冲突ip route show # 查看路由表ip route del default via x.x.x.x # 删掉错误路由nmcli connection modify ens33 ipv4.routes "0.0.0.0/0 192.168.1.1 100" # 设优先级 # V11基于openEuler，默认只有NetworkManager，无network服务# 如果从V10原地升级上来残留了network服务导致冲突，清理掉：systemctl stop network 2>/dev/nullsystemctl disable network 2>/dev/nullsystemctl restart NetworkManagernmcli connection reload

---

六、Bond配置：生产环境必须做

以前管生产数据库的时候，我们所有生产服务器都标配双网卡Bond。信创服务器也一样，Bond不是可选项，是必选项。一根网线断了业务就中断，这种事故在甲方那里是不可接受的。

Bond的底层实现：Linux内核的bonding模块（drivers/net/bonding/bond_main.c）通过虚拟出一个bond0接口，把多个物理网卡绑定到这个虚拟接口上。内核会根据配置的模式，决定数据包从哪个物理网卡发送，以及如何处理网卡故障切换。

Bond有7种模式，实际用得最多的就几种：

• mode 0（负载均衡）： 双网卡同时工作，带宽翻倍，需要交换机配端口聚合（LACP）

• mode 1（主备热备）： 一主一备，主断切备，不需要额外配置

• mode 4（802.3ad）： 动态链路聚合，最优方案，需要配LACP

• mode 6（自适应负载均衡）： 不需要交换机配合，不需要额外配置

mode 1和mode 4的核心区别：mode 1是主备模式，内核通过MII（Media Independent Interface）监控或ARP监控来检测主网卡状态，主网卡故障时自动切到备网卡。mode 4是LACP动态协商，需要和交换机配合，双方通过LACPDU（Link Aggregation Control Protocol Data Unit）报文协商聚合组，实现真正的负载均衡+冗余。

麒麟下配Bond最方便的还是nmcli。下面以mode 1热备模式为例：​​​​​​​

# 1. 创建bond0接口，模式为热备nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=1,miimon=100,primary=ens33" # 2. 添加从网卡（注意修改网卡名）nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname ens33 master bond0nmcli connection add type ethernet slave-type bond con-name bond0-port2 ifname ens37 master bond0 # 3. 给bond0配静态IPnmcli connection modify bond0 ipv4.addresses 192.168.1.100/24nmcli connection modify bond0 ipv4.gateway 192.168.1.1nmcli connection modify bond0 ipv4.method manual # 4. 启用bond0（先down原网卡再up bond0）nmcli connection down ens33nmcli connection down ens37nmcli connection up bond0 # 5. 验证Bond状态cat /proc/net/bonding/bond0

模式选择建议：如果交换机支持LACP，首选mode 4（带宽和冗余兼得）。交换机不支持或不确定，用mode 1（最简单可靠）。千万别用mode 0，交换机没配LACP的话会有大量丢包。

---

七、本地YUM源：离线环境的救命稻草

信创交付最大的痛点之一就是很多服务器没有外网。装完系统要装软件包，没有YUM源就抓瞎了。所以本地YUM源是交付标配，每台机器都要配。

单机本地源配置​​​​​​​

# 1. 挂载镜像mkdir -p /mnt/isomount -o loop /root/Kylin-Server-V11-2503.iso /mnt/iso # 2. 确认挂载成功ls /mnt/iso/Packages/ | head -10 # 3. 配置本地源cat > /etc/yum.repos.d/local.repo << 'EOF'[local]name=Kylin Local Repositorybaseurl=file:///mnt/isogpgcheck=0enabled=1EOF # 4. 禁用其他源（避免找不到外网报错）mv /etc/yum.repos.d/kylin_x86_64.repo /etc/yum.repos.d/kylin_x86_64.repo.bak # 5. 刷新缓存yum clean allyum makecacheyum list available | wc -l # 看看有多少可用包

开机自动挂载镜像

重启后/mnt/iso会丢失挂载，YUM源就失效了。写入fstab实现开机自动挂载：

​​​​​​​

# 获取镜像文件UUID（也可以用路径）echo "/root/Kylin-Server-V11-2503.iso /mnt/iso iso9660 loop,ro 0 0" >> /etc/fstab # 验证mount -als /mnt/iso/

内网YUM源服务器搭建

如果交付的机器多，每台都挂镜像太麻烦。建议在内网搭一台YUM源服务器，其他机器通过HTTP访问：​​​​​​​

# YUM源服务器上的操作：# 1. 安装HTTP服务yum install httpd -ysystemctl enable --now httpd # 2. 把镜像内容拷贝到web目录mkdir -p /var/www/html/kylincp -r /mnt/iso/* /var/www/html/kylin/ # 3. 客户端配置（替换file://为http://）cat > /etc/yum.repos.d/kylin.repo << 'EOF'[kylin]name=Kylin Network Repositorybaseurl=http://192.168.1.200/kylingpgcheck=0enabled=1EOF yum clean all && yum makecache

进阶：如果内网有麒麟官方源同步权限，可以用reposync工具定期同步官方源到本地服务器，保持包版本最新。命令：reposync -p /var/www/html/kylin --repoid=kylin

---

八、磁盘管理：从分区到LVM扩容

这是我亲身经历的一次血泪教训。有一次交付，我在/etc/fstab里写了磁盘挂载项，结果UUID写错了一个字符，重启后系统起不来，卡在emergency mode。现场客户在旁边看着，那个尴尬。

新磁盘挂载标准流程​​​​​​​

# 1. 查看磁盘信息lsblkfdisk -l | grep Disk # 2. 分区（以/dev/sdb为例）fdisk /dev/sdb# 交互操作：n → p → 1 → 回车 → 回车 → w # 3. 格式化为xfsmkfs.xfs /dev/sdb1 # 4. 获取UUID（推荐用UUID挂载，不用设备名）blkid /dev/sdb1 # 5. 创建挂载点mkdir -p /data # 6. 写入fstab（用UUID，不要用/dev/sdb1）echo "UUID=8ec068d3-c9af-4ab8-820e-ff54f4d78e84 /data xfs defaults 0 0" >> /etc/fstab # 7. 验证（重要！重要！重要！）mount -adf -h /data

关键操作：写完fstab一定要先执行mount -a验证！不报错再重启。报错了赶紧改。这一步能避免90%的fstab导致系统无法启动的问题。为什么用UUID不用设备名？因为重启后设备名可能会变（sdb变sdc），UUID是唯一的不变。

LVM逻辑卷扩容

如果安装时用了LVM，后期扩容非常方便。这是LVM最大的优势：

​​​​​​​

# 场景：根分区/快满了，加一块新盘扩容# 1. 新磁盘/dev/sdb分区fdisk /dev/sdb # n → p → 1 → 回车 → 回车 → t → 8e → w# （t → 8e把分区类型改成LVM） # 2. 创建物理卷pvcreate /dev/sdb1 # 3. 查看现有VG名称vgs# 假设VG名为kl_vm # 4. 把新PV加入VGvgextend kl_vm /dev/sdb1 # 5. 查看现有LV路径lvs# 假设LV路径为/dev/kl_vm/root # 6. 把所有空闲空间分给根分区LVlvextend -l +100%FREE /dev/kl_vm/root # 7. 在线扩展文件系统（不用卸载！）resize2fs /dev/kl_vm/root # ext4文件系统用这个xfs_growfs / # xfs文件系统用这个 # 8. 验证df -h /

整个扩容过程业务零中断，这也是为什么我强烈推荐生产环境用LVM的原因。

fstab写错导致系统无法启动的修复

如果不幸踩了fstab的坑，系统卡在emergency mode，别慌：

---

九、安全加固：别让裸奔的系统上了生产

很多人装完系统就交付了，安全配置完全没做。在甲方那里这属于重大隐患，安全扫描一过全是漏洞。以下几项是交付前必须做的：

密码策略加固​​​​​​​

# 修改密码策略配置vi /etc/login.defsPASS_MAX_DAYS 90 # 密码最大有效期90天PASS_MIN_DAYS 2 # 两次修改密码最小间隔PASS_MIN_LEN 12 # 密码最小长度12位PASS_WARN_AGE 7 # 密码过期前7天提醒 # 设置密码复杂度（需要安装pam_pwquality）vi /etc/security/pwquality.confminlen = 12 # 最小长度minclass = 4 # 至少包含4种字符类型maxrepeat = 3 # 最多3个连续相同字符

SSH安全加固

​​​​​​​

vi /etc/ssh/sshd_config# 关键加固项Port 22022 # 改掉默认端口PermitRootLogin no # 禁止root直接登录PasswordAuthentication no # 禁用密码登录（用密钥）MaxAuthTries 3 # 最大认证次数ClientAliveInterval 300 # 空闲超时5分钟ClientAliveCountMax 0 # 超时直接断开AllowUsers deployuser # 只允许指定用户 # 重启SSH服务systemctl restart sshd

注意：禁用密码登录前，务必先确认密钥登录能用！否则改完SSH重启后你就进不去了。建议改完后新开一个终端测试连接，确认没问题再关闭旧终端。

防火墙配置

# 麒麟默认使用firewalldsystemctl enable --now firewalld # 放行业务端口（以8080为例）firewall-cmd --permanent --add-port=8080/tcpfirewall-cmd --permanent --add-port=22/tcp # 放行特定IP访问SSHfirewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=22 protocol=tcp accept' # 重新加载firewall-cmd --reload # 查看已放行规则firewall-cmd --list-all

关闭不需要的服务

# 查看所有启用的服务systemctl list-unit-files --state=enabled # 关闭常见不需要的服务systemctl disable --now bluetoothsystemctl disable --now cupssystemctl disable --now avahi-daemonsystemctl disable --now postfix

V11 KSAF安全框架

V11的安全架构和V10完全不同。V11在保留SELinux基础能力之上，扩展自研了KSAF（Kylin Security Architecture Framework）可编程安全框架，不是直接替代、移除SELinux。日常运维不能简单理解为"换掉SELinux"。KSAF不是简单的SELinux加强版，而是分层的强制访问控制体系：

• MAC（Mandatory Access Control）： 强制访问控制，基于安全标签决定主体（进程）对客体（文件、端口）的访问权限

• RBAC（Role-Based Access Control）： 基于角色的访问控制，管理员、审计员、安全员三权分立

• TE（Type Enforcement）： 类型强制，通过类型规则限制进程的行为范围

如果你的服务器从V10升级上来，安全策略需要重新适配。交付前建议确认KSAF状态：

# 查看KSAF安全框架状态kylin-saf status # 查看安全策略等级kylin-saf policy --show # 设置安全等级（分为low/medium/high，生产环境建议medium）kylin-saf policy --set medium # 查看安全审计日志kylin-saf audit --list

注意：KSAF的安全策略等级直接影响系统行为。设成high可能会导致某些业务程序无法正常运行（比如限制网络端口、文件权限），建议先在测试环境验证。交付时跟甲方安全部门确认要求的安全等级再设置。

---

十、故障排查：救援模式、文件系统修复与日志收集

进入单用户模式修改root密码

忘记root密码是DBA常事。麒麟进入单用户模式的方式和CentOS类似：

​​​​​​​

# 以读写模式重新挂载sysrootmount -o remount,rw /sysroot # 切换到系统环境chroot /sysroot # 修改root密码passwd root # 如果SELinux是enforcing模式，需要执行touch /.autorelabel # 退出并重启exitexit

注意：如果SELinux处于enforcing模式，不执行touch /.autorelabel的话，改完密码重启后可能登录不上。系统会自动relabel一次文件系统，时间稍长，耐心等待。

文件系统修复

非正常关机后文件系统可能损坏，启动时卡在fsck检查阶段。根据文件系统类型选择修复工具：

# ext4文件系统修复fsck.ext4 -y /dev/sda2 # xfs文件系统修复（xfs修复前必须先卸载）umount /dev/sdb1xfs_repair /dev/sdb1 # 如果xfs_repair报错说有日志未清，先清日志xfs_repair -L /dev/sdb1 # 修复完重新挂载mount /dev/sdb1 /data

警告：xfs_repair -L会清空日志，可能导致数据丢失！只在常规xfs_repair失败时作为最后手段使用。修复前如果有条件，先做磁盘数据备份。

sos日志收集

出问题找原厂支持的时候，对方第一句话通常是"发个sosreport过来"。麒麟也支持sos工具，这是最高效的问题定位手段：

# 安装（如果没装的话）yum install sos -y # 收集完整诊断日志sosreport # 指定只收集某些模块（加快速度）sosreport --only-plugins kernel,network,kylin,hardware # 收集完后报告在/var/tmp/下，是个压缩包ls -lh /var/tmp/sosreport-*.tar.xz # 传给原厂支持即可scp /var/tmp/sosreport-*.tar.xz support@kylinos.cn:~/

sosreport会自动收集系统配置、内核版本、加载模块、系统服务状态、系统日志、硬件信息等诊断信息，打包成一个压缩文件。原厂拿到这个文件就能快速定位大部分问题。

sosreport的底层机制：sos是一个Python编写的插件化诊断工具，每个插件对应一个系统组件（kernel、network、hardware等）。执行时，sos会调用各插件的收集方法，把输出写入临时目录，最后打包成tar.xz。插件机制的好处是扩展性强，麒麟可以自定义kylin插件来收集特有的诊断信息。

kylin-sysassist智能诊断（V11新特性）

V11除了支持传统的sosreport，还内置了kylin-sysassist智能诊断工具，比sosreport更强大------它不仅能收集日志，还能对常见问题做自动分析和修复建议：​​​​​​​

# 一键全量诊断kylin-sysassist --check-all # 只检查网络问题kylin-sysassist --check network # 只检查磁盘和文件系统kylin-sysassist --check storage # 生成诊断报告（HTML格式，比sosreport更直观）kylin-sysassist --report --output /tmp/diagnosis-report.html # 查看自动修复建议kylin-sysassist --suggest

实战建议：交付时我习惯先用kylin-sysassist --check-all跑一遍全量诊断，把报告存档。这样万一后续出问题，有交付时的基线数据可以对比。比单纯跑sosreport信息更全，而且有修复建议，对排查效率提升很大。

常用信息查询命令

系统信息：

• nkvers：查看系统版本（麒麟专用命令）

• cat /etc/os-release：查看系统信息

• uname -r：查看内核版本

• hostnamectl：查看主机信息

硬件信息：

• lscpu：查看CPU信息（架构、核数、频率）

• free -h：查看内存使用

• lsblk：查看磁盘及分区

• lspci | grep -i ethernet：查看网卡型号

• dmidecode -t system：查看服务器型号

网络信息：

• ip addr show：查看所有网卡IP

• ip route show：查看路由表

• ss -tlnp：查看监听端口

• ethtool ens33：查看网卡链路状态

---

十一、内核升级与热补丁：什么时候该升，什么时候不该升

内核升级是信创系统管理中最敏感的操作之一。V11的内核从V10时代的4.19/5.10升级到了6.6，包名后缀也从.ky10变成了.ky11。我的建议是：能不升就不升，除非有明确的安全漏洞或硬件兼容性问题。

传统内核升级（需要重启）​​​​​​​

# 查看当前内核版本（V11默认是6.6.x）uname -r # 查看已安装的内核包（注意V11的包名后缀是.ky11）rpm -qa | grep kernel # 安装新内核（从麒麟官方源获取，包名格式以实际版本为准）yum install kernel-6.6.0-xx.x.v2505.ky11.aarch64 # 确认新内核在GRUB中是默认启动项grubby --default-kernel # 设置默认启动内核grubby --set-default /boot/vmlinuz-6.6.0-xx.x.v2505.ky11.aarch64 # 重启生效reboot

内核升级风险：

• 第三方驱动可能不兼容新内核，升级前确认驱动兼容性

• 某些业务软件绑定了内核版本，升级后可能无法启动

• 建议在测试环境先验证，确认无问题后再在生产环境操作

• 升级前务必保留旧内核，万一新内核有问题可以在GRUB里选旧内核启动

热补丁：免重启修复内核漏洞（V11新特性）

V11有个大杀器------kylin-warm热补丁技术。以前修内核漏洞必须重启服务器，数据库业务还得做切换，窗口期至少十几分钟。热补丁可以在系统运行状态下直接修复内核函数，不用重启，对数据库这种高可用要求极高的场景来说简直是救命稻草。

热补丁的底层原理：kylin-warm基于Linux内核的ftrace和kprobe机制。ftrace是内核自带的函数追踪框架，可以在运行时hook任意内核函数。kprobe是动态探针机制，允许在内核函数入口和出口插入自定义代码。kylin-warm利用这两个机制，把补丁函数注入到目标内核函数的入口，实现运行时修复。

具体来说，当应用热补丁时，kylin-warm会：# 查看热补丁状态

kylin-warm --list # 安装热补丁（从麒麟官方获取补丁包）kylin-warm --apply /path/to/hotfix.ko # 查看已安装的热补丁kylin-warm --list --installed # 如果热补丁有问题，可以回滚kylin-warm --rollback # 卸载热补丁kylin-warm --remove

热补丁 vs 传统升级：热补丁适用于安全漏洞修复和小范围内核函数修正，不适合大版本内核升级。我的策略是：安全漏洞优先用热补丁，大版本升级走传统流程。但要注意，热补丁不是万能的，有些底层改动（比如数据结构变更、驱动接口变更）仍然需要重启。每次打热补丁前先在测试环境验证，确认对业务无影响再上生产。

---

十二、交付检查清单：走完这些才算交付完成

每次交付我都会按这个清单逐项检查，全部打勾了才算交付完成。建议你也养成这个习惯：

1. 系统版本与授权书一致（nkvers确认）

2. 系统已激活（kylin-system-verify --show确认）

3. 补丁已更新到最新（dnf check-update无重要更新）

4. 主机名规范（hostnamectl确认）

5. IP地址正确且可ping通网关

6. DNS解析正常（nslookup测试）

7. Bond已配置且主备切换正常（cat /proc/net/bonding/bond0）

8. YUM源可用（yum list验证）

9. 磁盘挂载正确，mount -a无报错

10. 防火墙已配置，仅放行必要端口（firewall-cmd --list-all）

11. SSH已加固（端口、密钥登录、禁止root）

12. 密码策略已配置（长度、复杂度、有效期）

13. SELinux状态确认（getenforce）

14. 时间同步已配置（NTP或chrony）

15. 不必要的系统服务已关闭

16. sosreport能正常生成

17. 系统日志无异常报错（journalctl -p err）

18. 硬件状态正常（磁盘、内存、风扇）

19. KSAF安全框架等级已确认（kylin-saf status）

20. kylin-warm热补丁已检查（kylin-warm --list）

21. kylin-sysassist全量诊断通过并存档

22. 交付文档已提交（配置清单、IP规划表）

总结

从CentOS到麒麟，从x86到飞腾鲲鹏，国产化替代不是简单换个系统。底层架构变了，系统管理方式也得跟着变。但万变不离其宗------理解原理、做好预案、谨慎操作，这三条不管在什么平台上都适用。

这篇指南覆盖了从镜像选择到故障排查的完整交付链路，每一节里写的坑都是我亲身踩过的。如果觉得有用，建议收藏起来，下次交付的时候对照着检查。

信创这条路还很长，国产操作系统的生态也在快速迭代。技术文档会过时，但系统管理的底层方法论和谨慎的态度永远不会过时。如果你也在做信创交付，欢迎在评论区交流你的经验，大家一起摸着石头过河。

今天话题就聊到这，欢迎留言交流。觉得内容有用，别忘了点赞转发给有需要的朋友，回见！