Fabric: リモートサーバーの環境変数とPATHに問題があります（.bashrcをソーシングしていません）

これはbashのものであり、fabのものではありません。

bashが起動時にソースすることを決定するファイルは複雑になる可能性がありますhttp://blog.flowblok.id.au/2013-02/shell-startup-scripts.htmlおよびdebian / ubuntu（およびほとんどのディストリビューション）は/etc/profileでいくつかのカスタマイズがあり~/.bashrc 。

デフォルトのシェルファブが使用するのは/bin/bash -l -cで、 -lはそれを「ログイン」シェルにします。 debian / ubuntuのカスタマイズがないと、bashの「ログイン」シェルが~/.bash_profileが、 ~/.bashrcはできません。

しかし、ubuntu 16.04では、ログインシェルの場合でもデフォルトで.bashrcしているようです。 ただし、デフォルトの.bashrcの下部に追加された行は、非対話的に実行されていることを検出すると上部近くでベイルアウトするため、処理されません。

ここでは、ubuntu-16.04のデフォルトユーザー.bashrc 2行を追加しました

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

export VAR1=val1

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

export VAR2=val2

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
...

これが私がテストしているfabfileです：

from fabric.api import run, env, task

<strong i="23">@task</strong>
def get_myvars():
    run("echo VAR1=$VAR1 VAR2=$VAR2")

結果：

$ fab -H testpy05.ec2.st-av.net get_myvars
[testpy05.ec2.st-av.net] Executing task 'get_myvars'
[testpy05.ec2.st-av.net] run: echo VAR1=$VAR1 VAR2=$VAR2
[testpy05.ec2.st-av.net] out: VAR1=val1 VAR2=
[testpy05.ec2.st-av.net] out: 
...

一見正当に聞こえます、@ ploxilnに感謝します！

詳細な回答ありがとうございます！

これは標準のsshの動作とは異なるようで、デバッグが困難でした。 手動でsshを実行すると、すべて正常に機能しましたが、OSXで.bash_profileを実行していないため、ファブリックのPATH値が異なっていました。

@bitprophetこれはOSXのバグかもしれませんか？

@ code-treeファブリック1または2を使用していますか？ 1.xは明示的なシェルラッパーを使用するため、標準のOpenSSHクライアントとは異なります。 バージョン2はラッピングを行わず、sshdがユーザーに代わって実行していることに関して、OpenSSHクライアントのように動作するはずです。

バージョン1には、そのシェルラッパーを変更するためのいくつかのenv config valueオプションがあるため、IIRCが「インタラクティブモードを実行していくつかの追加ファイルを調達する」ためのbashである-iなどのフラグを追加してみてください。

私はバージョン2.2.1を使用しているので、それは奇妙です。 私は現在、アプリを機能させるために次のことを行う必要があります。
c.run('bash -l -c "python3 ./configure.py"')
Python 3をインストールしたときと同じように、Fabricによって実行されていない.bash_profileを介してPATHに追加されました。 標準の組み込みsshd構成にも変更を加えていません。

それは奇妙なことです、私は私が複製できるかどうかを見なければなりません。 私が何を意味するのかを証明するために、簡単な健全性トレースを実行しました。re：ファブリック2は何もしていません '特別な' re：sshd駆動の実行：

• Runner.runがスタートで、 commandかかります
• Runner._run_bodyを呼び出します。これはここにあり
• _run_bodyは、Runner.startを呼び出すだけです。
• ファブリックのリモートランナーの.startはこちら
• command追加の変更を加えることなく、Channel.exec_commandを呼び出すだけです。
• Paramikoがそこから引き継ぎ、コマンドがインライン化されたバニラ
• その後ssh myserver <command> 、おそらく

@ code-treeも、可能であれば、実行している内容とその他の環境の詳細（クライアントとサーバーのOS /バージョンなど）に関する詳細を投稿してください。

確かに、私は古いOSXバージョンをサーバーとして実行しています。 新しいMacOSですべてが正常に機能することを確認できれば、まあまあ。 しかし、そうでない場合は、一般的なサーバーとしてのMacOSの問題でしょうか？

• クライアント：Ubuntu 16.04、Python 3.6.6、OpenSSH 7.2p2、Bash 4.3.48、Fabric 2.2.1
• サーバー：OSX 10.11、Python 3.6.6、OpenSSH 6.9p1、Bash 3.2.57

ちなみに、これが実際に誤診のケースであるかどうか疑問に思っています。

OSXで.bash_profileを実行していないため、ファブリックのPATH値が異なります

代わりに、これは＃1744の例である可能性があります。ここで、ファブリック2は、ローカル環境変数をパイプにシャントするという点でsshとは異なりますか？ （問題の正確なenv変数と、それらがローカルとリモートで類似しているかどうかによって異なります。@ code-treeは、ローカルとリモートのbash_profileで正確な値を再確認することで、この理論を簡単に反証できます...😁）

しかし、とにかくこれを直接トラブルシューティングするつもりです。それで、私は気が狂っていないことがわかります。シェルとソースファイルに関してsshdが何をしているのかを理解しています。

