Vine Linux 4.0が出て1ヶ月ほどたったのでアップグレードした。http://vinelinux.org/vine4tips.html を見る限り、aptでアップグレードするのは激しく危険な香りがするが、CD-ROMドライブのついてないマシンなのでつけるのもめんどくさい、このためaptで強行。以下ではコケた点を中心にだらだらとメモする。
apt-get upgrade でコケた。sources.list を書き換えて apt-get upgrade をした直後あたりから、どうやらコマンドを実行するたびにみんながゾンビになっていっていた模様。2.4 カーネル起動中に apt-get dist-upgrade で 2.6 対応のコマンド類が入ったあたりで、2.4 カーネル上で 2.6 のバイナリのコマンドを実行しようとしてコケていたような気がするが、そんな詳しいことは実際のところはよくわからない。 ゾンビになったら新しい SSH セッションをはって、コマンド実行するたびに "&" をつけて無理矢理 reboot までこぎ着ける。
grubでコケた。ブートなので私みたいな素人には非常に困るトラブルだ。上記の reboot 後、いきなり Linux の起動に失敗してやがる。ただし grub そのものと、Linux Kernel そのもののインストールは完了していた模様で、grub から Linux を動かすときのオプションを見直すことで対応できた。このオプションは grub が動いている上で変更できたので助かった。
kernel /vmlinuz2.4hoge ro root=/dev/hda2 resume2=swap:/dev/hda3
initrd /initrd-2.4hoge.img
みたいになっていたので、
kernel /vmlinuz ro root=/dev/hda2 resume2=swap:/dev/hda3
initrd /initrd.img
と修正。起動後、/boot にある vmlinuz や initrd に合わせて、/etc/grub.conf を編集し、grub を MBR へインストールし直して終了。/boot には vmlinuz.old/initrd.old.img (のシンボリックリンク)もあるので、これに合わせて old の項目も入れておくと、万が一の時に助かるかもしれない。
Apache 1.3 でコケた。世間では Apache 2.2 が出てにわかに盛り上がっているそうだが、rarul.com はそんなのお構いなしに Apache 1.3 を使おうと思っていた。が、どうも modules/*.so が壊れたような気がしないでもない。 apt-get reinstall で Apache 1.3 関連のものを根こそぎ入れ直そうとするも，起動すらしてくれなくなってしまった。(log/httpd/error_log にも何も記録がない) なので、もう諦めて Apache 2.0 を使うことに決定。/etc/httpd/conf/httpd.conf を参考に、/etc/apache2/conf/httpd.conf を最初から書き直す。PHP がなぜか 5 と 4 のが混ざっていたので、この辺も入れ直す。log/httpd/ にいろいろ仕掛けたものがある (2003/06/24を参照)ので、これを log/apache2/ へ移して完了。
MySQLでコケた。そもそも起動してない。/var/lib/mysql/yuika.err (ホスト名) にエラーが記述されてるのでこれを頼りに修正する。豪快にコケすぎたので、コケた箇所で段落分けしとく。
/etc/my.cnf がそもそもない。/usr/share/mysql/my-medium.cnf あたりから /etc/my.cnf へコピー。bdb がないとかほざいているので、skip-bdb を my.cnf に記述。
Found invalid password for user とかほざいているので、ユーザを新しく追加・・・しようとするものの、すべてのユーザアカウントが無効なのでムリ。通常の /etc/init.d/mysqld からの起動ではなく mysqld_safe --user=mysql --skip-grant-tables & を使ってユーザアカウント作成する。ちゃんと作れれば /etc/init.d/mysqld から普通に起動し直せばOK.
Apache2 から CGI-Perl でDBI でMySQLにつなごうとすると Client does not support authentication protocol requested by server; consider upgrading MySQL client とか言われる。パスワードの保存形式まで変わったらしいため、"OLD_PASSWORD" を使ってとりあえず回避。このへんの話は "OLD_PASSWORD" で検索すればいっぱい見つかるかと。
varchar だったカラムが勝手にいっぱい varchar(16) にされてしまっていて、新しく入れようとしたものはすべて 16 で切られ、既存データは varchar(16) なのに 16 以上入っていて・・・という奇妙な状態だった。alter table (table_name) change (colum_name) (colum_name) varchar(1024) とかして対応。これで特に問題はなさそうだ。
文字コードがいっぱいおかしい。ちゃんと対応するにはこのへんを見てちゃんと理解しておいた方が良さそうだ。/etc/my.cnf で default-character-set=ujis にする。mysqld, mysql, client, mysqldump と複数の箇所に書かないといけない。やけくそなら、default-character-set=binary と書きまくといいかもしれない。
/etc/my.cnf を読んでくれるのは MySQL付属ツール類のみで、DBIやらPHPやらの場合はちゃんと文字コードが設定されているかどうかは怪しい。PHPの場合、"set names=binary" とかいうSQLを最初に投げるようにしておくといいかも。PerlのDBIの場合は、my.cnf を指定できるのだとかなんとか。
Movable Type が、ページ遷移するたびに認証画面へ戻されるというイヤな状況だったけど、dump して restore するだけで直った。よくわからん。
あとは、MySQLのバージョンアップ後に、default-character-setがない状態で入ったデータとdefault-character-setがある状態で入ったデータとで不整合が出てしまっているのをどうするかだな。一番簡単そうなのは「対応が面倒なので諦める」かな。
MySQL の 4.0以前 と 4.1以後とに大きな壁を感じることができてちょっぴり大人になれた気がする。
