FHS/6. オペレーティング・システム特有の補足説明

• Prev
• Next
• FHS

6章 オペレーティング・システム固有の補足説明 †

　このセクションでは特定のオペレーティング・システムに対してのみあてはまる追加補足や推薦事項です。このセクションの資料は決して FHS 標準と対立するものであってはいけません。

Linux †

　ここは Linux オペレーティング・システムのための補足説明です。

/ : ルートディレクトリ †

　Linux システムでカーネルが / 直下に置かれている場合、そこで用いられる名前は vmlinux か vmlinuz です。最近の Linux カーネルパッケージまで用いられていました。

/bin : 重要なユーザ・コマンド群（全てのユーザーが利用） †

Linux システムでは以下の追加ファイルを /bin 以下に必要とします:

• setserial

/dev : デバイスと特別なファイル †

以下のファイルが /dev になくてはいけません。

/dev/null

このデバイスに書き込まれる全てのデータは破棄されます。このデバイスから読み込みを行おうとしても EOF 条件しか返しません。

/dev/zero

このデバイスは 0 を返すデータの源です。このデバイスに書き込まれる全てのデータは破棄されます。このデバイスから読み込みを行うとゼロという値を含んでいるバイト値を返します。

/dev/tty

このデバイスはプロセスの端末制御と同じ概念です。デバイスがオープンされるたびに実際のターミナルデバイスがオープンされたかのように読み込み・書き込みが動作します。

(i) 補足説明

　以前の FHS では /dev に対してより厳しい必要条件を与えていました。/dev には他のデバイスが何か存在するかもしれません。デバイス名には他のデバイスのノードを指し示すシンボリックリンクか /dev 配下のサブディレクトリとなっているかもしれません。デバイスに対して番号を割り振ることは重要でも不要でもありません。

/etc : ホスト固有のシステム設定 †

　Linux システムでは以下の追加ファイルを /etc 以下に必要とします:

• lilo.conf

/lib64 と /lib32 : 64/32 ビット・ライブラリ（アーキテクチャ依存） †

　PPC64、s390x、sparc64、AMD64 といった 64ビット・アーキテクチャが必要とするライブラリ群は /lib64に、そして 32 ビット（あるいは 31 ビットの s390）のライブラリは /lib に置かなくてはいけません。

　64 ビットのアーキテクチャ IA64 の場合は、64 ビットライブラリを /lib に置かなくてはいけません。

(i) 補足説明

　 これは /lib<qual> と /usr/lib<qual> における一般的な規則の改良にあたります。PPC64、s390x、sparc64、AMD64 アーキテクチャは 32 ビット（s390 は 31 ビット）での動作もサポートしているためです。32 ビットのバイナリを多数のバイナリが置かれている /lib で使うことにしておけば、32 ビットのシステムは何も変更を行う必要はありません。IA-64 ユーザは異なった仕組みを用います。アーキテクチャ内では 32 ビットのものは独立したライブラリを用いるようにしています。

/proc : カーネルとプロセス情報の仮想ファイルシステム †

　proc ファイルシステムは /dev/kmem やその他の似たようなコマンドを使うよりも、プロセスとシステム情報を処理するために用いる Linux では事実上標準的なシステムです。記録装置の情報やカーネル情報、メモリ情報と同様、プロセスの情報を得るために /proc を用いることを強く推奨します。

/sbin : 重要なシステムコマンド群 †

Linux システムでは以下の追加ファイルを /sbin 以下に必要とします:

• ext2 (２番目に拡張された)ファイルシステムのコマンド（オプション）
  • badblocks
  • dumpe2fs
  • e2fsck
  • mke2fs
  • mklost+found
  • tune2fs
• ブートローダー用マップ・インストーラー（オプション）
  • lilo

/sbin のオプションファイル:

• 静的なバイナリ
  • ldconfig
  • sln
  • ssync

　静的な ln(sln) と静的な sync(ssync) は失敗したときの為に便利なものです。sln の主な用途（アップグレードによって /lib への調整が不適切で間違ったシンボリック・リンクを修復すること）は ldconfig プログラム（ /usr/sbin にあります）の登場によって重要ではなくなり、ダイナミックライブラリのアップグレードを ldconfig が務めるようになりました。静的な sync はいくつかの緊急事態で役に立ちます。標準的な ln と sync のバージョンでは静的なリンクが必要とされていないかもしれないので注意を払ってください。

　ldconfig コマンドは共有ライブラリをアップグレードするときだけよりも、むしろサーバ起動時に ldconfig を実行出来るように選べるようにしておくことが望ましいでしょう。（起動時の度に ldconfig を実行することに利点があるかどうかは明白ではありません。）たとえそうだとしても、以下の状況に陥った時のため多くの人から ldconfig は好かれています：

• わたしは /lib/<file> をちょうど削除してしまいました。
• ls コマンドが動的にリンクされているライブラリ名が分かりません。シェルを使っても ls を実行できません。なので、 "echo *" コマンドで置き換えるしか方法を知りません。
• 私は静的な sln を持っています。ですが、これが何をコールし、何をリンクしているか分かりません。

• その他
  • ctrlaltdel
  • kbdrate

　若干のキーボードで調整を必要とするために kbdrate が /sbin にインストールされるかもしれません。

　Ctrl-Alt-Del キーの組み合わせによって簡単にルートファイルシステムのファイル読み書きを禁止にし、ハードウェアの再起動を行わせることがカーネルのデフォルトとして実装されていました。init によっては Ctrl-Alt-Del 機能を利用不可能としている場合もあります。ですが、そのような場合は /sbin に ctrlaltdel プログラムが置かれているかもしれません。

/usr/include : Ｃ言語のヘッダファイル †

　C 言語か C++ 言語のコンパイラがインストールされているか、あるいは glibc をベースとしていないシステムでも以下のシンボリック・リンクを必要とされます。

/usr/include/asm -> /usr/src/linux/include/asm-<arch>
/usr/include/linux -> /usr/src/linux/include/linux

/usr/src : ソースコード †

　glibc に基づくシステムにはディレクトリに対する特定のガイドラインがありません。Linux 版 libc が glibc よりも優先度が高いシステムでは、以下のガイドラインと理論が適用されます。

　唯一ソースコードの置く場所が定義されているのは Linux カーネルのソースコードです。/usr/src/linux と規定されてます。

　もし C あるいは C++ コンパイラがインストールされていても、完全な Linux カーネルソースがインストールされていないなら、カーネルソースコードの組み込みファイルは以下のディレクトリに置かれているでしょう。

/usr/src/linux/include/asm-<arch>
/usr/src/linux/include/linux

　<arch> はシステムアーキテクチャの名前です。

メモ

　/usr/src/linux はカーネルソースコードツリーへのシンボリック・リンクの場合があります。

(i) 補足説明

　カーネルの組み込みファイルが /usr/src/linux や /usr/include に無い事は重要ではありません。システム管理者が管理者が始めてカーネルのバージョンアップを行うときでも問題はありません。

/var/spool/cron : cron と at のジョブ制御 †

　このディレクトリは cron と at のため、そしてプログラムのための可変的なデータを含みます。

• Prev
  FHS/5. /var 階層
• Next
  FHS/7. 付録(Appendix)
• Home
  Up