FusionCompute管理员密码重置：通过命令行安全恢复Web管理权限

1. 项目概述：当管理员密码成为“拦路虎”

在虚拟化平台的日常运维中，管理员账户的密码是通往核心管理界面的唯一钥匙。想象一下，当你需要紧急调整资源、排查故障或进行例行维护时，却因为忘记了FusionCompute管理界面的admin密码而被挡在门外，那种感觉无异于被锁在了自家数据中心的核心机房外面。这并非危言耸听，而是许多运维工程师都可能遇到的真实困境。无论是人员交接时密码记录不全，还是安全策略要求定期更换密码后遗忘，亦或是测试环境长期未登录导致的记忆模糊，“重置FusionCompute页面admin密码”都是一个极具现实意义且必须掌握的恢复性操作。

这个操作的核心价值在于，它不依赖于任何第三方工具或复杂的底层破解，而是利用FusionCompute系统自身提供的、合法的恢复机制，重新获得对管理平台的控制权。整个过程需要严谨的操作和对系统架构的清晰理解，因为任何不当步骤都可能影响平台的稳定运行。本文将从一个资深运维的角度，详细拆解在标准FusionCompute环境下，通过后台命令行安全、有效地重置Web管理界面admin密码的全过程，并分享其中容易踩坑的细节和原理。无论你是初次接触该平台的新手，还是需要一份可靠操作指南的老兵，这篇内容都将提供从思路到实操的完整参考。

2. 核心思路与方案选型：为什么是后台命令行？

面对FusionCompute管理员密码丢失，首先需要明确一点：我们无法也绝不应该尝试去“破解”或“绕过”Web前端的登录验证。那些网络热词中提到的“修改请求头role=admin”或尝试各种密码破译工具，在正规的企业级虚拟化平台面前不仅是徒劳的，更是危险且不合规的。FusionCompute作为企业核心基础设施，其安全设计不会留下如此低级的漏洞。正确的途径是寻找系统预留的、官方的身份恢复通道。

经过对FusionCompute架构的分析，可行的方案通常指向其底层基础——通常是基于Linux的CNA（计算节点代理）或VRM（虚拟资源管理）节点。密码信息最终会存储在系统的某个数据库或配置文件中。因此，主流且官方支持的方法就是通过SSH登录到FusionCompute的后台操作系统，找到并修改与Web认证相关的密码存储字段。这与“centos7重置root密码”、“linux密码重置”等热词背后的逻辑一脉相承，都是通过底层系统访问来重置上层应用凭证。

这里就涉及到方案选型的关键：是重置VRM节点上的密码，还是重置CNA节点上的？这取决于你的FusionCompute部署模式。

• 标准模式（含VRM）：Web管理界面（FusionCompute Portal）的认证主要由VRM节点负责。因此，我们需要操作VRM节点。这也是最常见的情况。
• 精简模式（无VRM，仅CNA）：管理功能集成在CNA上，此时则需要操作主CNA节点。

在开始前，务必通过管理IP的SSH端口测试，确认能登录到哪个节点，并查看其主机名或提示符来区分角色。本次演示将以最常见的、带有独立VRM节点的标准部署模式为例进行讲解。选择命令行方案的优势在于：1.可靠性高：是经过验证的官方或社区通用方法；2.影响范围小：仅修改认证数据，不涉及业务虚拟机运行；3.无需额外工具：仅需SSH客户端（如PuTTY、Xshell）。

注意：在执行任何重置操作前，请务必确认你有权限物理或网络访问到服务器，并且了解此操作可能带来的风险。建议在变更窗口或测试环境中先行演练。

3. 实操前的关键准备与环境确认

“工欲善其事，必先利其器。” 在动手敲命令之前，充分的准备工作能避免大半的麻烦。这个阶段的目标是清晰地定位目标节点并建立安全的连接通道。

3.1 确认网络与登录信息

首先，你需要知道FusionCompute管理平面的IP地址。这通常是你在浏览器中访问FusionCompute Portal所使用的IP。然后，尝试通过SSH连接这个IP地址的22端口。

