最新

おおいわのこめんと (2010-02)


2010-02-01

[Comp] Etch → Lenny アップグレード

いよいよ etch のサポートが 2/15 で打ち切られるとの アナウンス が流れてきてしまいました。

前回は upgrade が比較的面倒だったこともあって手動 backport で半年近く引っ張ったのですが、 今回はサーバ系のバージョン変化が比較的少なく、Xも Xorg 同士の移行で簡単そうなので、 期日までに(実験用 etch 固定環境以外)全部アップデートする方向で準備中。 とはいえ、もう2週間しかないので結構忙しい。

まして自宅に2台、*1 職場の自分用マシンで2台、共用サーバが6台もあると、 非常に大変であることには言うまでもないわけでして...。

とりあえず影響が少ないところから試行するのは鉄則で、 先週末から、まず職場のノートPCの VMware 環境 (a) をアップデートして 手順の確認と様子を見てみることから始める。 この環境は出張先での開発専用なので、壊れてもすぐに困らないのと 入っているパッケージ数が少ないのが選択の1つの理由。 VMware は snapshot とれるのでこういう時は気楽ですねぇ。 1つ大きなトラブル (1) が出たが、まぁなんとか移行完了。

ただ、自宅〜職場〜ノートPCの3つの開発環境は全部まとめて Unison で 同期をとっているので、1つを lenny にバージョンアップしたら 全部バージョン上げないと都合が悪い……。というわけで次は週末作業で自宅マシン。

自宅のメインマシン (b) は、home の外部バックアップと root のマシン内コピーを 作ってから移行。これも1つトラブル (1) が出て、あと 日本語 TeX 周りは ghostscript とかいろいろ壊れてるけどとりあえず 開発環境までは無事動いた。*2 ほっとする。自宅サーバはほとんどもうお仕事してないので後回し。

そして今日は職場のマシン群。 まずは止まってもあまり困らないサーバマシン (c) をバージョン上げて様子を見る。 ほとんど問題なくバージョンが上がるが、apache2 の設定 (2) でちょっと引っかかる。 apache2 を一旦止めて設定をわかる部分は書き換えてから移行した方が無難そう。

某所のルータをやっている OpenMicroServer (d) は問題なく終了してあとは リブートするだけで多分なんの問題もないはずだが、 ディスクの残り容量が 70MB を切っているのでその回避だけが厄介だった。

