通过Ansible执行OpenDistro ES安全脚本返回退出码126的问题求助

问题现象 #

通过Ansible playbook调用securityadmin.sh执行OpenDistro Elasticsearch安全初始化流程时，任务持续失败，返回退出码126，任务执行过程无任何标准输出、错误输出，手动SSH登录目标主机执行同路径、同参数的脚本却可正常运行。
对应Ansible任务配置与执行报错日志如下：

- name: Initialize elasticsearch security
  command: /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh [...]
  environment:
    JAVA_HOME: /usr/share/elasticsearch/jdk/bin/java

fatal: [sys-centos8a]: FAILED! => {"changed": true, "cmd": ["/usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh"], "delta": "0:00:00.013054", "end": "2021-02-19 09:41:50.267357", "msg": "non-zero return code", "rc": 126, "start": "2021-02-19 09:41:50.254303", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

已完成的排查动作 #

• 配置Ansible任务使用become提权至root用户执行，排除基础权限不足导致的执行失败
• 将目标securityadmin.sh脚本权限调整为777，排除脚本无执行权限触发的126类报错
• 在目标主机sudoers配置中添加Defaults env_keep += "JAVA_HOME"规则，解决sudo场景下环境变量传递异常问题
• 尝试切换执行身份为elasticsearch用户提权执行、显式配置sudo参数等方案，均未消除报错
• 交叉验证手动执行场景：无论以root还是elasticsearch用户身份SSH登录目标主机，执行相同脚本均可正常完成初始化流程，无报错

根因定位 #

• Ansible任务配置的JAVA_HOME路径存在本质错误：Java类应用的通用规范要求JAVA_HOME指向JDK安装根目录（目录下包含bin、lib等子目录），但当前任务配置中，错误把可执行文件/usr/share/elasticsearch/jdk/bin/java的完整路径赋值给了JAVA_HOME。securityadmin.sh内部会按照通用逻辑拼接Java可执行路径，即调用$JAVA_HOME/bin/java，这种错误配置下，实际生成的执行路径指向一个不存在的嵌套目录，bash尝试执行目录类型的路径时，就会返回退出码126。
• 报错无日志的原因与现象匹配：securityadmin.sh在初始化阶段会先校验Java可执行文件的有效性，检测到非法路径时会直接静默退出，不会输出任何标准输出或错误输出，和看到的空stdout、stderr的报错特征完全一致。
• 此前排查动作无效的原因：配置的sudoers env_keep规则没有解决问题，是因为错误根源不在sudo的环境变量传递环节，而是Ansible主动注入的环境变量值本身不合法。手动SSH登录时，交互登录shell会自动加载用户profile中配置的正确JAVA_HOME值，不会使用Ansible注入的错误路径，因此同脚本可以正常执行。

解决方案 #

• 修正Ansible任务中的JAVA_HOME配置值，将其改为正确的JDK根目录路径：

  environment:
    JAVA_HOME: /usr/share/elasticsearch/jdk
  

• 路径校验辅助：如果修正后仍存在异常，可在Ansible任务中临时添加调试步骤，核对实际注入的环境变量值与目标路径有效性：

  - name: 校验JAVA_HOME配置有效性
    shell: echo "Current JAVA_HOME: $JAVA_HOME && ls -l $JAVA_HOME/bin/java"
    environment:
      JAVA_HOME: /usr/share/elasticsearch/jdk
  

• 额外校验：确认目标脚本所在路径的文件系统未挂载noexec参数（可通过执行mount命令核对），避免非交互执行场景下的权限策略拦截。

内容的提问来源于stack exchange，提问作者adonas