また、これは＃1816のシナリオ/インテリジェンスに関連しているのではないかと思います。これもシェルとスタートアップファイルに関するものです。 ssh一方向に動作し、Fabricが別の方向に動作する（「sshdが通常シェルを呼び出す方法」ではない）というアサーションがあるため、直接関係はありませんが、とにかくリンクする価値があります。

これらの線に沿った何かに関連して、私が過去数ヶ月に行ったことを覚えているたくさんの深いsshdコードダイビングにつまずこうとしていることがわかりました。 イライラしますが、今は見つかりません。 編集：ああ、認証前にコマンドを実行することに関して、それは無関係のParamikoの問題（混乱する点がないためリンクされていない）だったと思います。 わかった。

では、コマンドexecを要求すると、実際に何が起こっているのでしょうか。

• SSH-the-protocolでは、 shellチャネル要求（ユーザーが定義したログインシェルプログラムをロードし、 command ）またはexecチャネルを作成する必要があります。リクエスト（「パスが含まれている可能性のある特定のコマンド文字列を実行する」とだけ表示され、それ以上は指定されません）
• 上で見つけたように、Paramikoは後者を行います。
• では、OpenSSH自体は実際に何をしているのでしょうか。 私はopenssh-portableのローカルチェックアウトを見ていきます（ 775f8a23f2353f5869003c57a213d14b28e0736e ）

さて、最初に少し間抜けします。 任意のDebian8.10コンテナ（OpenSSH 6.7を実行しています！）に対して実行すると、 ssh localhost whoamiを実行するとDEBUG3レベルのログにこれが表示されます。

debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Starting session: command for root from 172.17.0.1 port 42598

fab -H localhost -- whoami ：

debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Starting session: command for root from 172.17.0.1 port 42610

OK、彼らは両方ともexecやっています...それは予想されることです。 プロセスツリーに何か違いはありますか？ あるべきではありません、そして...ありません。 どちらも次のようになります。

sshd,1 -D -e
  └─sshd,1535
      └─pstree,1537 -alpU

だから、間違いなくシェルは機能していませんか？ 何してるの？ &&ようなシェルのようなものを使用できますか？

できます！ たとえば、 whoami && idは正常に機能します。 つまり、Unixプロセス制御についての私の理解を考えると、これは少し奇妙です。 sshdが文字通りexec(string)実行している可能性は低いようですが、シェルを使用して解釈している場合は、 pstreeませんか？

opensh-portableを実際に掘り下げて、何が何であるかを確認する時が来たと思います。

• すべての魔法はsession.cで発生するようです
• 最初の興味深い停止は、 session_input_channel_reqログ行が（ご想像のとおり）
• 私たちの場合はexecこれはsession_exec_reqを意味します
• これは私たちをdo_execにパントするだけ
• これは、ログを再度記録し、最終的にdo_exec_ptyまたは（この場合、ptyを要求しなかったため、ログ行にtty番号が少しないためわかります）のいずれかになります。 do_exec_no_pty
• どのフォークしてからdo_childを呼び出す
• これは実際にシェルを取得してその環境をセットアップします！
• そしてrcファイルで物事を行います...
  
  
  
  • それがSSH自身の.rcファイルを意味することを除いて
  
  
• 最後に、うん、それはシェル、-c、およびコマンド文字列でexecveを実行するために設定したシェルを使用し

また、2016年12月のように、過去にこのトレースの一部を実行しました（ただし、理由や焦点が異なります）： https ：//github.com/paramiko/paramiko/pull/398#issuecomment-264281759。 完全に忘れていた...

pstreeシェルが表示されない理由は、子を生成する代わりに親プロセスを置き換えるexecveを使用しているためです。 知っておくと良い。 （編集：間違って、ちょうどシェルとのsshd子PROCに取って代わることを、シェル自体はその後も置き換える-私にスタイルのexec呼び出しを行うことができ、コメントは下記を参照してください。）

とにかくそう！ これは、FabricとOpenSSHのクライアントがシェルの実行に関してまったく同じことをしていることを意味するはずです。 それらのどちらも、OpenSSHのコードベースのこれらの部分を変更することはありません。 それはいつものようなものでなければなりませんbash -c "python3 ./configure.py"の実際の値と、 bash @コードツリーのMacOSのレベルのユーザーとその構成されたシェルによって異なります。

env var伝送が差別化要因であるという私の予感が正確であるかどうか疑問に思います。それは、2つの実行環境がどのように異なるかということについて私が考えることができる他の唯一のことだからです。 私のCLIに焦点を当てたテストのFWIWでは、 envは両方のシステムで同じことを報告し、他の環境関連の問題に関係なく、（SSHセキュリティポリシーによる）_default_の動作は常にローカル環境が「リーク」しないことです。反対側。

ええ、私はsshdが常にユーザーのシェル（/ etc / passwdで構成されている）でコマンド文字列を実行すると確信しています。 ただし、コマンド文字列を解析して単一のコマンドであると判断できる場合は、コマンド文字列の前に「exec」を付けます。

$ ssh testdeploy02.ec2.st-av.net pstree -a
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-pstree -a

