ユーザー間で共有されるファイルを配置する最も適切なディレクトリは何ですか?


83

または:グループに属するファイルはどこに置けますか?

Unixシステムにjoesarahという2人のユーザーがいるとします。彼らは両方とも映画愛好家グループのメンバーです。彼らの映画ファイルはどこに置くべきですか?

  • /home/{joe,sarah}/moviesこれらのディレクトリはグループではなくjoe / sarahに属しているため、適切ではありません。

  • /home/movies-enthusiast映画愛好家はユーザーではなくグループであるため、これも適切ではありません。

  • /var/movies-enthusiast オプションかもしれませんが、これがFHSで許可されているかどうかはわかりません。

  • /srv/movies-enthusiast オプションもありますが、映画はシステムサービスに必要なファイルではありません。


6
FHSの言及に投票しました!この* nixユーザーであり、20年のカジュアルなシステム管理者はそれを知りませんでした。ありがとうございました!
CPRitter

回答:


72

使用しないでください

  • /usr共有可能な読み取り専用データ用です。ここのデータは、管理上の理由(新しいパッケージのインストールなど)でのみ変更する必要があります。
  • /opt 通常、自己完結型のプログラム、または何らかの理由でシステムの他の部分から隔離する必要があるプログラム(低および中程度の相互作用ハニーポットプログラムなど)用です。
  • /var以下のためである「などのログ、スプールファイル、および一時的な電子メールファイルなど、その内容は継続的にシステムの通常動作中に変更することが期待されているファイル---。」私はこのように考えるのが好きです:あなたのデータがリストに正しく要約されていない場合、一般的には属していません/var(ただし、これには例外があります)

つかいます

  • /homeユーザーのホームディレクトリ用です。一部の人は、このディレクトリをグループファイルの領域としても見ています。FHSは、「大規模なシステム(特に/ homeディレクトリがNFSを使用する多くのホスト間で共有されている場合)では、ユーザーのホームディレクトリを再分割すると便利であると述べています。 / guests、/ home / studentsなど」
  • /srvグループファイルの受け入れ可能な、頻繁に好まれる場所です。私は通常、Chris Downの回答で述べた理由により、グループ共有ファイルにこのディレクトリを使用します。グループファイル共有は、サーバーが提供するサービスであると考えています。

man hierFHSで記述されている各ディレクトリの目的の詳細については、hier(7)のマニュアルページ()を参照してください。


1
より一般的なケースでは/srv/data、データファイルにディレクトリを使用すると思われます。
ビクターヤレマ

4
男性雇用者に言及した場合は+1。私はそれが存在することを知りませんでした。
ザック・ボイド

おかげで、新しいLinuxユーザーのための非常に有用な情報と参考文献。
シヴァム

28

私の意見では、正しい場所は/srv/movies-enthusiastです。「サービス」はデーモンやプログラムである必要はなく、システムが提供するサービス(映画をそこに置くことができるなど)でなければなりません。FHSからの引用は次のとおりです。

/ srvには、このシステムによって提供されるサイト固有のデータが含まれています。

あなたの使い方はその定義に該当し、サービスを提供すると思います。


より一般的なケースでは/srv/data、データファイルにディレクトリを使用すると思われます。
ビクターヤレマ

11

Filesystem Hierarchy Standard(FHS)は混乱の作成しないようにするためにに付着する「Unixのディストリビューションの開発、パッケージ開発者、およびシステムの実装」のレイアウトを指定するあなたの名前空間を。

それはあなたの名前空間なので、適切だと思う名前を選ぶべきです。あなたが見つけた場合は/groups/movies-enthusiast理にかなって、あなたがそれを置く必要があります。入力しやすいために短いパス名が好きな場合/g/movies-enthusiast(または/g/m-e)が適しています。

選択したパスはFHSで定義されていないため、配布パッケージまたはサードパーティパッケージがそれらに触れてはなりません。そのため、FHSを読んで、準拠ソフトウェアによって使用される可能性のあるパスを確認する必要があります(目次は、知っておくべきことのほとんどを示しています)。

たとえば、個人的には/av、視聴覚コンテンツの保存場所/src、ソースコード、および/data未定義データ(仮想マシンイメージ、cdイメージ、chroot、保存済みパッケージなど)に使用しています。


私は個人的に/ dataをそのようなすべてのファイルに使用し、次に/ data / moviesをオーディオビジュアルコンテンツに、/ data / srcをソースコードに、/ data / musicを使用します。すべてが1つの(階層的な)場所にあります。
meduz

あなたが開発者、ディストリビューション開発者、pkg開発者、またはシステム実装者でなくても、非常に頻繁に良いアイデアの標準に従うか、それに従うこと。
フェリペアルバレス

