Filesystem Hierarchy Standard（FHS）を拡張してエンタープライズソフトウェアを収容する
何人の人がこれに興味を持っているかはわかりませんが、サーバーが数百台を超えると問題になり始めると思います。
アプリケーションチーム/ミドルウェアは、エンタープライズソフトウェアの次のバージョンをこのサーバーとそのアプリサーバーにインストールする必要があるという要求を送信します。職業はなんですか？
- ベンダーはRPMを提供していません
- たとえそうだとしても、RPMは大きな混乱です
- たとえば、あるRPMでは基本的にtarballを/ tmpにインストールし、ポストインストールとしてtarballをアンタールしてから、tarballファイルを削除しました。まだ表示されていない場合は、1つのファイルしかインストールされていないため、アンインストールできません。
- 彼らがインストールスクリプトを提供するところでは、再び...
- ドキュメントを信頼する以外に、ファイルがインストールされる場所を確認することはできません。
要するに、各ベンダーには独自の「ルール」と「デフォルト」があり、最悪の場合、ベンダーによっては何も持っていないようです。
これに対抗するために私が見つけた唯一の方法は、開発マシンへのインストールを研究し、それに対して独自のRPMを作成することです。これにより、この投稿のトピックが取り上げられました。
nix FHS は多くの問題を扱っていますが、それは仕事ではないので、サードパーティのソフトウェアに固有の問題も見逃しています。
ベンダー製品のインストールに関するFHS、標準、およびルールの拡張
私の同僚と私が取り組んできたのは、この標準を拡張して、ベンダーソフトウェア（Oracleデータベース、Oracleアプリケーションサーバー、Teamsite、Informaticaなど）を収容することです。
私はこれを文書化しましたここ、そして私たちは実際にそれに非常に満足しています...
- 親FHSに違反することはありません
- 厳格なエンタープライズソフトウェアのインストールを回避するのに十分な柔軟性があります
誰かがこの問題に興味を持っている場合（つまり、基準に従うことを高く評価し、必要に応じて基準を設定し、新参者が（ほぼ）直感的に拾い上げて歩き始めることができるクリーンなシステムを維持することに関心がある場合）-私はしたい知っている...
- どのようにして問題を解決できましたか？
- このモデルがあなたのために働くなら、そしてそうでないなら-なぜそうではないのですか？
私の究極の目標は、このモデルをどの企業の誰もが手に取って使用できるものにすることです。
ノート
ドキュメントページについて...
- これは進行中の作業なので、何かが曖昧な場合はお詫びします（そして修正します）
- サードパーティの選択肢としての
/optの指定は必須ではありません-本当に必要な場合は、代わりに/usr/localを使用できます。一貫性があります。/optを優先します。 - 質問する前に、
/etc/opt/<vendor>/<product>や同様のパスdoなどには、そのようにする理由があり、FHSから直接継承されます。
質問
- このモデルはあなたのために働きますか？
- ここで、対処されていないと感じるものはありますか？
もちろん、この標準を最初に使用することを保証するのに十分なサーバーがあることを前提としています。
提案された拡張機能で提案するのを見る前から、/ opt/<vendor>/<product>を提案するつもりでした。だから、はい、それは私のために働きます。
私の経験則は次のとおりです。
/、/ usr：OS自体。ネイティブパッケージシステムを使用するもの。
/ usr/local：自分で開発したもの、またはソースからコンパイルしたもの。
/ opt：サードパーティ製品。