企业官网建设流程全解析

作为常年折腾服务器系统的人，我最近花了不少时间把openEuler从零到一认真过了一遍。这系统在信创和云计算圈子里讨论度越来越高，但网上系统性的实操文档其实不算多，大多是官方手册的搬运，真正踩过坑才知道哪里疼。这篇笔记把我从下载ISO到装出带图形界面的ARM虚拟机、从配YUM源到源码编译升级OpenSSH、再到跑通Qwen3 8B/27B大模型推理的全过程整理出来，给同样想上手openEuler的朋友一份能直接照着做的参考。

先交代我的实验环境：主力机是一台x86_64工作站，另外借了一台鲲鹏920的ARM服务器。openEuler对x86和ARM都有良好支持，但很多细节的坑在ARM上更明显，我会把两个架构下的差异单独标出来。这篇文章适合刚接触openEuler的运维、正在做国产化替代评估的架构师，以及想在自己机器上跑大模型推理的AI应用开发者。

1. 为什么是openEuler：定位与选型逻辑

1.1 openEuler到底是什么

openEuler是一款开源的操作系统发行版，由开放原子开源基金会孵化，华为等厂商是主要贡献者。很多人喜欢拿它跟CentOS、Ubuntu比，其实从技术路线上看，openEuler和CentOS Stream更接近——两者都基于RPM生态体系，内核策略偏向企业级稳定性，但openEuler走了完全独立的社区演进路线。它的核心竞争力在于对多架构（尤其ARM）、高性能计算和云原生场景做了大量针对性优化，比如它内置的iSulad轻量容器运行时、A-Ops智能运维框架，这些都是其他发行版里要自己折腾半天才能凑齐的东西。

我决定深入研究它有三个现实原因：第一，身边不少做国产化替代的朋友都在用它，服务器端已经能看到实际生产部署；第二，openEuler的版本节奏和对新硬件的跟进速度比想象中快，24.03 LTS版本已经能很好地支持新一代ARM服务器；第三，它兼容大量RPM系生态，CentOS上积累的经验能平滑迁移过来，学习成本比想象中低。

1.2 和CentOS、Ubuntu的关键差异

对于中文用户，openEuler最友好的地方其实是社区和文档——很多问题在官方Gitee仓库的issue区和论坛里能直接搜到中文解答，这对排查问题的效率提升是巨大的。另外它的EasySoftware仓库（openEuler便捷安装软件平台）聚合了大量软件包，这也是热搜词里出现"openeuler easysoftware"的原因。

2. 安装openEuler：从ISO到跑起来

2.1 选择合适的版本与镜像

openEuler目前主要维护两条长期支持版本线：22.03 LTS和24.03 LTS。我的建议是：生产环境选22.03 LTS SP系列（成熟稳定），学习实验直接上24.03 LTS，因为24.03对新硬件兼容性更好，工具链也比较新，而且默认Python是3.11，后面跑AI相关工具省很多事。

下载镜像时务必注意架构：x86_64机器下载x86_64的ISO，ARM服务器下载aarch64版本。别下错了，ARM的ISO在x86机器上装不了，反过来也一样。openEuler官网提供标准ISO、软件包ISO和极简ISO三种形式，学习用标准ISO就够了，里面自带Anaconda安装器。

2.2 虚拟机安装的关键步骤

如果你打算在VMware或VirtualBox里装openEuler，有几点和装Windows完全不同。

第一步，创建虚拟机时操作系统类型不要选"Other Linux 5.x"，直接选"CentOS 7 64位"或"Red Hat Enterprise Linux 7 64位"这类兼容模板，这样VMware Tools的安装路径最顺。磁盘大小建议至少分配20GB，内存2GB以上，否则安装界面会非常卡。

第二步，从ISO引导后会进入GRUB菜单。openEuler默认进入图形化安装界面，但如果虚拟机显存配置不够或远程安装，会退回文本模式。文本模式一样能完成安装，只是分区和软件选择的交互逻辑略有不同。新手建议在VMware里给足显存并开启3D加速，走图形界面更直观。

第三步，磁盘分区。openEuler的Anaconda支持自动分区，实验环境直接选"自动配置分区"即可。但我强烈建议手动建立三个分区：/boot（500MB）、swap（内存大小或4GB）、/（剩余全部）。这样后续调整磁盘、排查引导问题时都会省很多事。

注意：如果要在物理机的NVMe硬盘上装openEuler，尽量用最新24.03版本。老版本内核和部分NVMe控制器有兼容性问题，具体表现为安装中途突然识别不到磁盘，这个坑在论坛里出现过多次。

