SaltStack cmd.run CLI执行正常但Jinja场景报错的差异问题

• CLI 直接执行的逻辑：本地终端输入的整条命令，先由本地shell完成引号解析，将完整的元数据获取字符串作为参数传递给salt-ssh进程。salt-ssh收到参数后，建立SSH通道连接目标EC2实例，将完整命令字符串交给实例上的shell（如/bin/bash）做二次解析执行，shell可正常识别变量赋值、$()命令替换、&&连接符等语法，因此可正常返回结果。
• Jinja模板内联调用的逻辑：Jinja求值阶段不会自动调用远端shell解析命令字符串。默认情况下，cmd.run会使用Python原生的shlex.split逻辑对命令字符串做空白拆分，将拆分后的参数列表直接调用系统接口执行第一个字段对应的可执行文件，完全跳过shell语法解析。

遇到的FileNotFoundError就是该逻辑导致的：拆分命令字符串时，第一个字段被切为TOKEN=$(curl，程序直接尝试查找这个路径的可执行文件，自然会抛出不存在的错误，根本没有走到shell解析的环节。

之前尝试为特殊字符加转义的操作无法生效，核心原因是命令字符串从未被传递到shell层，所有转义操作对Python原生的参数拆分逻辑完全无效。
报错是Pythonsubprocess模块抛出的，不是shell抛出的——如果是shell执行失败，会返回类似bash: TOKEN: command not found的标准错误，而非Python层面的文件不存在异常，通过报错栈来源即可直接定位执行模式的问题。

Salt的cmd.run模块有个关键参数python_shell，默认值为False：

• 当参数为False时，按Python原生模式拆分参数执行，不启用shell解析，适合无特殊语法的简单命令，安全等级更高，可避免shell注入风险。
• 当参数为True时，会将完整命令字符串传递给系统shell执行，兼容所有shell语法，和终端直接敲命令的效果完全一致。

CLI入口封装的cmd.run默认强制开启了shell执行模式，因此不需要额外传参；但Jinja内联调用的模块接口为了安全，默认关闭了shell执行模式，必须显式传参打开。

1. 在Jinja调用cmd.run时，显式开启shell执行模式：

{{ salt["cmd.run"](
    cmd='TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -s -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") && curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/public-ipv4',
    python_shell=True
) }}

2. 更优的替代方案是使用Salt内置的EC2元数据模块，不需要手动编写curl脚本处理IMDSv2令牌逻辑——模块内部已经实现了令牌获取、有效期刷新的全流程，直接调用即可拿到公网IP：

{{ salt['ec2_metadata.public_ipv4']() }}

• 遇到Python类的执行报错时，首先区分报错来源：如果是Python层抛出的异常（如FileNotFoundError、参数类型错误），优先检查执行模式、参数传递逻辑；如果是shell层抛出的语法错误，再去排查转义、特殊字符解析问题。
• 做最小化复现验证：分别测试带/不带python_shell=True参数的简单命令（如echo test && echo test2），观察拆分逻辑的差异，即可快速定位问题。
• salt-ssh场景下注意模块执行位置：Jinja内联的salt模块调用会通过SSH通道在目标远端主机执行，不会在管理节点本地运行，因此不需要担心跨主机拿不到元数据的问题。

内容的提问来源于stack exchange，提问作者mr.nekketsu