1. 为什么必须迁CentOS 7 停服之后的现实压力与迁移思路1.1 憋了快一年为什么这次非迁不可CentOS 7 停止维护这件事大家心里都有数但真正被逼到必须动手往往是某次安全扫描报告里冒出来十几个 CVE或者等保测评要求整改。堡垒机不像普通业务系统它管着所有服务器的登录入口一旦系统本身存在未修复漏洞攻击者拿下堡垒机就等于拿下了整个机房的钥匙。我在这次迁移前也纠结过一阵子Jumpserver 跑得好好的用户、资产、授权策略几千条贸然迁出问题怎么办但后来想通了CentOS 7 的镜像源已经全面进入 vault 归档阶段yum 装个基础包都要绕来绕去更别说安全补丁了。堡垒机这种核心安全设施长期跑在一个已被上游放弃的操作系统上本身就是最大的风险。所以接到“CentOS 7 全量替换”的指令后我第一反应就是Jumpserver 必须作为第一批迁走的核心系统——先迁最要命的再铺开其他业务。这次迁移我的目标系统选的是 Rocky Linux 9。原因很直接Rocky Linux 是 RHEL 9 的二进制兼容发行版运维习惯和 CentOS 几乎一致systemd 管理服务、firewalld 配置防火墙、dnf 装包这些操作可以无缝平移。对于想把 CentOS 7 尽快替换掉的团队来说Rocky Linux 9 的学习成本最低社区活跃企业用起来也放心。1.2 Jumpserver 组件拆解迁移前先把架构看透迁移 Jumpserver 前一定要先把它的组件结构摸清楚。Jumpserver 不是一个单进程程序而是由多个子服务协作组成core核心 API 服务负责认证、授权、资产管理、审计等主逻辑。kokoSSH 协议的字符型连接代理用户通过 Web 终端连 Linux 服务器走的就是它。lionRDP/VNC 协议的图形连接代理连 Windows 服务器用的。magnus数据库代理支持通过堡垒机连接 MySQL、Oracle 等数据库。lina / luna前端静态资源服务负责渲染 Web 界面。celery后台任务队列处理会话录像清理、邮件通知、定期任务等。redis缓存和任务队列的载体保存临时会话状态。mysql / postgresql核心业务库用户、资产、权限、审计记录的最终存储。理解了这套架构迁移时就知道要搬哪些东西了。不是把整个目录拷过去就能跑而是要确保新环境里每个组件版本匹配、数据库数据完整、密钥文件一致。很多人在迁移后遇到“用户登录不上”、“会话录像看不了”之类的怪问题十有八九是只迁了数据库没管密钥和持久化目录。1.3 迁移方案的选型同版本复刻还是借机升级迁移方案上我见过两条路线。第一条是在 Rocky Linux 9 上直接部署一套和旧环境同版本或同大版本的 Jumpserver然后把数据导入。好处是风险最小、验证路径最短适合把堡垒机当“生产基础设施”、追求稳定压倒一切的团队。第二条是借迁移机会把 Jumpserver 跨版本升级。比如 CentOS 7 上跑的 v2.x直接趁迁移升到 v3.x 甚至 v4.x。好处是能少折腾一次坏处是同时叠加了“操作系统版本变化”和“Jumpserver 大版本变化”两个变量出问题时很难定位是系统问题还是应用问题。我的建议是如果旧堡垒机当前版本还处于官方支持周期内优先走第一条路线——新系统装同版本数据迁移验证通过后再找窗口单独升级版本。如果旧版本实在太老比如 v2.x那就先在新环境装好已测试兼容的 v3.x 版本再把旧数据导进来尽量一次完成系统切换和版本刷新但提前做足兼容性测试。2. 新环境部署Rocky Linux 9 上的基础组件与 Jumpserver 安装2.1 系统层面的准备工作少一步后面都麻烦Rocky Linux 9 安装时我建议选择 Minimal 版本减少不必要的软件包降低攻击面。装完系统后先做几件基础工作。第一件事是配置好 dnf 源。CentOS 7 时代习惯了 yumRocky Linux 9 默认用 dnf虽然命令用法几乎一样但部分参数有差异比如yum clean all对应dnf clean all旧脚本里的yum命令在新系统上要替换。第二件事是关闭 SELinux 或正确配置策略。Jumpserver 官方安装脚本在检测到 SELinux 为 enforcing 模式时经常会执行某些目录读写操作失败。我不太建议无脑关闭 SELinux但在隔离的内网环境里实际运维时关闭它往往是最省事的方案。如果你必须保持 enforcing那就要单独给 Jumpserver 相关端口和目录打策略标签这个工作量不小而且每次升级都可能要重新调整。# 临时关闭 SELinux setenforce 0 # 永久关闭编辑 /etc/selinux/config sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config第三件事是安装常用基础工具和时间同步。堡垒机是审计设备时间不准会导致会话记录时间错乱直接影响追责审计。所以 chrony 必须配好而且要让堡垒机同步到公司内部统一的时间源。dnf install -y vim wget tar lsof net-tools chrony systemctl enable --now chronyd timedatectl set-timezone Asia/Shanghai2.2 数据库与缓存的初始化字符集和时区最容易踩坑Jumpserver 元数据可以存在 MySQL 或 PostgreSQL 里。我这次用的是 MySQL 8.0。在 Rocky Linux 9 上安装 MySQL 8.0直接用官方源即可。安装完成后创建库和账号时要特别留意字符集。Jumpserver 在安装阶段会把建表 SQL 执行到数据库里如果库的默认字符集不是 utf8mb4后面一旦遇到生僻字、特殊符号就可能出现乱码或者写入报错。dnf install -y mysql-server redis systemctl enable --now mysqld redisCREATE DATABASE jumpserver DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER jumpserver% IDENTIFIED BY Your_Strong_Password; GRANT ALL PRIVILEGES ON jumpserver.* TO jumpserver%; FLUSH PRIVILEGES;还要把 MySQL 的时区参数和连接层字符集调整好。SET GLOBAL time_zone 08:00; SET GLOBAL character_set_server utf8mb4;Redis 做缓存一般本地部署就够用。如果 Redis 设置了密码要在 Jumpserver 配置里对应填好没设密码的话至少把 Redis 绑定地址限制为 127.0.0.1别暴露到外部网络。2.3 Jumpserver 本体的部署官方安装器比手工部署靠谱得多从 v3.x 开始官方统一推荐使用 jumpserver/installer 仓库的安装器部署。相比手工拉代码、一个个启动组件这样的方式对依赖关系的处理省心非常多升级也方便。拿到安装器后先解压进入目录编辑config.txt把数据库和 Redis 连接信息填成步骤 2.2 里建好的内容cd /opt tar xf jumpserver-installer-v3.14.4.tar.gz cd jumpserver-installer-v3.14.4# config.txt 关键配置段 DB_HOST127.0.0.1 DB_PORT3306 DB_USERjumpserver DB_PASSWORDYour_Strong_Password DB_NAMEjumpserver REDIS_HOST127.0.0.1 REDIS_PORT6379 REDIS_PASSWORD然后执行安装脚本./jmsctl.sh install安装完成后用./jmsctl.sh status查看各组件状态确保 core、koko、lion、magnus 等都处于运行状态。我用官方安装器部署过多次只要网络正常、磁盘空间够基本一次能过。常见的问题是“容器无法启动”多数是数据库连接信息填错或者 MySQL 版本不兼容。这里有一个很容易被忽略的点Jumpserver 新版本的组件大多跑了 Docker 容器里即使你是用裸机部署方式Docker 环境也是必需的。安装器会自动处理 Docker 安装但如果你的网络环境受限、无法访问 Docker Hub那就要提前准备离线镜像包否则安装器会在拉镜像时卡住。生产环境尽量用离线包方式把安装器和镜像一次性拷到新机器上速度比在线拉取快得多也不容易中断。2.4 域名入口与 Nginx 反向代理配置Jumpserver 自带的安装器默认是用 Nginx 容器对外提供 Web 服务默认监听 80 端口。实际生产环境里堡垒机一般会通过域名访问并且启用 HTTPS。网上有不少教程直接让改容器内的 Nginx 配置但我不建议这么做升级容器后配置很容易被重置。更稳的做法是Jumpserver 容器内继续用默认的 HTTP 80 端口在宿主机上另装一个 Nginx做反向代理和 SSL 终止。这样证书轮换、Nginx 调优都独立于 Jumpserver 自身。server { listen 443 ssl; server_name jump.example.com; ssl_certificate /etc/nginx/ssl/jump.crt; ssl_certificate_key /etc/nginx/ssl/jump.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; } }注意 WebSocket 的location /ws/配置不能丢Jumpserver 的 Web 终端就是靠 WebSocket 维持实时连接的。如果不转发Upgrade头用户在 Web 终端里敲命令会时不时断连这是很多人忽略的“小问题”。3. 数据备份与迁移执行把旧堡垒机完整“搬”过去3.1 迁移前必须备份的东西一个都不能少Jumpserver 的数据并不全在数据库里。我列一下这次迁移我实际备份的内容MySQL 业务库全量备份用户、资产、授权规则、系统配置这是核心中的核心。Redis 持久化数据保存了部分缓存和会话状态虽然很多能重建但最好一并备份。/opt/jumpserver安装目录或你的部署路径安装配置、证书、密钥等全在这里面。core 的data目录里的密钥文件这是很多人忽略的致命点。历史会话录像和操作日志这是堡垒机的审计价值所在丢了等于审计能力直接清零。这里单独强调一下密钥文件。Jumpserver 里的资产登录凭据很多是以加密方式存在数据库里的但解密依赖 core 服务密钥目录下的 key 文件。如果只导数据库、不迁移密钥你会发现所有资产密码都解不开用户无法通过堡垒机登录任何服务器。这个坑特别典型我在论坛上看到过不止一次。所以迁移策略很简单新环境部署好同版本 Jumpserver 后先停掉 core 服务用旧环境的密钥文件覆盖新环境的对应目录再启动服务。顺序不能反否则 Jumpserver 会重新生成新密钥导致数据失配。3.2 数据库和 Redis 的备份操作备份数据库时建议用mysqldump加--single-transaction参数这样备份期间不会锁表对正在使用的生产环境友好一些。同时把存储函数、触发器、事件一起备份。mysqldump -ujumpserver -p --single-transaction --routines --triggers --events jumpserver jumpserver_backup_$(date %F).sqlRedis 备份最简单的方式就是触发一次BGSAVE然后把生成的dump.rdb文件拷走。redis-cli BGSAVE cp /var/lib/redis/dump.rdb /backup/redis_dump.rdb再把 Jumpserver 相关目录打包。tar czf jms_full_backup_$(date %F).tar.gz /opt/jumpserver这一步做完你手里就有了旧环境的完整快照。备份文件建议异地或者单独存储不要在旧服务器本地放一份就完事万一迁移过程中旧服务器出问题备份也丢了那就真的欲哭无泪。3.3 数据导入与组件切换新环境 Jumpserver 安装并验证启动正常后开始数据导入。数据库恢复前先停掉新环境的 core 和 celery 服务避免写入操作和恢复的数据产生冲突。./jmsctl.sh stop mysql -ujumpserver -p jumpserver jumpserver_backup_$(date %F).sqlRedis 的恢复是把备份的dump.rdb放到新 Redis 的持久化目录覆盖新生成的文件然后重启 Redis。systemctl stop redis cp /backup/redis_dump.rdb /var/lib/redis/dump.rdb chown redis:redis /var/lib/redis/dump.rdb systemctl start redis最后把旧环境的密钥目录同步过去再启动 Jumpserverrsync -av old-server:/opt/jumpserver/core/data/keys/ /opt/jumpserver/core/data/keys/ ./jmsctl.sh start同步密钥时要注意目录权限Jumpserver 容器内用户对密钥文件的可读权限必须正确否则 core 还是无法用密钥解密资产口令。3.4 版本差异的兼容性处理如果你的旧堡垒机是 v2.x而新装了 v3.x数据导入后多半会遇到“版本升级”提示。Jumpserver 在启动时会检测数据库结构版本并自动执行迁移脚本。这个过程通常能完成但如果跨的版本太远建议按官方升级路径走先在旧版本上逐步升级到某个过渡版本再导出数据。我的实际做法是先在旧机器上把 Jumpserver 升级到与目标环境同一版本确认业务正常后再备份导入新环境。这样数据库结构始终是一套导入后不会出现“结构太老、脚本跑不动”的问题。4. 上线验证与安全检查迁移完成不等于迁移成功4.1 功能验证清单从登录到业务侧的完整链路数据导入只是第一步真要宣布迁移成功得把整个业务链路完整跑一遍。我每次迁移都会列一张验证清单一项一项打勾Web 管理页面能否正常登录admin 账号是否可用。用户和用户组数据是否完整密码策略是否和旧环境一致。资产列表是否齐全包括 Linux、Windows、网络设备、数据库资产。授权规则是否正确绑定用户是否能正常看到被授权的资产。Web 终端连接 Linux 资产敲命令是否流畅字符终端是否卡顿。RDP 连接 Windows 资产远程桌面能否正常打开。数据库代理连接 MySQL、Oracle是否能正常执行查询。文件传输功能SFTP 上传下载是否正常。会话录像是否正常录制、回放。命令过滤规则是否生效高危命令是否被拦截。你可能觉得这么多项一个个测太费时间但堡垒机这东西任何一个功能静默失效都可能在后续使用中造成大麻烦。而且迁移后相当一段时间内用户会集中用堡垒机办公如果有功能异常上报的都是突发状况不如现在一条一条过清楚。4.2 数据一致性核对功能验证之外数据层面也要抽查。我的做法是挑几类关键数据进行总量对比比对用户总数、资产总数、授权规则数。抽查几个高权限账号看资产列表和授权是否完整。随机找一条授权规则解绑再绑定看状态是否同步。检查时发现一个细节问题旧环境的账号口令如果被密钥文件加密导入新环境时必须确保密钥文件版本一致否则授权规则在界面上看着正常但实际连接资产时会报“认证失败”。所以“先配密钥、再导数据、再启服务”这个顺序一定要坚持。4.3 防火墙与系统安全的复核新系统上线前还要过一遍安全配置。# 只放行必要端口 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-port2222/tcp firewall-cmd --reloadJumpserver 默认 SSH 连接端口是 2222koko 组件需要监听这个端口对外提供 SSH 转发。如果用户习惯用原生 SSH 客户端连接堡垒机这个端口必须在防火墙放行。另外MySQL 和 Redis 如果和 Jumpserver 在同一台机器那它们的端口最好只监听本机不要让 3306 和 6379 暴露到外网。尤其 Redis很多人因为偷懒不设密码还直接监听 0.0.0.0结果被扫到后植入挖矿程序这是老生常谈的问题了。4.4 旧系统保留多久比较稳妥迁移切量之后旧堡垒机不要立即销毁。至少要保留一到两周的观察期万一新环境出现只在特定场景下才触发的异常还能切回旧环境应急。实际操作时我会在旧机器网络层直接限制来源 IP只允许少数管理员的 IP 访问同时保留完整的只读权限防止误操作改变旧系统状态。等新环境稳定运行、所有的历史录像都确认能正常回放后再下线旧机器。5. 实战踩坑记录与排查技巧5.1 字符集问题乱码和写入报错的元凶这次迁移遇到的一个明显问题是从旧库导出的 SQL 文件默认可能是 latin1 字符集导入到 utf8mb4 的新库后中文全是乱码。排查过程很简单导入后随便看一眼用户昵称就发现问题了。解决方法是备份导出时不要偷懒明确指定字符集mysqldump -ujumpserver -p --default-character-setutf8mb4 --single-transaction jumpserver backup.sql导入时也指定字符集双保险mysql -ujumpserver -p --default-character-setutf8mb4 jumpserver backup.sql5.2 Redis 启动异常持久化文件引入的兼容性问题第一次在新系统恢复 Redis 时因为版本小版本不一致直接拿旧环境的dump.rdb覆盖过去导致 Redis 启动失败。报错信息是持久化文件版本不匹配或者加载失败。排查思路很简单启动 Redis 时开日志看具体报错。解决办法是把 Redis 升级到一致版本后再加载旧 RDB 文件或者通过旧环境redis-cli --rdb命令导出兼容性更好的备份文件。这里也提醒一下如果新旧 Redis 大版本差距很大比如 5.x 到 7.x直接覆盖 RDB 文件基本会失败最好的办法是让 Redis 版本尽量保持统一。5.3 防火墙和 SELinux 的隐形拦截还有一次比较耐人寻味的故障是Jumpserver 界面显示正常但用户从 Web 终端连资产时一直超时。我一度以为是 koko 组件问题后来排查才发现是新防火墙规则只放行了 80/443 端口koko 和外部通信的端口没放行。所以部署新环境时一开始就把 2222 等端口列入放行名单别等用户抱怨了再补救。SELinux 的坑则更隐蔽——即使关掉了也建议确认一下sestatus输出是 disabled 还是 permissive因为临时关闭和永久关闭是两回事重启后策略会重新加载。5.4 历史录像和日志文件的存储规划迁移后另一个容易被忽视的点是历史会话录像的存储。Jumpserver 的录像文件默认存在本地持久化目录很多公司的录像文件动辄几百 GB迁移时必须规划好磁盘空间。我在这次迁移前特意给数据盘做了扩容并建议后续把/opt/jumpserver里的录像存储目录单独挂载到独立数据盘避免日志和录像把系统盘塞满。录像文件一般不会被频繁读取但是要长期保留用对象存储归档会更好。5.5 迁移之后的工作总结这次从 CentOS 7 迁移到 Rocky Linux 9整体过程是顺利的但顺利建立在对每个环节都做了预案的基础上。迁移最忌讳想当然觉得“反正都是 Linux直接复制过去跑一遍就行”。堡垒机牵扯到数据库、缓存、密钥、录像、网络代理、Web 服务任何一环脱节都可能出问题。最后再分享一个小技巧迁移前花十分钟把旧环境的完整依赖清单导出一份包括 Jumpserver 版本号、MySQL 版本、Redis 版本、Nginx 版本以及各个配置文件的关键项。新环境部署时照着这个清单一步步对齐比事后回忆省力得多也不容易漏项。