2.3 ARM架构服务器的安装差异

在鲲鹏等ARM服务器上安装openEuler，流程和x86基本一致，但有三个区别值得注意：

• 引导方式通常强制UEFI，安装完成后不要乱改启动项顺序，否则会出现grub丢失；
• BIOS里要确认ACPI和硬件虚拟化选项已开启，后续跑KVM虚拟化要依赖这里；
• ARM版的软件仓库包名与x86略有差异（比如有些包在x86叫xxx.x86_64，ARM叫xxx.aarch64），配置YUM源时对应即可。

我实测发现，ARM服务器上openEuler安装速度明显比x86快，尤其是编译类操作，因为鲲鹏920的核心数通常比较多。但这也带来一个副作用：编译大项目时内存占用非常夸张，ARM服务器如果内存低于16GB，swap会疯狂抖动，编译速度反而慢下来。开swap分区时建议给到内存的1.5倍以上，或者干脆用zram。

3. 装完系统后必做的三件事

3.1 配置YUM源：不配源什么都装不了

openEuler装完系统第一件事就是配置YUM源，否则连tree这种基础工具都装不上。官方默认源在公网环境下能用，但速度不稳定，尤其是访问高峰时段。如果你在公司内网，通常建议直接使用内网镜像源，或者用官方镜像站。

我实测下来最稳的方案是使用openEuler官方镜像站对应版本的源。具体操作：

# 备份原始repo文件 mkdir -p /etc/yum.repos.d/backup cp /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/backup/ # 编辑源配置 vim /etc/yum.repos.d/openEuler.repo

以24.03 LTS x86_64为例，核心repo文件内容如下：

[openEuler_24.03_LTS] name=openEuler_24.03_LTS baseurl=https://mirrors.openEuler.org/openEuler-24.03-LTS/ enabled=1 gpgcheck=0 [openEuler_24.03_LTS_extras] name=openEuler_24.03_LTS_extras baseurl=https://mirrors.openEuler.org/openEuler-24.03-LTS/extras/ enabled=1 gpgcheck=0

把gpgcheck设成0主要是省去导入公钥的麻烦，生产环境建议设1并导入官方GPG Key。配置完成后执行：

dnf clean all dnf makecache

第一次makecache会下载大量元数据，耐心等一会。然后dnf install -y vim tree net-tools测试一下源是否正常。

这里有个经验之谈：如果公司网络有防火墙，dnf下载超时是很常见的事。排查方法很简单，先用curl -I测试源地址是否连通，再用dnf repolist确认repo是否被识别。90%的源问题都是这两个原因，还有10%是baseurl路径写错了，注意不同版本目录的拼接规则。

3.2 安装图形界面：从命令行到桌面

openEuler默认安装是纯命令行的，但很多初学者还是希望有个图形界面能更直观。安装图形环境其实就一条命令：

dnf groupinstall -y "Server with GUI"

或者更细粒度地安装GNOME：

dnf install -y gnome-desktop gnome-session gdm

装完后设置默认启动级别为图形模式：

systemctl set-default graphical.target reboot

我在实测中发现，openEuler的GNOME版本比CentOS 7新不少（24.03带的GNOME是40+版本），界面风格更现代化，自带的应用也够用。如果你用的是VMware虚拟机，装完图形界面后建议立即安装VMware Tools，否则分辨率锁在800x600，拖拽文件也不支持，体验会差很多。

3.3 VMware Tools的安装：实现自适应分辨率与拖拽

VMware Tools是热搜词里被问到很多的一个点。在openEuler上安装VMware Tools，关键是先装好编译依赖：

dnf install -y gcc make kernel-devel kernel-headers perl

然后在VMware菜单里选择"安装VMware Tools"，挂载光盘后执行：

mkdir -p /mnt/cdrom mount /dev/cdrom /mnt/cdrom tar zxf /mnt/cdrom/VMwareTools-*.tar.gz -C /tmp /tmp/vmware-tools-distrib/vmware-install.pl

安装脚本会一路询问，全部回车用默认值即可。装完后vmware-toolbox-cmd可用来查看分辨率、执行窗口缩放等操作。

注意：如果虚拟机内核升级过，VMware Tools的内核模块可能失效，表现为vmtoolsd进程报错、分辨率突然变回小窗口。这时需要重新运行vmware-install.pl让它重新编译内核模块。这个问题在使用VirtualBox的用户那边同样存在，思路是一致的。

4. 进阶实战一：源码编译升级OpenSSH

4.1 为什么要升级OpenSSH

