3章 root ファイルシステム †
目的 †
ルートファイルシステムは適切に起動・復帰・回復し、あるいはシステムを修復することが出来るようになっていなくてはいけません。
- システムを起動するためには他のファイルシステムをマウントするために十分な root 領域が確保されていなければいけません。ここには各種ユーティリティ、設定ファイル、ブートローダー設定、そして起動に重要なデータも含みます。/usr /opt /var には他の領域やファイルシステムから参照できる場所に置かれるよう設計されているでしょう。
- システムの回復・修復を行うにはルートファイルシステム上に破損したシステムの診断や、ベテラン管理者が再構築を行うためのユーティリティが置かれます。
- システムを復元するためには、ルートファイルシステムを用いて、それらユーディリティがシステムバックアップ(フロッピーやテープ上など)から復旧します。
(i) 補足説明
目標を実現する上での主な問題は、どれだけ多くのファイルをルートファイルシステム上におくべきか、あるいは少なくすべきかを熟慮して均衡を保つことでした。ルートファイルシステムを小さくしておくことのほうが望ましいです。
- 時折 FDD などのとても小さなメディアからマウントされることがあります
- ルートファイルシステムには多くのシステムに特化した設定ファイルが含まれています。例を挙げるなら、システムの kernel やホスト名の記述などです。つまり、ネットワークで結ばれたシステム間であっても、ルートファイルシステムが常に共有可能(shareble)ではないことを意味します。ネットワークでつながっているサーバ間においては、非共有ファイル領域によって占められる領域を減らす役割も持ちます。言い換えれば、小さなローカルハードディスクでもワークステーションになりうることが出来るのです。
- もしかしたらルートファイルシステムの為に多くの容量を確保できて心底満足しているかもしれませんが、一方で小さな領域しか確保できない方達もいます。多くのファイルをインストールするには、小さな領域のルートファイルシステムを用いることを想定して互換性を持たせなくてはいけません。開発者であるなら、多くのユーザが問題を抱えることを想定したほうがいいでしょう。
- 他の領域でデータ破損のエラーが発生するよりルートファイルシステムで発生する方が大問題になります。小さなルートファイルシステムであればシステム障害の影響を少なくさせる傾向が見受けられます。
アプリケーション側では決してルートディレクトリ配下に特定のファイルやディレクトリを作成するか必要とさせるようにしてはいけません。FHS 階層システムに従うように、どのようなパッケージも柔軟性を持たせてファイルを適切に配置します。
(i) 補足説明
ルートファイルシステム配下に新しいサブディレクトリを作ることを禁止する理由:
- システム管理者はパフォーマンスとセキュリティー上の理由により、ルート領域を小さく単純にしたがっています。
- たとえ規制をしてもシステム管理者が標準的なファイル階層を乱してなんとか領域をマウントしてしまうかもしれないからです。
- ディストリビューションはアプリケーションの運用を熟慮し、ルート配下に新しいディレクトリを作らないように極めて注意を払う必要があります。
必要条件 †
以下のディレクトリやシンボリックリンクは / 階層下のものです
- ディレクトリ名
- 説明
- bin
- 重要なコマンドのバイナリ(binary の bin)
- boot
- ブートローダーの為の静的なファイル(起動の boot)
- dev
- デバイスファイル(device の dev)
- etc
- ホスト特有のシステム設定(etcetera の etc)
- lib
- 重要な共有ライブラリとカーネルモジュール(library の lib)
- media
- リムーバブル・メディアのためのマウントポイント(メディア のmedia)
- mnt
- ファイルシステムの一時的なマウントポイント(mount の mnt)
- opt
- 追加アプリケーションのソフトウェア・パッケージ(option の opt)
- sbin
- 重要なシステムコマンド(sysytem binary で sbin)
- srv
- システムによって提供されるサービスデータ(service の srv)
- tmp
- 一時的なファイル(temporary の tmp)
- usr
- 第二階層
- var
- 動的データ(Variable の var)
上記のディレクトリの詳細については以下のサブセクションで詳細を規定します。/usr と /var については複雑なため、それぞれ独立した章で説明します。
オプション仕様 †
多くのシステムでは / ディレクトリ配下に以下のディレクトリかディレクトリへのシンボリック・リンクが作成されています。
- ディレクトリ名
- 説明
- home
- ユーザのホームディレクトリ(オプション)
- lib<qual>
- 重要な共有ライブラリの代理構成 (オプション)
- root
- root ユーザのためのホームディレクトリ(オプション)
以下の項では個々のディレクトリの詳細について述べます。
/bin : 重要なコマンドのバイナリ(全ユーザが使用) †
目的 †
/bin にはシステム管理者・一般ユーザ共に使用するコマンド群が設置されています。/bin はシングル・ユーザ・モードなど他のファイルシステムが読めない状態でも使えるようになっていなくてはいけません。また、ディレクトリには間接的に実行されるスクリプトが置かれている場合もあります*1。
必要条件 †
/bin 配下にサブディレクトリがあってはいけません。
/bin には以下のコマンドあるいはシンボリックリンクが必要です。
- コマンド
- 説明
- cat
- 標準出力にファイルを連結して出力(ファイル表示)します
- chgrp
- ファイルグループの所有権を変えます
- chmod
- ファイルアクセス許可を変えます
- chown
- ファイル所有者とグループを変えます
- cp
- ファイルとディレクトリをコピーします
- date
- システムの日付と時刻を表示・設定します
- dd
- ファイルを変換してコピーします
- df
- ファイルシステム上の使用領域量を表示します
- dmesg
- カーネルのリングバッファを表示するか制御します
- echo
- 1行のテキストを表示します
- false
- 何もせずに終了します(失敗を意味する 1 を返します)
- hostname
- 現在のホストシステムの名前を設定・表示します
- kill
- プロセスにシグナルを送ります(主に終了)
- ln
- ファイルへのリンクを作成します
- mkdir
- ディレクトリを作成します
- mknod
- ブロックデバイスや特別なファイルを作成します
- more
- ファイルを閲覧するフィルタ(ページ送りをします)
- mount
- ファイルシステムをマウントします
- mv
- ファイルを移動します
- ps
- プロセスの状態を報告します
- pwd
- 現在のディレクトリ名(present working directory)を表示します
- rm
- ファイルやディレクトリを削除します
- rmdir
- 空のディレクトリを削除します
- sed
- ストリームエディタを使用します
- sh
- ボーン・コマンド・シェルを実行します
- stty
- 端末ラインの表示・設定を変更します
- su
- ユーザ ID とグループ ID を変更してシェルを起動します
- sync
- ファイルシステムのメモリバッファをディスクと同期させます
- umount
- ファイルシステムをアンマウント(マウント解除)します
- uname
- システム情報を表示します
(i) 補足説明
/bin/sh があっても、それがボーンシェルの実体ではありません。本当のシェルコマンド(/bin/bash)へのハード・リンクかシンボリック・リンクです。
[ と test コマンドは、たとえシェルの一部だとしても POSIX2 標準に準拠するため /bin か /usr/bin にバイナリを置かなくてはいけません。
オプション仕様 †
対応するサブシステムがインストールされている場合、以下のプログラムかシンボリック・リンクは /bin 以下になくてはいけません。
- コマンド
- 説明
- csh
- C シェル(オプション)
- ed
- ed エディタ(オプション)
- tar
- tar アーカイブ・ユーティリティー(オプション)
- cpio
- アーカイブ上でのコピー操作を行う(オプション)
- gzip
- GNU ファイルの圧縮を行う(オプション)
- gunzip
- GNU ファイルの伸長(展開)を行う(オプション)
- zcat
- GNU ファイルの伸長(展開)を行う(オプション)
- netstat
- ネットワーク関連の統計値を出力する(オプション)
- ping
- ICMP ネットワークテストを行う(オプション)
もし gunzip と zcat プログラムがあるなら、それらは gzip へのシンボリック・リンクかハード・リンクです。/bin/csh は /bin/tcsh あるいは /usr/bin/tcsh へのシンボリック・リンクの場合があります。
(i) 補足説明
tar, gzip, cpio は / 領域への障害が起こったときのシステム回復を可能にするため加えられました。
逆にルートパーティションからの修復が必要でないなら、これらのファイルは不要となります。たとえば ROM チップからのルート構成や NFS による /usr へのマウントです。システムの修復をネットワーク経由で行うことを計画しているのであれば、ftp あるいは tftp(ftp接続を受けるために必要)がルートパーティション上に置かれるようにしなくてはいけません。
/boot : ブートローダーの為の静的なファイル †
目的 †
このディレクトリは起動時に必要とする設定ファイル群とマップ・インストーラーが全て置かれています。カーネルがユーザーモードでのプログラムを実行しはじめる前は /boot へデータを保管します。この中にはマスター・ブート・セクターとセクター・マップ・ファイルを含む場合もあります*2。
オプション仕様 †
特定のオペレーティング・システムではカーネルを / もしくは /boot に置く必要があります*3。
/dev : デバイスファイル †
目的 †
/dev ディレクトリは特別な場所あるいはデバイスファイルです。
オプション使用 †
/dev を手作業で作成しなくてはいけない場合があり得ます。/dev にはデバイスを作成するための MAKEDEV というコマンドが必要です。あるいはローカル・デバイス用に MAKDEV.local というファイルを含む場合もあります。
MAKEDEV はシステム上で構成されている全てのデバイスを個々に認識させるときに必要となります。
/etc : ホスト固有のシステム設定 †
目的 †
/etc 階層には設定ファイルが置かれます。"設定ファイル"というのはプログラムの操作や制御を行うときに必要となるローカルなファイルです。ファイルは静的(static)であり、実行可能なバイナリであってはいけません*4。
必要条件 †
/etc 階層下にはバイナリファイルを置いてはいけません*5。
以下のディレクトリあるいはディレクトリへのシンボリック・リンクが /etc に必要とされます:
- コマンド
- 説明
- opt
- /opt の為の設定ファイル
- X11
- X Window システムのための設定ファイル(オプション)
- sgml
- SGML の為の設定ファイル(オプション)
- xml
- XML の為の設定ファイル(オプション)
オプション仕様 †
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /etc に置かれます:
- ディレクトリ名
- 説明
- opt
- /opt の為の設定ファイル
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /etc に置かれなくてはいけません*6:
- ファイル名
- 説明
- opt
- /opt の為の設定ファイル
- csh.login
- C シェルログインのための環境初期化ファイル(オプション)
- exports
- NFS ファイルシステムのアクセス制御リスト(オプション)
- fstab
- ファイルシステムのための静的な情報(オプション)
- ftpusers
- FTP デーモンのユーザアクセス制御リスト(オプション)
- gateway
- ゲートウェイ・経路を記述したファイル(オプション)
- gettydef
- getty 使用時の速度と端末設定(オプション)
- group
- ユーザー・グループ・ファイル(オプション)
- host.conf
- DNS リゾルバ設定ファイル(オプション)
- hosts
- ホスト名の静的な情報(オプション)
- hosts.allow
- TCP ラッパーのためのアクセス許可ホストのリスト(オプション)
- hosts.deny
- TCP ラッパーのためのアクセス拒否ホストのリスト(オプション)
- hosts.equiv
- rlogin, rsh, rcp のための信頼できるホストのリスト(オプション)
- hosts.lpd
- lpd のための信頼出来るホストのリスト(オプション)
- inetd.conf
- inetd のための設定ファイル(オプション)
- iniittab
- init のための設定ファイル(オプション)
- issue
- ログイン前のメッセージ表示・識別情報のファイル(オプション)
- ld.so.conf
- 共有ライブラリの検索をする外部ディレクトリ(オプション)
- motd
- 今日のログイン(message of the day)用のファイル(オプション)
- mtab
- ファイルシステムについての動的な情報(オプション)
- mtools.conf
- mtools のための設定ファイル(オプション)
- network
- ネットワーク名についての静的な情報(オプション)
- password
- パスワード・ファイル(オプション)
- printcap
- lpd プリンタ利用可能データベース(オプション)
- profile
- シェルログインのための環境初期化ファイル(オプション)
- protocols
- IP プロトコルのリスト(オプション)
- resolv.conf
- DNS のリゾルバ設定ファイル(オプション)
- rpc
- RPC プロトコルのリスト(オプション)
- securetty
- root ログインのための TTY アクセス制御(オプション)
- services
- ネットワークサービス名とポート番号のリスト(オプション)
- shells
- 適切な(正当な)ログインシェルのパス名(オプション)
- syslog.conf
- syslogd のための設定ファイル(オプション)
mtab を /etc 配下に置くのは歴史的な経緯により不適切とされています*7。
/etc/opt : /opt の為の設定ファイル †
目的
/opt 配下にインストールされるアプリケーションのソフトウェア・パッケージが /opt/<サブディレクトリ名> であれば、対応する設定ファイルのディレクトリ名がが /etc/opt/<サブディレクトリ名>となります。
必要条件
/etc/opt/<サブディレクトリ> の構造に対する制限は特にありません。
特定動作のためのシステムパッケージに含まれる設定ファイルが異なった場所にあれば、/etc/opt/<サブディレクトリ名> ディレクトリに移動させなくてはいけません。
(i) 補足説明
/opt に関する補足説明は特にありません。
/etc/X11 : X Window システムのための設定(オプション) †
目的
/etc/X11 は全ての X11 ホストが参照する設定ファイルの場所です。ローカルな環境でのみ利用したい場合は /usr ディレクトリが読み込み専用(read-only)となっている必要があります。
オプション指定
対応するサブシステムがインストールされていれば、/etc/X11 以下にファイルやシンボリック・リンクがあります。
- ファイル名
- 説明
- Xconfig
- Xfree86 初期バージョンのための設定ファイル(オプション)
- X86Config
- Xfree86 バージョン3か4のための設定ファイル(オプション)
- Xmodmap
- X11 の グローバルなキーボード修正ファイル(オプション)
/etc/X11 の中には xdm やその他のプログラム(たとえば若干のウインドウ・マネージャ等)の利用するサブディレクトリが含まれる場合があります*8。ウインドウ・マネージャーは標準の設定ファイル名である .*wmrc を system.*wmrc として用い(広く受け入れられる代替名が無いため)、サブディレクトリは用いない事を薦めます。どのようなウインドウ・マネージャであっても実際のウインドウ・マネージャのバイナリと同じと識別できる名前を用いなくてはいけません。
/etc/sgml : SGML の為の設定ファイル(オプション) †
目的
SGML システムが用いるハイレベルに定義されているパラメータ群の定義ファイルが置かれています。ファイル名は *.conf というのが一般的です。ファイル名 *.cat は DTD という SGML 文章の書式定義ファイルで、カタログやリファレンス、その他 DTD が必要とする一覧を含んでいます。優れたカタログはすべてを一覧に集中させているものです。
/etc/xml : XML の為の設定ファイル(オプション) †
目的
XML システムが用いるハイレベルに定義されている一般的な設定ファイルが置かれています。ファイル名は *.conf というものが一般的です。優れたカタログは全てを一覧に集中させているものです。
/home : ユーザのホームディレクトリ(オプション) †
目的 †
/home はかなり標準的な概念ですが、明らかにサイトに特定されたファイルシステムです*9。セットアップ方法はホスト毎に異なるでしょう。そのため、プログラムは /home 配下に配置すべきではありません*10。
必要条件 †
ユーザが用いるアプリケーションがそれぞれ固有の設定ファイルを持つ場合、ユーザのホームディレクトリ内に . (ドット)で始まるファイル名を用います。アプリケーションがサブディレクトリを必要とする場合も同様に . (ドット)で始まるディレクトリ名を用います。サブディレクトリ内で設定ファイルを置く場合は . を用いないほうが良いでしょう*11。
/lib : 重要な共有ライブラリとカーネルモジュール †
目的 †
/lib ディレクトリはルートファイルシステム上でシステムを起動したり /bin や /sbin のコマンドを実行させる際に必要となる重要な共有ライブラリを配置します*12。
必要条件 †
最低でも以下のファイル名のパターンを必要とします(ファイルもしくはシンボリック・リンク):
- ファイル名
- 説明
- libc.so.*
- 動的にリンクされた C ライブラリ(オプション)
- ld*
- リンカ・ローダーの実行制御(オプション)
もし C プリプロセッサがインストールされるなら、歴史的な経緯から /lib/cpp が参照されるでしょう*13。
オプション仕様 †
対応するサブシステムがインストールされる場合、/lib 以下にディレクトリ、あるいはディレクトリへのシンボリック・リンクでなくてはいけません:
- ディレクトリ名
- 説明
- modules
- カーネルが読み込み可能なモジュール(オプション)
/lib<qual> : 重要な共有ライブラリの代替フォーマット(オプション) †
目的 †
システムによっては特定フォーマットのバイナリを実行するために /lib とは別個のライブラリを用いる場合があるかもしれません*14。
必要条件 †
複数のディレクトリが存在する場合は、/lib<qual>/cpp を必要としない以外、一般的な /lib ディレクトリが必要とする条件と同じです*15。
/media : リムーバブル・メディアのためのマウントポイント †
目的 †
ディレクトリにはフロッピーディスク、CD-ROM、ZIPディスクなどのようなリムーバブル・メディア(書き換え可能な記録媒体)をマウントするためのサブディレクトリを含みます。
(i) 補足説明
以前から /cdrom , /mnt, /mnt/cdrom といったようにリムーバブル・メディアをマウントするためには多くの異なった場所がありました。マウントポイントを全てルート直下のディレクトリに置くことになれば、リムーバブル・メディア毎に多くの余分なサブディレクトリが必要になってしまうでしょう。とはいえ、最近まで一般的には /mnt をマウントすることが一般的でしたので、伝統的に /mnt ディレクトリを一時的なマウントポイントとして用いることと矛盾してしまうでしょう。
オプション指定 †
対応するサブシステムがインストールされている場合、それらは /media 配下へのディレクトリかシンボリックリンクでなくてはいけません:
- ディレクトリ名
- 説明
- floppy
- フロッピードライブ(オプション)
- cdrom
- CD-ROM ドライブ(オプション)
- cdrecorder
- CD-R ドライブ(オプション)
- zip
- Zip ドライブ(オプション
ある種のメディアをマウントすることによって1つ以上のデバイスが存在するシステムでは、'0' に始まってデバイス名を示すマウントディレクトリを作成することができます。ですが、無条件で同じファイル名のものは存在してはいけません*16。
/mnt : ファイルシステムの一時的なマウントポイント †
目的 †
システム管理者が必要なときに一時的にファイルシステムをマウントできるように用いるディレクトリです。ディレクトリにはローカルな利用のみで、動作中のどのようなプログラムに対しても影響を与えてはいけません。
インストール用プログラムはこのディレクトリを使用してはいけません。/mnt ではない適切な未使用ディレクトリをシステムは用いなくてはいけません。
/opt : 追加アプリケーションのソフトウェア・パッケージ †
目的 †
/opt は追加アプリケーションのソフトウェア・パッケージのために用います。
パッケージは /opt 配下にパッケージ自身の名前を /opt/<package> とするか /opt/<provider> というディレクトリ階層で配置します。<package> はソフトウェア・パッケージを指し示す名前のことで、<provider> は LANANA(Linux Assigned Name And Number Authority - http://www.lanana.org/ ) に登録してある提供者名です。
必要条件 †
- ディレクトリ名
- 説明
- <package>
- 静的なパッケージのオブジェクト(ファイルなど)
- <provider>
- LANANA に登録された提供者名
/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 ユーザのためのホームディレクトリ(オプション) †
目的 †
ルートアカウントのホームディレクトリは開発者かローカル設定によって定義されますが、/root が root の為のホームディレクトリとして推奨される場所です*17。
/sbin : 重要なシステムコマンド †
目的 †
システム管理者が用いるユーティリティ(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 以下に必要とされます:
- コマンド名
- 説明
- shutdown
- システムを停止する命令です
オプション指定 †
対応するサブシステムがインストールされる場合、以下のファイルあるいはファイルへのシンボリックリンクが /sbin に置かれます。
- コマンド名
- 説明
- fastoot
- ディスクのチェックをせずにシステムを再起動する(オプション)
- fasthalt
- ディスクのチェックをせずにシステムを停止する(オプション)
- fdisk
- パーティション・テーブルの操作をする(オプション)
- fsck
- ファイルシステムの確認と修復をする(オプション)
- fsck.*
- 特定のファイルシステム用に確認と修復をする(オプション)
- getty
- getty プログラム(オプション)
- halt
- システムを停止する命令(オプション)
- ifconfig
- ネットワークインターフェースの構築をする(オプション)
- init
- システム起動時の最初のプロセス(オプション)
- mkfs
- ファイルシステムを構築する(オプション)
- mkfs.*
- 特定のファイルシステムを構築する(オプション)
- mkswap
- スワップ領域の構築をする(オプション)
- reboot
- システムの再起動をする(オプション)
- route
- IP 経路テーブルの表示/調整をする(オプション)
- swapon
- ページング・スワッピングを有効にする(オプション)
- swapoff
- ページング・スワッピングを無効にする(オプション)
- update
- 定期的にデーモンがファイルシステムのバッファをフラッシュする(オプション)
/srv : システムによって提供されるサービスデータ †
目的 †
/srv はシステムによって提供されるサイトに特定したデータを置きます。
(i) 補足説明
/srv を指定することの主な目的はユーザが特定のサービスのためのデータファイルを見つけやすいようにすることと、サービスが読み込み専用(readonly)、書き込み可能なデータと(CGI スクリプトのような)スクリプトのために特定の置き場所をサービスが必要とする場合のためです。ただし、特定のユーザのみが利用する重要なデータは各ユーザのホームディレクトリに置かれるべきです。
現時点で /srv ディレクトリをどのように命名したり扱うかについて具体的に特定されておらず、意見の一致もみられません。/srv が使用を想定しているプロトコルは ftp rsync, www ,cvs といったものです。大きなシステムではシステム管理者が利用しやすいように /srv/physics/www や /srv/compsci/csv のような構造を用いることで利便性が向上するでしょう。ですが、実際のところ /srv ディレクトリ配下にサブディレクトリやファイルを配置を必要とするプログラムはみうけられません。とはいえ、 /srv は FHS 互換システムに定義されており、いずれこのようなデータの置き場所として用いられるべきでしょう。
ディストリビューションは管理者の権限なく /srv ディレクトリに置かれているファイルを消してはいけないよう注意しなくてはいけません*19。
/tmp : 一時的なファイル †
目的 †
/tmp ディレクトリは一時的なファイルを必要とするプログラムのために提供されなくてはいけません。
プログラムは /tmp 配下でディレクトリやファイルが存在し続ける事を想定してはいけません。
(i) 補足説明
IEEE 標準 P1003.2(POSIX, part 2) では上記のセクションに類似している条件を提示しています。
/tmp に保管されたデータは操作によっては削除されるかもしれません。/tmp 以下のファイルやディレクトリはシステムの起動時に削除する事を推奨します。
FHS では歴史的背景と一般的な習慣から /tmp の利用を推奨しましたが、システム管理者にとって必需な標準領域とはなりませんでした。