2.9 からは、MySQL の 4.1.2 以降が必須となっています。まあ MySQL 4.0 系列のサポートはすでに打ち切られているので、いつこうなってもおかしくありませんでしたが、一部のレンタルサーバなどではまだ 4.0系列を使っているところもあり、バージョンアップしようとするとエラーが出てしまいます。

また、バージョンアップすると、プラグインとして利用してる “Simple Tags” が動かなくなっしまいました。次のようなメッセージが出ます。

Simple Tags can't work with this WordPress version !

暫定的な回避策として、プラグインを編集して、

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false  ) {

の部分を

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false || strpos($wp_version, '2.9') !== false ) {

に変更することで対応できました。

EPEL に RPM パッケージが用意されています。yum で EPEL を使えるようにして phpMyAdmin をインストールします。

# yum install phpMyAdmin

アクセス許可

初期状態では、サーバのローカルからしか許可されていません。これをローカルエリアネットワークからアクセスできるように許可するには、/etc/httpd/conf.d/phpMyAdmin.conf を編集します。

<Directory "/usr/share/phpmyadmin">
  Order Deny,Allow
  Deny from all
  Allow from 127.0.0.1
  Allow from 192.168.1.0/24 ←追加
</Directory>

これで http://サーバ名/phpmyadmin/ にアクセスして、ログイン画面が出ればOKです。

もちろん、インターネット側からアクセスできるような設定もできますが、その場合は IP アドレスを限定したり Digest 認証の設定をするなどセキュリティには注意を払いましょう。

「mcrypt 拡張をロードできません」のエラー

「mcrypt 拡張をロードできません。PHPの設定を確認してください」というエラーが出た場合は、php-mcrypt パッケージがインストールされていません。yum でインストールして、Apache を再起動します。

# yum install php-mcrypt
# service httpd graceful

blowfish_secret の設定

「設定ファイルが秘密のパスフレーズ（blowfis_secret）を必要とするようになりました」というエラーが出た場合は、/usr/share/phpmyadmin/config.inc.php ファイルを編集して、$cfg['blowfish_secret'] に秘密のパスフレーズを設定します。

$cfg['blowfish_secret'] = 'ここに秘密のパスフレーズを設定'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

サーバが応答しません (あるいはローカルの MySQL サーバのソケットが正しく設定されていません)のエラー

「サーバが応答しません (あるいはローカルの MySQL サーバのソケットが正しく設定されていません)」というエラーが出るときは、メッセージどおり、MySQL のサーバが動いていない可能性があります。phpMyAdmin と MySQL のホストが異なる場合は、/usr/share/phpmyadmin/config.inc.php の $cfg['Servers'][$i]['host'] を変更します。

$cfg['Servers'][$i]['host'] = '192.168.1.100';  //←localhost から変更

RPM インストールであれば問題ないはずですが、それでもつながらない場合、ソケットの場所を確認します。ターミナルから mysql コマンドで接続したら　statusコマンドでソケットのパスを確認します。

$ mysql -u root
mysql> status
--------------
UNIX socket:            /var/lib/mysql/mysql.sock

このパスを、phpMyAdmin の config.inc.php に記述します。また connect_type も確認しましょう。

$cfg['Servers'][$i]['connect_type']  = 'socket';       // ←tcpから変更
$cfg['Servers'][$i]['socket']        = '/var/lib/mysql/mysql.sock';

ログイン画面の前にブラウザのパスワードダイアログが表示される

ログイン画面の前にパスワードダイアログがでる場合、以下の方法でログイン画面の表示に変更できます。管理画面に別途 Digest 認証などをかけているときは干渉して都合が悪いです。

$cfg['Servers'][$i]['auth_type']     = 'cookie'; //←http から変更

ログイン画面が出たら、通常は mysql データベースのログインアカウントとパスワードで入れるはずです。MySQL の初期状態では root ユーザでパスワード無しでは入れてしまいますので、その場合は root のパスワードを設定しましょう。

php.ini 変更

register_long_arrays を有効にします。

「1054 - Unknown column 'p.products_id' in 'on clause'」

この場合は、catalog/defaul.php 中の SQL 文で、left join の前の部分を (, ) で括ってやればよいようです。MySQL 4.1 より MySQL 5.0 では文法的なチェックが厳しくなったためということです。

$listing_sql = "select " . $select_column_list . " p.products_id, p.manufacturers_id, p.products_price, p.products_tax_class_id, IF(s.status, s.specials_new_products_price, NULL) as specials_new_products_price, IF(s.status, s.specials_new_products_price, p.products_price) as final_price from ((" . TABLE_PRODUCTS_DESCRIPTION . " pd, " . TABLE_PRODUCTS . " p) left join " . TABLE_MANUFACTURERS . " m on p.manufacturers_id = m.manufacturers_id, " . TABLE_PRODUCTS_TO_CATEGORIES . " p2c )left join " . TABLE_SPECIALS . " s on p.products_id = s.products_id where p.products_status = '1' and

IBM による買収が報道されていましたが、結局は Oracle が SUN を手に入れることになりました。両社は10年ほど前は蜜月の関係でしたが、いまや Oracle は SUN のハードに興味は無いのだと思っていました。

さて、Oracle にとって SUN を買収するメリットは何でしょうか。Solaris という UNIX OS ももはや魅力ではありません。Windows や Linux でも Oracle が広く使われるようになっているからです。MySQL も以前コアだった部分を Oracle が買収して反感を買っていました。OpenOffice で MS に対抗する? どれも無さそうです。

それとも Java でしょうか。Oracle はアプリケーションサーバも手がけていますから、Java の主導権を握ることは理にかなっていると言えそうです。おそらく IBM に SUN を買われるよりも、手に入れたほうが（生殺しになったとしても）IBM の影響力をそぐという意味では正しいと判断したのでしょう。

ハードウェアの部分に Oracle が本気で取り組むとは思えないのですが、うまくいかなければ HP や富士通に売却するのではないかと思います。

それにしても、Oracle に買収されたあとの Java、OOo、MySQL、Glassfish の未来は暗いですね。特に MySQL。まだ IBM の方がよかったですね。IBM は Microsoft に対抗するために Java も OOo も強化したかったはずですからね。

「IBMがSun買収に向けて交渉」の報道というニュースが駆け巡っています。サーバ市場は飽和状態ですが、以前から再編対象と言われていた SUN を IBM が買収すれば、IBM はシェア上は HP に対してかなりの差をつけることになりそうです。

SUN の Solaris 機は、CPU とサーバを富士通が開発・製造していたと思います。両社の提携が発表されたときは、SUN は近い将来富士通に買収されるのではないかと思っていましたが、そのような組み合わせは実現しませんでしたね。

気になるのは SUN が昨年買収した MySQL の位置づけです。IBM は DB2 という RDBMS を持っていますが、JAVA DB の cloudscape を Apache に寄贈するなど、オープンソースに理解が深そうです。MySQL コミュニティの人たちには朗報なのかもしれません。SUN は Cobalt や iPlanet (Netscape のサーバ部分) など買収した資産を活かせない風潮があると思いますので、IBM に飲み込まれてくれた方がいいですよね。

一方でシスコがブレードサーバ市場に参入というニュースもありました。サーバ分野の合従連衡にはまだまだ目が離せませんが、サーバの保守が打ち切られたり、互換性のないブレードサーバが乱立するのは避けて欲しいところですね。

まあ、IBM としてはサーバのハードよりも、Java が欲しいのかもしれません。Java のオープンソース化を一番熱望していたのは IBM ですからね。

買収したのが Oracle でなくてよかったと思いますが、Sun は過去に Cobalt を買収して失敗したりしているので、今回もそのようなことにならないか心配です。あと MySQL には Intel、SAP、Red Hat などが投資していましたが、今後の関係がどうなるのか興味深いところ。

また「Sun」という色が付くことで嫌がる OSS 支持者が、PostgreSQL や Firebird に流れることも予想されますね。LAMP から LAPP への流れが加速するかもしれません。

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 33554432 bytes!
[ERROR] Can't init databases
[ERROR] Aborting

InnoDB のログファイルのデフォルトは 5M ですが、これを 32M ほどに設定し直したところ、ファイルサイズが設定と違うという理由でエラーとなっているようです。自動的に再作成はしてくれないようですので、ログファイルを削除してから MySQL を起動すれば大丈夫でした。

対処しようにもコンソールからもなかなかログインできず、手こずりました。top 込まんとでは mysql が仮想メモリの 80% 以上を使っていたので間違いなく MySQL が何らかの理由で仮想メモリを食いつぶしたのだと思います。スワップしまくりでした。

mysqld を停止して（Timeout で失敗しましたが）、swapoff -a としてスワップ領域も開放しました。

原因は調査中なのですが特に DoS ということはなさそうなので、先頃リリースされた MySQL のアップデート版 RPM をインストールしたせいではないかと考えています。が、どこかのスパムボットによる絨毯爆撃の可能性も考えられるため、とりあえず Apache のパラメータをいじって同時接続数を減らしたりはしてみました。単にメモリ不足なのかもしれませんが。どうなることやら。

  update temp_table set num = (select max(num) +1 from temp_table) where num=1;
  ERROR 1093 (HY000): You can't specify target table 'temp_table' for update in FROM clause

PostgreSQL や Oracle ではこのようなエラーは起きずに更新が完了します。対処方法としてはテンポラリテーブルを使うか MySQL をやめること。テンポラリテーブルも同一クエリ内では2回以上使えなかったりと制限があります。

MySQL はちょっと凝ったことをしようとすると途端にできなくなるので、本当に困ります。

それぞれの内容を確認すると、URL が http://example.org/?attachment_id=1116 のようなおかしな状態になっています。

この URL を修正すれば良さそうですが、管理画面からは URL は変更できません。もしかしたらプラグインで編集できるものもあるかもしれませんが、今回は MySQL のコンソールから作業しました。もちろん phpMyAdmin からでも修正可能だと思いますが、私は試していません。

そもそもアップロードした画像の情報がどこに格納されているかというと、それぞれの記事やページと同じように wp_posts (wp_ の接頭辞は環境により異なっている場合があります) テーブルに格納されています。ここが WordPress の特徴です。このテーブルの guid というカラムに、先ほどの URL が格納されています。ためしに正常に表示される画像と比べてみると、

mysql> select guid, post_mime_type from wp_posts where id=1116 or id=1024;
+------------------------------------------------------------+----------------+
| guid                                                       | post_mime_type |
+------------------------------------------------------------+----------------+
| http://example.org/wp-content/uploads/2007/08/sapari.jpg | image/jpeg     |
| http://example.org/?attachment_id=1116                   |                |
+------------------------------------------------------------+----------------+

post_mime_type の値が空になっているのでこれを修正する必要がありそうです。また guid　の URL の形式がまるで異なるのがわかります。この URL を修正すればよいのですが、画像の内部バスが wp_postmeta テーブルに格納されているのでそれを利用します。

mysql> select meta_value from wp_postmeta where post_id=1116 and meta_key='_wp_attached_file';
+------------------------------------------------------------+
| meta_value                                                 |
+------------------------------------------------------------+
| /old/site/path/wp-content/uploads/2007/07/search-regex.png |
+------------------------------------------------------------+

しかし、wp_postmeta テーブルには、インポート前のサーバ上の内部パスが格納されていました。まずこれを修正します。

mysql> update wp_postmeta set meta_value=replace(meta_value, '/old/site/path/', '/new/hoge/path') where meta_key='_wp_attached_file' and meta_value like '/old/site/path/%';

次にこのデータを利用して、wp_posts を更新しますが、こちらは SQL 一発というわけにはいきません。個別に ID と mime_type を確認・指定しながら SQL を実行します。一気にやる方法は MySQL にはカーソルをループで回して……のようなことをやる術がないので、おそらくできないと思います。あれば教えてください。こういうときに Oracle や PostgreSQL と MySQL の差が出てしまいますね。

mysql> update wp_posts set
    -> guid = (select replace(meta_value, '/new/hoge/path/', 'http://example.org/')
    ->  from wp_postmeta where post_id=1116 and meta_key='_wp_attached_file'),
    ->  post_mime_type='image/png' , where id = 1116;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

もちろん post_mime_type には画像が JPEG のときは image/jpeg を、PNG のときは image/png を指定します。これで、アップロードしたファイルを確認してみると、

これを繰り返していき、すべての画像が復旧できました。

この画像が表示されなくなる現象は再現性があるので、WordPress のインポートプログラムのバグだと思います。将来的には改善されると思いますが、同じことでハマって悩んでいる人の助けになれば幸いです。

データベースの作成

root ユーザで mysql のコンソールに入り、CREATE DATABASE コマンドを実行。

# mysql -u root
mysql> CREATE DATABASE db_name;

ユーザの作成

Oracle や PostgreSQL と異なり、CREATE USER 文ではなく GRANT 文で作成する。

mysql> GRANT ALL PRIVILEGES ON db_name.* TO user_name@localhost IDENTIFIED BY "*********";

データベースの一覧

mysql> SHOW DATABASES;

データベースの選択

mysql コンソールに入ってから使うデータベースを指定したり、切り替える場合。

mysql> \u db_name;

テーブルの一覧

mysql> SHOW TABLES;

テーブルの詳細情報

mysql> DESC table_name;

データベースのダンプ

データベースの内容をファイルに出力

$ mysqldmp -u user_name -p db_name | gzip > db.dump.gz

データベースのリストア

$ zcat db.dump.gz | mysql -u user_name -p db_name

これは各記事の「ピンを許可」のチェックの方が優先されるためですので、既存の記事へのトラックバックを拒否したいのであれば、過去の記事の「ピンを許可」のチェックを外す必要があります。記事数が多い場合はいちいち設定できませんので、MySQL にログインして、SQL で一括変換するのが良いと思います。

mysql> UPDATE wp_posts SET ping_status='closed';
Query OK, 52 rows affected (0.00 sec)
Rows matched: 50  Changed: 50  Warnings: 0

mysql> SELECT COUNT(ping_status), ping_status FROM wp_posts GROUP BY ping_status;
+--------------------+-------------+
| count(ping_status) | ping_status |
+--------------------+-------------+
|                 50 | closed      |
+--------------------+-------------+
1 row in set (0.00 sec)

元に戻すときは ‘closed’ の代わりに ‘open’ を指定します。コメントの場合は ping_status のところを comment_status にしましょう。コミットも忘れずに。

mysql> UPDATE wp_posts SET comment_status='closed';

別の方法もあるかもしれませんが、SQL を使える人ならばこういう方法を知っておけば色々応用が利くと思います。

最近、書く時間がほとんど取れず、情報が遅れてしまい申し訳ありません。

7月中旬にどさっとパッケージが公開されました。大物パッケージも多いです。前回書いてないものを挙げると……

• OpenSSH CAN-2004-0175
• Telnet CAN-2005-0468 CAN-2005-0469
• ImageMagick CAN-2003-0455 CAN-2004-0827 CAN-2004-0981 CAN-2005-0005 CAN-2005-0397 CAN-2005-0759 CAN-2005-0760 CAN-2005-0761 CAN-2005-0762 CAN-2005-1275 CAN-2005-1739
• kdelibs kdebase CAN-2003-0592 CAN-2004-0411 CAN-2004-0689 CAN-2004-0721 CAN-2004-0746 CAN-2004-1158 CAN-2004-1165
• gd CAN-2004-0941 CAN-2004-0990
• OpenSSL CAN-2004-0975
• Samba CAN-2004-0882 CAN-2004-0930 CAN-2004-1154
• cpio CAN-1999-1572
• cURL CAN-2005-0490
• MySQLCAN-2005-0709 CAN-2005-0710 CAN-2005-0711
• gdk-pixbuf CAN-2005-0891
• Mozilla (Galeon, epiphany, devhelp) CAN-2005-1476 CAN-2005-1477 CAN-2005-1531 CAN-2005-1532
• PostgreSQL CAN-2004-0977 CAN-2005-0227 CAN-2005-0244 CAN-2005-0245 CAN-2005-0246 CAN-2005-0247
• SquirrelMail CAN-2004-1036 CAN-2005-0075 CAN-2005-0103 CAN-2005-0104

Mozilla はようやく 1.7.8 になりました。この 1.7.8 にもセキュリティホールが見つかっており、1.7.10 が準備中でしたが、おそらく 1.7.11 になると思います。

また前回リリースされた PHP パッケージの FC1、FC2 用のアップデートがリリースされていますが、FLP サイトにはまだアドバイザリが掲載されていません。直接ダウンロードはできるようになっています。

いくつかのパッケージが updates-testing に上がってきています。しかも kernel, OOo, php, MySQL, Mozilla など大物揃いです。

これらのパッケージがテスト（QA）されて、問題がなければ公開されます。だれもテストしなければ、いつまで経っても updates-testing ディレクトリに入ったままです。ぜひ協力してください。

• kernel RH73、RH9、FC1、FC2 が対象
• OpenOffice.org RH9、FC1、FC2 が対象
• gaim RH73、RH9、FC1 が対象
• php RH73、RH9、FC1、FC2 が対象
• sharutils RH73、RH9、FC1、FC2 が対象
• mysql RH73、RH9、FC1が対象
• cvs RH73、RH9、FC1、FC2 が対象
• gftp RH73、RH9、FC1 が対象
• lvm RH73、RH9、FC1 が対象
• mozilla、galeon、epiphany、devhelp RH73、RH9、FC1、FC2 が対象

特に mozilla は Fedora Legacy ではなかなかリリースされなかったパッケージです。当初は 1.4.x 系列でパッチを作成していましたが、すでに本家 Mozilla の安定版が 1.7 系列に移行してたため、パッチのバックポートに時間がかかっていました。その上、次々と脆弱性が発見されて、リリースが先延ばしになっていました。結局、すべての OS で 1.7.7 をパッケージしてリリースすることになったようです。

update-testing のパッケージは、Fedora Legacy Repositoryから入手できます。ミラーサイトにはまだ行き渡っていないパッケージもあるようです。

MySQL, sharutils, SpamAssassin の各パッケージに対するアップデートがリリースされています。今回は詳細は割愛しますので、リンク先の文書で確認してください。