前些天处理了一个三节点Fusioncompute虚拟化项目的用户密码遗失问题。其实问题很简单,就是FC系统的WEB界面管理员密码和远程登录VRM主机的Gandalf账户密码被改来改去,谁也不知道正确密码了。然后,这个简单的内容经过业主IT部门、设备销售部位、公司售后这一串人员之后,到我手里的时候就已经是被描述为三台主机的root密码没了、系统无法登录、要尽全力保障业务虚机数据安全了。
这件事情最搞的地方在于售前他们给华为开工单,华为一线和二线开碰头会的结果是建议整个环境推到重来……唉,不想吐槽华为虚拟化产品线已经很久了。

2025.01 北京·房山 某矿山机械公司的灯塔工程示范车间

现场调查

物理

  1. 核对现场涉及主机环境,根据售前交付的实施规划表,清点交换机和服务器的状态以及标签、机架位置、线缆连接等基本信息;
  2. 与现场甲方维护人员核对IP地址、服务器配置、主机名、上次可使用相关账号密码的关键信息;
  3. 与甲方确认必要保存的实施底线,明确业务虚机数据的规模、数量、可接受风险程度;
  4. 与甲方确认机房行为管理细则,包括明确实施期间的活动范围以及饮水 如厕等位置,也包括甲方其他关注行为违规项目(例如,甲方规定车间内必须全时佩戴安全帽);
  5. 经甲方同意,连接包括笔记本电脑电源、具体可使用的网线接口和IP地址;
  6. 如需连接外网,则要经甲方同意并在甲方同意的网络通道连接;

逻辑

  1. 依据现有信息表格,核对服务器IP地址和账号信息调查事故现场
  2. 核对故障现象,明确故障范围

故障处理

CNA主机检查

根据前期调查表格,明确VRM主机的服务器位置,登录对应CNA主机查看VRM主机属性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 查看第一台CNA主机的虚机情况
[gandalf@CNA01 ~]$ su - root
Password:
Last login: Thu Jan 9 16:01:01 CST 2025
CNA01:~ # TMOUT=0
CNA01:~ # virsh list
Id Name State
------------------------
1 i-00000002 running

# 查看第二天CNA主机的虚机情况
[gandalf@CNA02 ~]$ su - root
Password:
Last login: Thu Jan 9 16:01:01 CST 2025
CNA02:~ # TMOUT=0
CNA02:~ # virsh list
Id Name State
------------------------
1 i-00000001 running

确定VRM主机的VNC端口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 确定主VRM主机VNC端口为标准端口
# 使用标准端口通过vnc连接CNA主机01IP
CNA01:~ # modify_vm_vnc open i-00000002
vrm id:i-00000002
Begin safe stop vm i-00000002
del_nginx_libvirt_conf, cmd is sh /etc/vna-api/ecs_scripts/NginxDelServer.sh "5900"
Begin undefine vm i-00000002
Begin define vm i-00000002
Begin start vm i-00000002
add_nginx_libvirt_conf, cmd is sh /etc/vna-api/ecs_scripts/NginxAddServer.sh "172.16.199.100" "5900"
modify vm vnc success.

# 确定备VRM主机VNC端口
# 使用指定5935端口通过vnc连接CNA02主机IP
CNA02:~ # modify_vm_vnc open i-00000001
vrm id:i-00000001
Begin safe stop vm i-00000001
del_nginx_libvirt_conf, cmd is sh /etc/vna-api/ecs_scripts/NginxDelServer.sh "5935"
Begin undefine vm i-00000001
Begin define vm i-00000001
Begin start vm i-00000001
add_nginx_libvirt_conf, cmd is sh /etc/vna-api/ecs_scripts/NginxAddServer.sh "172.16.199.101" "5935"
modify vm vnc success.
# 可以看出是非标准接口
CNA02:~ # virsh dumpxml i-00000001 | grep vnc
<graphics type='vnc' port='5935' autoport='yes' listen='127.0.0.1' keymap='en-us'>

连接VRM

创建VNC连接

连接VRM主机

登录并改密

修改FC密码

查询FC数据库密码

1
2
3
4
5
# 备份用户数据库,默认密码为 SingleLOUD!1
pg_dump -U galax vrm -W SingleLOUD\!1 -t sm.tbl_user > /home/GalaX8800/tbl_user.sql

# 遗忘FC数据库密码或者非默认密码,则可以使用如下脚本查询
python -c "import fskmc; print(fskmc.FS_KMC_Manage().kmc_decrypt(\"`cat /etc/galax/gaussdb/gaussdbpwd.conf`\"))"

修改Admin密码

1
2
3
4
5
6
# 重置admin密码为初始密码为 IaaS@PORTAL-CLOUD8!
# 修改后请进入系统管理-->权限管理-->用户管理 修改管理员密码
psql -U galax vrm -W SingleLOUD\!1 -c "update sm.tbl_user set password='ed1a53af6f94d460ae36d39157e84d8bw+MJmGLcUz02' where username='admin' and usertype='0';"

# psql为非标准密码,则可以使用以下命令重置admin密码为 Huawei@123!
psql -U galax vrm -c "update sm.tbl_user set password='75832dd7fb530fc7f574d61d49cadf20rF86+JEaDx02' where username='admin' and usertype='0';"

事件总结

本次事件由于root密码其实没有变化,所以相对容易解决.如果虚拟化部署的VRM主机的root密码、gandalf密码和admin密码全没了的话,就要麻烦一些,需要将VRM进入维护模式然后再进行root密码重置。业主一直抱怨FC环境为什么不能提供硬性的重置密码功能,比如发个短信或者其他认证等方式来修改密码。

其实吧,FC系统的密码重置策略在管理不严格的甲方那边很容易造成此次事件重现。首先,FC的密码是三个月需要定期修改,并且无法复制粘贴。其次,FC的官方文档中没有应对此种事件的合理手段。本次事件耗时近六个小时,其中绝大多数时间都消耗在和400扯皮上了。使用vnc连接VRM主机的操作是我自己尝试出来的,官方文档中的Fusioncompute_VncView工具早在8.1版本中就已经EOS,二线工程师都无法下载了。另外,在FC系统之外,使用VNC连接VRM主机没有密码验证,也是挺迷的。虽然官方文档中花大篇幅描述了如何重置VNC密码,但就这么直接连上了……