Linuxのシステムディレクトリの配置をまとめた、FHSというルールがある - 後編 -

こんにちは。
開発チームのワイルド担当、まんだいです。

前回の続きになりますが、残るディレクトリは/usr と /var だけになります。
ただこの2つ、なかなか仕様が細かく、まとめるのに時間が掛かりました。

/usr

/usr は、読み込み専用の共有データの置き場所です。
/usr 以下のディレクトリ構成も明確に決められているので、こちらも見ていきたいと思います。

 

/usr/bin

このディレクトリは最も重要なディレクトリとFHSでは位置づけられていて、システム内の実行可能なコマンド群が格納されます。
重要な点として、このディレクトリにサブディレクトリを作ってはいけないというルールが設けられている点でしょうか。

細かいルールとしては、perl、python、tclsh、wish、expectの5つのサブシステムがインストールされている場合は、必ず /usr/bin に実行ファイル、もしくは実行ファイルへのシンボリックリンクを設置しなければいけないという決まりになっています。

余談ですが、perlが「Practical Extraction and Report Language」の頭文字を取ったものだということを先ほど知りました。

 

/usr/include

このディレクトリは、C言語用の汎用インクルードファイルが配置されるディレクトリです。
BSDコンパチブルなインクルードファイルは、bsdというサブディレクトリを配して設置するようです。

 

/usr/lib

ここは共有ライブラリやオブジェクトファイルを配置するためのディレクトリです。
まれにユーザーやスクリプトから直接実行される事を意図しない内部的なバイナリファイルが存在します。

先に出た /lib と何が違うのか、明確な線引はないようで、その実CentOS7では、/lib は /usr/lib へのシンボリックリンクです。

各アプリケーションは、直下に1つのサブディレクトリを持て、アーキテクチャ依存のデータはその中に押し込んでおく必要があります。
要は /usr/lib 直下をむやみに汚染するなということですね。

/usr/lib/sendmail は、MTAによってsendmailコンパチブルな実行ファイルへのシンボリックリンクを用意せねばならんという、過去の遺産に引きずられたルールもあります。
sendmailは偉大ですね。

 

/usr/libexec

先ほどの /usr/lib に置かれている内部的な実行可能なバイナリファイルというやつを配置するためのディレクトリになります。
どうでもいい私の肌感覚では、ライブラリなのか実行ファイルなのかはっきりしてくれという気がするのですが、そうも割り切れないやつらが世の中にいるようです。

この「内部的な実行可能なバイナリファイル」というのが、議論の的になることがしばしばあるようで、未だ結論は見えていないようです。

 

/usr/lib<qual>

こちらは、/lib<qual> と同様、OSのアーキテクチャ依存のライブラリを収めるディレクトリになります。

 

/usr/local

こちらはシステム管理者が個別にインストールしたソフトウェアのインストール先となります。
/usr/local 直下のディレクトリ構成は、/usr と似た構成を取ります。
自前でコンパイルしてインストールする場合は、こちらのディレクトリを指定するのが慣例ですね。

yumやapt-getなどのパッケージ管理システムは、/usr にシステムをインストールするため、うっかり /usr 直下にソースインストールすると、上書きされる恐れがあります。
バージョン違いのPHPやrubyを設置したい場合などがまさにそれで、設定ファイルに関しても、/etc 直下に置くと困るので、/etc/local にサブディレクトリを切って配置するのが好ましいとの事です。

 

/usr/sbin

こちらは、sbinなので、システムバイナリを置くディレクトリですが、/sbin と違い、必須コマンドではない、でもシステム管理に必要なコマンドを配置するところです。

例えば、iptablesやntpd、crond、LVMなどの便利なファイルシステム構築用コマンドです。
実行可能なバイナリ、もしくはバイナリファイルへのシンボリックリンクのみが配置可能で、サブディレクトリを置いてはいけない事になっています。

 

/usr/share

このディレクトリは、リードオンリーのアーキテクチャ依存のデータファイルが置かれるところです。
アーキテクチャ依存かどうか微妙な気がするのが、フォントファイルで、/usr/share/fonts 以下にフォントファイルを設置すれば、システムが認識するようになっています。
/usr/share/man 以下に、マニュアル関係のファイルも収められているところです。

 

/usr/src

こちらには、ソースインストールした際のソースコードなどを補完しておくところです。
基本的には後々参照する事が目的ですが、物によってはアンインストールする際にインストール時のconfigureファイルなどが必要になってくるので、インストールが終わったからと言って捨てるのは早計だということです。

 

/var

/var は可変データファイルの置き場所です。
可変データとは、ログやロックファイル、一時ファイルなどです。
Linuxを監視管理する上で、重要なデータが置かれています。

 

/var/account

saコマンドやlastcommコマンドで収集したログを保管するところです。
historyコマンドが実行したコマンドのログなのに対して、saコマンドは実行回数や実行時間など、システム資源を利用したデータに重きをおいた統計データ、lastcommコマンドはhistoryコマンドに近い、コマンド実行のログになります。

 

/var/cache

アプリケーションのキャッシュデータを保存するディレクトリです。

 

/var/crash

このディレクトリには、システムクラッシュダンプが保存されます。
システムクラッシュダンプって何だ？ と思ったんですが、5.6. /var/crash : System crash dumps (optional)を見てみると、「現行のシステムにはシステムクラッシュダンプはサポートされていませんが」という文が添えられておりました。

ちなみにシステムクラッシュダンプは、kdumpという名前でRHEL7ではデフォルトでインストールされているようです。
CentOS7にも、インストールされておりました。