很多生产环境的openEuler初始自带的OpenSSH版本较旧，而安全扫描、等保合规审计经常要求SSH版本升级到指定版本以上。按RPM包方式升级可能遇到依赖冲突，源码编译是可控性最高的方案。不过我现在要说清楚，源码升级SSH属于高风险操作，稍有不慎就会在远程环境里把自己锁在外面，建议提前做好带外管理准备。

4.2 源码编译的完整步骤

先查看当前版本：

ssh -V

然后按以下流程操作：

# 安装编译依赖 dnf install -y gcc make zlib-devel openssl-devel pam-devel krb5-devel # 下载源码包 cd /opt wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.6p1.tar.gz tar zxf openssh-9.6p1.tar.gz cd openssh-9.6p1 # 预编译配置 ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/usr/lib64 --with-pam --with-zlib # 编译安装 make -j$(nproc) make install

这里有几个细节必须注意：

• configure前务必确认openssl-devel装好了，而且版本匹配（OpenSSH 9.6需要OpenSSL 1.1.1以上）；
• --prefix=/usr会让二进制覆盖到系统路径，避免出现"两个ssh版本并存"的混乱状态；
• 编译前务必备份原有ssh配置：cp -r /etc/ssh /etc/ssh.bak；
• 升级后要检查/etc/ssh/sshd_config里的PermitRootLogin是否保留了你原本的配置，源码编译默认配置可能重置这个值。

重启服务：

systemctl restart sshd systemctl status sshd

如果SSH服务起不来，多半是配置文件权限问题。源码编译安装后/usr/bin/sshd的权限可能不对，需要：

chmod 0755 /usr/bin/sshd chmod 0600 /etc/ssh/ssh_host_*_key

这个坑我踩过一次，排查了很久才发现是ssh_host_ed25519_key权限变成了0644，sshd直接拒绝启动。另外提醒一句，升级完成后新开的终端别急着关，先在另一个窗口测试ssh localhost能通，再关闭旧会话，这是保命的操作习惯。

4.3 升级失败后的回滚方案

无论如何，升级前请备份：

# 备份原始openssh rpm列表 rpm -qa | grep openssh > /root/openssh-rpm-backup.txt # 如果新版本不工作，用dnf重新安装原版 dnf reinstall -y openssh-server openssh-clients

源码编译最大的风险在于卸载不干净——make install覆盖了系统文件，但dnf reinstall时RPM并不知道这些文件被改了，可能报冲突。解决办法是先make uninstall（如果有uninstall目标），或者手动删除新版本文件后再reinstall。这个操作强烈建议在维护窗口执行，毕竟SSH断了就真的断了。

5. 进阶实战二：libvirt-daemon-kvm虚拟化

5.1 在openEuler上搭建KVM虚拟化环境

热搜词里"ARM架构openEuler服务器使用libvirt-daemon-kvm虚拟化"是个非常典型的企业场景——在鲲鹏服务器上用openEuler做宿主机，跑KVM虚拟机承载各种业务。这个组合在企业里已经很常见了。

安装核心组件：

dnf install -y qemu-kvm libvirt-daemon libvirt-daemon-driver-kvm virt-install systemctl enable --now libvirtd

验证KVM是否可用：

ls -l /dev/kvm virsh version

/dev/kvm存在说明内核KVM模块已加载。ARM架构上这里有个常见问题：如果BIOS没开启虚拟化扩展，/dev/kvm不会出现，需要进BIOS打开相关选项。鲲鹏服务器上这个选项通常在Advanced -> Virtualization下。

5.2 创建第一台虚拟机

virt-install是创建虚拟机最方便的工具。以安装一个openEuler ARM虚拟机为例：

virt-install \ --name openEuler-vm1 \ --memory 4096 \ --vcpus 4 \ --disk path=/data/kvm/openEuler-vm1.qcow2,size=50,format=qcow2 \ --os-variant openeuler \ --network network=default \ --cdrom /data/iso/openEuler-24.03-aarch64.iso \ --graphics vnc,listen=0.0.0.0

几个参数的经验值：

• --vcpus建议不要超过宿主机物理核心数，ARM服务器通常核多，分配4-8核做实验比较合适；
• --disk的size是虚拟大小，qcow2格式按需占用物理空间，不用担心一开始就占50GB；
• --os-variant先执行osinfo-query os | grep openEuler确认有对应选项，没有就选linux2023之类兼容值。

如果一切顺利，通过VNC客户端连上宿主机的IP加端口号即可看到安装界面。注意VNC监听默认只允许本机连接，要远程访问必须设置listen=0.0.0.0并配置防火墙放行端口（默认从5900开始挨个递增）。

