ホストAとホストBがあり、AはパスワードなしでBをSSH接続できると仮定します。
Aのシェルからssh root@B ls
を実行すると、ls
が実行され、出力が表示されます。
ただし、Aのシェルからssh root@B yarn
のようなものを実行すると、bash: yarn: command not found
が表示されます。
yarn
は、Bのシェルでyarn
を手動で入力することで利用できると確信しています。
許可の問題だと思います。 ls
とyarn
の実行レベルは異なる場合があります。
それでは、その正確な理由と、Aのシェルからssh root@B yarn
を利用できるようにするにはどうすればよいですか。
yarn
コマンドは、シェルの初期化スクリプトを介して$ PATHに追加された非標準の場所にあります(例:〜/ .bashrcまたは〜/.* profileまたは/etc/profile.d)。
問題は、非対話型モードで実行されている場合、Bashがこれらのスクリプトを完全に無視することが多いことです。インタラクティブに入力されたprintenv PATH
と非インタラクティブに開始されたssh root@B printenv PATH
を比較すると、おそらく異なる値が表示されます。
これを修正するには、リモートサーバーのOSによって異なります。
ssh root@B ". /etc/profile && yarn ..."
は常に機能するはずです(/ etc/profileがPATHが設定されている場所であると想定します。そうでない場合は、正しいファイル名に置き換える必要があります)。
yarn
コマンドを標準の$ PATHの場所の1つ(たとえば、/ usr/binまたは多くの場合/ usr/local/bin)にリンクすると、常に機能するはずです– otherが必要ない場合存在する環境変数。
必要なすべての環境変数を設定して本物を実行するシェルスクリプトを/usr/[local/]bin/yarn
で作成すると、常に機能するはずです。
〜/ .bashrcまたは/etc/bash.bashrcを介して$ PATHを設定すると、Debian/Ubuntuで機能しますが、他のほとんどのディストリビューションでは機能しません(残念ながら、Bashはこれをコンパイル時オプションとして提供します)。
〜/ .pam_environmentまたは/ etc/environmentを介して$ PATHを設定すると、一部のディストリビューションで機能します。これらはシェルスクリプトではなく、異なる構文を使用することに注意してください。