LinuxOSのアプリケーションについて

LinuxOS 初心者にとっての大きな鬼門は アプリケーション の インストール の手順が、これまで慣れ親しんできた WindowsOS や MacOS のそれと大きく異なる点かもしれません。

WindowsOSやMacintoshOSは OS の種類やバージョンが限られていますから、利用できるアプリケーションの選択に悩むことはほとんどないでしょう。

またインストールの方法も、通常はインストールプログラムを起動して後は質問に答えてゆくだけ、という方法が一般的ですからインストール作業を難しいと思うことはあまりないはずです。

一方LinuxOSなどの UNIX 系のOSでは、 ディストリビューション の種類が多いため、まずはそのアプリケーションパッケージが使用中のOSで使えるものなのかどうかを調べるのが一苦労です。

またインストールの方法にしても、 RPM のように全自動で行われるものや、 ソース プログラムを入手して コンパイル しなければならないものなど様々です。

これはそもそもUNIX系OS上で使われるアプリケーションの多くが、OSの基本理念である 「オープンソース」 の考え方を踏襲していて、

「ソースの内容はすべて公開しますから、あとは利用する方々の判断で使ってください。そして改良のために出来ればその結果を教えてください。」

というスタンスで供給されているからです。

これが、

「アプリケーションの利用者は通常初心者であるから、できるだけ迷わずに利用できる形で供給しなければならない。」

という クライアント 向けOS用のアプリケーションの供給習慣と異なる点です。

特に サーバー アプリケーションの場合には更に、 「利用者はサーバー構築の基本を理解しているはずなのでくどくど説明などしなくても大丈夫」 という前提で供給されるものが多いため、初心者にとっては更にハードルは高いものとなっているはずです。

このパートでは WBEL や CentOS でサーバーを構築する初心者のために、アプリケーションの選定方法や一般的なインストールの考え方について解説します。

OS標準のパッケージの利用が最優先

WBEL や CentOS に限らず多くの Linux ディストリビューション には、利用頻度の高いと思われる アプリケーション が最初からたくさん添付されているのが普通です。

例えば クライアント 向けに特化した LindowsOS にはクライアント向けのアプリケーションが非常に多く添付されていますが、WBELやCentOSはもともと 企業の サーバー 用途向けに開発された RHEL の クローン ですからサーバーアプリケーション中心のディストリビューション構成になっています。

このように最初からディストリビューションに付属しているアプリケーションは、通常そのディストリビューション上で利用しやすいように最適化されていますから、もしも必要なアプリケーションが添付している場合には可能な限りそれを利用するようにします。

ディストリビューションの多くは形式こそ様々ですが通常 パッケージマネージャ と呼ばれるプログラムによってアプリケーションのインストール状況を管理していますから、インストールや アンインストール はそのプログラムの管理に委ねる形で行うのが定石です。

WBELやCentOSを含む多くのRedHat系ディストリビューションでは、パッケージマネージャとして RPM が使用されていますから、WBELやCentOSではまず第一にRPMを利用したインストールを考えるのが正しい選択です。

この コンテンツ ではWBELやCentOSのアプリケーションのインストールやアップデートは yum で行うようにセットアップしています 、が、yum自身はパッケージマネージャではありません。

yumは "yum.conf" の設定 に従って、理化学研究所のFTPサーバー 上にある最新のアプリケーションと 構築中のLinuxサーバー 上のアプリケーションを比較して、 "*.rpm" のダウンロードを支援するツールです。

つまりyumを利用する場合、実際にアプリケーションパッケージのアップデートやインストールを担っているのはもちろん RPM ですから、間接的にはRPMを利用していることになるわけです。

従ってアプリケーションの操作には可能な限りyumを利用するように心がけましょう。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

標準以外のRPMを利用する場合のポイント

構築中のLinuxサーバー で利用する アプリケーション を、 WBEL や CentOS 用に準備された「最適化パッケージ」で100%賄うことができればそれがベストです。

ただ「最適化パッケージ」の中で見つからないアプリケーションを利用したい場合には、別の場所からアプリケーションパッケージを探し出して インストール する必要があります。

そしてその場合には、可能な限り WBELやCentOSで問題なく利用出来る可能性の高い"*.rpm"を使用 して、管理を RPM に委ねるようにします。

