アップグレードインストールは現実的か？ 〜7.3 to 8.0編〜 (1/5)

　次々とディストリビューションバージョンがアップデートするLinux。細部を見れば、個々のパッケージやカーネルが替わっている程度だが、これを機にまとまったアップデートをしたいと考える人も多いだろう。しかしサーバ用途で利用している場合、手軽にバージョンアップを行うなど非現実的だ。ほとんどの場合は、ディスク障害などを機にクリーンインストールし、再設定をするのではないだろうか。

インストールオプションの選択肢には、アップデートインストール「既存のシステムのアップグレード」が用意されている

　ここでは、Red Hat Linuxに用意されているアップデートインストールオプションが現実的であるかを判断するため、Red Hat Linux 7.3のほぼインストール直後の状態からRed Hat Linux 8.0へアップグレードしてみた。そうとはいえ、何も使用されてない環境では判断があいまいになるため、ApacheとBINDだけは設定ファイルを編集し、さらに、「chkconfig --level 345 httpd on」、「chkconfig --level 345 named on」としてデーモンの自動起動設定をしている（参考Tips「コンソール上でhttpdなどのデーモンをコントロールしたい」）。

　ほかの詳細な結果は、2〜5ページに掲載したRPMパッケージの状態によって判断してほしい。

　なお、元となるRed Hat Linux 7.3は、インストールタイプで「カスタム」を選択、「すべてインストール」にてインストールしたものだ。Red Hat Linux 8上では、「インストールのタイプ」画面で見られる「既存システムのアップグレード」オプションを選択し、次の画面で現れる「アップグレードするパッケージをカスタマイズ」チェックを外した状態である。

　これによる実行結果では、アップデートパッケージが1258個、3.675GBのインストールになった。

　アップデート後は、/root/ディレクトリにログファイルが保存される。残念ながら途中で文字化けが見られ、すべてを把握することが困難だ。興味のある人は、リンク先のログを参考にしてほしい。

　Red Hat Linux 8で大きく変わったものの1つとして、Apacheは1.3から2.0に変更された点が挙げられる。1.3の設定ファイルをそのまま流用できないため、RPMパッケージとはいえ、アップデートが困難な処理の1つだ。

　設定ファイルは、RPMパッケージのアップデートとしてスタンダードな新しいパッケージの設定ファイルを拡張子「.rpmnew」で保存される。

　このままの状態（1.3のhttpd.conf）でhttpdを起動させようとすると、次のようなエラーとなる。

　このため、「httpd.conf.rpmnew」ファイルを新たに設定編集してから、「httpd.conf」とリネームして利用する必要がある。

　BINDは7.3で「bind-9.2.0-8」、8で「bind-9.2.1-9」とマイナーバージョンアップに止められている。このため、ディレクトリ構成はもちろん設定ファイルも流用でき、アップデート後も問題なく動作する。

　自動起動設定もそのまま継承される。

　カーネルに関しても、rpmコマンドの「-i」（インストール）ではなく、「-U」（アップデート）で処理されていることが分かる。「アップデート」を行ったため当然かもしれないが、古いカーネルも残しておいてくれてもよかったのに、と感じる点だ。

　しかし、動作には問題がないため心配はなかった。

　ここまでで挙げたものはほんの一端に過ぎない。ほかの多くのパッケージも、ほとんどがマイナーバージョンアップでありディレクトリ構成や設定ファイルフォーマットに変更が無いのであれば、問題なく動作するはずだ。

　次のページからは、全PRMパッケージの名称とバージョンをAからZまで分けて比較している。量が膨大なため見づらいかもしれないが、着目ポイントを書いたため参考にしてほしい。

　結果としては、ほとんどのものが依存性問題も無くアップデートされていることが分かる。7.3が2002年5月6日、8.0が9月30日のリリースであることから、それほど大々的な変化があることも考えづらい。アップデート対象としては、比較的問題の起きにくいケースであることは確かだ。

　ここで検証環境として挙げたのは、Red Hat Linux 7.3のほぼクリーンなままの状態であったため非現実的なものだともいえる。しかし、アップグレードスクリプト自体を判断する上では重要だろう。

1/5