web-dev-qa-db-ja.com

`ssh root @Hostコマンド`を使用してコマンドが見つかりません

ホストAとホストBがあり、AはパスワードなしでBをSSH接続できると仮定します。

Aのシェルからssh root@B lsを実行すると、lsが実行され、出力が表示されます。

ただし、Aのシェルからssh root@B yarnのようなものを実行すると、bash: yarn: command not foundが表示されます。

yarnは、Bのシェルでyarnを手動で入力することで利用できると確信しています。

許可の問題だと思います。 lsyarnの実行レベルは異なる場合があります。

それでは、その正確な理由と、Aのシェルからssh root@B yarnを利用できるようにするにはどうすればよいですか。

1
Eugene

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を設定すると、一部のディストリビューションで機能します。これらはシェルスクリプトではなく、異なる構文を使用することに注意してください。

3
user1686