ssh root@<管理IP>

或者使用PuTTY等工具进行连接。

这里会遇到第一个常见卡点：SSH的root密码是什么？这个密码与Web界面的admin密码是两套独立的凭证。在FusionCompute初始安装时，会分别设置VRM/CNA节点的root密码和Web登录的admin密码。如果你连root密码也遗忘了，问题会变得更复杂，可能涉及通过Console口或iKVM进入单用户模式重置，这超出了本文范围。我们假设你仍保有SSH的root密码。

3.2 识别节点角色

成功登录后，你需要立即判断当前节点是VRM还是CNA。有几个快速识别的命令：

• 查看主机名：hostname。VRM节点的主机名通常包含“VRM”字样。
• 查看进程：ps -ef | grep tomcat或ps -ef | grep galaxengine。VRM上会运行大量的Java进程（如与Web管理相关的服务）。
• 查看安装目录：ls /opt/galax。这个目录的存在性是一个重要标志。

如果当前节点是CNA，你可能需要找到并登录到VRM节点。在标准部署中，VRM可能有一个独立的管理IP，或者安装在某个特定的CNA节点上作为虚拟机运行。你需要联系当初的部署人员或查阅架构文档来确定VRM的IP。如果VRM是虚拟机，你可能需要先登录到其所在的CNA主机，再通过virsh list或xl list命令找到VRM虚拟机，并尝试通过虚拟机的Console或网络进行连接。

3.3 备份关键数据（重要！）

在修改任何系统配置前，备份是铁律。虽然密码重置操作本身修改的数据量很小，但备份能让你在发生意外时（例如误操作了其他配置文件）有回滚的可能。

1. 备份待修改的配置文件：我们即将操作的是与用户认证相关的文件。可以先找到它并备份。例如，使用cp命令。
2. 记录当前状态：执行cps host-list或查看其他系统状态命令，记录当前集群和主机概况。这有助于在操作后验证系统是否正常。

准备工作就绪，并且确认我们已经登录到了正确的VRM节点后，就可以开始核心的重置操作了。

4. 核心操作步骤详解：定位与修改密码字段

这是整个流程最核心的部分，需要格外细心。不同版本的FusionCompute，其密码存储的机制和位置可能略有差异，但原理相通：找到存储admin用户密码哈希值（或加密值）的数据库或文件，并将其替换为一个已知密码的哈希值。

4.1 寻找密码存储位置

经过多个版本的实践，FusionCompute Web用户的认证信息通常存储在内嵌数据库中。对于早期版本，可能是Derby或HSQLDB，后期版本则更可能使用PostgreSQL。我们无需深究数据库类型，只需要找到访问它的方法。

一个常见且相对稳定的入口是通过FusionCompute自带的数据库命令行工具。请按顺序尝试以下步骤：

步骤一：切换到数据库操作目录并连接

cd /opt/galax/base/tomcat/webapps/Client/WEB-INF/classes # 或者尝试 /opt/galax/... 下的其他相关路径，具体路径可能因版本而异 # 查找是否有dbscript目录或包含数据库驱动jar包的目录

更通用的方法是寻找galaxengine服务使用的数据库连接配置。我们可以通过查找配置文件或进程参数来定位。

ps -ef | grep galaxengine | grep -v grep

在输出中，寻找包含-Ddb.url或-Ddatabase.home的Java启动参数。这个参数指明了数据库文件或连接字符串的路径。

步骤二：使用内置工具查询用户表假设我们找到了数据库的JDBC连接信息。FusionCompute通常会提供一个封装好的数据库查询脚本或工具。例如，可能会有一个querydb.sh或类似的脚本在/opt/galax/tools/目录下。如果找不到，我们可以尝试直接使用Java命令调用HSQLDB或Derby的交互工具。

这里提供一个基于常见情况的实操路径（以可能存在的HSQLDB为例）：

# 进入可能包含数据库文件的目录 cd /opt/galax/data/db # 查看是否存在 .script, .log, .properties 文件（HSQLDB特征） ls -la

