ディストリビューション
ひとえにLinuxと言っても、狭義だとLinusさんが作ったOSのカーネルの部分を指すんですが、そんなことをここで書きたい訳じゃなくて、そのカーネルを利用して様々なディストリビュータ((ディストリビュータ:流通業者でいいのかな?))がOSパッケージとしての(広義の)Linuxを出してます。その数はかなりに上りますので、それぞれの特徴をよく理解して選ばないと痛い目にあいます。
-ディストリビューションとしては老舗のRedHat。
※今は企業向けの有償のRedHatと、バージョンアップが激しいフリーのFedoraCoreに分かれます。
- マニアックなDebian。
- ディスクトップに強そうTurbo。
- DBに強いMiracle。
- 1CD Linuxで最近有名なKNOPPIX。
- 日本語に強いと言われていたVine(最近はどうなんだろう?)。
多少文化の違いはあれど、なれればさほど違いは無いのですが、やはり自分の力が試されるLinuxなので、よく吟味して自分にあったパッケージを選んだ方がいいです。
rpmとソースのコンパイル
最近のLinux(RedHat系)サーバにソフトウエアをインストールするには、大きく2つの方法があります。一つはソースプログラム(要はコンパイルされていない生のプログラムコード)を入手してビルドする方法、もう一つはすぐに実行可能なバイナリ形式になってるプログラムを入手する方法で、RedHat系のバイナリは通常「rpm」というファイルに一まとめにされています。
私は通常ソースプログラムから設定しますが、ここでは両方の基本的な操作方法とメリットなどを解説します。
※最近はパッケージを自動だダウンロード/インストールするup2dateや、yumなどもありますが、中身はrpmをダウンロードしてきて展開しているだけのようなものです。
依存関係
通常、多くのソフトに「依存関係」があります。依存関係とは1つのアプリケーションを導入するのに複数のパッケージが必要となることです。これはrpmでもソースでも同様です。
例として、パケット監視ソフトである「iplog」を導入する場合は、パケットキャプチャリングライブラリである「libpcap」が必要です。「libpcap」は「yacc」や「flex」が必要だったりします。
よほど一般的なものは通常のディストリビューションならもともと入ってます。
依存関係を解消するには、その親子関係を確認し、その順番に従って、インストールする必要があります。
上記の例の「iplog」は「libpcap」が必要で、「libpcap」には「flex」が必要、「flex」を入れるには「yacc」が必要、、、と言った依存関係なので、依存関係を解消するには「yacc」→「flex」→「libpcap」→「iplog」の順に入れるのが正解になります。
※rpmの場合はいっぺんにしていするとうまくやってくれたりします。
まぁ、普通はインストール時に足りないものがあったらエラーになりますので、その時点で導入すれば問題無いでしょう。
rpmの概要と使い方
rpmは「RedHat Package Manager」の略でその名の通り、RedHat系Linuxで頻繁に使用されてるパッケージ管理ツールです。Windows系の人にわかり易く説明すると「アプリケーションの追加と削除」のようなものです。
Linuxでの運用を深く知りたいのであればソースからのインストールをおすすめします。
- ソースからの方が各ファイルの所在や設定などの位置がわかりやすい。
- その為、障害対応に強い。
- そもそも、UNIX系のOSはソースからコンパイルすることによりマルチプラットホームへ対応できる。
- rpm形式でリリースされてない物もある(特にOpenBlockSではかなり困る)。
と、こんな理由です。もちろんrpmにもメリットはあります。導入が楽だとか、企業系サーバだと管理工数の削減とかメーカサポートを受けやすくするとかがあります。
会社のサーバを建てるときは無理せず3年くらいのサポート付き有料パッケージを買って、マニュアルに従ってインストールした方がいいでしょう。
とりあえず、以下に簡単な操作方法を記しておきます。
原則としてインストール/アンインストールはroot権限で行うようです。
※以下の「パッケージ名」とはrpmファイル名です。通常は「xxx.rpm」という拡張子が付いてます。インテル系のcpuで動くバイナリの場合は「xxx.i386.rpm」と書かれてる場合もあります。当然ながらOpenBlockSのようなインテル系のCPUではない物にインストールしても(インストールは成功しますが)、動きません。
- インストール済みパッケージの確認
その1、全部表示(長いです)
rpm -qa
その2、特定のパッケージの確認
rpm -qa パッケージ名
※このパッケージ名はバージョン情報を省略可能。たとえば「rpm -qa libusb」で「libusb-0.1.5-3」と表示されます。「rpm -qa lib」だけではダメ。
その2、特定のパッケージの確認(あいまい検索)
rpm -qa | grep lib
- パッケージのインストール
rpm -i パッケージ名
rpm -ivh パッケージ名(←インストールの状況が詳しくわかるのでお勧め)
- パッケージのアップグレード
rpm -U パッケージ名
rpm -Uvh パッケージ名(←インストールの状況が詳しくわかるのでお勧め)
※パッケージには依存関係(つまり幾つかのパッケージをインストールしないとソフトが動作しないもの)を意識しなければならない場合があります。依存関係にあるパッケージが無いと通常はエラーでインストールできません。依存関係を無視する場合は以下のコマンドでインストール可能です(でも、動かない可能性が大)。
rpm -i –force –nodeps パッケージ名
- アンインストール
rpm -e パッケージ名
- パッケージの各ファイルが何処に入っているかを調べる。
rpm -ql パッケージ名
ソースの扱い方の基本
UNIX系OSではどのタイプのOSでも、どのディストリビューションでもソースコードを入手すればよほどの事が無いかぎり動かないことはありません。あまり意識する必要はありませんがソースコードは以下の流れで実行プログラムになります。
ソースコードA ソースコードB
| |
(コンパイル) (コンパイル)
↓ ↓
オブジェクト オブジェクト
(バイナリ) (バイナリ)
| |
|←−−−−−−−−−−−−
|
|←オブジェクトライブラリ
|
(リンク)
↓
実行可能プログラム
↓
(インストール)
1、「コンパイル」作業では所謂「機械語」に変換されます。しかし、基本的には実行可能ではありません。コンパイルされたオブジェクト(中間プログラムとか中間コードと言われるときもある)の中にはよく使われるもの(たとえばTCP/IPの通信モジュールとか)があるので、それは「オブジェクトライブラリ」として別にパッケージ化されている場合があります(「lib云々」というファイル名)。
2、作成されたオブジェクトは「リンク」されて一つ(もしくは複数)の実行可能プログラムになります。
3、実行可能プログラムは最終的に「インストール」によって特定のディレクトリに格納されたり、正しい設定ファイルが設定されたりします。
「コンパイル」から「リンク」までの一連の作業のことを「メイク(make)」とか「ビルド(build)」と言われます。
ソースコードの中身には通常OS依存コードや機種依存コードが含まれる場合があります。たとえば、Windowsの場合は「C:\」へアクセスし、UNIX系なら「/(root)」へアクセスすると言ったものです。通常はプログラムの中にそう言った依存コードをコンパイラに伝える記述があるので、特に意識する必要はありません。しかし、その依存関係がファイル単位で違ったり、必要なファイルやコンパイラの所在の確認の為、通常はコンパイルの前に「環境設定(cnfig/configure)」が必要になる場合が多いです。
ソースベースプログラムのインストールの基礎知識
ソースプログラムは通常tarボールで圧縮/単ファイル化されてます(拡張子が.tar.gz)。始めの作業はこれを入手し、展開することから始めます。
※(.tar.Zや、rpmの場合もありますが、ここではそれらを扱いません)
まず、入手元のURLを確認したら(Windowsで落としてFTPで送ってもいいですけど)、ダウンロードします。ダウンロードにはwgetが便利です。
wget http://xxxx/xxxx.tar.gz(対象がftp://でも大丈夫です)
パッケージを入手したら展開ですが、展開するには以下のようなコマンドを入力します。
tar zxvf xxxx.tar.gz
これでパッケージが展開され、新しいディレクトリが出来ます。
※ときどきディレクトリを作らず、実行したところにいきなり展開するパッケージもありますので、注意してください(bindとか)。
パッケージの後はその中にあるドキュメントを参照してインストールします。通常は「INSTALL」とか「Readme」の「Installation」や「How to Install」等に書かれています。
ここで注意するのは「どこ」に「なんの権限」で展開するかです。通常はインストール以外はroot以外の権限で作業を行います。パッケージの展開場所も、自前で用意したディレクトリの他に、「/usr/src」や「/usr/local/src」などが存在する場合もあります。
私は通常、コンパイルにroot権限が必要無いときは自前のディレクトリでコンパイルし、root権限が必要なものは「/usr/src」あたりでコンパイルします。
※「/usr/src」はroot以外書き込み不可能なので、他のユーザにソースを改竄されることがありません。
展開する場所はどこでもいいですが、ソースプログラムは「インストール以外はroot権限を使用しない」のが基本なので注意しましょう。
また、インストールが終わったら展開したソースとコンパイル済みオブジェクトをディレクトリごと削除した方がいいです。
一般的なソースのコンパイルとインストール
通常、導入方法はドキュメントを参照すべきですが、最近ではほとんどのパッケージが以下の手順で導入することが出来ます。
$ ./configure
$ make
$ su
# make install
まず始めは非root権限で作業を始めます
※非root権限の作業は行頭が「$」で表現されています。root権限の場合は「#」です。
1、環境設定
$ ./configure
※「./config」の場合も多いです。
基本的にコンパイルオプションは環境設定の時点で指定します。以下はその例
$ ./configure –prefix=/usr/local/bin –with=xxx –without=yyy
基本的にはドキュメントに詳しく書いてありますが、上記の例ではよく使われるオプションを示しています。「–prefix」はインストール先の指定、「–with」は追加する機能、「–without」は除去する機能です。
2、メイク
$ make
メイクは「./configure」によって設定された環境を元にコンパイル/リンクを行い、実行可能プログラムを生成する作業です。「./configure」は通常パッケージの中に存在しますが(頭に./が付いてるのがその証拠)、makeは事前に用意されたプログラムで、「./configure」によって作成されたテキストファイル「Makefile」を参照し作業します。その他、「Makefile」を参照することによって、いろいろなオプションや設定を確認することが可能です。
3、権限変更
$ su
インストールは通常root権限で行うことがほとんどなので、インストール前に管理者権限に以降します。
※コンパイル済みのプログラムを他のユーザから実行されることによりroot権限を奪われることを阻止する為です。
当然ながらここでrootのパスワードが必要になります。
4、インストール
# make install
この作業により必要な実行プログラムや設定ファイルが任意の位置にコピーされ、パーミッションやオーナーの設定までされます。この作業が終わったら特に理由が無ければ「exit」でユーザ権限に戻りましょう。ソフトによっては設定ファイルが作成されないで、展開したディレクトリからサンプルの設定ファイルをコピーしなければならないときもあります(net-snmpとか)。
(コラム)Makefileの中身を見よう
通常のソースパッケージは「./configure」によって「Makefile」が作成されます。これはテキストファイルなので中身が見れます。このMakefileを読めるようになると、いろいろなことが可能になります。以下に読み方の一例を示します。
prefix = /usr/local
sysconfdir = ${prefix}/etc
「prefix」は通常、インストール先を示してます。一般的には「./configure –prefix=/usr/local」のオプションで指定することが出来ます。
「sysconfdir」は通常、設定ファイルの位置を示す場合がほとんどですが、「${prefix}/etc」の「${prefix}」は一つ上の「prefix」の値を参照している為、「/usr/local/etc」を意味してます。設定ファイルは「/etc」にまとめたいと言う人は「sysconfdir = /etc」と書き換えることも出来ます。
これらの値を参照することによって、どのファイルが何処に導入されるのかがわかります。
- install:
上記のように「install:」とか「clean:」とか書かれている行があります。これらは「make install」や「make clean」などの「make」コマンドのオプションに連携しており、「make install」を実行すると「Makefile」の「install:」以降の処理が実行されます。
実際に何が行われるかは非常に複雑ですが、一般的に以下の意味があります。
- 一般的なもの
install:・・・パッケージのインストール
install-man:・・・マニュアル(man)のインストール
clean:・・・コンパイル済みのファイルや作業ファイルを削除し、「./configure」する前の状況に戻す。「./configure」をやり直したい時に念のため実行すると確実。
test:check:・・・インストール前の実行テストや設定ファイルの確認
all:コンパイルからインストールまで全て行ってしまう。
uninstall:・・・アンインストール。
- パッケージ固有(紹介してもしょうがないんですが、、、)
certificate:・・・apacheでSSLを有効にした場合の認証関連の設定を対話的に行うオプション。
love:・・・なんだか忘れましたが、こんなのもありました。
ソースのコンパイル方法 その2
ソースコードの中にはパッケージ化されてないものもあります。たとえばURLを見ると「xxx.txt」とか、C言語のソースコード(xxx.c)の場合です。通常はC言語(拡張子が「.c」)かC++(「.cpp」)なので、拡張子が違ったら直しておきます。わからない場合は中身を見ると2,3行目にファイル名が書かれています。これらのソースは以下の操作で実行ファイルを作ることが出来ます。
$ gcc -o xxx xxx.c
もしくは
$ cc -o xxx xxx.c
上記の「xxx」はコンパイル後の実行ファイル名、xxx.cはコンパイル前のダウンロードしたソースプログラム名です。gccやccは極一般的なコンパイラで、この操作ならリンクまで行ってくれますので、(そういう設計のソースなら)そのまま実行できます。
$ ./xxx
ちなみに一般的なディストリビューションの場合、インストール時のパッケージの選択で「開発環境」関連を選択しないと、gccなどのコンパイラや必要なオブジェクトパッケージがインストールされない場合があるので注意しましょう。
※でも、企業系のサーバなら公開サーバの中でコンパイルするのは危険なので、開発環境を入れるのはやめましょう。同じ環境のテストサーバを用意して、そっちでコンパイルすべきです。
「\」
「\(Windows系なら¥、Unix系ならバックスラッシュに見えると思います)」は、シェルやtelnetではコマンドの接続子として使用することが出来ます。
たとえば、
$ ./configure –with-mpm=worker –enable-deflate=shared –enable-ssl –enable-dav –enable-dav-fs –with-ssl=/usr/local/opensslenter
という長いコマンドは、
$ ./configure \<enter>
–with-mpm=worker \<enter>
–enable-deflate=shared \<enter>
–enable-ssl \<enter>
–enable-dav \<enter>
–enable-dav-fs \<enter>
–with-ssl=/usr/local/openssl<enter>
※<enter>はそこでエンターキーを押すという意味
という風な入力も可能です(意味はまったく一緒)。
このサイトでも見やすいようにところどころ「\」を使用してますので、見たまま入力する場合は注意してください。

Leave a Reply