02 12月 09 FreeBSD 8.0-RELEASEのアップグレードは難しい その2

昨日FreeBSD 8.0-RELEASEのアップグレードは難しいで記事を書きましたが、現実的なアップグレード方法を研究しました。

ずばり、portsのmisc/compat7xをインストールすることです。

# portsnap fetch update
# freebsd-update upgrade -r 8.0-RELEASE
# freebsd-update install
# shutdown -r now
# freebsd-update install
# portinstall misc/compat7x
# freebsd-update install
# shutdown -r now

これでばっちりです。とりあえずこれでバージョンアップ作業を進めていきたいと思います。

01 12月 09 FreeBSD 8.0-RELEASEのアップグレードは難しい

FreeBSD 8.0-RELEASEが11/25付でリリースされました。主な新機能は以下の通りです。

• Giant Lockの更なる排除
• ZFS v13の正式サポート
• カーネルプロセスとカーネルスレッドの分離
• 新しいTTYレイヤの採用
• USBメモリをマウント中に引き抜いてもパニックしない
• ネットワークスタックの仮想化”Vimage Jail”
• 新たなUSB実装「USB2」

マイコミジャーナル・スラッシュドットで記事になっています。

で、早速FreeBSD 7.2-RELEASEからFreeBSD 8.0-RELEASEにバージョンアップしようとしましたが、、、なかなか手強いです。今回のバージョンアップから、過去ライブラリとの互換性が失われることにより、portsのrebuildが必要となります!!

実際の手順はFreeBSD 8.0-RELEASE Announcement と FreeBSD Update to 8.0-BETAを参考にしてやってみましたが、はまりました。

はまりどころ

バージョンアップ手順は、以下の順序で行います。

# portsnap fetch update
# portupgrade -a
=> portsの最新化

# freebsd-update upgrade -r 8.0-RELEASE
=> この時点ではパッチのダウンロードのみ

# freebsd-update install
=> この時点でkernelだけがアップグレードされる

# shutdown -r now

# freebsd-update install
=> FreeBSD 8.0-RELEASEのバイナリ・ライブラリがインストールされる
# portupgrade -f ruby\*
# rm /var/db/pkg/pkgdb.db
# portupgrade -af
=> FreeBSD 8.0-RELEASEのライブラリを利用してportsの強制rebuild

# freebsd-update install
=> FreeBSD 8.0-RELEASE以前のライブラリが削除される

# shutdown -r now

上記の通りにやっても、portsの強制rebuild再構成時に依存性や各種諸々の制約でrebuildが失敗します。

この結果、FreeBSD 8.0のシステムができあがった後にportsのdaemon(BIND/Apache等)が起動してこなくて、ひどい目に遭います(libz.so.4/libwrap.so.5がないとかいろいろ怒られました)。

BIND起動時の例)

[root@hoge ~]# /etc/rc.d/named  start
/libexec/ld-elf.so.1: Shared object "libz.so.4" not found, required by "named-checkconf"
/etc/rc.d/named: ERROR: named-checkconf for $named_conf failed

openssh-portable起動時の例)

[root@hoge ~]# /usr/local/etc/rc.d/openssh start
/libexec/ld-elf.so.1: Shared object "libwrap.so.5" not found, required by "sshd"
/usr/local/etc/rc.d/openssh: WARNING: failed precmd routine for openssh

一応抜け道としてcompat7xをインストールすればいいという話もありますが、それはまだ試していません。またの機会にでも試してみたいですね。

後日(2009/12/2)追記

compat7xを利用すれば簡単にバージョンが上げられますね。詳細はここで。

29 11月 09 cactiのバージョンアップができない件について

ノードごとのリソースグラフを管理するため、cactiを0.8.7b から 0.8.7eにバージョンアップしようとしたのですが、以下のエラーが出ます。

Invalid Cacti version 0.8.7b      , cannot upgrade to 0.8.7e

なんでだろうと調べてみたら、結論から言うと、my.cnfにdefault-character-set = binaryの設定を登録していたことが原因だった。では何故こうなるのか?を以下にまとめます。

原因詳細

上記エラーを出す部分のソースコードですが、cacti0.8.7eのバージョンアップ画面で利用されるinstall/index.phpの364-369行目が該当します。

    364         if (!is_int($old_version_index)) {
    365                 print " <p style='font-family: Verdana, Arial; font-size: 16px; font-weight: bold; color: red;'>
Error</p>
    366                         <p style='font-family: Verdana, Arial; font-size: 12px;'>Invalid Cacti version
    367                         <strong>$old_cacti_version</strong>, cannot upgrade to <strong>" . $config["cacti_versio
n"] . "
    368                         </strong></p>";
    369                 exit;
    370         }

364行目で$old_version_index変数の条件判定が失敗するため、エラーになることがわかります。

この$old_version_index変数の中身はmysqlのversionテーブルから取得したもので、mysqlからバージョンアップ前のバージョン情報を取得することで、バージョンアップ可能かどうかを判定しています。

データベースのcharacter-setがutf8の場合

データベースのcharacter-set=utf8だと正常にバージョンアップできます。試しにmysqlに対してversionテーブルが持つ値を検索してみたところ、以下応答となります。versionテーブルのcactiカラムはchar(20)であり、取得できるバージョンも”0.8.7b”となります。

mysql> desc version;
+-------+----------+------+-----+---------+-------+
| Field | Type     | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| cacti | char(20) | YES  |     | NULL    |       |
+-------+----------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> select * from version;
+--------+
| cacti  |
+--------+
| 0.8.7b |
+--------+
1 row in set (0.00 sec)

データベースのcharacter-setがbinaryの場合

character-setがbinaryだと以下のようにversionテーブルのcactiカラムがbinary(20)!!!となり、応答結果は”0.8.7b______________”‘(表示都合上、NULL文字を”_”で表現)”となります。cactiの初期データ作成に用いるcacti.sqlではCHAR(20)を指定しているのに・・・binary型に変換されるようですね。

mysql> desc version;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| cacti | binary(20) | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> select * from version;
+----------------------+
| cacti                |
+----------------------+
| 0.8.7b               |
+----------------------+
1 row in set (0.00 sec)

この場合、上述の$old_version_index変数にはバージョン情報 + NULL情報を含んだ値が返されるため、エラーになる・・ということがことの真相のようです。

データベースのキャラクタセットにbainaryを使う際は注意が必要ということか。

言い訳ですが、今回cactiに利用しているデータベースは昔MySQL 4.0系を利用していた物を流用しました。流用の中で、セキュリティ対策を考慮して4.0系から5.1系までバージョンアップさせた物を使っています。

有名な話ですが、4.0系から5.0系以上にバージョンアップすることは大変な苦労を伴います。理由はMySQLの4.1系で文字コード自動変換が実装された事が原因であり、そのままバージョンアップすると、文字化けすると既存データ破損が大量に発生するため、苦肉の策としてcharacter-setをbinaryにした上でバージョンアップ作業を行っていました。

でもまさかこんなところで落とし穴があるとは・・・・。

下手なことはやらないものですね。以後気をつけます。

26 9月 09 PHP高速化にチャレンジ

www.kinusati.netのコンテンツ(wordpress/mediawiki/cacti)がもっさりしていると指摘があったので、PHP高速化にチャレンジしました。結果は以下のWikiページにまとめています。

FreeBSD:PHPを高速化

APC(Alternative PHP Cache)を利用して、サイト全体が高速化してびっくり。使えるものは使ったほうがいいですね。