如果存在，可以使用以下方式连接：

java -cp /opt/galax/base/tomcat/webapps/Client/WEB-INF/lib/hsqldb-*.jar org.hsqldb.util.DatabaseManagerSwing # 注意：上述jar包版本号需替换为实际存在的文件名。

但生产环境通常无图形界面，所以更常用命令行工具DatabaseManager：

java -cp /opt/galax/base/tomfat/webapps/Client/WEB-INF/lib/hsqldb-*.jar org.hsqldb.util.DatabaseManager -url jdbc:hsqldb:file:/opt/galax/data/db/galaxdb -user sa -password

重要提示：上述路径、jar包名、数据库URL、用户名和密码都是示例，必须根据你实际环境中的发现进行替换。密码可能为空，也可能在安装时设置。如果遇到“ora-28547: connection to server failed”这类错误（这实际上是Oracle的错误码，但有时会被误用或出现在混合环境中），说明数据库连接字符串或驱动不对，需要重新确认数据库类型。

4.2 执行密码更新操作

假设我们已经成功连接到了数据库。我们需要找到存储用户信息的表，表名可能类似于TBL_USER、USERS、SYS_USER等。可以通过SQL查询来探索：

SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='TABLE';

或者直接查询可能的用户表：

SELECT username, password FROM TBL_USER;

你会看到admin用户对应的password字段，里面是一串长长的哈希值（可能是MD5、SHA-256或加盐后的哈希）。

重置密码的本质，就是将这串哈希值替换为新密码明文对应的哈希值。因此，我们需要提前生成目标密码的哈希。这里有一个关键技巧：为了确保兼容性，最安全的方式是让FusionCompute自身来生成这个哈希。我们可以通过创建一个临时用户，或者利用系统已有的密码加密逻辑。

一个经过验证的可靠方法是：直接使用已知的、正确的密码哈希值进行覆盖。如果你有一个测试环境，或者记得另一个用户的密码，你可以先查询出那个已知密码的哈希值，然后用它来覆盖admin的密码字段。这样，admin的密码就变得和那个已知密码一样了。

操作示例： 假设我们通过查询，发现用户test的密码哈希是5f4dcc3b5aa765d61d8327deb882cf99（这是“password”的MD5值，仅作示例），而admin的哈希是另一串值。我们可以执行更新：

UPDATE TBL_USER SET password='5f4dcc3b5aa765d61d8327deb882cf99' WHERE username='admin';

执行后，记得提交事务（如果数据库需要）：

COMMIT;

然后退出数据库工具。

4.3 重启相关服务使配置生效

仅仅更新数据库是不够的，因为用户认证信息可能被缓存于应用服务器的内存中。必须重启负责Web认证的相关服务。

# 查找与认证或Web服务相关的进程 ps -ef | grep -E '(tomcat|galaxengine|auth)' | grep -v grep # 通常，重启galaxengine服务是必要的。使用FusionCompute的服务管理命令更安全。 cps service-stop --service galaxengine cps service-start --service galaxengine # 或者，如果找不到cps命令，可以尝试重启Tomcat systemctl restart tomcat # 如果使用systemd # 或 /etc/init.d/tomcat restart # 如果使用init.d脚本

服务重启需要一两分钟。在此期间，Web管理界面将暂时无法访问。

5. 验证与后续配置

服务重启完成后，打开浏览器，使用admin用户和刚才设定的新密码（在上述例子中就是password）尝试登录FusionCompute Portal。

登录成功后的必须操作：

1. 立即修改密码：出于安全考虑，第一时间在“系统管理”或“个人设置”中将admin密码修改为一个强密码，并妥善保管。
2. 检查系统状态：登录后，快速浏览一下主机、集群、存储和虚拟机的状态，确保所有服务运行正常，没有因服务重启而引发异常告警。
3. 审计与记录：在运维日志中记录此次密码重置事件的时间、原因和操作人，符合安全审计的要求。

6. 常见问题排查与深度避坑指南

即使按照步骤操作，也可能遇到各种问题。下面是我在多次实践中总结的“坑点”和解决方案。

