.rpmnewおよび.rpmsaveファイルを正しく整理するためのガイドライン

 FedoraあるいはRed Hat系ディストリビューションの新規ユーザ向けのアドバイスとして.rpmnewおよび.rpmsaveという拡張子の付いたファイルについて注意を促す必要性を感じた人はほとんどいないだろう。大部分のユーザにとってこれらのファイルは、知らないうちにハードドライブ上に作成されていただけの存在ないしは、バージョンアップグレード時において瞬間的に表示されるメッセージ項目の1つに過ぎないはずである。つまり、これらのファイルは何をどう扱っていいのかよく分からない存在であり、故に放置しておくべしというのが、大半のユーザの認識するところだろう。実際のところ、これらのファイルはいくつかの基本コマンドを使うことで簡単に整理できるものであり、またこうした作業をこまめに行っておくことが、将来的なアップグレードをトラブルフリーに進めるための予防措置として機能するものなのである。

 .rpmnewも.rpmsaveファイルも、RPMパッケージにおける“アップグレードは慎重に”という方針に基づいて作成されるものである。つまりデフォルト設定ファイルに対する変更を伴うアップグレードにおいて、個々のシステムで使われている現行の設定ファイルをすべて上書きするという処理は、各ユーザが過去に施した設定を丸ごと消去してしまう危険性を常に内在させている。よって先の方針では、そうした単純な処理の代わりに.rpmnewまたは.rpmsaveというファイルを使って復元用の情報を保存させるようにしているのである。そうした措置において、変更対象となった設定ファイルを変更前のオリジナル状態で残すようにした場合は、新規のデフォルト設定ファイルを.rpmnewファイルに格納させておく。そうではなく、変更対象となった設定ファイルは新規のデフォルトファイルで置き換えたという場合は、変更前のオリジナル設定ファイルを.rpmsaveファイルにコピーしておくのである。

 個々のパッケージにおいてどちらのファイル作成が行われるかは、パッケージメンテナの裁量次第というのが実状だ。1つの典型例として最近行われたFedora 8のアップグレードを見てみると、ほぼ全員のメンテナが.rpmnewファイルを使用する方式を選んでいたことが分かるが、そうした選択を一目で見抜けというのは酷な要求というものだろう。いずれにせよ、例えば複数のキーボード設定を/etc/X11/xorg.confに追加していたというユーザにとって、アップグレード時にそれらのユーザ設定が丸ごと上書きされたので最初から設定し直せ、というのは願い下げにしたい事態のはずである。

 各自のシステムにどのようなファイルが追加されるにせよ、1つ確かなのは、そうしたファイルの処理法を把握しておく必要があることだ。メジャーアップグレードをした直後に整理対象となるファイルは何十個にも上るものであり、そうした負担を抱えたユーザが.rpmnewおよび.rpmsaveファイルはそのまま削除するという安直な決定を下すのも分からない訳でもないが、そうした選択はこれらのファイルが用意されている本来の趣旨と真っ向から反することになる。

 すべての.rpmnewおよび.rpmsaveファイルを吟味する余裕などないというユーザでも実践可能な合理的なアプローチとしては、システム全体のパフォーマンスに影響しそうなファイルだけを調べるという選択肢もあるだろう。そうしたファイルの大部分は、設定ファイルの大半を格納している最上層ディレクトリである/etcに置かれているはずである。その他の/etc以外にあるファイルの重要度は低く、システム全体のパフォーマンスに影響する可能性は小さいはずだが、それでもこの種の作業は慎重に進めなくてはならない。

 これは特にメジャーアップグレードの場合に当てはまる話ではあるが、システムのアップグレードを行った後には常に.rpmnewおよび.rpmsaveファイルを調べるようにしておくべきである。その際に遭遇する最初の問題は、これらのファイルがどこに置かれているかを突き止めることだ。悪いことにFedora系システムの場合、アップグレードログの格納先は以前のバージョンで使われていた/rootディレクトリから変更されてしまっている。さらにその名称から予想される/var/logも、この種の情報の保存には使われていない。

 一番お手軽な方法は、デスクトップ検索ツールを利用してファイルシステム全体をスキャンするか、あるいはroot権限でログインしてからコマンドラインで「find / -print | egrep "rpmnew$|rpmsave$"」を実行し、/ディレクトリ以下を全検索させてヒットするファイルのフルパスを出力させることである。

 後はこうして作成したリストを基にして、同一ディレクトリに格納された変更前後のファイルを特定すればいい。変更前と変更後のバージョン比較は、テキストエディタ上で2つのウィンドウを開いて相違点を対比させるということもできるが、この種の作業はコマンドライン操作の方が簡単に行えるものである。

 変更前後の相違点を手作業で特定する作業は集中力の勝負となるためある程度の見落としは不可避だが、コマンドラインで「diff file1 file2 」というコマンドを実行すればすべての変更点を確実に網羅することができる。その実行結果は、一方のファイルにしか存在しない行の開始位置が、1番目のファイルについては>記号で、2番目のファイルについては<記号でそれぞれ示されるようになっている。また実行時に-yオプションを指定すると、双方のファイルが2列形式で表示され、-cオプションを指定すると、コンテクストを保持しながら相違行を示す記号が表示されるようになるので、前後関係を把握しながら比較できるようになる。その他のオプションについては、diffコマンドのmanページを調べれば各自の役立つものが見つかるはずだ。

 このようにして相違点を確認するためのリストが作成できれば、何もせずに.rpmnewファイルを削除してよいのか、新規の設定ファイルを.rpmsaveで上書きさせるべきか、あるいは両ファイルに分散した残すべき設定を合成した新規ファイルを作成するかを判定できるようになる。仮にアップグレードにおける変更点が新規設定行の追加オンリーだけであった場合は、「cat file1 file2 > outputfile 」というコマンドを使用することで先のプロセスを自動化することが可能で、後はこのコマンドで出力されたファイル名を変更して新規の設定ファイルとして使えばいい。そうした単純なアップグレードでなかった場合は、該当行を個別にコピー&ペーストするしかない。また言うまでもないことだが、こうした整理後にリブートした結果、変更を取り消す必要に迫られるかもしれないので、削除や上書きするファイルについては事前にバックアップしておくべきである。

 先の手順で特定した変更箇所の情報を基にして適切な判断を下すには、GNU/Linuxに関する基本知識が必要となる。ただし比較的経験の浅い新規ユーザであっても、特定された変更の意味を把握することは不可能ではない。

 例えば私がFedora 8のアップグレードを実施した際には、ブート時にスキップさせるモジュールをカーネルに指定する/etc/modprobe.d/blacklistを格納した.rpmnewファイルにおいて、bcm43xxに関する行が含まれていることが判明した。仮にその時点でこの指定が何を意味するのか理解できなかったとしても、インターネットで検索すれば、問題の行はBroadcomワイヤレスカード用のfirmware-cutterに対する参照を行うための設定であることが分かったはずだ。firmware-cutterとは、純正ドライバの存在しない一部モデルのワイヤレスカードをGNU/Linuxで使用可能にするためのソリューションである。よってこのfirmware-cutterが対応したカードを使用していたのであれば、実際に用いるblacklistファイルからは先の指定行を削除しておけばよかったということになる。

 こうした比較作業を実践するとなると、かなりの時間と手間がかかるはずである。そうした代償を支払うことでハードドライブに蓄積されたすべての.rpmnewおよび.rpmsaveファイルの整理を終了させたというユーザであれば、yum用に最近開発されたyum-merge-confというプラグインをインストールすべきだろう。PirutおよびPupを陰で支え、Fedora系ディストリビューションのアップデータ兼グラフィカルパッケージマネージャとして使われているのがyumというコマンドである。そしてこのプラグインを使うと、これらのファイルの処理を先延ばしにするのではなく、本稿で説明したプロセスがインストール時に実行可能となるのだ。ただしその性質上、アップデートをyumを介して実行しない限りこのプラグインは利用できない。

 実際にどのようなソリューションを選ぶかは個々のユーザ次第ではあるが、いずれにせよ.rpmnewおよび.rpmsaveファイルの整理はFedora系システムにおけるシステム管理の基本操作の1つに過ぎない。これらのファイルの整理を怠れば、アップグレードの御利益の大半が受けられないシステムと化す危険性が生じてくるのである。こうした状態はセキュリティ面でも劣ったものになるだろう。更に最悪のシナリオを想定すると、最新版のデフォルト設定を前提とした一部パッケージが問題を引き起こし、次回のメジャーアップグレードにてトラブルに遭遇するという可能性も否定できないのだ。実際にはそこまでのトラブルは発生しないかもしれないが、そのような可能性がゼロではない以上、予防措置として.rpmnewおよび.rpmsaveファイルにおける変更箇所の整理をすることは充分に意味ある作業のはずである。

Bruce Byfieldは、コンピュータジャーナリストとして活躍しており、Linux.com、IT Manager’s Journalに定期的に寄稿している。

Linux.com 原文