最近はLinuxでも、WindowsUpdateに似たアップデートの仕組みが付いている。
企業向けのLinuxディストリビューションである”RedhatEnterpriseLinux（RedhatES）”には、up2dateという仕組みが採用されており、自分も仕事で使っているインターネットサーバーでお世話になっていた。
GUI（XWindowsシステムのデスクトップ）でup2dateを起動して、アップデートしたいパッケージを選択すると、ウィザード形式でインストールが完了するという・・・のが正常な動き。
しかし！今回は違った。
9/23以降のアップデートで127もの膨大な更新があり、ダウンロード中にファイルが破損。しかしアップデート自体は、正常に終了。ログアウトで異常に気づいたが、リブートしたら「あらら、別世界」
デスクトップ起動が出来ないばかりか、telnet、ssh、Webサービスまで起動しない。
「やばい！」
泣きそうになる。（笑）
up2dateという仕組みでアップデートした環境は、RHNというredhat社のサイト、ローカルで持っているパッケージデータベース、パッケージ単位の依存性、MD5チェックサムなどの広範囲な知識がないと、完全に再現することが難しい・・・・ということを、今回身に染みて知った。
RedhatES3のCDから現在までのアップデートファイル数は、なんと1000程度もある。
これを一つ一つセットアップしていくのは、気が遠くなる。Linuxの世界では、ソースからコンパイルして、依存性をチェックして、インストールというのが一般的らしく、rpmパッケージでさえ”邪道”呼ばわりされる、鬼門である。
サイトから更新分をチェックしてダウンロードし、ファイルの正常性を確認してから、これまで組み込まれたファイルとの依存性をチェックして、インストールスクリプトが実行され、ユーザー設定をバックアップして、数々のモジュールやライブラリが更新された状態で、正常にブートするというのは、まさしく奇跡だ。
最終的には、up2dateディレクトリに残っていたrpmファイルを一つ一つチェックし、破損ファイルを突き止め、再度ダウンロードし、MD5sumで原本性を確認。ローカルのrpmdbを初期化、再構築してから、全インストールすることで、以前の状態まで復元できたのだが、もし、依存性チェックや全ファイルのMD5照合をコマンドでしていたら、文字通り泣いていただろう・・。
本当に恐ろしい世界だ。
※SunCobaltRaQではBlueLinkというアップデートの仕組みがあったが、アップデートのトラブルは全く無かった。（その代わり、専用のpkgファイルしかサポートしていなかった）
※RedhatES3でも、今回以前アップデートが失敗したことはなかった。今回は、一気に大量のバグフィックスがあったので、サイトが混雑していたのだろう・・・。それにしてもセキュリティアップデートのつもりが、とんでもない障害に繋がってしまうとは・・・・トラブルを引き起こすのは、クラッカーなのか管理者なんだろうか（汗）