たとえインストールするパッケージがWBELやCentOS標準のものでなくとも、とりあえずRPMに管理を任せてしまえば、そのアプリケーションのインストールに必要な他のパッケージの情報なども教えてくれますし、 アンインストール するときも簡単に作業することができるようになるからです。

例えばこの コンテンツ では、 drac 及びdracとの連携がセットされた UW IMAP など に、そういった「標準以外の "*.rpm" 」をインストールしています。

ただ注意しなければならないのは、 「"*.rpm"ならば何でもOK！」 ではないということです。

RPMはRedHat社が開発した「アプリケーション管理を便利にするパッケージマネージャ」で、その便利さから非常に多くの ディストリビューション で採用されているわけですが、共通しているのはあくまで「管理」の機能だけです。

"*.rpm" をインストールしたとき、「実行ファイルなどがどこにインストールされるか」などは、その "*.rpm" がどのディストリビューションでの利用を前提に作成されているのかで決定します。

つまり原則としては、

「"*.rpm"というパッケージでも、他のディストリビューション用のものは利用できない」

と考えてください。

とはいえ、WBELやCentOSのようなメジャーではないディストリビューションの場合には、標準以外で専用の "*.rpm" が見つかることはまずありません。

ただ思い出して欲しいのは、WBELやCentOSは商用版として最もメジャーな RHEL の クローン ということです。

WBELやCentOS用のパッケージはなかなか見つからなくても、RHEL用のパッケージならば比較的多く配布されていて、それらは100%利用可能と考えて間違いありません。

また、RHELのベースのディストリビューションである RHL9 や FedoraCore 用のパッケージもかなりの確率で利用できます。

一般的にいうと、ディストリビューションの成り立ちが近いもののパッケージは互換性が高いので、例えば、

のような序列で "*.rpm" の利用が可能な確率が高くなると考えてよいでしょう。

関連ページ・ ディストリビューション関連

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

最終手段は「ソースをコンパイル」

UNIX 系 OS へのアプリケーションの配布形態は、元々大部分が ソース プログラムでした。

ユーザーは入手したソースプログラムの内容を利用する OS に合わせて修正を加え、それを コンパイル して使う、という手順で使用するのが一般的だったわけです。

この、

「お使いの環境のために必要な修正は自分でやってくださいね。」

という一見投げやりに思える配布形態は、実は種類の多いUNIX系OSのユーザーに対する配慮から生まれた「親切な」習慣です。

しかし、このソースプログラムの修正やコンパイル作業といった作業が、そういう習慣も知識もない通常の クライアント OSのユーザーにとって「容易なことではない」のは事実で、そのことがUNIX系OSの普及を妨げていた要因の一つといえるかもしれません。

ともあれ、UNIXから派生した LinuxOS も、 RPM のようなパッケージ管理マネージャが登場するまでは、この「ソースをコンパイル」というインストール手段が一般的だったわけです。

ただRPMが普及した現在でも、依然として多くのアプリケーションは「ソースでの配布」が一般的であることに変わりはありません。

なぜならRPMは「RPMを採用する ディストリビューション が普遍的に利用できる供給方式」ではなく、あくまで「ひとつの管理方法」に過ぎないからです。

つまりアプリケーションの開発者が RHEL 用にソースをコンパイルし、RPMパッケージを作成したとしても、それが FedoraCore や TorboLinux で問題なく利用できるという保証もなく、かといって普及しているすべてのディストリビューション用にパッケージを作成するのは開発者にとって容易なことではないため、

「お使いの環境のために必要な修正は自分でやってくださいね。」

という習慣が相変わらず続いているというわけです。

さて、ソースプログラムは一般的に

などの一般的な アーカイブ 形式で配布されます。

通常はこれを 構築中のLinuxサーバー 上に ダウンロード し、必要な初期設定を行った後に コンパイル します。

と、一般的に説明してしまうととても簡単なことのように思えるかもしれませんが、ソースの内容や設定の方法などはもちろん初心者が容易に理解できるものではありませんから、開発元や同じプログラムの利用者の情報を参考にする必要があります。

もちろんこの方法を使えば、自分の環境に合わせて最適なアプリケーションを構築できるわけですから、熟練者はあえて「カスタムメードのRPM」は使わず、ソースからコンパイルする手段を選択する場合が多いようです。

