この特集のトップページへ
この回のトップページへ

どのディレクトリを編集してよいのか

 これまでに解説してきたディレクトリ構造を見ると,システム側で使われているディレクトリがかなり多いと感じるだろう。システム管理者や利用者が利用できる場所は,とても限られているのが分かるはずだ。

 FHSにおいて,システム管理者がプログラムをインストールするために利用できるディレクトリは,/usr/local以下だけである。

 それ以外のディレクトリ,例えば/bin/usr/bin/sbin/usr/sbinにアプリケーションをインストールするのは極力避けたほうがよい。

 なぜならば,それらのディレクトリには,OSで標準提供されているコマンドが含まれるため,これらと合わさってしまい後からインストールしたコマンドなのかが分からなくなる可能性があり,OSのアップグレードやパッチの適用によって書き換えられてしまうことも予想されるためだ。

 それに対し,/usr/localディレクトリは,OS(システム)から利用されることは一切ないため,システムアップグレードやパッチの適用によって書き変わってしまうことはない。

 ただし,規模の大きなアプリケーションであるならば,/usr/localディレクトリではなく,/optディレクトリにインストールすることも検討してもよいだろう。

 /optディレクトリは,アプリケーションパッケージごとにサブディレクトリを分けて格納することを想定して考えられたディレクトリだ。この/optディレクトリに格納したファイルも,OSのアップグレードやパッチの適用によって書き変わってしまうことはない。

 比較的規模が大きくなく,単純に/usr/local/binディレクトリや/usr/local/sbinディレクトリにコマンドをインストールするだけのものは該当しないが,設定ファイルを多数要求したり構成するコマンドが複数ある場合,これらを1つのディレクトリにまとめたほうが便利な場合がある。この際には,/optディレクトリ下に適当なディレクトリを作成し,そのディレクトリにアプリケーションをインストールするのが好ましい。

 そうとはいえ,Red Hat Linuxの場合には,アプリケーションをRPMパッケージでインストールすれば適切だと思われる場所にインストールされるので,このような考えが厳密に守られていくという保証はない。

 いちばんに考慮すべきなのは,.tar.gz形式などのソースファイルを展開し,自らmakeしてインストールする場合だけだ。

どのディレクトリをバックアップすべきか

 FHSでは,(1)システムが利用するディレクトリ,(2)静的で変化しないファイルを格納するディレクトリ,(3)動的に変化するディレクトリの3つが完全に分離されている。この点を考慮すると,どのディレクトリ階層に存在するファイルをバックアップしておけばよいのかも分かってくるだろう。

 まず比較的分かりやすいのが,/varディレクトリだ。この/varディレクトリ下には,動的に変化するファイルが多数含まれるため,1日1回か,数時間置きといったように比較的短いタイミングでバックアップする必要がある。場合によってはRAIDを構成し,ミラーリングを構成して耐久性を上げたり,ストライピングして高速化を図るという配慮もあるだろう。ただし,ログファイルをバックアップ対象にすると,思いのほかバックアップ時間が掛かってしまうため注意が必要だ。

 それに対して,/varディレクトリ以外のディレクトリに格納したファイルは,システムのインストール時にファイルが格納されるディレクトリであったり,システム管理者が必要に応じて書き換えるファイル,または利用者が書き換えるファイルを格納するディレクトリだ。

 例えば,/binディレクトリや/sbinディレクトリ,/bootディレクトリなどは,起動時に必須のコマンドやブートイメージが保存されていることから,万が一バックアップをしていなかったとしても,OSのシステムCD-ROMなどから書き出せば復旧させることが可能だ。

 同様に,/etcディレクトリの内容は,システム管理者がシステムの変更をする際に書き換えるだけなので,構築を完了したり、システムの構築内容を変更した際にバックアップを行っておけば十分だろう。もちろん定期的にバックアップをするようスケジューリングしておけば,手間を軽減させることもできるはずだ。

 /usrディレクトリも同様で,ほとんどのファイルはOSのインストール時に自動的にインストールされるため,比較的バックアップを行う必要性はない。

 ただし,RPMパッケージのインストールや/usr/localディレクトリにシステム管理者が新たにアプリケーションをインストールすることがあるため,/usrディレクトリのバックアップをまったく行わないというわけにはいかないだろう。新しいアプリケーションをインストールした時にでも差分バックアップを行ったり,適当な間隔でフルバックアップを行うことは必要だ。/optディレクトリも同様である。

 後はユーザーのホームディレクトリを適時バックアップしておけば,万が一のハードディスク障害時などにも安心だ。