そして職務机上のメインマシン (e) も更新。ここで2つトラブル (3)(4) が出て、 解決したら雪が積もって帰りが大変になった (^^;。まぁでもこのおかげで 気づいていなかった次の本番サーバでのトラブルの種を見つけることができたので、いいことにするか。 これで開発環境のあるマシンの更新は完了。

……5台片付いたのであと5台ですか (^^; 結構重要なマシンが残ってるし気が遠いなぁ。 というわけでシステム管理日記でした。

追記 (2010-03-07)

残っていたメインのサーバは先月中に片付け、最後に死んでいたマシンと自宅サーバをアップデートして、 ついに身の回りは全部 lenny upgrade が完了しました。これでしばらくはまたラクにメンテできるといいな。

トラブルリスト

一応他の人に同じトラブルが起こった時の参考になるかも知れないのでメモを残しておくことにする。

(1) texlive-base-bin の postinst に失敗する

これは、どうも sarge → etch → lenny と移行してきた環境で問題が起こるみたい。 etch → lenny な (e) では問題が起こらなかったので。 /etc/texmf/updmap.d に sarge 時代のゴミが残っていると失敗するようなので、 mfw とかのエントリがあるそれらしいファイルをリネームするなり削除するなりしてから upgrade すればいいみたい。(e) には該当ファイルがそもそもなかった。 ファイル名はメモし損なったのでまた気がついたらその時に。

(2) apache2 の設定

これはリリースノートにも書いてあるが、VirtualHost のデフォルト設定が変わったことが原因。 sites-enabled と記述が矛盾したり重複したりするので、後者の VirtualHost (と Listen) の設定を見直すべし。 sites-enabled の設定を標準からいじっていなければ問題ないのかな?

あと、suexec が別パッケージになったのも同じくリリースノートに書いてある。 パッケージのアップグレード順を工夫して apache2 の更新と同時にできれば入れておきたい。

(3/7追加): 方法としては、 Aptitude のアップグレード後、他のアップグレードを行なう前 に、aptitude install apache2-suexec で パッケージを入れてしまえばいい。ちゃんと Updates: 依存関係が指定されているので、前のものと干渉したりはしない。

ただ、僕の管理するマシンは suexec を全部「僕の」権限を細分するするために使ってるので いいのだが、アップグレードするといきなり suexec が効かなくなるってのはちょっとひどいよねぇ。

(3) python-central が削除・更新できなくなる

Debian-backports の trac パッケージが python 環境をぶち壊すみたい。 known かつ unfixed な issue になっているようだ。 これは結構困った状態。

とりあえず (e) のマシンでは trac を使っていないのだが、 この状態から trac をアンインストールしようとしてもできないので、 今回は無理矢理

  • /var/lib/dpkg/info/trac.prerm の if 文をつねに偽にして、 trac 削除時に python-central を使わずに強制削除させる
  • そうすると次の python-central のインストール時に trac が消せないと文句言われるので、記録しているファイルを探して 1行だけ削除してしまう
として解決したけど……どうしようかねぇ。次の本番でもトラブる事が 目に見えているので、もう1度 VMware で試験環境作って試すべきかな?

追記(3/7): 結局本番環境では、アップグレード前に trac を削除、アップグレード後に再導入、という最も簡単な手をとりました。
(4) VMware Server 1 の console が動かなくなる

X のライブラリの何かの不整合で問題が起こっているように見え、 ぐぐると皆さんいろいろ試行錯誤をした跡があるのですが、 結局のところ、正しい解決策は「gnome-icon-theme をインストールする」 だそうで……。わかるかそんなもん。

Debian bug で原因究明してくれた人に感謝。

(5) xscreensaver が2画面を認識しなくなる

些細なので上では挙げていないが、(b)(e) どちらでも出現。 nVidia のバイナリドライバを使って2画面表示をしている環境で X をアップデートしたら、なぜか xdpyinfo の出力に XINERAMA が2つ表示され、 ほとんどのアプリは問題ないのだが xscreensaver が画面情報を認識できずに 2画面に跨って表示を出してしまう。

まぁ実害ないのでとりあえず保留。

追記(3/20): Xscreensaver のソースを読んだところ、nvidia のドライバが RandR 1.2 拡張で個別画面の情報を返していないため、XINERAMA より優先されて いたことが判明。XScreensaver 5.06 で個別対策済みのようだが、 lenny の 5.05 では(少なくともデスクトップPCなど動的画面変更がない場合) .xscreensaver
GetViewPortIsFullOfLies: True
を設定すればよい。

追記 (2010-03-07)

以下 3/7 追加。

(6) gs-esp が干渉して safe-upgrade ができない

gs, gs-esp, gs-gpl とかいろいろ入っている環境で、aptitude が依存関係を解決できないでアップグレード失敗することがあります。 これは safe-upgrade 前に、aptitude install ghostscript と明示的に優先するパッケージを指定してやれば 解決します。

(7) bind が再設定中ずっと止まってしまう

ネームサーバとして動かしているマシンで、Debian のリリースノート推奨の順序でアップグレードすると、 bind のアップグレードが他の多数のパッケージと同時に処理され、長時間サービスが止まった状態になります。

Debian の aptitude が upgrade を行なう時、強い (pre-depends な) 依存関係が存在しない パッケージ群をできるだけ一度にまとめて 「関連するサービス停止→パッケージ展開→順番に設定しながらサービス再開」 の順序で作業を行なうので、他のパッケージの展開や設定を延々と待ってしまうのですね。 その間名前引きをそのサーバに依存したマシンが全部使えなくなるので、結構痛い。

解決策としては、これも safe-upgrade 前に、aptitude install bind9 で明示的に bind だけを アップグレードしてしまうのが良さそうです。もし作業を始めてしまって展開が時間かかりそうだったら、 とりあえず /etc/init.d/bind9 start で設定を待たずにスタートさせてしまうのも1つの方法のようです。 こうしていても、パッケージ設定の際にはもう一度きちんと止めてくれるので(ぎりぎりのタイミングとかでなければ)大丈夫。 他にも数分〜10分程度の down-time が許されないサービスがある場合は、少なくとも前半の手は同じように使えると思います。

(8) vmware-server がモジュールを作れない

Gcc が 4.3 になってしまったので、カーネルモジュールの構築に失敗します。 Google してもいまいちな解しか見つからないのですが、正解は単純に CC=gcc-4.1 /path/to/vmware/bin/vmware-config.pl のようです。VMware のこの手のスクリプトは CC 環境変数を見てくれるのです。

*1 このWeb サーバのあるマシンだけは 前回導入時 に lenny testing を入れているので今回は対象外。

*2 そもそも移行前から /usr/local 側の 自分でインストールしたマクロとかがいろいろ微妙に壊れてたのだが、最近 日本語の論文書いてないので壊れてても困らないという (^^;。 英語環境だけならパッケージでサクッと揃うしね。


大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)