GBase 8a运维案例:一次操作系统用户安全加固导致的扩容失败

GBase 8a集群上线项目扩容操作,最终用户出于安全考虑,都会做安全加固,结果就是一些命令表面看着很正常,可是一旦远程运行,或者多几次用户su切换,就会出问题。

现象

GBase 8a V86集群扩容操作后,报错,新节点服务无法正确启动。

GBase 8a 集群扩容操作后,报错,新节点服务无法正确启动

排查

查案gcinstall.log日志

get cluster task id fail,该错误,一般是因为集群LOCK状态,gcluster无法从gcware层拿到任务编号。

GBase 8a报错 get cluster task id fail.

查看 集群状态

集群为LOCK状态,因为5个gcware里有i3个是CLOSE状态,正好是新扩容的3个节点。截图中没有显示出来CLOSE字样。

检查gcware的配置和日志

未发现corosync.conf ,当然也没有log文件。

排查防火墙

检查防火墙,发现没有关闭。

手工关闭后,再次运行扩容。

再次报错

本次报错是无法运行gccli命令,报找不到类库和环境变量,比如GCLUSTER_HOME环境变量。

检查dba用户

因为扩容操作,必须是dba用户(一般是gbase)操作,执行某些命令会su到root下进行。测试了一下发现

  • 如果当前root登录,su - gbase可以正常运行。
  • 如果当前是gbase用户,su 到root正常,但再次su - gbase就会出现bash错误,环境变量全部都失效了

如上的情况,也导致了在集群安装后,运行gccli命令是,缺少环境变量的错误。

查看gbase用户的主目录/home/gbase,发现其属主为wheel, 也就是不是gbase:gbase,而是gbase:wheel。将整个目录的属主全部修改后,再次做su测试,问题依旧。

联系安全加固人员恢复用户安全配置

由负责人进行恢复,本次扩容延迟。

第二次扩容

一天后,再次扩容,顺利完成。

总结

某些安全加固,内部可能包含了许多我们不熟悉的配置,比如这种su - gbase, su, 再次su - gbase才会出现的问题。如不确认系统可用,可以联系先【临时】取消加固,待操作完成后,再次加固来规避。