新しいディレクトリを追加しても、FHSに反することはありません。実際、FHSに準拠するためには、新しいディレクトリを作成ないことが必要になる場合があると主張します。FHSは、複数の当事者間で調整する必要のない質問は、この標準の範囲外であることを明確に述べています。したがって、FHSで定義されたディレクトリのいずれかに最終的に必要なものをすべて詰め込もうとすると、ファイルをあるべきではないディレクトリに配置する状況が発生します。
-jwatkins

7

この目的のためにルートから新しいマウントポイントまたはディレクトリを作成しても問題はありません。

特にこれがこのシステムの主な目的である場合、私はただ作成します

/ movies-enthusiast

他の同様の「グループ」がある場合、それらを一緒にホストすることを好む場合と好まない場合があります。

/data/movies-entusiast
/data/next-group
etc

または

/share/movies-enthusiast
/share/next-idea
etc

考慮すべき質問:この目的のためにマウントポイントを専用にしますか?

ソフトリンクを検討しましたか?

いずれにしても、ルールはありません。1人のユーザーを管理者にして、残りのユーザーにこのプロジェクトスペースへのアクセスを許可する場合は、ユーザーのホームディレクトリで自由にホストしてください。または、/ home / shared / *名前空間を作成します。あなたはあなた自身の上司です。

ああ、一つのこと:あなたが何をするにしても、それを文書化してください。システムの回復、毎日のチェック、バックアップなどの一部になる必要があります。重要な構成は注意する必要があります(たとえば、グループメンバーシップ、アクセス許可セット、パフォーマンスのためのfs調整可能パラメータ、およびデフォルト以外のすべて)。


1

FHSは管理を容易にすることでもあるので、その理由で/ srvを使用しますが、それは私がやったことではありません。しかし、完璧な後知恵があります。NASで/ export / srvを使用しています。

ドロップボックスの場合は、setgidとstickyの両方であることを確認してください。また、それを使用する人が有用なumaskを持っていることを確認してください。ただし、ファイルアクセスモードの例で行ったように、wheelは使用しないでください。eXecuteを削除しないでください。さもないと、O_oサプライズになります。

bash-3.2$ mkdir movies
bash-3.2$ sudo chmod 03771 movies
Password:
bash-3.2$ ls -ld movies/
drwxrws--t 2 andrewb wheel 68 Apr  4 17:09 movies/
bash-3.2$ umask 026
bash-3.2$ touch movies/junk
bash-3.2$ ls -l movies/
total 0
-rw-r----- 1 andrewb wheel 0 Apr  4 17:09 junk

1

FHS は、ローカルサイト、配布、アプリケーション、ドキュメントなど複数の関係者間でファイルの配置を調整する必要がある問題に対処することを覚えておくことが重要です。FHSは、状況に応じてルールを設定しようとはしていません。ローカルファイルのローカル配置はローカルの問題ですFHS 3.0、セクション1.1)。

したがって、FHSの規則に反しない限りmovies、技術的にディレクトリをどこにでも置くことができます。それでも、あなたの質問は最も適切な場所に関するものでしたので、いくつかの一般的な答えを考えてみましょう(特定のユースケースを考えると、最も優先度の高い順に並べられます)

  • /<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>/home/teachers/<username>または/home/staff/<username>にあり、共有のものはたとえば/home/workgroup/<workgroupname>。いつか彼らは部門の下位区分にもなります。それでも、あなたはアイデアを得る。正直に言うと、私は個人的にこの戦略が好きではありませんが/home、複数のサーバーに分散させると(NFSなどを介して)物事が少し簡単になります。



0

/ opt / moviesのような個別のディレクトリを作成し、それらに適切なユーザーおよびグループのアクセス許可を設定することをお勧めします。また、ディスクquotaを使用してディスクの総消費を回避することもできます。


0

これは答えと同じくらいコメントです(だから私にそれを支持しないでください!)が、コメントに収まるには長すぎます。

私は2つのことを行いますが、どちらもあなたが直面している問題を回避します。

1)システムディスク上のすべての空き領域の個別のパーティションを作成し、データスペースにラベルを付けます。それが、現在のすべてのメディアファイルと他のデータの行き先です。これは/ media / dataspaceとして自動マウントされ、「data」というディレクトリの下に「data」であるものをすべて置いて、定期的にバックアップしたくない作業ファイル、vms、isoイメージなどと区別します。

個別のパーティションを使用すると、/または/ homeの下に格納されている場合のように、システムがいっぱいになってもシステムを危険にさらさないという利点があります。

2)他の物理ドライブ(ノートパソコンの場合はUSB)に、ほとんどのデータ/メディア、特に「今」使用していないものを置きます。これにより、バックアップが簡単になり、必要に応じて別のコンピューターに簡単に接続できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.