パスへの追加と/ binからのリンク
私たちのシステム管理者は、サーバーにソフトウェアアプリケーション（Maven）をインストールし、/usr/local/maven/bin/フォルダーをパスに追加するように全員に指示しました。
次のように、そのフォルダー内のいくつかのプログラムを/binフォルダー（または全員がパスにある他のフォルダー）からリンクする方が便利だと思います。
ln -s /usr/local/maven/bin/* /bin
これは正しいです？私の提案にはいくつかの隠れた副作用がありますか？
リンクについて
通常、/usr/local/*を/binにリンクしませんが、これはより歴史的な慣行です。一般に、提案していることを実行できない「技術的な」理由はいくつかあります。
/binで実行可能ファイルへのリンクを作成すると、問題が発生する可能性があります。
おそらく、システムがRPM、dpkg、APT、YUM、pacman、pkg_addなどのパッケージマネージャーで管理されているパッケージを使用している場合は、最大の注意点になるでしょう。これらの場合、通常はパッケージをmanagerはその役割を果たし、
/sbin、/bin、/lib、/usrなどのディレクトリを管理します。 1つの例外は、/usr/localです。これは、パッケージマネージャーがファイルに干渉することを心配する必要なく、通常はボックスに収まるので安全な場所です。多くの場合、
/usr/local用にビルドされた実行可能ファイルでは、このPATHが実行可能ファイルにハードコードされます。これらのアプリケーションのインストールの一部として/usr/localに含まれている構成ファイルがある場合もあります。そのため、実行可能ファイルのみにリンクすると、これらのアプリが.cfgファイルを後で見つけるときに問題が発生する可能性があります。このような場合の例を次に示します。$ strings /usr/local/bin/wit | grep '/usr/local' /usr/local/share/wit /usr/local/share/wit/.cfgファイルの検索に適用される同じ問題は、プライマリアプリを実行する必要がある「ヘルパー」実行可能ファイルでも発生する可能性があります。これらも/usr/binにリンクする必要があります。これは問題がある可能性があり、実際にリンクされたアプリを実行しようとしたときにのみ表示されます。
注：一般に、/usr/binで1つだけのアプリにリンクする誘惑を回避するのが最善です。
/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でリンクを作成することは、もっともらしくはありますが、ほとんどのシステム管理者にはお勧めできません。
- カスタムとして表示され、別の管理者がボックスを受け取る必要がある場合に混乱を招く可能性があるため、眉をひそめられるでしょう
- この「壊れやすい」カスタマイズの結果として、将来の状態でシステムが壊れる可能性があります。
尋ねられた質問への回答：
これは正しいです？
いいえ、それは悪い習慣です。
私の提案にはいくつかの隠れた副作用がありますか？
はいいくつかの副作用があります。提案は、アプリケーションによっては機能する場合と機能しない場合があり、長期的には後退するか壊れる可能性があります。
このようなシンボリックリンクを作成する理由がないには、合理的な理由があります。
このディレクトリはオペレーティングシステム/ディストリビューションの開発者に属するため、管理者は
/bin（注1を参照）を「所有」しません。一方、/usr/localはローカル管理者が作成したソフトウェアの従来の場所であり、/opt/<packagename>はバンドルされていないソフトウェアの場所です。/binでファイルまたはリンクを作成すると、パッケージのインストールによって上書きされるリスクがあります。この場合、OSによって提供される架空のmavenパッケージが原因で、ローカルでビルドされたものがOSバージョンよりも新しいソースコードから作成された場合の回帰。たとえば、SVR4pkgadd、debiandpkg、red-hatrpm、およびslackware tarballはすべて、シンボリックリンクを盲目的に上書きします。一部のアプリケーションは、構成ファイル、プラグイン、および同様のリソースを取得するために呼び出される場所を調べます。シンボリックリンクでアプリケーションを呼び出す場合、そのコードはアプリケーションをたどることができず、
/usr/bin以外の場所にあるこれらのリソースファイルを探します。/usr/local/maven/binには他のバイナリがある可能性があり、このディレクトリをPATHに追加しないと、それらを使用できなくなります。maven2ページ は、このディレクトリをPATHに追加するように指示します（正確には、M2環境変数をパスに追加します。例：export PATH = $ M2：$ PATH。）、別のアプローチを使用することにより、あなたはそのステップを壊しているので、サポートされていない方法で進んでいます。もちろん、システムのほとんどのユーザーが
mavenユーザーである可能性がある場合は、すべての.profileではなくPATHをグローバルに設定する方が理にかなっています。
注1：
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.
/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
/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環境変数を作り直す必要なく、コマンドラインからこれらのバイナリを呼び出すことができます。