ルートファイルシステムは適切に起動・復帰・回復し、あるいはシステムを修復することが出来るようになっていなくてはいけません。
(i) 補足説明
目標を実現する上での主な問題は、どれだけ多くのファイルをルートファイルシステム上におくべきか、あるいは少なくすべきかを熟慮して均衡を保つことでした。ルートファイルシステムを小さくしておくことのほうが望ましいです。
- 時折 FDD などのとても小さなメディアからマウントされることがあります
- ルートファイルシステムには多くのシステムに特化した設定ファイルが含まれています。例を挙げるなら、システムの kernel やホスト名の記述などです。つまり、ネットワークで結ばれたシステム間であっても、ルートファイルシステムが常に共有可能(shareble)ではないことを意味します。ネットワークでつながっているサーバ間においては、非共有ファイル領域によって占められる領域を減らす役割も持ちます。言い換えれば、小さなローカルハードディスクでもワークステーションになりうることが出来るのです。
- もしかしたらルートファイルシステムの為に多くの容量を確保できて心底満足しているかもしれませんが、一方で小さな領域しか確保できない方達もいます。多くのファイルをインストールするには、小さな領域のルートファイルシステムを用いることを想定して互換性を持たせなくてはいけません。開発者であるなら、多くのユーザが問題を抱えることを想定したほうがいいでしょう。
- 他の領域でデータ破損のエラーが発生するよりルートファイルシステムで発生する方が大問題になります。小さなルートファイルシステムであればシステム障害の影響を少なくさせる傾向が見受けられます。
アプリケーション側では決してルートディレクトリ配下に特定のファイルやディレクトリを作成するか必要とさせるようにしてはいけません。FHS 階層システムに従うように、どのようなパッケージも柔軟性を持たせてファイルを適切に配置します。
(i) 補足説明
ルートファイルシステム配下に新しいサブディレクトリを作ることを禁止する理由:
- システム管理者はパフォーマンスとセキュリティー上の理由により、ルート領域を小さく単純にしたがっています。
- たとえ規制をしてもシステム管理者が標準的なファイル階層を乱してなんとか領域をマウントしてしまうかもしれないからです。
- ディストリビューションはアプリケーションの運用を熟慮し、ルート配下に新しいディレクトリを作らないように極めて注意を払う必要があります。
以下のディレクトリやシンボリックリンクは / 階層下のものです
上記のディレクトリの詳細については以下のサブセクションで詳細を規定します。/usr と /var については複雑なため、それぞれ独立した章で説明します。
多くのシステムでは / ディレクトリ配下に以下のディレクトリかディレクトリへのシンボリック・リンクが作成されています。
以下の項では個々のディレクトリの詳細について述べます。
/bin にはシステム管理者・一般ユーザ共に使用するコマンド群が設置されています。/bin はシングル・ユーザ・モードなど他のファイルシステムが読めない状態でも使えるようになっていなくてはいけません。また、ディレクトリには間接的に実行されるスクリプトが置かれている場合もあります*1。
/bin 配下にサブディレクトリがあってはいけません。
/bin には以下のコマンドあるいはシンボリックリンクが必要です。
(i) 補足説明
/bin/sh があっても、それがボーンシェルの実体ではありません。本当のシェルコマンド(/bin/bash)へのハード・リンクかシンボリック・リンクです。
[ と test コマンドは、たとえシェルの一部だとしても POSIX2 標準に準拠するため /bin か /usr/bin にバイナリを置かなくてはいけません。
対応するサブシステムがインストールされている場合、以下のプログラムかシンボリック・リンクは /bin 以下になくてはいけません。
もし gunzip と zcat プログラムがあるなら、それらは gzip へのシンボリック・リンクかハード・リンクです。/bin/csh は /bin/tcsh あるいは /usr/bin/tcsh へのシンボリック・リンクの場合があります。
(i) 補足説明
tar, gzip, cpio は / 領域への障害が起こったときのシステム回復を可能にするため加えられました。
逆にルートパーティションからの修復が必要でないなら、これらのファイルは不要となります。たとえば ROM チップからのルート構成や NFS による /usr へのマウントです。システムの修復をネットワーク経由で行うことを計画しているのであれば、ftp あるいは tftp(ftp接続を受けるために必要)がルートパーティション上に置かれるようにしなくてはいけません。
このディレクトリは起動時に必要とする設定ファイル群とマップ・インストーラーが全て置かれています。カーネルがユーザーモードでのプログラムを実行しはじめる前は /boot へデータを保管します。この中にはマスター・ブート・セクターとセクター・マップ・ファイルを含む場合もあります*2。
特定のオペレーティング・システムではカーネルを / もしくは /boot に置く必要があります*3。
/dev ディレクトリは特別な場所あるいはデバイスファイルです。
/dev を手作業で作成しなくてはいけない場合があり得ます。/dev にはデバイスを作成するための MAKEDEV というコマンドが必要です。あるいはローカル・デバイス用に MAKDEV.local というファイルを含む場合もあります。
MAKEDEV はシステム上で構成されている全てのデバイスを個々に認識させるときに必要となります。
/etc 階層には設定ファイルが置かれます。"設定ファイル"というのはプログラムの操作や制御を行うときに必要となるローカルなファイルです。ファイルは静的(static)であり、実行可能なバイナリであってはいけません*4。
/etc 階層下にはバイナリファイルを置いてはいけません*5。
以下のディレクトリあるいはディレクトリへのシンボリック・リンクが /etc に必要とされます:
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /etc に置かれます:
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /etc に置かれなくてはいけません*6:
mtab を /etc 配下に置くのは歴史的な経緯により不適切とされています*7。
目的
/opt 配下にインストールされるアプリケーションのソフトウェア・パッケージが /opt/<サブディレクトリ名> であれば、対応する設定ファイルのディレクトリ名がが /etc/opt/<サブディレクトリ名>となります。
必要条件
/etc/opt/<サブディレクトリ> の構造に対する制限は特にありません。
特定動作のためのシステムパッケージに含まれる設定ファイルが異なった場所にあれば、/etc/opt/<サブディレクトリ名> ディレクトリに移動させなくてはいけません。
(i) 補足説明
/opt に関する補足説明は特にありません。
目的
/etc/X11 は全ての X11 ホストが参照する設定ファイルの場所です。ローカルな環境でのみ利用したい場合は /usr ディレクトリが読み込み専用(read-only)となっている必要があります。
オプション指定
対応するサブシステムがインストールされていれば、/etc/X11 以下にファイルやシンボリック・リンクがあります。
/etc/X11 の中には xdm やその他のプログラム(たとえば若干のウインドウ・マネージャ等)の利用するサブディレクトリが含まれる場合があります*8。ウインドウ・マネージャーは標準の設定ファイル名である .*wmrc を system.*wmrc として用い(広く受け入れられる代替名が無いため)、サブディレクトリは用いない事を薦めます。どのようなウインドウ・マネージャであっても実際のウインドウ・マネージャのバイナリと同じと識別できる名前を用いなくてはいけません。
目的 SGML システムが用いるハイレベルに定義されているパラメータ群の定義ファイルが置かれています。ファイル名は *.conf というのが一般的です。ファイル名 *.cat は DTD という SGML 文章の書式定義ファイルで、カタログやリファレンス、その他 DTD が必要とする一覧を含んでいます。優れたカタログはすべてを一覧に集中させているものです。
目的 XML システムが用いるハイレベルに定義されている一般的な設定ファイルが置かれています。ファイル名は *.conf というものが一般的です。優れたカタログは全てを一覧に集中させているものです。
/home はかなり標準的な概念ですが、明らかにサイトに特定されたファイルシステムです*9。セットアップ方法はホスト毎に異なるでしょう。そのため、プログラムは /home 配下に配置すべきではありません*10。
ユーザが用いるアプリケーションがそれぞれ固有の設定ファイルを持つ場合、ユーザのホームディレクトリ内に . (ドット)で始まるファイル名を用います。アプリケーションがサブディレクトリを必要とする場合も同様に . (ドット)で始まるディレクトリ名を用います。サブディレクトリ内で設定ファイルを置く場合は . を用いないほうが良いでしょう*11。
/lib ディレクトリはルートファイルシステム上でシステムを起動したり /bin や /sbin のコマンドを実行させる際に必要となる重要な共有ライブラリを配置します*12。
最低でも以下のファイル名のパターンを必要とします(ファイルもしくはシンボリック・リンク):
もし C プリプロセッサがインストールされるなら、歴史的な経緯から /lib/cpp が参照されるでしょう*13。
対応するサブシステムがインストールされる場合、/lib 以下にディレクトリ、あるいはディレクトリへのシンボリック・リンクでなくてはいけません:
システムによっては特定フォーマットのバイナリを実行するために /lib とは別個のライブラリを用いる場合があるかもしれません*14。
複数のディレクトリが存在する場合は、/lib<qual>/cpp を必要としない以外、一般的な /lib ディレクトリが必要とする条件と同じです*15。
ディレクトリにはフロッピーディスク、CD-ROM、ZIPディスクなどのようなリムーバブル・メディア(書き換え可能な記録媒体)をマウントするためのサブディレクトリを含みます。
(i) 補足説明
以前から /cdrom , /mnt, /mnt/cdrom といったようにリムーバブル・メディアをマウントするためには多くの異なった場所がありました。マウントポイントを全てルート直下のディレクトリに置くことになれば、リムーバブル・メディア毎に多くの余分なサブディレクトリが必要になってしまうでしょう。とはいえ、最近まで一般的には /mnt をマウントすることが一般的でしたので、伝統的に /mnt ディレクトリを一時的なマウントポイントとして用いることと矛盾してしまうでしょう。
対応するサブシステムがインストールされている場合、それらは /media 配下へのディレクトリかシンボリックリンクでなくてはいけません:
ある種のメディアをマウントすることによって1つ以上のデバイスが存在するシステムでは、'0' に始まってデバイス名を示すマウントディレクトリを作成することができます。ですが、無条件で同じファイル名のものは存在してはいけません*16。
システム管理者が必要なときに一時的にファイルシステムをマウントできるように用いるディレクトリです。ディレクトリにはローカルな利用のみで、動作中のどのようなプログラムに対しても影響を与えてはいけません。
インストール用プログラムはこのディレクトリを使用してはいけません。/mnt ではない適切な未使用ディレクトリをシステムは用いなくてはいけません。
/opt は追加アプリケーションのソフトウェア・パッケージのために用います。
パッケージは /opt 配下にパッケージ自身の名前を /opt/<package> とするか /opt/<provider> というディレクトリ階層で配置します。<package> はソフトウェア・パッケージを指し示す名前のことで、<provider> は LANANA(Linux Assigned Name And Number Authority - http://www.lanana.org/ ) に登録してある提供者名です。
/opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, /opt/man の各ディレクトリはローカルのシステム管理者が使用するために予約されているディレクトリ名です。パッケージ名によってはローカルのシステム管理者によって初期段階でこれら意図されたディレクトリにファイルやリンクを置く場合もあります。ですが、これら予約名のディレクトリが存在しない場合もありますので注意が必要です。
ユーザによって実行されるプログラムは /opt/<package/bin 配下か /opt/<provider> 配下に置く必要があります。パッケージが UNIX マニュアルページを含む場合は /opt/<package>/share/man か /opt/<provider> 配下に設置し、/usr/share/man 配下と同様の構成を持たなくてはいけません。
パッケージによって可変的なファイル(通常のファイルに対する操作)は /var/opt にインストールされなくてはいけません。詳しくは /var/opt に関するセクションを読んでください。
特定のホストに対する設定ファイルは /etc/opt に設置しなくてはいけません。詳しくは /etc セクションをご覧下さい。
どのようなパッケージでも /opt, /var/opt, /etc/opt 配下のディレクトリ以外にパッケージファイルを置く場合はファイルシステム上で規定されている設置方法に従わなくてはいけません。たとえば、デバイスのロックファイルは /var/lock であり、デバイス自身は /dev でなくてはいけません。
ディストリビューションによってはソフトウェアを /opt にインストールするかもしれませんが、ローカルのシステム管理者の許可無くインストールされたソフトを修正したり削除してはいけません。
(i) 補足説明
UNIX コミュニティでは /opt を追加ソフトウェアを置く場所にする習慣があります。System V アプリケーション実行インターフェース[AT&T 1990]では System V インターフェース定義(第三版)を元にし /opt を用いるように定義された事と非常に似ています。
Intel Binary Compatibility Standard v.2(iBSC2) でも同様に /opt に似た構造が提供されています。
一般的にシステムでパッケージが必要とする全てのデータは /opt/<package> 配下に置く必要があり、このなかには /etc/opt<package> と /var/opt/<package> という予約ディレクトリに置くことも含まれます。
ディストリビューションが /opt を使うにあたり、ディストリビューションによってインストールされるローカルのソフトウェア、特に若干のソフトウェアの実行ファイルパス名と衝突してしまうという障害があります。
/opt/<provider> のディレクトリ構造を決めるのはソフトウェアのパッケージ次第です。つまり、パッケージは /opt/<provider>/<package> か似たような構造である /opt/package というガイドラインに従う必要があります。パッケージは /opt/<provider>/lib や /opt/<provider>/bin といったディレクトリにサポート用のファイルを必要に応じて分散して配置することができます。
ルートアカウントのホームディレクトリは開発者かローカル設定によって定義されますが、/root が root の為のホームディレクトリとして推奨される場所です*17。
システム管理者が用いるユーティリティ(root しか実行できないコマンドも含む)は /sbin, /usr/sbin, /usr/local/sbin に配置されます。/sbin はシステムの起動、回復、修復に必要となる実行ファイルが置かれていて、その他の実行ファイルは /bin に置かれます*18。/usr にマウントされているプログラムは(問題がなければ)一般的には /usr/sbin へ置かれます。システム管理者がローカル環境にプログラムをインストールするのは /usr/local/sbin であるべきです(( 何を /sbin ディレクトリに配置するかを決めるのは単純です:もし標準(システム管理者ではない)ユーザが実行するファイルであれば、それらは /bin ディレクトリに置くべきです。一般ユーザが利用するコマンドは /sbin に置くべきではありません。たとえば、chfn といったファイルはユーザが時折使うため /usr/bin に置かなくてはいけません。ping コマンドは root ユーザが(ネットワークの回復と診断に)用いますが、一般ユーザも使うことがあるので /bin に置かなくてはいけません。/sbin では全ユーザが setuid と setgid プログラム以外のすべての実行ファイルに対して読み込みと実行権限を持つことをお奨めします。/bin と /sbin はセキュリティ上の配慮やオペレーティング・システムから参照するユーザについて考慮されていません。ですが、一般ユーザが使うコマンドは /bin へ、/sbin は管理者によって実行されるべきものとしてファイルの区別を設けたほうが便利でしょう。元々 /sbin に対してはセキュリティ上、一般ユーザが利用してはいけないということはありません。 ))。
以下のコマンドあるいはあるいはシンボリックリンクが /sbin 以下に必要とされます:
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /sbin に置かれます。
/srv はシステムによって提供されるサイトに特定したデータを置きます。
(i) 補足説明
/srv を指定することの主な目的はユーザが特定のサービスのためのデータファイルを見つけやすいようにすることと、サービスが読み込み専用(readonly)、書き込み可能なデータと(CGI スクリプトのような)スクリプトのために特定の置き場所をサービスが必要とする場合のためです。ただし、特定のユーザのみが利用する重要なデータは各ユーザのホームディレクトリに置かれるべきです。
現時点で /srv ディレクトリをどのように命名したり扱うかについて具体的に特定されておらず、意見の一致もみられません。/srv が使用を想定しているプロトコルは ftp rsync, www ,cvs といったものです。大きなシステムではシステム管理者が利用しやすいように /srv/physics/www や /srv/compsci/csv のような構造を用いることで利便性が向上するでしょう。ですが、実際のところ /srv ディレクトリ配下にサブディレクトリやファイルを配置を必要とするプログラムはみうけられません。とはいえ、 /srv は FHS 互換システムに定義されており、いずれこのようなデータの置き場所として用いられるべきでしょう。
ディストリビューションは管理者の権限なく /srv ディレクトリに置かれているファイルを消してはいけないよう注意しなくてはいけません*19。
/tmp ディレクトリは一時的なファイルを必要とするプログラムのために提供されなくてはいけません。
プログラムは /tmp 配下でディレクトリやファイルが存在し続ける事を想定してはいけません。
(i) 補足説明
IEEE 標準 P1003.2(POSIX, part 2) では上記のセクションに類似している条件を提示しています。
/tmp に保管されたデータは操作によっては削除されるかもしれません。/tmp 以下のファイルやディレクトリはシステムの起動時に削除する事を推奨します。
FHS では歴史的背景と一般的な習慣から /tmp の利用を推奨しましたが、システム管理者にとって必需な標準領域とはなりませんでした。