6.1 连接数据库失败

• 问题现象：执行Java数据库连接命令时，报错“Class not found”或“无法建立连接”。
• 排查思路：
  1. 路径错误：-cp参数中的jar包路径必须绝对准确。使用find /opt/galax -name \"*hsqldb*.jar\"或find /opt/galax -name \"*derby*.jar\"来精确查找。
  2. 数据库类型错误：FusionCompute版本可能已切换数据库。检查/opt/galax/data/目录下是否有postgresql目录。如果是PostgreSQL，连接方式完全不同，可能需要使用psql命令行客户端，连接信息可能在/opt/galax/etc/下的配置文件中。
  3. 权限问题：确保以root用户执行命令，并且数据库文件（如.script文件）的读写权限正常。

6.2 找不到用户表或字段

• 问题现象：连接数据库后，执行SELECT查询不到用户表，或者表结构不一样。
• 排查思路：
  1. 表名差异：直接查询数据库的系统表INFORMATION_SCHEMA.TABLES，列出所有表名，寻找与用户、认证相关的表名。
  2. 版本差异：不同版本的表结构可能有微小改动。如果找不到password字段，可以查看表结构DESCRIBE TBL_USER;，看看密码是否存储在名为credential、passwd或encrypted_password的字段中。

6.3 更新密码后登录仍失败

• 问题现象：数据库更新成功，服务也重启了，但用新密码还是无法登录。
• 排查思路：
  1. 哈希算法不匹配：这是最常见的原因。你用来覆盖的哈希值，其生成算法（MD5、SHA-256、加盐方式）必须与FusionCompute当前使用的完全一致。最稳妥的方法就是使用系统内另一个正常用户的密码哈希，如前文所述。
  2. 服务未完全生效：等待时间稍长一些，或尝试重启整个VRM虚拟机（作为最后手段）。
  3. 浏览器缓存：清除浏览器缓存和Cookie，或使用隐身模式重新登录。
  4. 多节点缓存：如果是集群环境，认证信息可能在多个节点有缓存。确保你更新的是主VRM节点的数据库，并重启了正确的服务。

6.4 操作导致服务异常

• 问题现象：重启服务后，部分功能异常或管理界面无法加载。
• 应急预案：
  1. 回退备份：立即使用之前备份的配置文件进行还原。
  2. 检查日志：查看/var/log/galax/目录下的相关日志，特别是galaxengine.log和tomcat日志，寻找错误信息。
  3. 寻求官方支持：如果影响业务，应立即联系华为技术支持，并提供详细的操作日志。

个人实操心得：

1. 测试环境先行：任何密码重置或关键操作，务必先在测试环境或克隆的环境上验证一遍完整流程。这能帮你提前熟悉路径和命令，避免在生产环境手忙脚乱。
2. 善用搜索但谨慎参考：网上关于“重置密码”的帖子很多，但很多是针对特定旧版本的。一定要以你当前环境的文件路径和进程信息为准，不要生搬硬套。
3. 记录“密码指纹”：在一切正常时，可以有意设置一个复杂但自己知道的备用管理员密码，并记录其对应的密码哈希值（通过查询数据库获得）。将这个“密码指纹”密封存档。未来需要重置时，直接使用这个哈希值覆盖，你就知道新密码是什么了，这是一个非常高效的“后门”技巧，但必须确保存档介质的安全。
4. 强化日常管理：避免依赖单一admin账户。应按照最小权限原则，为不同管理员创建角色账户，并启用审计日志。对于admin密码，使用企业密码管理器进行保管和定期更换，从根本上减少此类紧急操作的发生。

整个重置过程，本质上是对系统认证模块的一次“外科手术式”的干预。它要求操作者既要有胆大心细的动手能力，也要有对系统架构的敬畏之心。当你成功登录的那一刻，不仅意味着权限的恢复，更代表着你对于这套系统底层运行逻辑的理解又加深了一层。记住，权限越大，责任越大，恢复访问后的第一件事永远是加强安全措施。