UNIX / Linuxファイルシステムの編成のいくつかの側面について

1.0はじめに

前の記事（ Linux：xstowマネージャーを使用した非配布プログラムのインストール）を書いた後、私は二重の印象を持っています。 一方では、記事のすべてが正しく、他方では、レビューは、UNIXファイルシステムのさまざまな部分の指定にいくつかの矛盾があることを示しました。 たまたま、私は人々に私のハンマーを渡し、ハンマーの使用方法を説明し、このハンマーでどの釘とどこにハンマーを打つべきかを言わなかった。 このギャップを埋めようとします。 この記事では、できる限り、UNIXファイルシステムがどのように構成されているのか、なぜこのように行われているのか、このシステムでなぜ、どのように動作するのかを説明します。







将来的には、UNIXの例としてDebian / Ubuntuディストリビューションを使用します。



私たちが人生から知っているように、私たちの人生全体は、私たちの前に生じる問題の解決策であり、以前の問題の解決などから生じる問題を含む無限の問題の出現です...

2.0問題：OSでさまざまな目的のファイルを配置する方法

それでは、最初の問題、システムにファイルを配置する方法を定式化しましょう。 一方では、オペレーティングシステムとプログラムがあります。各プログラムは通常、いくつかの、時には多くのファイルで構成されています。 オペレーティングシステムの基本ファイルですべてが多かれ少なかれ明確な場合、原則としてそれらは常に同じ場所にあり、インストール/アンインストールが可能なプログラムのファイルでは、状況はより複雑です。 一方では、ファイルが目的別にソートされていると便利です。他方では、プログラムファイルのディレクトリツリーがプログラムに対応するディレクトリにあると便利です。 これらのソリューションの長所と短所をさらに詳しく見てみましょう。

2.1最初のオプション：パッケージでファイルを並べ替える

最初に頭に浮かぶのは、OSファイルをパッケージに分解してみましょう。 つまり 各ソフトウェアパッケージには、このプログラムの製造元が必要とするファイルが既に配置されるサブディレクトリがある独自のディレクトリがあります。



長所：

• 各メーカーは、必要に応じて自分のディレクトリにファイルを配置します。
• プログラムのインストール/アンインストール、ディレクトリのコピーまたは破棄、およびすべての作業は簡単です。

短所：

• オペレーティングシステムは、対応する環境変数にあるリストから実行可能ファイルまたは共有ライブラリを検索します。 たとえば、実行可能ファイルへのパスは、 $ PATH環境変数にリストされています。 パッケージが多い場合、これらのリストは非常に大きくなります。
• 同じ場所に異なる目的のために同様の目的のファイルを配置することが望ましい別の正当な理由があります。 実際には、さまざまな理由で、さまざまな目的のファイルのディレクトリ/ファイルシステムのプロパティが異なる必要があります。 これは、セキュリティ上の理由から、場合によっては最適なシステム構成の理由から必要です。 UNIXには、ディレクトリにファイルシステムをマウントする機能があります。 それは何を与えますか？ たとえば、バイナリを読み取り専用モードで起動するためのディレクトリをマウントすると、悪意のあるプログラムはそこに何も書き込むことができず、起動を禁止するモードで他のディレクトリをマウントすることができます。 変更が必要なファイル（データベースファイルなど）を別のファイルシステムに配置します。そのファイルシステムのパラメーターも最適に構成できます。

2.2 2番目のオプション：システム内の機能でファイルを並べ替える

長所：

• ファイル機能に基づいてファイルシステムを最適に構成できます。
• ファイルとディレクトリ、およびマウントされたファイルシステムのアクセス許可を最適に構成できます。
• このようなディレクトリへのアクセスをネットワーク経由で提供することは可能であり、便利です。

短所：

• 共有ディレクトリには多くのファイルがありますが、どのパッケージに属しているかは明確ではありません。 パッケージの削除に問題があります。

3.0 UNIXスタイルのソリューション

UNIXでは、2番目のオプションが選択されます。 つまり 同じ機能を持つ異なるプログラムのファイルは同じディレクトリにあります。 たとえば、さまざまなユーザープログラムの実行可能ファイルは/ usr / binディレクトリにあります。

4.0 UNIXスタイルのソフトウェアインストールのソリューションから生じる問題

もちろん、アプローチの欠点から問題が発生します。 これらは、プログラムのインストール、プログラムのアンインストール、およびどのファイルがどのプログラムに属しているかを判別するのが困難です。 これはほとんどの場合、重要なタスクです。

5.0問題解決：パッケージマネージャー

将来的には、MPパッケージマネージャーを呼び出します。



さまざまなUNIX / Linuxディストリビューションの前のセクションで定式化された問題は、インストールされたソフトウェアに関する情報を特別なプログラム（パッケージマネージャー）にインストール、アンインストール、保存することで解決されます。 Debian / Ubuntuでは、dpkgがこれを行います。 実際、これは、これに関連する一連のプログラム全体のうちの1つのプログラムにすぎません。 dpkg、これはバックエンドです。いくつかのフロントエンド、apt-get、aptitude、dselect、synapticがあります。



MPは何をしますか？ 少なくともDebian / Ubuntuでは、彼は次のことを行います。

1. パッケージをインストールします。
2. パッケージの削除。
3. 依存関係の追跡（パッケージをインストールする場合、このパッケージに必要な他のパッケージをパッケージと共にインストールします）
4. リモートリポジトリからネットワーク経由でパッケージをインストールします。
5. インストール済みパッケージのローカルデータベースを維持します。
6. ネットワーク経由など、インストールに使用できるパッケージのローカルデータベースを維持します。
7. 利用可能なパッケージおよび/またはそれらのバージョンを変更するときにデータベースを更新します。
8. パッケージ更新の正しいインストール。
9. システム全体をアップグレードします。

たくさん、どう思いますか？ そして、Debian / Ubuntu MPはこれについて本当に良い仕事をしています。



パッケージ自体は通常、ファイルのアーカイブ、いくつかのフィールドを含むパッケージの説明、およびパッケージのインストールおよび削除時に実行されるスクリプトです。 Debian / Ubuntuでは、パッケージファイルの拡張子は.debです。

6.0パッケージマネージャーに関連する問題

ご存じのように、問題なく何も起こりません。 MPの使用も例外ではなく、独自の問題をもたらします。 もちろん、MPはそれがもたらすよりもはるかに多くの問題を解決しますが、それでもそれらを知って対処する必要があります。 したがって、問題は次のとおりです。

1. 依存関係。 これは、一方でMPを使用することのプラスです。 一方、依存関係の追跡は、パッケージ管理者にとって大きな仕事です。 現在、Debianには25,113個のパッケージがあります。 一部のパッケージは他のパッケージの必須インストールを必要とするか、またはその逆に互換性のないパッケージがあります。 その結果、大きく複雑な依存関係のシステムができます。 これらすべてをチェックする必要があります。
2. 互換性のないパッケージの組み合わせが見つかる場合があります。
3. 時々、あらゆる種類のトリッキーなリングの依存関係があります。
4. 多数のパッケージを相互に結合する必要があるため、ディストリビューションに含まれるパッケージバージョンが廃止される場合があります。
5. 多くの場合、配布ソフトウェアでは必要なバージョンではありません。
6. パッケージが非常に多いにもかかわらず、ディストリビューションに含まれていないソフトウェアが必要な場合があります。
7. MPが実行されているディレクトリにソフトウェアをインストールすることはできません。そうしないと、ソフトウェアがMPによってインストールされたソフトウェアと競合する可能性があります。 簡単に言えば、MPによってインストールされたファイルを上書きしたり、その逆を行うことができます。

7.0パッケージマネージャー、階層/ usr / localに関連する問題の解決

最近、ほとんどすべての必要なソフトウェアが配布パッケージに含まれています。 それでも、遅かれ早かれ、原則として、各ユーザー/管理者は、ディストリビューションに含まれていないソフトウェアをインストールする必要に直面しています。 通常、次のようなオプションがあります。

問題1。	他の設定でパッケージを再コンパイルする必要があります。
問題2	必要なソフトウェアはディストリビューションに含まれていません。
問題3	ディストリビューションは、必要なバージョンではありません。

になる方法 システムを乱すリスクを最小限に抑えながらこれを行う方法は？ 利用可能ないくつかのオプションがあります。