とはいえ、これはLinuxビギナーにとっては容易な作業ではありませんから、意味が良くわからないうちは可能な限りRPMを利用し、どうしても必要な場合にだけ「腰を据えて」ソースを利用するようにしましょう。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

パッケージのアーキテクチャについて

LinuxOS にはその原型ともいえる UNIX と同じく、様々な アーキテクチャ の ホスト機 に対応する ディストリビューション があります。

例えば WindowsOS を動作させるパソコンと MacintoshOS を動作させるパソコンとでは ハードウェア の構成もアーキテクチャも全く異なるわけですが、それぞれに最適化されたディストリビューションを インストール すればどちらでも同じようにLinuxOSを利用できるというわけです。

ところでLinuxOS上で用いる アプリケーション についても同じ考え方があります。

つまり同じ WBEL や CentOS (またはWBEL4及びCentOS4)用のアプリケーションでも、 i386 用と x86_64 用でパッケージが異なるのが普通です。

例えば Webalizer のパッケージの場合、

i386用：webalizer-2.01_10-15.ent.i386.rpm

x86_64用：webalizer-2.01_10-15.ent.x86_64.rpm

という具合です。

おわかりと思いますが、 i386 版をインストールしたWBEL4やCentOS4上にはi386用のWebalizerのパッケージをインストールしなければなりませんし、 x86_64 版をインストールしたWBEL4やCentOS4上にはx86_64用のWebalizerのパッケージをインストールしなければなりません。

なぜこんな面倒なことになっているのでしょうか。

先に説明したとおり、元々 UNIX 系OSでのアプリケーションのインストール方法は、その ソース プログラムを入手してホスト機上で コンパイル する、というものでした。

ホスト機上にインストールされるコンパイラは、そのホスト機のアーキテクチャで最適に動作するように バイナリ プログラムを作成するようになっています。

つまり元々が同じソースプログラムであってもホスト機のアーキテクチャが異なれば違うプログラムが出来上がって最適動作をする、という仕組みになっているわけです。

一方の「簡単インストール」が売りの RPM などのパッケージソフトは、通常コンパイル済みのバイナリファイルと各種 スクリプト の アーカイブ になっていて、パッケージマネージャーで展開するだけで所定の位置に各ファイルが配置され、初期設定が行われるように工夫されたものです。

こういう コンパイル済み 形式のパッケージは利用可能なホスト機のアーキテクチャを選んでしまうため、個々に準備しておかなければならないとういうわけです。

OSのインストール CD や、 yum を利用したアプリケーションの追加インストールの場合、通常は適切なアーキテクチャのパッケージが自動的に選択されますのであまり気にする必要はありませんが、 Rpmfind.net のような一般サイトからアプリケーションを ダウンロード してインストールする場合には、お使いのアーキテクチャに合ったパッケージを選ぶようにしてください。

ところで、上のパッケージ例で示したように、 rpm パッケージの場合は ".rpm" の手前に必ずアーキテクチャ表記があります。

WBELやCentOSではほとんどのパッケージが "i386" か "x86_64" のどちらかになりますが、例えば カーネル 関係のパッケージのようにハードウェアに深く依存するパッケージの場合、同じ インテルアーキテクチャ のホスト機であってもその微妙な違いによって "i486" 、 "i586" 、 "i686" と細分化されていますし、AMD社製の場合は "athlon" が使われることもあります。

通常これらはWBELやCentOSのインストール時に適切なものが選択されますからあまり気にする必要はありません。

また、これとは別に例えば Pop-before-smtp のパッケージ

ようにアーキテクチャの表記の部分が "noarch" となっているものもあります。

これは "No Architecture" 、つまりアーキテクチャの種類に関係なく利用できるパッケージであることを意味しています。

これはアプリケーションの実体が直接動作するバイナリプログラムではなく、システム上の インタープリタ を利用して実行される Perl や PHP などの スクリプト である場合に多く見られます。

このようにシステム上の別のプログラムだけを利用して動作するタイプのアプリケーションの場合、利用されるプログラムがアーキテクチャの違いを認識して稼動するため、それを利用するアプリケーションはアーキテクチャに依存しない、というわけです。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト