前言
PATH being overwritten · Issue #6785 · saltstack/salt · GitHub
ssh连接远程主机执行脚本的环境变量问题_whitehack的博客-CSDN博客
ssh连接远程主机执行脚本的环境变量问题 (feihu.me)
01-案例现象
发现通过 saltstack 去远程执行脚本因为获取不到 minion 的环境变量导致脚本运行失败
我们先在 master 去获取一下 minion 的环境变量
salt 192.168.149.130 cmd.run 'echo $PATH'
再去 minion 上查看环境变量
是不是发现不对劲了,通过 master 远程获取 minion 的环境变量跟去 minion 本地获取的环境变量不一致!
但在远程主机上操作不也是通过 shell 来执行的吗?难不成在远程主机上操作的 shell 和在本地操作的 shell 有区别?
02-定位问题
我通常使用的是 bash,所以我们 man 一下看看
bash 的四种模式
在 man bash 的 INVOCATION一节讲述了 bash 有四种模式
bash 会根据这四种模式而选择加载不同的配置文件,而且加载的顺序也有所不同
里面有两个概念需要先解释一下—— interactive 和 login
- login
login 即登录的意思,login shell 是指用户以非图形化界面或者以 ssh 方式登录到机器上时获得的第一个 shell (简单点来说就是需要输入用户名和密码的 shell)
登录机器后用户获得的第一个 shell 就是 login shell
- 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 )时,执行该文件
03-解决问题
通过上面我们了解到 bash 有四种运行模式
结合上面的问题我们知道
- 通过 master 对远程 minion 执行命令是非交互 nologin 模式的bash。获取到的是minion 的 $BASH_ENV 来获取指定配置文件(minion本地设置了这个变量也不行,需要在命令行里设置)
- 直接在 minion 本地执行命令是交互 login 模式的 bash。获取到的是 minion 的 /etc/profile 文件
- 因为读取到的配置环境不一样,所以就会出现环境变量不一样的问题
如何解决呢?
- 方法一
远程执行的命令行里定义一下 $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: 不读取任何文件