このセクションでは自宅サーバーとしてLinuxを扱ううえで役に立つ基本操作基礎知識テクニックについて初心者/ビギナー向けに解説します。
お便利サーバー.com+相互リンクサイト内をキーワードで検索
LinuxOSの使いこなし術

LinuxOSを使いこなす

クライアントOSとの違い

絶対パスと相対パス

"パスが通っている"とは?

"/"と"."と".."の意味

"."(ドット)ファイルについて

ワイルドカードと正規表現

コマンドの強制終了

コマンド操作の補完機能

コマンド操作の履歴機能

リダイレクトとパイプ

属性とパーミッション〜その1

属性とパーミッション〜その2

アカウント情報ファイルの操作

ランレベルについて

システムが起動しないときは

ハードディスクの増設

アプリケーションの導入法


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によるプログラムアップデートについて(WBEL3) yumによるプログラムアップデートについて(CentOS3) yumによるプログラムアップデートについて(WBEL4) yumによるプログラムアップデートについて(CentOS4) yumによるプログラムアップデートについて(CentOS5) 、が、yum自身はパッケージマネージャではありません。

つまり、WBELやCentOSの ディストリビューター が逐次更新してくれているパッケージリストと比較しているわけです。感謝ですね。

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

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

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

このページの先頭へ↑

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

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

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

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

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

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

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

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

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

つまり原則としては、

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

と考えてください。

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

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

例えば、
Welcome to the RPM repository on rpmfind.net
のように、開発者とは別の機関でRPMを管理し、配布をサポートしているところもあります。
こういうサイトを探すと比較的簡単に目的のパッケージを見つけることができます。

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

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

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

WBEL3,CentOS3 = RHEL3 > RHL9〜8 > RHL7 >> VineLinux2〜3 >> その他

WBEL4,CentOS4 = RHEL4 > FedoraCore1〜3 > 他FedoraCore >> その他

CentOS5 = RHEL5 > FedoraCore4〜6 > 他FedoraCore >> その他

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


このページの先頭へ↑

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

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

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

この、

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

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

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

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

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

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

特に、ファイルシステム上で整然と管理される必要のある サーバー アプリケーションの場合は、大部分のディストリビューションで共通で使用できるRPMを作成することは非常に困難なはずです。

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

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

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

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

"*.tar.gz","*.tar.Z","*.tar.bz2"

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

通常はこれを 構築中の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 Pop-before-Smtpについて のパッケージ

pop-before-smtp-1.33-1.noarch.rpm

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

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

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

ちなみにpop-before-smtpはPerlのスクリプトです。

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

このサイトは既に更新を終了していますが、今のところ店じまいの予定はありません。 リンクフリー ですので、趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。
Powered by Apache
”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。
www.centos.org - The Community ENTerprise Operating System