5.3 宿主机网络桥接配置

默认的NAT网络（default）让虚拟机通过宿主机上网，但外部无法直接访问VM。学习阶段无所谓，生产环境需要把虚拟机网络桥接到物理网卡：

# 创建桥接接口 nmcli con add con-name br0 ifname br0 type bridge nmcli con mod br0 ipv4.addresses 192.168.1.10/24 nmcli con mod br0 ipv4.method manual nmcli con up br0

然后把物理网卡（比如ens3）桥接到br0上。ARM服务器上网络接口命名通常从ens0或enp189s0f0开始，先ip addr看一下实际名字再操作。桥接配置错是最容易导致宿主机断网的，建议在IPMI或带外管理可用的情况下操作，否则一旦断网可能要去机房救。

6. 进阶实战三：部署Qwen3 8B/27B大模型

6.1 openEuler作为AI推理平台的可行性

openEuler不是典型的AI发行版，但它的内核和CUDA兼容性做得不错，在x86_64加上NVIDIA GPU的环境里，配合Ollama或vLLM可以跑当前主流的大模型。ARM架构这边就别指望本地GPU大模型了，目前openEuler在ARM服务器上对GPU和CUDA生态的支持还比较薄弱，纯CPU推理27B模型速度非常慢，实际意义不大。所以这部分主要针对x86_64加NVIDIA GPU的机器。

6.2 基于Ollama的一键部署

如果只想快速跑通Qwen3 8B，Ollama是最省事的方式：

# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动服务 systemctl start ollama # 拉取并运行模型 ollama run qwen3:8b

第一次运行会自动下载模型权重（8B大概5GB），网速不够的话耐心等一下。Ollama会自动检测GPU并用CUDA加速，实测在RTX 4090上8B模型生成速度快得像翻页。

27B版本：

ollama run qwen3:27b

27B量化版大约15GB权重，如果GPU显存只有16GB，会有一部分层跑到CPU上，速度明显下降但依然可用。想完全GPU运行建议至少40GB显存，也就是A100或双卡4090。如果只有单卡24GB显存，我实测会有一部分层offload到CPU，生成速度大致在每秒10-20 token左右，日常对话还能接受，批量跑任务就有点煎熬了。

6.3 基于vLLM的高并发部署

如果是给团队做API服务，Ollama不是最优解，vLLM的吞吐量更高，支持高并发推理：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-8B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --port 8000

注意在openEuler上用pip装vLLM前，最好用conda或venv隔离环境，因为vLLM依赖的CUDA工具链相对较新，和系统Python包可能会打架。环境变量CUDA_VISIBLE_DEVICES可以用来控制多卡调度。

提示：openEuler的Python默认版本在24.03 LTS是3.11，vLLM要求Python大于等于3.8，没问题。但pip安装的vLLM自带wheel对GCC版本敏感，如果编译过程报错，先装gcc-toolset-13并激活对应环境再重试。

7. 学习过程中的高频坑位与最终心得

7.1 高频问题速查表

7.2 我对openEuler的整体评价

经过这段时间的系统学习，我的直观感受是：openEuler确实是服务器操作系统里工程完成度非常高的一个，它不是Linux发行版的简单换皮，而是从内核到用户态都做了不少落地的企业级优化。比如A-Ops智能运维能自动分析故障日志，iSulad容器运行时比Docker更轻，这些特性在企业批量部署时价值会放大。

但从学习角度看，openEuler最大的门槛依然是生态：很多第三方软件的官方文档只写了Ubuntu或CentOS的命令，你需要在openEuler上多一步转换工作，比如把apt换成dnf，把某些依赖包的名称做映射。好在openEuler兼容RPM系，大部分CentOS的软件源地址和包名可以复用，走完一遍下来反而能加深对Linux底层机制的理解。

我个人建议的学习路径是：先装系统练基础操作，再配YUM和图形界面扫清常用功能障碍，然后通过编译OpenSSH理解源码包和RPM的关系，之后用KVM虚拟化建立运维视角，最后才是大模型这种应用层尝试。这样从底层到上层每个环节都亲手碰过，后面不管转运维还是转AI工程，心里都有底。

最后分享一个我踩过的坑：在openEuler上不要轻易用dnf remove卸载内核相关包——它的依赖关系在某些SP版本里校验不严，可能把关键驱动一起卸掉，导致重启后网卡消失。真要清理内核，用dnf remove --noautoremove指定包名，并确保有备用手段可以救急。Linux这条路上，备份永远比技巧重要。