更新日期：2026-10-18
从 Ubuntu 转向 openEuler，最直观的变化是包管理命令，但真正需要适应的是软件来源、配置布局、安全策略和交付方式。把 apt 换成 dnf，只完成了很小一部分工作。
本文面向已有 Ubuntu 运维经验、准备在独立机器部署 openEuler 的读者。采用“新环境部署、迁移业务与数据”的思路，不把 Ubuntu 直接原地转换为 openEuler，也不假定 EL 系迁移工具支持 Ubuntu。具体版本、SP 和架构请以目标系统的官方文档为准。
保留的经验与需要重新检查的部分
Linux 的进程、文件权限、网络和 systemd 基础仍然有用。变化主要集中在发行版提供的软件包、默认配置与支持范围。
| 在 Ubuntu 上熟悉的内容 | 到 openEuler 后要确认 |
|---|---|
| DEB、APT、PPA | RPM、DNF、目标版本支持的软件仓库 |
| 软件包名称 | 实际包名、拆包方式、提供的命令与文件 |
| AppArmor 或其他安全配置 | SELinux 等机制是否安装、启用及具体策略 |
| UFW 或其他防火墙管理 | firewalld、nftables 等实际使用方式 |
| 用户与服务默认值 | 服务账号、目录权限、监听地址和单元文件 |
| x86 环境下的二进制 | 目标 CPU 架构和原生依赖是否匹配 |
表格描述的是检查方向，不是说每个镜像都具有完全相同的默认值。云镜像、最小化安装与定制镜像可能不同。
先建立源系统与目标系统清单
在 Ubuntu 上保存版本、架构、服务和包清单：
cat /etc/os-release
uname -m
dpkg-query -W -f='${binary:Package}\t${Version}\n'
systemctl list-unit-files --state=enabled
ss -lntup
在 openEuler 上收集对应信息：
cat /etc/os-release
uname -m
rpm -qa | sort
dnf repolist
systemctl --failed
将它们保存为迁移记录，并单独登记容器、手工编译软件、用户级服务和外部依赖。包清单不能覆盖所有实际部署内容。
包名不要机械翻译
同一个应用，在两个发行版上可能使用不同包名、配置目录和子包拆分。需要的如果是某个可执行文件或开发头文件，应查哪个包提供它，再安装正确包。
dnf search nginx
dnf info nginx
dnf provides '*/nginx'
示例用于查询目标仓库，不保证所有 openEuler 版本都提供同一候选包。查看结果中的来源、版本与架构，再按官方部署要求选择。
PPA 不能直接搬到 RPM 系统；为其他 EL 发行版制作的仓库也不能仅凭“都是 DNF”就混用。依赖解析失败时，优先检查目标版本和包来源，不要用关闭签名校验或强制忽略依赖作为常规解法。
配置应该迁移意图，而不是覆盖整个目录
例如 Web 服务，需要迁移的是站点、反向代理、TLS、日志与权限等配置意图。把 Ubuntu 的整个 /etc 复制到新系统，可能覆盖包管理、网络、账号和服务配置，造成难以追踪的问题。
应先在目标系统按正常方式安装服务，再将业务配置逐项合并。检查实际单元文件与启动命令：
systemctl cat nginx
systemctl status nginx --no-pager
journalctl -u nginx -n 80 --no-pager
服务名称以实际安装为准。若包名和服务名不同，用包文件清单与系统单元列表查找，不要直接创建一个同名服务掩盖问题。
权限与安全策略单独验收
目录读写失败，可能来自普通文件权限、服务账号、SELinux 标签、挂载方式或 systemd 沙箱限制。先查具体拒绝证据，再改对应规则。
若系统安装了相应工具，可以查询：
command -v getenforce
command -v firewall-cmd
systemctl is-active firewalld
第一步只是确认工具和服务是否存在。随后按目标系统安全文档检查状态、日志与允许规则，不要把关闭 SELinux、停用防火墙当作安装教程的固定步骤。
远程修改网络或防火墙前，保留独立管理入口。变更应先在测试环境验证，并有恢复旧规则的方案；不要在唯一 SSH 会话里一次改变地址、路由和访问策略。
Python、Node 与容器也有边界
应用可以使用自己的运行时环境，但不要替换系统管理工具依赖的 Python。迁移 Python 虚拟环境时，应在目标系统根据依赖描述重新创建，而不是直接复制旧 .venv，因为其中可能包含绝对路径和平台相关二进制。
容器减少了一部分用户态差异，却仍然共享宿主内核。CPU 架构、设备映射、卷权限、网络和安全策略都需要验证。x86_64 镜像也不会因为宿主安装成功，就自动在 aarch64 上原生运行。
如果同时更换发行版和架构，建议先验证目标架构制品是否存在，再安排迁移。否则，问题可能发生在部署链路最早的位置。
用一个服务完成演练
选择一个可恢复的小应用，保持应用版本和数据库版本不变，在 openEuler 上重新部署。恢复一份测试数据，验证登录、读写、上传、定时任务、邮件和外部存储，再重启机器复测。
验收清单可以很短，但必须覆盖真实业务：
- 服务由预期账号运行，端口只暴露给需要的网络。
- 数据目录、日志和挂载重启后仍然正确。
- 关键业务请求完成，监控和备份任务正常。
- 备份已经在独立环境恢复，而不只是生成了文件。
- 切流后出现故障时，明确如何处理新增数据与旧环境回退。
准备正式迁移时，先暂停或协调写入，再做最后同步和切流。若新环境已经产生业务数据，不能只切回旧机器而忽略差异。
从哪里继续阅读
euler.casa提供版本、仓库、按架构安装、运维和排障入口。官方文档则用于核对你选择的大版本、SP 和组件支持情况。
完成这轮迁移后，最好留下一个可重复部署的配置记录。下一台机器不应再依赖“上次临时装过什么”的记忆，这也是跨发行版迁移最值得顺手改进的地方。