$ ssh testdeploy02.ec2.st-av.net 'pstree -a && sleep 1'
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-bash -c pstree -a && sleep 1
  |               `-pstree -a

$ ssh testdeploy02.ec2.st-av.net 'VAR=-a sh -c "exec pstree \$VAR"'
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-pstree -a

環境変数に関しては、これらは主にsshクライアントとsshdサーバーの構成によって制御されます。

$ grep Env /etc/ssh/*_config
/etc/ssh/ssh_config:    SendEnv LANG LC_*
/etc/ssh/sshd_config:AcceptEnv LANG LC_*

したがって、sshクライアントは（コマンド文字列自体の外部で）いくつかの変数を明示的に送信し、それらはsshdによってフィルタリングされます。 しかし、明らかにいくつかの例外があります。

$ ssh testdeploy02.ec2.st-av.net env | grep TERM
$ ssh -t testdeploy02.ec2.st-av.net env | grep TERM
TERM=xterm-256color

実際、「シェルを単一のコマンドに置き換える自動実行」動作は、bashの機能だと思います。

$ dash -c "pstree -a"
...
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─dash -c pstree -a
  │                   └─pstree -a

$ bash -c "pstree -a"
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─pstree -a

編集：完全を期すために：

$ bash -c "pstree -a && sleep 1"
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─bash -c pstree -a && sleep 1
  │                   └─pstree -a

ああ、私は間違っていました。 execveは、 sshdの子procが置き換えられることを意味しているので、その後に何が起こるかは、シェル自体と-c xxxに対して何をするかによって決まります。 私のテストはzsh、fwiwで行われました。

また、 @ ploxiln yeaは、上記でリンクされている他のチケットを参照していますが、@ code-treeが実際にそれらとは異なる症状を経験しているかどうかは

申し訳ありませんが、これは誤報だと思います。 sshインラインを介してコマンドを実行することと、sshを介してログインした後に実行することの間に違いがあることに気づいていませんでした。 ssh host 'echo $PATH'すると、PATHも更新されませんが、ログイン後のecho $PATH正常に機能します。

sshがこれを行う理由はまだわかりません（実際にssh host 'bash -l -c "python3 ./configure.py"'実行する必要があるようです）。 とにかく、これは結局のところファブリックの問題ではないと言っても過言ではありません。 混乱させて申し訳ありません。

@ code-treeこれは、前述の内容に関連しています-シェルには、動作するいくつかの異なるモードがあり、「ログイン」および「インタラクティブ」と呼ばれることがよくあります（通常、これらはどちらとも見なされない基本モードの上にあります）。シェルが実行されているときに、ロードするrcファイルのセットが変更されます。

ここでの重要な点は、 bash -c xxxは「インタラクティブ」とは見なされないため、 .bash_profileなどの特定のファイルの読み込みをスキップしますが、 -cなしでbashを実行するだけです。通常はインタラクティブで、プロファイルファイルをロードします。

上で見たように-sshdは、単一のコマンドを実行するように要求すると（Fabricが実行するように、またはssh host commandが実行するように）、常にbash -c <command send down the pipe>を実行するため、常に非対話モードになります。 （Fabric 1が行うことを実行し、 -lて独自のネストされたシェルを実行しない限り...しかし、 bash -c "bash -l -c \"oh god escaping is hard help\""を実行しているので、これからいくつか🥃を実行します。

とにかく、すべてが失われるわけではありません。数年ごとにこの部分の記憶を更新する必要があるようです。そうですね...今は更新されています😆

これはbashのものであり、fabのものではありません。

bashが起動時にソースすることを決定するファイルは複雑になる可能性がありますhttp://blog.flowblok.id.au/2013-02/shell-startup-scripts.htmlおよびdebian / ubuntu（およびほとんどのディストリビューション）は/etc/profileでいくつかのカスタマイズがあり~/.bashrc 。

デフォルトのシェルファブが使用するのは/bin/bash -l -cで、 -lはそれを「ログイン」シェルにします。 debian / ubuntuのカスタマイズがないと、bashの「ログイン」シェルが~/.bash_profileが、 ~/.bashrcはできません。

しかし、ubuntu 16.04では、ログインシェルの場合でもデフォルトで.bashrcしているようです。 ただし、デフォルトの.bashrcの下部に追加された行は、非対話的に実行されていることを検出すると上部近くでベイルアウトするため、処理されません。

ここでは、ubuntu-16.04のデフォルトユーザー.bashrc 2行を追加しました

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

export VAR1=val1

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

export VAR2=val2

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
...

これが私がテストしているfabfileです：

from fabric.api import run, env, task

<strong i="24">@task</strong>
def get_myvars():
    run("echo VAR1=$VAR1 VAR2=$VAR2")

結果：

$ fab -H testpy05.ec2.st-av.net get_myvars
[testpy05.ec2.st-av.net] Executing task 'get_myvars'
[testpy05.ec2.st-av.net] run: echo VAR1=$VAR1 VAR2=$VAR2
[testpy05.ec2.st-av.net] out: VAR1=val1 VAR2=
[testpy05.ec2.st-av.net] out: 
...

あなたは私の命を救いました。 これは私が見つけた完璧な答えです:)どうもありがとう！