kdumpが何をするかというと、システムがクラッシュした時にぶっ飛んでしまってどうしてもアクセスできなかったカーネルのメモリ領域をダンプします。
このメカニズムが中々ワイルドというか、強引というか、という内容で、kexecという別のコマンドから、カーネルをもう一つ立ち上げて（こちらを2番目のカーネルと呼んでいる。なので、ユーザーが使うOSは1番目のカーネルと呼称する）、1番目のカーネルのメモリ領域を取得、kdumpがそれをファイルに書き落とすという処理が、クラッシュ時に発生します。

kexecを稼働させるために必要なメモリ領域は、1番目のカーネルが使用するメモリの160MB + 2ビットにつき、4KBのRAMを専有するので、1TBのメモリでは、224MB必要になるという事になります。
結構な量を食いますね・・・。

また、別系統のカーネルが同時に稼働するので、少なからずCPUも利用するはずなので、ここも注意が必要です。

もう一つ、大きな問題として、果たしてメモリのダンプをみて、どこまでクラッシュした原因に近づけるか、という点があります。
私自身、恐らくこれをみて原因の特定はできないと思うので、kdumpを利用することはないのかも知れません・・・。

 

/var/games

こちらはゲームに関するデータの保存領域になります。
Linuxでゲームする事があまりないと思いますが、例えばUbuntuには、上海や数独がプリインストールされているので、遊んでみてはいかがでしょうか？

 

/var/lib

ここは、インストールされたシステムのデータを保存する領域です。
例えば、yumでインストールされたMySQLの場合、/var/lib/mysql 以下にスキーマデータが全て存在しています。

 

/var/lock

こちらはlockファイルの置き場所になります。
とはいえ、lockファイルの置き場所は、システムによってまちまちなのが現状で、MySQLは/var/lib/mysql にソケットのロックファイルが置かれています。
FHS3.0への移行期ということなのか、それとも変える気がないのか、その辺りは微妙なところなのかなとも思います。

 

/var/log

このディレクトリは管理者なら必ず見るべき場所ですね。
カーネルや、各種アプリケーションのログは大抵こちらに保存されています。

ログの種類によって、rootないしそれに準じた権限を持つユーザーにしか許可がないものもありますので、管理都合によっては、その辺りの調整も必要になってきます。

 

/var/mail

こちらは各ユーザーへ配送されたメールの保管場所になっています。
ただ、OSによっては、メールボックスが /var/spool/mail に設定されているものもあり、このディレクトリはシンボリックリンクになっている事もあります。

 

/var/opt

このディレクトリは、/opt にインストールされているソフトウェアの変数データの保存先とされています。
静的ファイルは、/etc 内に保存するように規定されていて、あっちこっちに設定ファイルが飛んでいるような印象も受けます。
実行ファイルは /opt 内と、/opt にインストールされたパッケージは割と厳し目に（笑）ファイルの保存先が規定されていて、肩身が狭い印象を受けます・・・。

 

/var/run

このディレクトリは、過去のFHSの仕様に沿って設計されたシステム向けに残された互換性のためにあるディレクトリです。
現在は、/run というディレクトリにその役目が移っていて、CentOS7で確認すると、/run へのシンボリックリンクになっています。

原文では、utmp へのアクセスにこだわった内容で、半分くらい utmp に関する記述になっています。

 

/var/spool

/var/spool は処理待ちのデータが置かれる一時データ的なものを置くディレクトリです。
/var/tmp よりもう少し明確に、後処理を待っているデータのようなものでしょうか。

/var/spool/mail には、ローカルユーザー宛のメールが置かれていますし、/var/spool/cron 以下には、各ユーザー名で登録されたものがテキストファイルになっています。

 

/var/tmp

/var/tmp は、再起動しても削除されない /tmp という位置づけです。
ですので、このディレクトリを使って作業する際は、必ずファイルを作成したアプリケーションで削除するべきです。

 

/var/yp

こちらは、NIS（Network Information Service）のデータを配置するディレクトリになります。

なぜypなのか、それはNISの前身システムのなまえがSun Yellow Pagesという名前だったから、という訳だそうで、今は亡きサン・マイクロシステムズの遺産です。
「Yellow Pages」が商標の問題で使用できなくなったため、NISに解明され、現在に至ります。

ややこしい事に、/var/nis というディレクトリも今回は出ていませんが存在して、こちらは NIS+ が利用するディレクトリのため、NISが利用する事はありません。

ちょっとつっこんで解説すると、NISとは、ユーザーアカウントやネットワークに関する設定情報を構成するネットワーク内で共有するためのソフトウェアです。
現在使われているもので、似たようなものとしては、DNSというのがありますが、こちらはネットワークに焦点を当てられているので、NISの方が、守備範囲は広いという言い方もできます。

めちゃくちゃ便利だと、これだけ見ると思ってしまいますが、開発されたのは1980年代で、悪さをしに来る輩がいるほど、公衆のネットワーク網が発達していなかったため、セキュリティという概念はありません。
また、NISが管理できるのは、単一のドメインに限定されていて、作りも簡単なものです。

そこで、NISの弱点を克服したのがNIS+で、複数のドメインが階層的に管理でき、暗号化を使ったセキュリティもしっかり考えられたまさに+要素盛りだくさんのシステムです。
ただ、こちらも暗号化に使われているのがDESだったりするので、セキュリティ的にはちょっと脇が甘い部分もあります。

調べても、Solarisのページしか出てこず、15年以上前の資料なので、21世紀の昨今、/var/yp が何なのか、知らずともLinuxは操れますよというところになりそうです。

長くなってしまいました。

以上です。