Saltstack 环境变量的坑

PATH being overwritten · Issue #6785 · saltstack/salt · GitHub

ssh连接远程主机执行脚本的环境变量问题_whitehack的博客-CSDN博客

ssh连接远程主机执行脚本的环境变量问题 (feihu.me)

1.案例现象

发现通过 saltstack 去远程执行脚本因为获取不到 minion 的环境变量导致脚本运行失败

我们先在 master 去获取一下 minion 的环境变量

salt 192.168.149.130 cmd.run 'echo $PATH'

再去 minion 上查看环境变量

是不是发现不对劲了，通过 master 远程获取 minion 的环境变量跟去 minion 本地获取的环境变量不一致！

但在远程主机上操作不也是通过 shell 来执行的吗？难不成在远程主机上操作的 shell 和在本地操作的 shell 有区别？

2.定位问题

我通常使用的是 bash，所以我们 man 一下看看

bash 的四种模式

在 man bash 的 INVOCATION一节讲述了 bash 有四种模式

bash 会根据这四种模式而选择加载不同的配置文件，而且加载的顺序也有所不同

里面有两个概念需要先解释一下—— interactive 和 login

1. login

login 即登录的意思，login shell 是指用户以非图形化界面或者以 ssh 方式登录到机器上时获得的第一个 shell （简单点来说就是需要输入用户名和密码的 shell）

登录机器后用户获得的第一个 shell 就是 login shell

1. interactive

interactive 即交互式

交互 shell 会有一个输入提示符，并且它的标准输入、输出和错误输出都会显示在控制台上。所以一般来说只要是需要用户交互的，即一个命令一个命令的输入的shell都是 interactive shell

而如果无需用户交互，它便是 non-interactive shell。通常来说如 bash script.sh 此类执行脚本的命令就会启动一个 non-interactive shell，它不需要与用户进行交互，执行完后它便会退出创建的shell

interactive + login shell

第一种模式是 交互式+登录 shell

例如：

• 用户直接登录到机器上获得的第一个 shell
• 用户通过 ssh 连接到机器上获得的第一个 shell

加载配置文件：

• 首先加载 /etc/profile

• 然后再尝试依次去加载下列三个配置文件之一，找到一个便不再寻找

  • ~/.bash_profile
  • ~/.bash_login
  • ~/.profile

non-interactive + login shell

非交互式+登录 shell

例如：

• bash -l script.sh
• -l 参数是将shell作为一个 login shell 启动，而执行脚本又使它为non-interactive shell

加载配置文件：

• 首先加载 /etc/profile

• 然后再尝试依次去加载下列三个配置文件之一，找到一个便不再寻找

  • ~/.bash_profile
  • ~/.bash_login
  • ~/.profile

interactive + non-login shell

交互式+非登录 shell

例如：

• 在已有的一个 shell 中运行 bash，此时会打开一个交互式的shell，而因为不再需要登陆，因此不是 login shell

加载配置文件：

• /etc/bash.bashrc 和 ~/.bashrc

non-interactive + non-login shell

非交互式+非登录 shell

例如：

• bash script.sh
• ssh user@remote command
• 这两种都是创建一个shell，执行完脚本之后便退出，不再需要与用户交互

加载配置文件：

• 会去寻找环境变量 BASH_ENV，将变量的值作为文件名进行查找，如果找到便加载它

总结：

#登录机器后的第一个 shell
login + interactive

#新启动一个 shell 进程，例如运行 bash
non-login + interactive

#执行脚本
non-login + non-interactive

#运行头部有：#!/usr/bin/env bash的可执行文件
non-login + non-interactive

#通过 ssh 连接到主机
login + interactive

#远程执行脚本
non-login + non-interactive

#远程执行命令
non-login + interactive

#linux 图形化界面
non-login + interactive

bashrc VS profile

Linux 是一个多用户的操作系统，每个用户登录系统后，都会有一个专门的运行环境

这个运行环境实际上就是一组环境变量的定义，用户可以对自己的运行环境进行配置，通常在 profile 或者 bashrc 文件下进行修改

bashrc 和 profile 都是 Shell 的启动设置文件(其实这两个文件也是 Shell 脚本)，可以为当前的Shell 初始化环境变量等

• profile

  • 某个用户唯一的用来设置全局环境变量的地方
  • 用户登录之后 profile 才会运行
  • /etc/profile中设定的变量(全局)的可以作用于任何用户

• bashrc

  • bashrc 是在系统启动之后会自动运行
  • ~/.bashrc等中设定的变量(局部)只能继承/etc/profile中的变量，他们是”父子”关系

• 补充

  • ~/.bash_profile: 每个用户都可使用该文件输入专用于自己使用的 shell 信息，当用户登录时，该文件仅仅执行一次，执行用户的.bashrc文件
  • ~/.bash_logout: 当每次退出系统(退出 bash shell )时，执行该文件

3.解决问题

通过上面我们了解到 bash 有四种运行模式

结合上面的问题我们知道

1. 通过 master 对远程 minion 执行命令是非交互 nologin 模式的bash。获取到的是minion 的 $BASH_ENV 来获取指定配置文件（minion本地设置了这个变量也不行，需要在命令行里设置）
2. 直接在 minion 本地执行命令是交互 login 模式的 bash。获取到的是 minion 的 /etc/profile 文件
3. 因为读取到的配置环境不一样，所以就会出现环境变量不一样的问题

如何解决呢？

• 方法一

远程执行的命令行里定义一下 $BASH_ENV 路径，让非交互 nologin 模式下的 bash 能够获取到这个变量

salt ip cmd.run 'export BASH_ENV=/etc/profile && 执行命令' 

或者 source 一下配置文件使其生效，让当前 bash 去获取到环境变量

salt ip cmd.run 'source /etc/profile && 执行命令' 

• 方法二

在命令行里加上 runas 参数，加了这个参数之后就相当于会以 runas参数中指定的用户去登录这个 shell，就变成了非交互 login 模式下的 bash

默认会去加载 /etc/profile 配置文件

salt ip cmd.run '执行命令'  runas='root'

补充：

当 bash 分别用 bash 或者 sh 命令执行时是会有差距的

当 bash 以是 sh 命启动时，即我们此处的情况，bash 会尽可能的模仿 sh（向下兼容），所以配置文件的加载变成了下面这样：

• interactive + login: 读取 /etc/profile 和 ~/.profile
• non-interactive + login: 读取 /etc/profile 和 ~/.profile
• interactive + non-login: 读取 ENV 环境变量对应的文件
• non-interactive + non-login: 不读取任何文件