LinuxではFHSが確実に浸透していく

 ここまで説明してきたように,FHSは論理立てられた根拠の上に整然とディレクトリ階層がどうあるべきかを提唱しているものだ。そのため,ディレクトリ階層が美しく,用途別にディレクトリがまとまっているため,管理しやすいという特徴がある。

 ただし,その整然さがゆえに実態とあまり合わない部分があることも否めない。たとえば,Apacheをソースコードからmakeしてインストールする場合,/usr/localディレクトリ以下に保存するのがよいのか,それとも,/optディレクトリ以下にapacheというディレクトリを作成してそこにインストールするのがよいのだろうか。

 どちらがよいのかは一概にいえないし,システム管理者の考え方にもよるだろう。Apacheを(RPMパッケージではなく)ソースファイルからmakeコマンドでインストールした際には,/usr/localディレクトリにapacheという名前のディレクトリが作られ,ここにインストールされるようになっている。

 しかしFHSでは,/usr/localディレクトリには,個々のアプリケーションのためのサブディレクトリ(この場合には、/usr/local/apacheディレクトリ)を作ることは推奨されていない。そのため,システム管理者は(1)FHSを無視して/usr/local/apacheにインストールする,(2)FHSに則して/opt/apacheなどのディレクトリに格納する、(3)FHSに則って、httpdなどのバイナリファイルは/usr/local/sbinディレクトリなどに,httpd.confなどの設定ファイルは/usr/local/etcディレクトリなどにといったように,適時保存する場所を分けるという3つの選択肢がある。

 しかし,ソースのインストール先を変更する場合には,Configure時にオプション指定をしたり,場合によってはMakefileを編集したりする必要がある。これはなかなか厄介な問題だろう。このような背景から,現実的にはFHSを無視して/usr/local/apacheディレクトリにインストールしてしまうことが多いだろう。

 筆者の個人的な見解だが,FHSはディストリビューションが標準で構成するディレクトリ構造を定義するものであり,システム管理者は別にFHSに完全に則った形で利用する必要はないと考える。どこに何をインストールするのかをきちんと把握しているのであれば,そうそうFHSにこだわる必要はないだろう。いずれほとんどの代表的なアプリケーションは,Configureコマンドを実行して自動的にMakefileを生成する際に,FHSに添った構造にインストールされるよう移行していくはずだ。現在のようなFHSへの移行期は,現実に添った形でアプリケーションをインストールしていけばよいのだ。ただし,いずれは移行していくのであれば,今から実行しておくというのもよいかもしれない。

 ところでFHSは,Linuxに限らずUnix系すべてのOSで利用されることを想定したディレクトリ階層である。

 しかし,ディレクトリ階層は個々のOSがもつポリシーが最も反映される部分であり,さらに歴史的な理由や風土やコミュニティの事情なども関係している。このような背景から,なかなか他のUnix系のOSがFHSに準拠する構成に移行するのは難しいことだろう。FHSの提唱は,利用者や開発者にとってよい流れだと考えられているが,個々のOS事情というものがあることから,実際に「どのUnix系OSでも,同じ構成のディレクトリでありほぼ同じようにシステムを利用できる」といった環境を実現するのは難しいと思われる。

 そうとはいえ,Linuxの世界に限ってみればFHSは標準的なディレクトリ構造になるのは間違いない。FHSは,オープンソースソフトウェアの標準化を推進する非営利団体であるFSG(Free Standards Group)が提唱する標準化仕様であるLSB(Linux Standard Base)で定義されている標準的なディレクトリ階層として採用されており,ほとんどのLinuxディストリビュータがFHSに準拠しようと努力している最中だ。

 いままでは,ひとくちにLinuxといってもディストリビューションの違いによって異なる部分が多々あった。これからは,FHSやLSBによって標準化され,ディストリビューションの差違は小さくなりディストリビューションの違いを意識せずに利用できるようになっていくだろう。

[大澤文孝,ITmedia]

PREV 4/4