パスへの追加と/ binからのリンク

システム管理者はサーバーにソフトウェアアプリケーション（Maven）をインストールし、全員に/usr/local/maven/bin/パスにフォルダーを追加するように指示しました。

次のように、そのフォルダー内のいくつかのプログラムを/binフォルダー（または全員がパスに持っている他のフォルダー）からリンクするだけの方が便利だと思います。

ln -s /usr/local/maven/bin/* /bin

これは正しいです？私の提案に隠れた副作用はありますか？

リンクについて

通常はにリンク/usr/local/*しません/binが、これは歴史的な慣習です。一般に、提案したことを実行できない「技術的な」理由がいくつかあります。

実行可能ファイルへのリンクを作成/binすると、問題が発生する可能性があります。

1. おそらく最大の警告は、RPM、dpkg、APT、YUM、pacman、pkg_addなどのパッケージマネージャーによって管理されているパッケージがある場合です。これらの場合、通常はパッケージを管理者は、そのジョブを実行し、のようなディレクトリを管理/sbin、/bin、/lib、と/usr。1つの例外は/usr/local、パッケージマネージャーがファイルに干渉することを心配せずに、通常はボックスに収まると思われる安全な場所です。

2. 多くの場合、ビルドされた実行可能ファイルに/usr/localは、このPATHが実行可能ファイルにハードコーディングされています。/usr/localこれらのアプリケーションのインストールの一部として含まれる構成ファイルもあります。そのため、実行可能ファイルのみにリンクすると、これらのアプリが.cfg後でファイルを見つける際に問題が発生する可能性があります。そのような場合の例を次に示します。

   $ strings /usr/local/bin/wit | grep '/usr/local'
   /usr/local/share/wit
   /usr/local/share/wit/
   

3. .cfgファイルの検索に適用される同じ問題は、プライマリアプリが実行する必要がある「ヘルパー」実行可能ファイルでも発生する可能性があります。これらもリンクする必要があります。/usr/binこれは問題がある可能性があり、リンクされたアプリを実際に実行しようとしたときにのみ表示されるためです。

注：一般に、で1つのアプリにリンクする誘惑を避けることが最善です/usr/bin。

/etc/profile.d

管理者は、すべてのユーザーにこの管理を提供$PATHさせるのではなく、/etc/profile.dディレクトリに対応するファイルを追加することで、これをボックスの全員に非常に簡単に追加できます。

このようなファイル/etc/profile.d/maven.sh：

PATH=$PATH:/usr/local/maven/bin

通常、これはすべてのユーザーのセットアップを汚染するのではなく、管理者として行います。

代替手段を使用する

ほとんどのディストリビューションはalternatives（Fedora / CentOS）またはupdate-alternatives（Debian / Ubuntu）と呼ばれる別のツールを提供する$PATHようになりました/bin。これらのツールを使用して、の外部にあるツールにループすることもできます。これらのようなツールを使用することは、ほとんどの管理者が「標準的な慣行」と見なすものにより忠実であり、システムをある管理者から別の管理者に簡単に引き渡すことができるため、好ましいです。

このツールは、リンクを作成する際に同様のことを行います/bin。しかし、これらのリンクの作成と破棄を管理するため、ツールを介して行う場合と、提案したとおりに直接行う場合とでは、システムの意図したセットアップを理解しやすくなります。

ここでは、ボックスでOracleのJavaを管理するためにそのシステムを使用しています。

$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb  5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb  5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb  5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb  5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb  5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb  5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz

これの効果を見ることができます：

$ type java
java is /usr/bin/java

$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java

私の0.02ドル

でリンクを作成すること/binは、もっともらしいことですが、ほとんどのシステム管理者によって非常に推奨されません。

1. カスタムとして表示され、別の管理者がボックスをピックアップする必要がある場合、混乱につながる可能性があるため、眉をひそめます
2. この「脆弱な」カスタマイズの結果、将来の状態でシステムが破損する可能性があります。

質問への回答：

これは正しいです？

いいえ、それは悪い習慣です。

私の提案に隠れた副作用はありますか？

はい、いくつかの副作用があります。あなたの提案は、アプリケーションに応じて機能する場合と機能しない場合があり、長期的に退行したり壊れたりする可能性があります。

このようなシンボリックリンクを作成しない理にかなった理由があります。

• /binこのディレクトリはオペレーティングシステム/ディストリビューションの開発者に属するため、管理者は「所有」しません（注1を参照）。一方/usr/local、ローカル管理者によって構築されたソフトウェアの従来の場所は、/opt/<packagename>バンドルされていないソフトウェアの場所です。でファイルまたはリンクを作成すると/bin、パッケージのインストールによって上書きされるリスクがあります。この場合maven、OSによって提供される架空のパッケージであり、ローカルでビルドされたものがより新しいものから作成された場合、リグレッションにつながる可能性がありますOSバージョンのソースコード。たとえば、SVR4 pkgadd、debian dpkg、red-hat rpmおよびslackware tarballはすべて、シンボリックリンクを盲目的に上書きします。

• 一部のアプリケーションは、設定ファイル、プラグイン、および同様のリソースを取得するために呼び出される場所を探します。シンボリックリンクを使用してアプリケーションを呼び出すと、そのコードはそれをたどることに失敗し、そうで/usr/binない場所でこれらのリソースファイルを探します。

• 他のバイナリが存在する可能性があり/usr/local/maven/bin、このディレクトリをPATHに追加しないと使用できなくなります。すべての潜在的なコマンドをリンクすることで、コマンドでそれを考慮しているため、削除されました。

• Maven2をページが PATHにこのディレクトリを追加するように指示（正確には：あなたのパスにM2の環境変数を追加し、例えば輸出PATH = $ M2：$ PATH。）、あなたのようにステップを壊している、別のアプローチを使用して、サポートされていないを行っています方法。もちろん、システムのほとんどのユーザーが潜在的なmavenユーザーである場合は、すべてのユーザーではPATHなくグローバルに設定する方が理にかなってい.profileます。

注1：

Slackwareのドキュメント：

   The /bin directory usually doesn't receive modification
   after installation. If it does, it's usually in the form
   of package upgrades that we provide.

Debian /ファイルシステム階層標準

/bin/
   Essential command executable (binaries) for all users (e.g., cat, ls, cp) 
   (especially files required to boot or rescue the system)
...
/opt/
   Add-on application software packages 
   Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
   Same as for top-level hierarchy

Solarisのドキュメント：

/usr/bin
   Platform-dependent, user-invoked executables. These  are
   commands  users expect to be run as part of their normal
   $PATH. For executables that are different  on  a  64-bit
   system  than  on a 32-bit system, a wrapper that selects
   the  appropriate  executable   is   placed   here.   See
   isaexec(3C).  An approved installation location for bun-
   dled Solaris software. The analogous location for add-on
   system     software     or     for    applications    is
   /opt/packagename/bin.

Debianを示す簡単なテストではdpkg、--force-overwriteオプションが使用されていない場合でも、既存のリンクは保持されません。

# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb 
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May  7  2009 /usr/bin/banner

シンボリックリンクが必要な場合は、にシンボリックリンクすることをお勧めします/usr/local/bin。私のサーバーでは、ローカルソフトウェアをインストールして/opt/NAME、バイナリをにシンボリックリンクしていました/usr/local/bin。

推奨される2つの方法の代わりに/usr/local/bin、実行時にスクリプトで指定したバイナリを実行するシェルスクリプトを作成します。たとえば、mavenを例として使用して、/usr/local/bin呼び出されるシェルスクリプトを作成します。このスクリプトにはmaven、mavenバイナリが存在する場所で実行し、引数を渡す小さなスクリプトが含まれています。

#!/bin/sh
exec /usr/local/maven/bin/maven "$@"

これには、「リンク」するすべてのバイナリに対してこれを行う必要があるという欠点がありますが、$PATH環境変数を台無しにすることなく、コマンドラインからそれらのバイナリを呼び出すことができます。