問題1。	解決策1：	他の設定でパッケージを再コンパイルします。 （これは、他の設定のパッケージが必要な場合です）。 ディストリビューションでコンパイルされたパッケージと比較して依存関係が変わる場合がありますが、実際には危険はありません。 すでに、明確な唐辛子があります、あなたは中毒の責任があります。
問題2,3	解決策2	独自のパッケージをビルドして、システムにインストールします。
問題1,2,3	決定3	階層内のソースから収集されたソフトウェアをインストールする/ usr / local

ソリューション1は明確なように見えるので、 ソリューション2とソリューション3を詳しく見てみましょう。

解決策2：独自のパッケージをビルドし、システムにインストールします。

長所：

1. セクション6.0にリストされているMPのすべての機能を使用できます。
2. パッケージが複数のマシンにインストールされるように設計されている場合、MPのネットワーク機能を使用し、パッケージで独自のリポジトリを作成し、MPの標準的な方法でこれらのパッケージをインストール/更新できます。

短所：

1. MPのすべてまたは一部の機能を使用するには、追加の作業が必要になることがあります。 使用しない場合、MPを使用する意味は何ですか？
2. パッケージの互換性を確認しない場合、パッケージが他のパッケージと競合する可能性が高く、競合が最も予期しないものになる可能性があります。
3. このアプローチの大規模な実装（独自のパッケージの作成）により、RPMの場合のように、テストが不十分で互換性のない多くのパッケージがインターネットに表示される可能性があります。

Debianポリシー² （Debianの派生物としてのUbuntuもガイドされています）は、2つのことを直接述べています。

• ローカルにインストールされたソフトウェアは、 / usr / local階層にインストールされます。
• ローカルにインストールされたソフトウェアは、システムを更新するときに上書きされないようにする必要があります（MPを介した更新を意味します）。

したがって、このマシンまたは少数のマシンにローカルにインストールされるリポジトリーにないソフトウェアの場合、標準的な方法は/ usr / localにインストールすることであると結論付けることができます。



ソフトウェアをDebian / Ubuntuシステムに配布およびインストールする場合、最良の方法は.debパッケージにパッケージ化することです。 しかし！ この場合、このパッケージの依存関係、競合、および更新を担当します。

8.0 / usr /ローカル階層の問題

1. ご存知のように、どのソリューションも新しい問題をもたらします。 例外ではなく、前のセクションで概説したソリューションです。 1つのパッケージを/ usr / localにインストールしている限り、問題はありませんが、複数のパッケージがあるとすぐに、管理が不十分な一連のファイルが表示されます。 セクション4.0で説明されています。
2. もう1つの問題は/ usr / local / varディレクトリの問題です。ご存じのように、プログラムデータファイルは/ varディレクトリに書き込まれ、プログラム操作中に変更される可能性があります（ログ、データベースPIDなど）。 しばしば
   
   / varは別のパーティションで行われますが、変更可能なファイルは/ usr / local / varにあることがわかりました 。

9.0 / usr /ローカル階層に関連する問題の解決、考えられる回避策

問題1の解決策は私の記事⁵で説明されているため、解決策について詳しく説明しません。 つまり、各プログラムは/ usr / local / stowディレクトリ内の独自の階層に配置され、その後、特別なマネージャー（xstow）がプログラムファイルへのシンボリックリンクを配置します。



問題の解決2.この問題は、手で解決する必要があります。 stowプログラムを使用した場合は、たとえば、 / var階層内で一意の名前（たとえば、 / var / local_var）でディレクトリを作成し 、そこにリンクを作成できます。 しかし、これは本当にそのようなニーズがある場合にのみ行う価値があります。

10.0階層/最適化

ポリシー^2の / opt階層にサードパーティソフトウェアをインストールします 。 ソフトウェアは、 / opt / packageまたは/ opt / providerの形式のディレクトリにインストールします 。

11.0ユーザーの問題、/ホーム階層

繰り返しになりますが、ポリシー²によると、ユーザーファイルは/ home階層の/ home / username形式のディレクトリに保存されます 。 ソフトウェアのインストールについて話す場合は、ここからインストールできます。 さらに、これを行う方法はユーザーの裁量に任されています。



いつするの？

• ユーザーには、コンピューターの管理者権限がありません。
• 一時的に、「見る」。
• 独自のスクリプト。

