エンタープライズ:特集 2003/09/05 21:00:00 更新


特集:第1回 RPM活用でLinuxサーバ運用の手間を軽減 (3/5)

RPMのメリットは運用の手間軽減につながる

 Red Hat LinuxやTurbolinuxなど、多くのLinuxディストリビューションでは、システムインストールを行った段階で必須なものほぼすべてがRPMパッケージでインストールされる(ただしインストールオプションに依存する)。市販されているディストリビューションであれば、ATOK Xなどの日本語入力環境、TrueTypeフォントも付属するだろう。Windowsのようにインストール後にはすぐに使えることを目指しており、最新のディストリビューションバージョンであれば不満も少ないはずだ。

 しかし、Linuxで用いられる(オープンソース)プログラムやライブラリは日々更新される。それこそ昨日インストールしたら、パッケージ単体ごとに見れば次の日に次期バージョンがリリースされていた、ということも多々ある。

 アップデート管理の難しさは、ここにポイントがある。本来オープンソースとして配布される機構は別にあり、そのカスタマイズを行って配布・販売するのがディストリビュータ(Red Hatなど)だ。このため、オープンソース直のユーザー会などから配布される方が早く、その数時間後から数日後に、Red Hatの場合であれば、重大なバグ、深刻な欠陥なども同様に「Errata(エラッタ)」と呼ばれる情報として配信される。それでも、ディストリビュータのパッケージ提供を待つよりは、開発元を直接辿った方が速く修正プログラムを入手できることが多いのも事実だ。この時間差と運用の手間は天秤にかけられる。

 各ディストリビュータは、数千種のプログラムからユーザーに適したプログラムを選択してパッケージに収めている。採用されなかったプログラムの中にも「自分の好み」に会うプログラムがあるかもしれない。そのようなプログラムを見つけた時にも、RPMのパッケージで自らインストールしたくなるだろう。

 逆に、インストール時には内容や機能がよく分からず、とりあえずインストールしてみた。ところが後々調べたら重複する機能のプログラムを複数インストールしていたかもしれない。ディスク領域を空けるために、そうした不要なプログラムを削除したい場合もあるだろう。

 このような場面では、RPMが非常に便利だ。rpmコマンドを使い、ほんの数ステップの作業でインストールやアンインストールを行えるからだ。

運用面を重視するとカスタマイズ不可というデメリットが表面化する

 インストール、アンインストールが容易なRPMにもデメリットな面が幾つかある。ひとつは、依存関係で芋づる式に更新作業が増えてしまうことだ。ソースからコンパイルする方法と異なり、RPMパッケージ内(ヘッダ)には主として以下のような情報が含まれている。

  • 配置するファイルのディレクトリ情報
  • 利用するライブラリ情報
  • 依存する(依存される)他のパッケージ

 これらはインストールしたパッケージのデータベース情報として追記されていく。ディレクトリ情報はシステムに存在しなければ自動的に作成するのが通例であり、同時にインストール、アンインストールした後の設定処理、クリーンアップする作業情報も含まれる。従ってファイルを置いたディレクトリを云々はさほど問題にならない。やっかいなのは後者だ。

 RPMパッケージをインストールする際、必要なライブラリはシステムに含まれない。あるいはバージョンが異なる場合には、RPMはエラーメッセージを出力する(これを「依存関係」と呼ぶ)。この際、何が必要なのかも通知されるため、該当する依存パッケージをインストールする必要があるのだ。しかし、これには自動化機構が無いため慣れを必要とする。

 例えば必要なパッケージがひとつ、あるいは少数で済めば話は簡単だ。ところが、依存関係にあるパッケージが別のパッケージに依存し、そのパッケージが更に別の依存関係を求めるといった芋ヅル式の依存関係に及ぶことがある。KDEやGNOMEのような比較的大規模なウインドウマネージャ(デスクトップ)環境や、システムの基幹ライブラリを更新する際には、相当数のパッケージを用意、更新しなければならない。

 アンインストールを行う際にも同じことが起きる。不要なパッケージが別のパッケージの依存関係にある場合、RPMはそれをエラーとして出力する。この場合、依存関係にあるパッケージは先にアンインストールしておかなければならないといった困った状態になる。目的のパッケージアンインストールのために、本来必要なパッケージをいったんアンインストールし、後からインストールを行うこともある。

 パッケージ内には必要なプログラムやライブラリの情報が含まれ、OS内部で管理されている。その仕組みがシステム管理者の負担を軽減したことは間違いない。だから必ずしも「デメリット」とは言い切れないが、大量の依存関係が出現すると少々苦労させられることも事実である。

 もうひとつは、プログラムを自由にカスタマイズするオプションが使えないということだ。例えば代表的なhttpdであるApacheは、コンパイルする際のオプションでいろいろな機能の追加や削除ができる。EXPATを無効にしたり、suexecの機能を有効にしたいという場合、tar.gzからのコンパイルであれば「sh./configure」の実行時に「--enable_suexec」や「--disable-rule=EXPAT」のオプションを付加すればよい。Apacheに限っていえば、多くの機能はモジュール化されていているため、RPMのバイナリファイルであってもある程度は融通が利く。

 しかし、こうしたコンパイル時の機能オプションは非常に多い。Samba、Postfix、courier-imapなどは、機能や仕様を大きく変更できるオプションが幾つもある。このようなサーバ系プログラムに限らず、デスクトップアクセサリのような小さなプログラムであってもだ。

 通常RPMは標準的なオプションを付けてコンパイルする。前述したApacheのように、機能はモジュール化することで自在に追加、削除できる形式に業界の動きもある。しかし、大規模な基幹系サービスなどは、極力パフォーマンスを重視する傾向にあり、それこそが安定度にもつながっていく。不要な機能が含まれていてプログラムサイズが大きくなっていたり、特殊だが必要に思う機能が動作しない、ということもある。これはRPMがバイナリファイルである以上、どうしようもない。そうしたオプションを使いたければ、自分でコンパイルしなおすしか方法がないのだ。

 src.rpmはこのような場面で解決策となる。src.rpmの使い方、コンパイルの方法については、第2回目で解説しよう。

