または:グループに属するファイルはどこに置くことができますか?
Unixシステムに2人のユーザーがいるとします。ジョーそしてサラ。彼らはすべて組織のメンバーです映画愛好家グループ。映画ファイルをどこに置くべきですか?
/home/{joe,sarah}/movies
このディレクトリは次のものなので、不適切です。ジョー/サラ、彼らのグループではなく。/home/movies-enthusiast
また不適切だから映画愛好家ユーザーではなくグループです。/var/movies-enthusiast
オプションかもしれませんが、FHSがそれを許可するかどうかはわかりません。/srv/movies-enthusiast
オプションかもしれませんが、映画はシステムサービスに必要なファイルではありません。
答え1
使用しないでください
/usr
読み取り専用データを共有するために使用されます。ここのデータは管理上の理由でのみ変更できます(新しいパッケージのインストールなど)。/opt
一般的には、スタンドアロンプログラム、または何らかの理由でシステムの残りの部分(たとえば、低または中程度の相互作用ハニーポット)から分離する必要があるプログラムに適しています。/var
ある「ログ、スプールファイル、一時メールファイルなど、システムが正常に動作している間にコンテンツが継続的に変更されると予想されるファイルです。」私はこのように考えたいです。データがリストに正しく表示されない場合、通常はリストに属しません/var
(例外はありますが)。
使用
/home
ユーザーのホームディレクトリに使用されます。一部の人はこのディレクトリをグループファイル領域と見なすことがあります。 FHSは実際には次のように述べています。「大規模システムでは、特に/ homeディレクトリがNFSを使用して多くのホスト間で共有されている場合は、ユーザーのホームディレクトリを細分化すると便利です。使用して行うことができます。/srv
グループファイルに適しており、一般的に好ましい場所です。 Chris Downの記事で言及されている理由で、私は通常、グループ共有ファイルにこのディレクトリを使用します。回答;グループファイル共有は、サーバーが提供するサービスと見なされます。
man hier
FHSで説明されている各ディレクトリの目的の詳細については、hier(7)のマニュアルページ()を参照してください。
答え2
私の考えにはぴったりの場所だと思います/srv/movies-enthusiast
。 「サービス」はデーモンやプログラムである必要はなく、システムが提供するサービス(映画を見ることができるようなもの)であればよい。これはから来たものですFHS:
/ srvには、このシステムによって提供されるサイト固有のデータが含まれています。
私はあなたの使用がその定義に属し、サービスを提供すると確信しています。
答え3
これファイルシステム階層標準(FHS) は、混乱を避けるために「Unix ディストリビューション開発者、パッケージ開発者、システム実装者」が従うレイアウトを指定します。あなたの名前空間。
このためあなたの名前空間については適切だと思うものを選択する必要があります。意味のあるものが見つかったら、そこに/groups/movies-enthusiast
投稿する必要があります。簡単に入力できるので、短いパス名を好む場合/g/movies-enthusiast
(または/g/m-e
)が適しています。
選択したパスはFHSで定義されていないため、ディストリビューションやサードパーティのパッケージはそのパスに触れてはいけません。したがって、FHSを読んで、互換ソフトウェアが使用できるパスを見つける必要があります(ディレクトリは知っておくべきほとんどの内容を教えてくれます)。
たとえば、私は個人的にオーディオビジュアル/av
コンテンツ、/src
ソースコード、/data
未定義データ(仮想マシンイメージ、CDイメージ、chroot、保存パッケージなど)を保存するために使用します。
答え4
FHSを覚えておくことが重要です。複数の当事者(ローカルサイト、ディストリビューション、アプリケーション、ドキュメントなど)間のファイル配置を調整する必要がある問題を解決します。; FHSは、あなたが直面する可能性があるすべての状況に対してルールを作成しようとはしません。ローカルファイルのローカル配置はローカル問題です。(FHS 3.0、セクション 1.1)。
movies
したがって、技術的にディレクトリをどこにでも置くことができます。FHS慣行に違反しない限り。しかし、あなたの質問は最適したがって、いくつかの一般的な答えを考えてみましょう(特定のユースケースに応じて、最も好むものから最も好まないものの順に並べ替えます)。
/<someprefix>/<groupname>
または/media/<volumename>/<groupname>
:正直言って、このオプションがLinuxの世界でなぜ悪い評判を持っているのかはわかりませんが、明確にしておくとそうです。あなたのシステムであり、FHSは、確立された意味と矛盾しない限り、ルートレベルで新しいディレクトリを作成できると言います。たとえば、必要に応じてディレクトリを作成し/groups
たり、その中のファイルを整理したりできます。/shared
一部の管理者は、それをファイルシステムの残りの部分から分離することを好み、他のボリューム(たとえば、下/media/<volumename>/<groupname>
)をマウントします。どちらも優れており、FHSに準拠しています。/srv/<groupname>
または/srv/<someprefix>/<groupname>
:FHSによると、/srv
このシステムが提供するサイト固有のデータが含まれています。。 FHSは引き続き説明した。/ srvサブディレクトリの名前を指定するために使用される方法は指定されていません。。私の個人的な経験によれば、/srv
このディレクトリを利用するほとんどの管理者は、クライアントごと、サイト別、またはプロジェクト別のサブディレクトリを使用してから、データディレクトリをそのレベルに配置します。構造化方法に関係なく、/srv
それらのファイルを共有することがサービス自体を構成すると合理的に想定できる場合は、複数のユーザー間で共有するファイルを保存することは完全に許可されます。自分に聞いてください。 「これらのファイルをSMB / NFS / AFS / GIT / ...で共有するのは妥当ですか?」その場合は、ディレクトリをローカルファイル共有サービスと見なしてサブディレクトリに保存できます。/srv
実際には、これらのファイルを他のシステムに提供するデーモンがなくても同じです。/home/<groupname>
または/home/<some-prefix>/<groupname>
:FHSは次のように言います。/home
かなり標準的な概念ですが、明らかにサイト固有のファイルシステムです。。以下の各ディレクトリが実際のユーザーの名前でなければならないという要件はまったくなく、グループのサブ/home
ディレクトリは許可されていますが、グループとユーザー間の最終的な競合を避けるために予防措置を講じる必要があります。それにもかかわらず、衝突の可能性を避けるために、いくつかの分割戦略を使用するいくつかの大規模機関(特に大学)がこの戦略を使用しているのを見ました。たとえば、実際のユーザーのホームディレクトリはまたは/home/students/<studentid>
に配置され、共有コンテンツは配置されます。中 。時には部門の支店かもしれませんが、ポイントはわかります。正直なところ、私は個人的にこの戦略を好むことはありませんが、複数のサーバーに分散した場合(たとえば、NFSを介して)作業がはるかに簡単になるため、大規模な組織にとって好まれます。/home/teachers/<username>
/home/staff/<username>
/home/workgroup/<workgroupname>
/home