OAT添加服务器时指定用户不生效,默认采用了系统uid:gid为500的用户

【 使用环境 】 测试环境
【 OAT、OCP 】添加服务器并部署ocp
【 使用版本 】4.2.1
【问题描述】因为系统初始化安装时添加了uid:gid为500的was用户,因此OAT添加服务器时指定用户oceanbase,uid:gid为666;但在添加完服务器后,部署完ocp,发现启动的用户为uid:gid为500的was用户,不是我添加服务器时指定的oceanbase用户
【复现路径】
1、现在服务器上新增uid:gid为500的was用户
2、通过OAT进行服务器添加,并指定系统用户为oceanbase,uid:gid为666
3、通过OAT进行ocp安装,安装结束后,查看运行用户
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

根据文档库中的信息,当您在 OAT 添加服务器时指定了用户 oceanbase,但是实际部署 OCP 后发现启动的用户为 uid:gid 为 500 的 was 用户,这可能是由于 OAT 在执行某些操作时默认使用了系统中存在的 uid:gid 为 500 的用户。 [1]

解决方案

  1. 检查当前 OCP 或 OceanBase 相关的服务是否以 admin 用户运行

    • 您可以通过 ps aux | grep <service_name> 命令检查当前运行的服务是否确实使用了 was 用户。
    • 如果确实使用了 was 用户,您可以手动调整服务的运行用户。
  2. 手动修复方式

    • 通过 useraddgroupadd 命令来设置 uid=666gid=666 的 oceanbase 用户。
      groupadd -g 666 oceanbase
      useradd -u 666 -g 666 oceanbase
      
    • 确保 OAT 在添加服务器时正确指定了 oceanbase 用户。
    • 重新部署 OCP,确保 OCP 服务以 oceanbase 用户启动。
  3. 验证 OAT 配置

    • 检查 OAT 的配置文件,确保在添加服务器时指定了正确的用户。
    • 您可以在 OAT 的配置文件中查找相关的用户配置项,确保没有被覆盖或错误配置。
  4. 联系 OceanBase 支持

    • 如果上述方法仍然无法解决问题,建议联系 OceanBase 的售后支持,获取更详细的帮助和指导。

希望这些步骤能帮助您解决问题。如果还有其他疑问,请随时联系 OceanBase 的人工答疑以获取更多帮助。

更多信息请查看:

  1. 主机标准化检查项
  2. 部署 OAT
  3. 管理负载均衡
  4. 使用 OCP 部署两副本加仲裁服务的 OceanBase 集群
  5. 使用 OCP 部署三副本 OceanBase 集群
  6. 使用 OCP 部署单副本 OceanBase 集群
  7. 使用 OCP 部署单机集中式 OceanBase 数据库
  8. 部署 OCP
  9. 接管 OCP
  10. 安装 OCP

主要是部署OCP拉起的容器的admin用户id也是500,只要没有权限问题就好
后面的OBServer的用户id都能改


所以这个使用uid:gid为500的是个默认指定逻辑?
又或者说,可以指定用户与uid,但是系统中不能有uid:gid为500的用户存在?
目前权限到不影响,只是运行用户不符合投产要求

是的,根据我的观察是默认指定的逻辑。
建议就是部署OB的环境里面不要占用500的用户id,要不就是更改你这个was用户的ID :joy:

好的。了解了。多谢

OAT是企业版工具,建议去咨询商业技术支持同学。

1.如你所在的企业客户已签署OceanBase企业版销售合同,请你联系客户经理;
2.如你所在的企业客户尚未签署OceanBase企业版销售合同,你可通过OceanBase官网商务咨询页面留下你的联系方式,OceanBase企业版的业务顾问会在一个工作日内与你联系。
OceanBase官网商务咨询

https://www.oceanbase.com/contactus?fromPage=https%3A%2F%2Fwww.oceanbase.com%2Fsoftwarecenter-enterprise&dataSources=softwarecenter-enterprise_footercontact_d2022