Fedora Upgrade HOWTO | ||
---|---|---|
HOME |
Fedora Core 1 から Fedora Core 3 へアップグレードした際の経験から OS のリリースをアップグレードする際の要点をまとめた。 yum や apt を使ってライブアップグレードする手もあるようだが、最も安全且つ確実なのは anaconda を使う、つまりインストール CD によるアップグレードだということなので、冒険は犯さずに CD からブートしてアップグレードを行った。
ミラーサイト ring.riken.jp や ftp.kddilabs.jp から ISO イメージをダウンロードする。どうしてもダウンロード量をケチりたい人は、とりあえず CD-1 だけ焼いてみて、一旦 CD ブートし、アップグレードを途中まで進めてみるといい。RedHat 系のインストーラは、実際にファイルやブートローダーをいじる前に、インストールされているパッケージを調べてどの CD が必要か確認画面を出すので、そこで確認できる。確認したらアップグレードをキャンセルすれば問題ない。
後日思いついたことだが、おそらくアップグレード時にも FTP/HTTP インストールが使える。それなら CD-1 だけで済むはずだ。しかし、筆者は新規インストールではその手を使ったことがあっても、アップグレードでは怖くて使ったことがない。
当然ながら、何が起こるか分からないので、バックアップは必須だ。この工程と「3. デーモンを止める」は実際には渾然一体であり、データが書き換わらないよう、止められるサービスは先に止めておかなければならない。以下は、バックアップ項目の覚え書き。もちろん運用によって千差万別で、これ以外にもあるかも知れない;
必要なバックアップが取れたら、すかさず、それ以上データが更新されないよう、問題となるサービスを止め、マシンを再起動しても再び開始しないようにしておく。こんな具合;
root# service httpd stop root# chkconfig httpd off
monit や deamontool といったデーモン管理サービスを使っている場合は、それらの対処も忘れずに。
使いもしない不要なパッケージがインストールされていると、アップグレードの際に余計な時間がかかる。ぎりぎりまで絞り込む必要はないが、特にコピー量が膨大なのが OpenOffice 。要らないのならアンインストールしておこう。また、現在使っているカーネル以外に古いカーネルがインストールされたままになっていると、インストーラがエラーを起こしたり、アップグレード後の整理が厄介なので、それらもアンインストールしよう。
アップグレード実行時のトラブルを減らすため、是非ともやっておきたい。
root# rpm --rebuilddb
アップグレード後の整理の際に参考にするため、過去のパッケージアップデートなどで放置されたリンク切れのシンボリックリンクと *.rpmnew や *.rpmsave ファイルをリストアップ。混乱を避けるため、削除やリネームしておこう。ただし、リンク切れシンボリックリンクは全て無用とは限らないので注意。また、どうしても残しておきたい rpmsave/new ファイルは、 *.rpmnew_fc1 とか *.rpmnew_package_ver としておくとアップグレード後に見分けがつきやすい。これらゴミファイルの検出に便利なコマンドとしては;
root# find / -regex '.*\.rpm\(new\|save\)' -print >rpmgarbage.txt
root# symlinks -vr / |grep -e '^dangling' >dirtylinks.txt
あるいはもう少しきれいな出力がほしければ、
root# symlinks -vr / |awk '/^dangling/ { printf "%s %s %s\n",$2,$3,$4 }' \
>dirtylinks.txt
新しいリリースのインストール CD 1 からマシンをブートし、アップグレードを実行する。その際の覚え書き;
あとは CD を入れ替えながら待つのみ。
さて、アップグレードが完了してリブートすると、多少の警告メッセージは出るが、この段階ではまだあまり気にしなくてよい。しかし、システムの正常稼働に必要な最低限の設定ファイルは、ここで一旦整備する必要がある。ここでの目標は、OS の基幹部分が正常に稼働し、次の yum アップデートでリモートサイトに接続できるようにすること。かなりの数のファイルはどうせ次の yum アップデートで再度入れ替わってしまうので、あまり几帳面にやっても無駄だ。
新しい設定ファイルは、従来のファイルを *.rpmsave にリネームしてからコピーされているか、一部は、不用意な入れ替えを避けて *.rpmnew としてコピーされ、まだ有効になっていない。この段階で、確認が必要と思われるものは;
サーバの運用方法によっては、ネットワーク正常稼働のために以下のものも検討する必要があるだろう;
設定が終わったら一度リブートして反映させる。
リブート後、yum の設定を行い、`yum update' ですべてのパッケージを最新版にアップデートする。 apt を使っている人はそれなりにどうぞ。私の好みでは、暫定的に /etc/yum.conf に;
exclude=kernel* hal
を書き加え、カーネルのアップデートだけは後回しにする。設定の不完全なファイルが五万とあるこの状態で、万が一カーネルエラーが重なったら、原因の特定に大変な手間がかかる恐れがある。 hal はカーネルのバージョンに直接依存するパッケージなので一緒に除外しておく。
まず /usr/share/doc/fedora-release-3/RELEASE-NOTES-x86-en.html を読む。日本語訳も Fedora JP wiki にある。
「現状のゴミファイルの確認」で調べた情報も活用しつつ、古い設定を *.rpmsave にバックアップしながらコピーされたファイルや、 *.rpmnew としてコピーされ新しい仕様がまだ反映されていないファイルを点検、削除、編集する。検出に便利なコマンドは「現状のゴミファイルの確認」で紹介した。また、アップグレード時に出力されたログ /root/upgrade.log, /root/upgrade.log.syslog も役に立つ。「必要最低限のシステム設定ファイルを確認」で編集したファイルも再度確認が必要だ。
file.rpmnew を file に上書き移動するかどうかは、diff で内容を比較したりファイル属性 (ファイルなのかシンボリックリンクなのかディレクトリなのかやパーミション) を見比べて決めなくてはならないが、面倒くさい作業なので、少しはラクにするためシェルスクリプトを作った。この replrpmnew スクリプトは、引数で与えられた 1個のファイルを .rpmnew ファイルと比較 (diff と `ls -l') し、差異がなければ即上書き移動、差異がある時はユーザに同意を求めてから上書き移動する。スクリプトファイル冒頭の設定変数を適宜調整してから使用すること。また、今のところ、目的のファイルのあるディレクトリへ cd してから実行しなければならないという制限事項がある。使用例:
root# cd /etc/smb root# replrpmnew smb.conf
なお、FC1 から FC3 へのアップグレード時、 PostgreSQL はデータの互換性問題が発生し、アップグレード直後はサービス自体が立ち上がらなかった。データディレクトリを一旦初期化して、ダンプしておいたデータをリストアすることで解決した。
この作業が必要なのは、特に、monit や deamontool などのデーモン管理ツールを使用している場合。 rpm によるパッケージアップグレード/アップデートは、 /etc/rc.d/init.d/ に 各 rc ファイルをインストールし、所定のランレベルで起動するよう chkconfig を掛けたはずであり、現段階ではデーモン管理ツールと標準の rc とで重複処理しているものがあるはずだ。アップグレード前に off にしてあったサービスが勝手に on にされることは「一部の例外」を除いてほとんどないとはいえ、新登場のデーモンが、要りもしないのに on になっているケースはある。例えば「一部の例外」には sendmail があり、FC1 になくて FC3 で新たに追加されたサービスには mDNSResponder と nifd (他にもあるかも知れない) がある。mDNSResponder と nifd はともに Zeroconf (開発元 Apple名は `Rendezvous' 改め `Bonjour'。=> 日本語訳) 関連のデーモンで、howl パッケージに含まれるが、インターネットサーバ目的で運用しているマシンなら今のところまず要らない。
ソフトウェアの仕様変更やパッケージ構成の変更などの理由で、リンクの切れたシンボリックリンクがどうしても残ってしまうので、「現状のゴミファイルの確認」で調べた情報も参考にして、それらを掃除していく。そこでも紹介したが、壊れたシンボリックリンクを検索するには;
root# symlinks -vr / |awk '/^dangling/ { printf "%s %s %s\n",$2,$3,$4 }' \
>dirtylinksnew.txt
などとするのがいいだろう。しかしどれもこれも不要とは限らない。疑わしい場合は、アップグレード後の RPM データベースから、そのファイルやディレクトリがいずれかのパッケージに含まれるかどうか調べよう。インストールされているパッケージに属する、つまり必要なものなら;
root# rpm -q --whatprovides /path/to/suspicious/dir/or/file
でパッケージ名が得られるはずだ。この時、引数は絶対パスで指定しなくてはいけない。
手動でコンパイルしてあったアプリケーションは、共有ライブラリのバージョンが変わったために正常動作しないことがある。そういう場合は新しい環境の下でコンパイルしなおす必要がある。正常に動いているように見えるプログラムも、なるべく再コンパイルしたほうが確実だ。
メール配送エージェントに qmail を使用している場合は、アップグレードが否応なしにインストールする sendmail をアンインストールする必要もある。 sendmail をアンインストールした後には qmail の sendmail ラッパーのシンボリックリンク を張り直すことも忘れずに。
FC1 から FC3 へのアップグレードでは、システムユーザを作成 (useradd) した際にユーザのホームディレクトリにコピーされる /etc/skel 下のドットで始まるファイルも、幾つか新しくなった。しかし、rpm システムは既存のユーザが持っているドットファイルまでは更新してくれないので、 /etc/skel から手動でコピーしなおしてやらなければならない。 skel ファイルを修正していた人は、先に skel ファイルを編集してから、実際にユーザディレクトリにあるものと比較しながら上書きするなり修正するなりしよう。 root のドットファイルも忘れずに。
FC1 から FC3 へのアップグレードでは、 Xfree86 が xorg に替わったこともあり、デスクトップのデフォルト設定もかなり変更になっていた。新しい機能を活用するためにも、各ユーザの X や Gnome, ウィンドウマネージャの設定を一度リセットすることを勧める。「よろず環境設定」の「ユーザのデスクトップをリセットしたい」が参考になるはずだ。
もうひとつオマケ。 FC 3 や 4 では、インプットメソッドとして IIIMF という仕組みが取り入れられた。 canna などを使って頻繁に日本語入力をする人なら恩恵があるかも知れない。アップグレードでは入らないので、欲しければ手動でインストールしてやる必要がある。ただ、筆者は日本語をほとんど打たないので、実験用マシンに入れてみたが正直あまり有難みを感じず、本チャンのマシンでは採用を見送った。 Gnome, canna を使ってきた人であれば、 yum で iiimf-le-canna, iiimf-x, iiimf-gnome-im-switcher の 3 つを指定してやれば、依存が解決されて合計 6 つくらいのパッケージがインストールされる。入ったら、一旦 X セッションを出てから `service iiim start' でサービスを開始。 ps コマンドの表示では htt と htt_server がそれに当たる。 X を立ち上げると、それまで Shift + space だった日本語入力開始キーが、 Ctrl + space に変わっているはずだ。 Gnome アプレットも用意されているので、好きな人は、バーに追加してみるなどいろいろいじくってみていただきたい。