サブディレクトリを持つディレクトリ各ディレクトリの役割を知ろう（サブディレクトリ編）
第3回 各ディレクトリの役割を知ろう（サブディレクトリ編）前回は、ルートディレクトリ直下の各ディレクトリについて、どれがどう使われるのかを解説しました。今回は、さらにそのサブディレクトリについても、説明していきます。
サブディレクトリを持つディレクトリ
ルートディレクトリ直下にあるディレクトリの中で、さらに複雑なサブディレクトリ構造を持っているのが/etc、/opt、/usr、/varの4つです。これらのディレクトリを順番に見ていきましょう。
■FHS 2.2における/etcの構造
|
|||||||||||||
| 図1 /etc以下の構成 | |||||||||||||
前回説明したように、各種の設定ファイルの保存場所として使われるのが/etcです。FHS（Filesystem Hierarchy Standard：前回参照） 2.2では、/etcにバイナリファイルを置かないこと、/opt用の設定ファイルを置くために/etc/optを設けることが要求されています。さらに、オプションとしてX Window System用の/etc/X11、SGMLとXML用の/etc/sgmlが規定されています。
/etcには以下のファイルを配置することになっていますが、いずれもオプションです。
| csh.login | cshのシステム設定ファイル | ld.so.conf | 共有ライブラリのパス | |
| exports | NFSアクセス制御リスト | motd | ログイン後のメッセージ | |
| fstab | ファイルシステムの静的な情報 | mtab | ファイルシステムの動的情報 | |
| ftpusers | FTPアクセス制御リスト | mtools.conf | mtools用設定ファイル | |
| gateways | routed用ファイル | networks | ネットワーク名の静的情報 | |
| gettydefs | getty用設定ファイル | passwd | パスワードファイル | |
| group | ユーザーグループ一覧 | printcap | プリンタデータベース | |
| host.conf | リゾルバ設定ファイル | profile | shのシステム設定 | |
| hosts | 静的なホスト名情報 | protocols | IPプロトコルリスト | |
| hosts.allow | TCP_Wrappers用設定ファイル | resolv.conf | DNSリゾルバ設定ファイル | |
| hosts.deny | TCP_Wrappers用設定ファイル | rpc | RPCプロトコルリスト | |
| hosts.equiv | rsh系コマンド用設定ファイル | securetty | root用にアクセス制御を行えるTTY | |
| hosts.lpd | lpdアクセス制御リスト | services | ネットワークサービスのポート一覧 | |
| inetd.conf | inetd用設定ファイル | shells | 使えるシェルプログラムのリスト | |
| inittab | init用設定ファイル | syslog.conf | syslogdの設定ファイル | |
| issue | ログイン前の表示用ファイル |
/etc/X11に配置するべきファイルとしては、XconfigかXF86Config（いずれもXFree86の設定ファイル）、Xmodmap（X11用キーボード変換ファイル）が挙げられています。もちろんこれだけではなく、X Window Systemで動作するさまざまなプログラムの設定ファイルもここに置かれます。
/etc/sgmlには、*.confという汎用設定ファイルと*.catというDTD定義用のファイルを配置することになっています。
■Red Hat Linux 7.1における/etc
FHS 2.2で規定されているファイルやディレクトリは、必要最小限の要素にすぎません。実際、Red Hat Linux 7.1では/etcにさまざまなファイルやディレクトリが配置されています。代表的なところでは、
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 図2 Red Hat Linux 7.1の/etc（主要ディレクトリおよびファイルのみ）。FHS 2.2の規定が最小限のものであることが分かる | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
といったところでしょうか。ディストリビューションによって違うのはもちろん、Red Hat Linux 7.1であってもインストール時のオプションなどによって変わってきます。
FHS 2.2における/opt
|
|||||||||||||||||||||||||||||||||||||||||||||||||
| 図3 /optの構造。ただし、現時点では/optはあまり活用されていない | |||||||||||||||||||||||||||||||||||||||||||||||||
FHS 2.2では、/optの下にアプリケーションパッケージごとに専用のディレクトリ（以下<package x>で示す）を作ることになっています。なお、/optにはローカルシステムの管理者用に予約された6つのサブディレクトリがあります（図3参照）。
プログラムは/opt/<package x>/binに配置する必要があります。また、UNIXのマニュアルフォーマットにのっとったファイル（manページ）は、/opt/<package x>/man以下に配置します。このとき、サブディレクトリの構造は後述の/usr/share/man以下と同じようにします。
なお、パッケージが利用するのは/opt以下だけではありません。例えば、作業用のデータは/var/opt以下に、ホスト固有の設定ファイルは/etc/opt以下に配置します。
巨大な/usrのディレクトリ構造
/usrには、読み出し可能かつ共有可能なファイルを配置します。一般的にいって、ここには多数のファイルが配置され、ディレクトリ構造も複雑になっています。
FHS 2.2におけるサブディレクトリは以下のように定義されています。ここでも、ディレクトリによって「必須」と「オプション」に分かれます。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 図4 /usr以下のサブディレクトリ構造。binやsbin、libなど、他所にもあるディレクトリがあるため始めは混乱させられる | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
X Window Systemがインストールされる/usr/X11R6だけはちょっと特別扱いです。これは歴史的な経緯が絡んでいるためです。また、/usr/spool、/usr/tmp、/usr/spool/locksをそれぞれ/var/spool、/var/tmp、/var/lockに対するシンボリックリンクとして設置することもできます。これは古いシステムとの互換性を確保するためなので、できれば使わない方がいいでしょう。
■/usr/bin
|
|||||||||||||||||||||||||
| 図5 /usr/bin。ここはインストールするプログラムによって内容が異なる | |||||||||||||||||||||||||
/usr/binは、シングルユーザーモードには不要なバイナリファイルを配置するディレクトリで、パッケージの追加や削除によってディレクトリ内のファイルは増減します。この点だけからも、/binと/usr/binでは扱いが違うことが分かるでしょう。なお、複数のバイナリファイルで構成されているアプリケーションの場合は、さらにサブディレクトリを作成します。例を挙げると、mhやperl、python、tcl、wishなどです。
■/usr/local
|
|||||||||||||||||||||||||||||||||||||||||
| 図6 管理者が自由に使える/usr/local。上記のサブディレクトリは「必須」に指定されている | |||||||||||||||||||||||||||||||||||||||||
/usr/local以下は、システム管理者が自分でアプリケーションをインストールする場所として利用します。ここは、システム関連のソフトウェアをアップデートしても変更されないようになっています。サブディレクトリはbin、games、include、lib、man、sbin、share、srcが必須です。各サブディレクトリの用途は、/usrや/にある同名のディレクトリに準じます。
■/usr/sbin
/usr/sbinは、比較的重要でないシステムバイナリを配置します。「比較的」というのは/sbinと比べた場合です。/sbinには緊急時に必要なプログラム、/usr/sbinは通常運用時に使うプログラム、のように使い分けられています。
■/usr/share
/usr/shareには、アーキテクチャに依存しないデータを収めます。つまり、i386システム、Alphaシステム、PowerPCシステムのいずれでも、同じものがそのまま使えるということです。/usr/share/manと/usr/share/miscが必須、それ以外はオプションです。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 図7 /usr/shareで「必須」とされているのは2ディレクトリのみ。あとはオプション | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
/usr/share/man以下にはさらにサブディレクトリがあり、それぞれ
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 図8 man以下のサブディレクトリは、それぞれmanページのセクション番号に対応している | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
のような意味を持っています。
共有できない/var
/varはホスト固有の可変データ（variable data）用領域であり、ホストごとに用意する必要があります。当然、他ホストとの共有はできません。
/varもほかのディレクトリと同様、多くのサブディレクトリを持っています。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 図9 /varにも多くのサブディレクトリがある。あせらず、徐々に覚えていけばいいだろう | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
■/var/cache
/var/cacheは、一時的な記憶場所です。例えば、インストール直後のRed Hat Linux 7.1にはmanコマンドで表示する整形済みのテキストが入っていたりします。普通は容量に上限を設けて、古いものから順に捨てていきます。これによって、最近参照したデータを再び参照するとき、素早い応答が可能になります。
■/var/lock
/var/lockは、ファイルの読み書きなどで排他制御を行う場合に使います。Linuxはマルチユーザー／マルチタスクシステムですから、1つのファイルに対して同時に書き込み要求が発生する可能性があります。そのままではファイルに不整合が発生するので、書き込み中という目印のファイルを/var/lockに作成します。個々のプロセスは、このファイルを見て自分が書き込めるかどうか、あるいは読み出すデータが信頼できるものかどうかを判断します。本来ならOSに任せたい処理ですが、細かい作業を行うときにはどうしても必要になってきます。
■/var/log
各種プログラムの動作記録を収めているのが/var/logです。例えば、ブート時のメッセージを収めたboot.logを見ることで、起動時に特定のハードウェアを認識しているかどうかを確認したりします。
また、Linux動作中の各種メッセージはmessagesに記録されます。ここを見ることで、不正なアクセスがないかどうかをある程度は判断できます。実際には、毎日ここをチェックするのは大変なのでswatchやTripwireといったチェックプログラムを使った方がいいでしょう。
さらに、maillogとhttpd-access.logも重要です。それぞれ、sendmailなどのMTA（Mail Transfer Agent）、ApacheなどのWebサーバの動作記録です。記憶に新しいところでは、Code Redによるアクセスがhttpd-access.logに記録されます。自サイトに対する攻撃だけでなく、他サイトに対する攻撃の踏み台になっていないかどうか、このファイルで頻繁にチェックする必要があります。ただし、httpd-access.logに形跡がないからといって、100％安全というわけではありませんが……。
■/var/run
/var/runにあるのは、特定プロセスのプロセス番号を含んだファイルがほとんどです。あるプロセスにシグナルを送る場合、まずpsコマンドでプロセス番号を調べる必要があります。これは面倒ですし、タイプミスの恐れもあります。そこで、
$ kill -HUP `cat /var/run/sendmail.pid` |
などとタイプして使います。これならシェルによるファイル名補完などが使えるので、よりタイプが楽になるしミスも少なくなります。ただ、すべてのプログラムがここを利用しているわけではありません。
■/var/spool
spoolはSimultaneous Peripheral Operation On-Lineの省略形で、もともとはIBM用語です。本来は、動作の遅い周辺機器に対して効率よくデータを送るためのバッファです。転じて、FIFO（First In First Out）の、いわゆる「キュー」と呼ばれるバッファとして使われているようです。/var/spool/lpdは、プリンタに送るデータをためておくバッファなので、字義に近い使われ方です。ほかには/var/spool/mqueueや/var/spool/fax、/var/spool/atといったディレクトリもあります。それぞれ、うまく送れなかった電子メールやFAXのデータを保存しておいたり、atコマンドで指定されたコマンドを保存しておいたりする場所です。ここにあるデータは、各デーモンが適当な間隔でサーチすることで処理されます。従って、対応するデーモンが何かの拍子に止まってしまうと、いつまでたっても処理されないことになってしまいます。
また、sendmailを使ったメールサーバであれば、/var/spool/mailの下に各ユーザー名と同じファイルがあります。これが、いわゆるメールボックスです。ユーザーに送られたメールは、いったんここに保存されます。その後、mailコマンドで読み出したり、POP3でメーラーに読み込んだりするわけです。最近では、MTAとしてqmailを使うサーバもあるようですが、その場合は/var/spool/mailを使わず、直接各ユーザーのホームディレクトリにメールを配送するのが一般的です。
FHSは基本パターン
以上、2回にわたってLinuxのディレクトリ構造を解説してきました。FHS 2.2をベースとしているので、実際はディストリビューションによって微妙に違います。ですが、基本的な考え方は同じはずですから、FHSを押さえておけばだいたいの類推は可能でしょう。