ディストリビューション外のRPMパッケージ入手方法

 アップデートされたRPMパッケージの入手方法はさまざまだ。Red Hat Linuxであれば、ftpサイトや専用のツール「up2date」コマンドで公式配布される新しいバージョンが入手できる。ただし、up2dateはRed Hat Linuxに含まれるRPMパッケージの更新が目的だ。元のシステムに含まれないプログラム(RPM)は提供されない。このような傾向は、up2dateに限らず、各ディストリビュータも何らかの方法でRPMを使ったシステム更新が可能だが、オリジナルシステムに含まれていないパッケージが追加されることは通常無い。

 そこで自分でプログラムを見つけたいならば、パッケージを集積したほかのサイトから入手する。主要なサイトは、以下のようなところだろう。これらは開発元のサイトから直接リンクが張られていることもある。ただし、前述のようにディストリビューション独自のアップデートには含まれないため、自らバージョンを追う必要がある。

 比較的規模が大きく、多様なディストリビュータのファイルを検索できる。ライブラリや依存するパッケージ、収録されるファイルからのリンクも容易であり、いちばんアクセスする頻度が高くなるだろう。反面、同じファイルが複数あったり、どれを選べばよいのか迷うかもしれない。

 rpmfind.netと同程度の規模を持つ。パッケージはrpmに限定されない。各パッケージの内容や開発元のWebページへのリンクも充実している。

 主として最新のプログラム(アプリケーション)が蓄積される。依存関係から求められるライブラリ類はあまり多くない。

 比較的規模が小さい。Red Hat Linux 7.2以降とPowerPC、Mandrake Linuxの主要なもののみを揃える。絶対量が少ないため、src.rpmを入手する際に探しやすい。

 探し方のおすすめとしては、プログラム(アプリケーション)自体はfreshrpms.netを散策し、依存関係で必要なパッケージがある場合にはrpmfind.netやfreshmeat.netを見てみる、というのが分かりやすい順序だ。

rpmの基本的な操作方法〜インストール・アップデート

 rpmコマンドには多くのオプションがあるが、インストール時に用いる主要なものは次の通りだ。

オプション(パラメータ)
内     容
-i 新規のパッケージをインストールする
-U 既にインストールされているパッケージをアップデートする
-F -Uと同じだが、古いバージョンがインストールされている場合のみ機能する
-v より多くの処理過程情報を表示する
-h インストール時に「#」を表示し、インストール状況を表示する
--force パッケージのバージョンの新旧、競合を無視して強制的にインストールする
--nodeps パッケージの依存関係をチェックしない
--test 実際にはインストールせず、依存関係や競合をチェックする

 「-i」と「-U」は、どちらかがパッケージインストール時に必須だ。新しいファイルをインストール場合には「-i」、旧バージョンからのアップデートであれば「-U」、または「-F」を付加する。「-U」は「Update」だが、古いバージョンがインストールされていなければ「-i」と同じ新規インストールとなる。「-F」は「Fresh」の意味であり、古いバージョンがインストールされていなければエラーを返す。「-v」と「-h」はその直後に続けても構わない。

# rpm -ivh [パッケージ名]

 例えばgkrellm(システム監視用のユーティリティ)のパッケージをインストールする指定は、以下のようになる。

# rpm -ivh gkrellm-2.1.14-fr1.i386.rpm
警告: gkrellm-2.1.14-fr1.i386.rpm: V3 DSA signature: NOKEY, key ID e42d547b
Preparing... ########################################### [100%]
1:gkrellm ########################################### [100%]

 Red Hat Linux 8.0以降からは、パッケージのインストール時にGPG Keyをチェックするようになった。このパッケージは「fr1」とあるようにfreshrpms.netから入手したもののため、このKeyが含まれていないという警告だ。ただし、Freshrpms.netなど信頼できるサイトからダウンロードしたものであれば、基本的にこの表示は気にしなくてもよい(昨今の騒ぎから、ダウンロード後にチェックサム確認するといった防御策が必要かもしれない)。RPM-GPG-KEYも配布されていれば「rpm --import RPM-GPG-KEY.txt」と付加することで警告が表示されなくなる。

前のページ | 1 2 3 4 5 | 次のページ

[渡辺裕一,ITmedia]