Skip to main content

给 Rocky Linux 用户一个中文入口:介绍我的新网站 rocky.casa

October 17, 2026
介绍 Rocky Linux 中文文档站 rocky.casa,按新装机、同代迁移、跨大版本迁移和日常运维安排阅读入口,说明迁移前的业务盘点、兼容性检查、备份恢复与故障反馈方法。
给 Rocky Linux 用户一个中文入口:介绍我的新网站 rocky.casa

更新日期:2026-10-18

我做了一个面向 Rocky Linux 用户的文档站:rocky.casa。内容围绕安装、包管理、迁移、升级、运维与排障组织,希望让读者从“准备做什么”出发,找到对应的操作入口。

Rocky Linux 常常出现在“CentOS 替代品”名单里,但真正维护一台服务器时,问题会具体得多:旧机器能否启动新版本?第三方软件是否支持?同大版本迁移和跨大版本升级有什么区别?故障之后要查哪一层?这些问题比一张发行版排名表更值得长期整理。

本站是独立的非官方社区文档站,与 Rocky Enterprise Software Foundation 没有隶属或授权关系。官方发行公告和文档仍然是版本、支持与兼容性判断的依据。

不止是安装完成

安装系统只是服务器生命周期的第一步。真正影响后续工作的,是软件源、账号权限、服务管理、数据存储、备份以及更新策略是否连得起来。

rocky.casa 的导航按任务划分。第一次装系统可以从下载安装开始;已有机器可以先查软件仓库和运维服务;准备换系统则进入迁入 Rocky。

同一条命令出现在不同教程里,前提可能完全不同。例如安装某个软件之前,教程可能已经启用了额外仓库;你只复制最后一行,就可能遇到找不到包、版本不符或依赖冲突。按路径阅读,能够保留这些前提。

先把三种变化分清

操作改变什么重点检查
同一大版本内更新系统包与补丁软件源、事务、服务重启与应用回归
从其他 EL 系发行版迁入发行版包、仓库与标识迁移工具支持矩阵、第三方包与回退
从旧大版本迁往新大版本系统基线与大量依赖硬件、应用认证、数据搬迁与重新部署

把三者都叫作“升级”,容易误判工具能力。一个支持特定源系统迁移到同代 Rocky 的工具,不自动具备任意跨大版本升级能力。

Rocky 官方提供 migrate2rocky 文档,但实际使用前仍须核对源版本、目标版本及当前限制。脚本能启动不是支持矩阵匹配的证明,也不能用一次测试机成功替代生产验收。

新装机可以这样使用网站

先从版本页面确认目标大版本,再到下载入口选择架构和介质。校验镜像之后,在虚拟机或备用机器完成一次安装。

首次进入系统,建议保存以下基线:

cat /etc/os-release
uname -m
uname -r
dnf repolist
systemctl --failed
ss -lntup

记录发行版、内核和仓库,是为了日后知道自己从什么环境开始;检查监听端口,是为了确认实际开放了哪些服务。输出里可能包含进程和网络信息,分享排障记录时按需要脱敏。

随后再建立日常运维流程:普通用户管理、密钥登录、时间同步、日志、备份与安全更新。验收不止看“SSH 能登录”,还应确认重启后业务自动启动、挂载正常、监控恢复、备份任务确实完成。

迁移用户最需要的是一份业务清单

迁移工具通常处理发行版层面的变化,而应用是否正常,需要维护者自己验证。

建议先列出业务实际使用的内容:Web 服务、数据库、运行时、定时任务、外部挂载、证书、监控代理以及闭源驱动。每项都记录安装来源、版本、数据目录、启动方法和验收动作。

项目不能只看建议增加的验收
数据库进程是否存在业务账号读写、扩展、备份恢复
Web 服务首页是否打开登录、上传、后台任务和反向代理
存储目录是否存在挂载点、权限、重启后可用性
容器容器是否 Running数据卷、网络、健康检查和外部依赖

如果无法在另一台机器恢复业务,就不要把“原地迁移失败后重新装回来”当成完整回退方案。系统可以重装,迁移期间产生的新数据却需要单独处理。

兼容目标与具体支持要分开看

Rocky Linux 的兼容定位对选型有意义,但业务供应商是否支持某个版本、驱动是否适配某个内核、云镜像是否包含所需组件,仍需逐项核查。

例如,一个闭源备份代理可能只支持列出的发行版和版本组合。即使它在其他系统上能够运行,也不意味着供应商承诺处理事故。遇到这种约束时,应把合同支持和技术可运行性分成两栏记录。

与 RHEL 的差异适合作为阅读入口。不要仅凭同样使用 RPM 和 DNF,就把发行版、仓库、认证以及支持服务视作相同。

遇到故障,按层定位

启动失败、仓库报错与应用启动失败需要不同证据。前者看控制台、启动项和内核日志;仓库问题看地址、签名与依赖;应用问题则回到服务单元、权限和应用日志。

一个有用的反馈通常包含:系统版本、执行命令、完整错误、最近一次改动,以及已经做过的检查。必要时附上脱敏后的配置片段,而不是整份带有密码或令牌的配置。

我的期待是,rocky.casa 能成为日常操作的入口,MF8 博客则补充跨发行版比较和具体故障分析。如果你正在决定从 CentOS 转向哪里,可以先看选型比较,确定路线之后再进入文档站。

官方资料与继续阅读