第1部 構築編

本番運用に向けて

カーネルのアップグレード

サーバの構築とはやや横道にそれるが、Linux カーネルのアップグレードをしてみたい。

Linux という呼び名は、正確には OS の根幹を司るカーネルと呼ばれる部分のことだ。
Red Hat Linux などは Linux カーネルに様々なソフトウェアやインストーラをバンドルすることで、デストリビューションと呼ばれるパッケージを構成しているわけだ。
その根幹である Linux カーネルはオープンソースで開発されていて、Windows など及びもしないほど頻繁にバグフィックスや機能強化、セキュリティ修正などが為されている。

今回サーバ構築で利用している Linux は Red Hat Linux 7.3 だが、実は 7.3 購入時点で 8.0 が既に出ていた。
この時点で既に 7.3 に含まれる Linux カーネルは古いということだ。
ま、8.0 には Apache2.0 とか BIND9 とか、色々と妙に新しいモノが入りまくっていたので敢えて避けたのだが………

Red Hat Linux 7.3 には BIND8 が入っていたが、自前で BIND9 をインストールしてしまったので、こと BIND に関しては最新だ。

Linux カーネルが古いと言うことは、実はそれだけでセキュリティホールとなる場合がある
セキュリティが見付かってカーネルがアップグレードされている場合があるからだ。
だから、基本的には常に最新を導入しておくのにこしたことはない。
と言うわけで、カーネルをアップグレードしたい。

カーネルのアップグレードと言っても、Red Hat Linux を利用している限りはカーネルコンパイルとか色々とややこしいことは基本的には考えなくてもいい
Red Hat の FTP サイトに行って最新の RPM ファイルを取ってきて、インストールすればいいだけだ。

で、早速 Red Hat の FTP サイトに行ってみる。
Red Hat Linux 関連のアドレスは ftp://ftp.redhat.com/pub/redhat/linux/ だ。

Red Hat 自体は世界各地からアクセスされるため非常に重い。
ミラーサイトを使ってみるのも手だ。
しかし今回はとにかく最新であることを求めたので、タイムラグがあるミラーは避けた。

FTP に匿名でログインすると、各バージョンのディレクトリの他に、updates というディレクトリがある。
そこから順に、updates7.3enos と潜っていくと、CPU 毎にディレクトリが分かれている場所にたどり着く。
ウチのサーバは Xeon なので、i686 ディレクトリに更に潜る。
すると kernel-2.4.18-19.7.x.i686.rpm という RPM が見付かった。
更にウチのサーバは Dual 構成なので kernel-smp-2.4.18-19.7.x.i686.rpm も必要だ。
あと必要なのはカーネルソース
一度上のディレクトリに戻って、今度は SRPMS ディレクトリに潜る。
と、kernel-2.4.18-19.7.x.src.rpm が見付かった。
というわけで、これら 3 つの RPM ファイルを死に物狂いでダウンロード、合計 60MB 近くある。

さて、ダウンロードした RPM を早速サーバに FTP 転送して、インストールしてみよう。
と思うのだが、その前に緊急用のブートディスクを作っておきたい
直接 root でログインして、以下のように実行する。

# /sbin/mkbootdisk `uname -r`

これでブートディスクが作成された。
一度ブートディスクで正常に起動することを確認して、再び root でログインして以下のようにインストールする。

# rpm -ivh kernel-2.4.18-19.7.x.i686.rpm

この時、rpm コマンドのオプションはインストールを示す i だ。
U でアップグレードしてはいけない
カーネルのアップグレードで元のカーネルを残しておかなかった場合、場合によっては非道いことになる。
さて、これで通常のカーネルがインストールされるはずなのだが………

怒られた。

しかも英語コンソールで日本語を出されたモノだから読めない。
kon を起動して日本語コンソールに切り替えて、もう一度やってみると、依存関係が解決出来ないと来た。
kernel-2.4.18-19.7.x.i686.rpm は modutils-2.4.18 に依存しているというコトらしい。
RPM による管理では、互いの依存情報を構築することが出来るので、時々こういうコトがあるのだ。

仕方ないので気を取り直して、再び Red Hat の FTP に潜る。
潜ったのだが………ここで緊急事態発生

カーネルが更にアップグレードしてやがったっ!!

前回 FTP に入った時点では 2.4.18-19 が最新だったのだが、2.4.18-24 が出ていやがった
最新が更にあるのに手元のバージョンを引き上げないのも勿体ないので、もう一度、今度は kernel-2.4.18-24.7.x.i686.rpm、kernel-smp-2.4.18-24.7.x.i686.rpm、kernel-2.4.18-24.7.x.src.rpm の 3 つの RPM を落としてきた。
これがまた合計 60MB 程度、死に物狂いだ。
さらに、依存問題を解決するために modutils-2.4.18-3.7x.i386.rpm も取ってくる。
これは i686 ディレクトリではなく i386 ディレクトリにある。
ついでに使わないけどそのソースである modutils-2.4.18-3.7x.src.rpm も取ってくる。

実に見事なダウンロードっぷりだ。
普段はまるで使わないが、こう言う時だけは Iria などのダウンロード支援ソフトが役に立つ。

で、ダウンロードしたファイルをサーバに FTP 転送して、root で直接ログイン。
最初に以下のようにして modutils をアップグレードしてしまう。

# rpm -Uvh modutils-2.4.18-3.7x.i386.rpm

続いて、

# rpm -ivh kernel-2.4.18-24.7.x.i686.rpm
# rpm -ivh kernel-smp-2.4.18-24.7.x.i686.rpm

とインストール。
その足で /boot/grub/grub.conf を見てみると、追加した 2.4.18-24 カーネルが起動候補の中に入っていた。
んで、サーバを再起動。
追加された Red Hat Linux (2.4.18-24.7.xsmp) を選択して起動させる。
しばらく眺めていると無事に Linux が起動したようだ。

カーネルは OS の根幹だし、取り敢えずしばらくは様子見をしてみる。
ダメだったら 2.4.18-19 もインストールして更に様子を見てもいいし、仕方なく 2.4.18-3 に戻してもいいだろう。
一通り必要な機能を動かした感じでは正常に動いていそうだが………

ちなみに、セキュリティ対策のひとつとして、稼働している OS その物を隠すという手段がある。
サーバがどの OS で稼働しているかを公開してしまうだけで、実はセキュリティホールとなる場合があるのだ。
今回は説明の都合上カーネルのバージョンまで公開してしまっているが、これは本来は以ての外なのである。
例えば今回インストールしたカーネルにセキュリティホールが存在した場合、自ら「ウチのサーバにはセキュリティホールがあります」と公言していることになる。
これがどんなに危険なことかは理解出来ることと思う。

これとほぼ同義で、Microsoft Windows の Internet Information Server の上で動くスクリプトエンジンである Active Server Pages も巨大なセキュリティホールだ。
ASP の拡張子はモロに .asp であるが、現在 ASP が稼働するのは Windows サーバだけ、つまり拡張子 .asp が稼働していること = Windows サーバということになり、Windows サーバに多種多様なセキュリティホールが存在することは周知の事実であるのだ。
さらに Windows サーバの場合、Linux と違ってカーネル部分が無意味に巨大でありカーネルのアップグレードが OS 全体のアップグレードと同義のことが多いこと、OS 全体のアップグレードにかなりの規模の予算が必要であること、OS 全体のアップグレードによって正常動作しなくなってしまうアプリケーションが多々あることなど、経済的・時間的なリスクの為に放置されていることが多い。

Valid HTML 4.01 Strict Valid CSS!