私は通常、ファイルレイアウトごとにディレクトリとパッケージを組み合わせて使用​​します。 常に動作するソフトウェアの場合、原則として、これらは私のスクリプトです;ディレクトリ/ home / username / bin / home / username / etc / home / username / varを作成します。 ただ見たりプレイしたいソフトウェアは、ディレクトリ/ home / username / sw / softnameでコンパイルされ、そこから起動します。

12.0 /ホーム階層の他の用途

/ホーム階層は、コンピューターで実行される大規模なタスクに関連するファイルをホストするためによく使用されます。 たとえば、プロジェクトはprojectnameという名前で開発されています。 次に、 プロジェクト名という名前でシステム内のユーザーを起動し、それに関連するすべてのものを/ home / projectnameディレクトリに配置します

13.0その他のOS

かつて、ボボッキンの母親は彼女の父親に言った。

「私たちの小さなボボチカはすでに

セックスについて話す時間？」

お父さんは考えて答えました。

「おそらくあなたは正しいでしょう、どういうわけか不快です。」

ママ：「さて、蝶の例について教えてください。」

お父さんはリトルジョニーに電話して言った：

「小さなジョニー、あなたと私がいたことを覚えている

売春宿？」

「私は覚えています。」

「さて、ここで：蝶はまったく同じです。」





逸話

Freebsd

FreeBSDでは、原則としてすべてが同じですが、わずかな違いがあります。 基本システムのファイルは、メイン階層のDebian / UbuntuのLinuxファミリーのようにそこにあります。 バイナリパッケージは、パッケージとポートの2つの概念に対応しています。



パッケージはDebian / Ubuntuのパッケージとほぼ同じです。 パッケージマネージャとして、パッケージ（およびポート）を操作するために一連のコマンドが使用されます。



ポートは、システムでソースをコンパイルおよびインストールできる補助ファイルのセットです。 これにより、メディア（CDROMなど）からソースコードを自動的にダウンロードしたり、インターネットからダウンロードしたり、システムにコンパイルしてインストールしたりできます。



パッケージとポートの両方が/ usr /ローカル階層にインストールされます。



Debian / Ubuntuの場合と同じように、ソフトウェアのパッケージもポートもない場合に状況が発生する可能性があります。 それからもちろん、ソースからソフトウェアをインストールする必要があります。 これを行うには、このソフトウェアのポートを作成するか、単にソースをコンパイルして/ usr /ローカル階層にインストールします。 もちろん、FreeBSDには多くのソフトウェアがインストールされているため、注意する必要があります。 これによる競合の可能性が高まります。



さて、記事⁵で説明した方法に戻ると、独自のポートを作成しない場合、xstowプログラムを使用して順序を維持できると思います。 BSD主義者には、私には知られていない好みの方法があるかもしれませんが、間違っている場合は知識のある仲間に修正してもらいます。

Windowsファミリー

オペレーティングシステムのWindowsファミリでは、原則として、各ソフトウェアパッケージに独自の階層がある場合、ソフトウェアをホストするアプローチが使用されます。 宛先ごとのファイルのレイアウトへのいくつかのシフトがありますが、これは妨げられます：



-ファイルシステムによる単一ツリーの欠如（パーティション、C：、D：などを示す文字）。

-伝統。

-実績のあるソフトウェアとの互換性の要件。

おわりに

この記事がお役に立てば幸いです。 原則として、別の記事で他のUNIX / Linux FSディレクトリと階層の目的をより詳細に分析することができます。

使用されている略語のリスト

.deb	Debian / Ubuntuソフトウェアパッケージファイル拡張子
dpkg	dpkgは、Debianのパッケージ管理システムのバックボーンであるソフトウェアです。
PID	プロセスID
RPM	Red Hat Package Manager-Red Hat Package Manager
Db	データベース
MP	パッケージマネージャー
OS	オペレーティングシステム
ソフトウェア	ソフトウェア
リポジトリ	MP経由でアクセスできるソフトウェアストレージ
FS	ファイルシステム

文学

1. 標準のLinuxファイルシステム階層（File System Hierarchy Standard）

2. ファイルシステム階層標準 （Debianポリシーの補遺）

3.http： //ru.wikipedia.org/wiki/RPM

4.http： //ru.wikipedia.org/wiki/Dpkg

5. Linux：xstowマネージャーを使用した非配布プログラムのインストール

6.男性雇用者