Oct 29, 2007

「灯台下暗し」の読み方

「灯台下暗し」という慣用句の世間一般の発音が、昔から気になっている。なぜ皆「もと」にアクセントを置くのだろうか?まるで「東大モトクロス」のようだ。関東のイントネーションによるそれは「大正デモクラシー」をも連想させる。

中1の頃、一般的な発音を知らずに、「灯台下」(関西弁で、尻上がり)「暗し」(同じく「ら」にアクセント)と級友に言ったら、なんやその変な言い方、と笑われてしまい、「灯台」(尻上がり)「下暗し」(「もと」にアクセント)やろ、と訂正された。その訂正された読み方を聞いた時に違和感を覚えてから20年以上、TVでもその違和感のある読み方しか耳にせず、ずっと疑問に思っている。

「ほの暗い」のように「下暗し(もとくらし)」という形容詞がある訳では無く、「下」は灯台(燭台)の真下のことを指し「灯台」にかかるのだから、「下」と「暗し」の間は切れるはずだ。従って「灯台」「下暗し」と切れて聞こえる読み方をするのは間違ってると思うのだが、どうなのだろうか。

See more ...

Posted at 21:42 in 雑記 | WriteBacks (2)
WriteBacks

「ほの暗い」のように「下暗し(もとくらし)」という形容詞がある訳では無く… (^o^)(^o^)(^o^) 私もずっと違和感感じてたんですよ~っ! 友人曰く、「灯台下暗し」があの発音なのは大正デモクラシーの影響に間違いないそうです。 何を根拠に!?と思いつつ、確かに大正デモクラシーの発音は揺るぎがないし、 日本人は義務教育でほぼ確実に習っているのであながち嘘とは言い切れないかも?

Posted by yukineco at 06/25/2010 09:48:38 PM

ほほうそんな民主主義的な発音の混用または抑揚のユニフィケーションが原因または理由でございましたか。 関西では灯台モトクラシーと大正デモクラシーでは自然に発音するとイントネーションのパターンにそれなりの隔たりがあるためまさかそんな統合一体化リファクタリングはあったはずがないと思って居りましたが、やはり我々関西人も関東人による無機質な日本語の簡素化、日本文化の否定、外国文化への移行の弊害を被っているとは知りませんでした。 「モトクラシー」が国語辞典に載る日は遠くないでしょうか。

Posted by ynomura at 06/26/2010 01:24:58 AM

jvim+cannaでローマ字かな入力できない時

このサーバーには、FreeBSDのportsを使って、jvim-canna+freewnnをインストールしていた。
先日、ふとこのサーバー上で日本語の文章を書きたくなって、jvimで書き始めた。ヘルプを見ていると、日本語入力中にかな漢変換エンジンを切り替えることができるとあったので、FreeWnnからCannaに切り替えると、ローマ字入力がひらがなやカタカナに変換されないことに気づいた。aiueoと打つと、日本語入力モードにも関わらず、画面にaiueoと表示され、スペースキーを押しても漢字変換がされなかった。

jvimは日本語入力fepとしてONEWというものを使っているらしい。ONEWのREADMEを読むと、どうやらONEWに対してCannaのローマ字かな変換表(ONEW_CANNA_RKTAB)、またはその探索パス(ONEW_CANNA_RKPATH)を指定する必要があるらしかった。

さらに調べていると、Cannaのデフォルトのローマ字かな変換表はdefault.cbpという名前らしく、このサーバーには/usr/local/share/canna/dic/default.cbpが存在したので、cshで

setenv ONEW_CANNA_RKPATH /usr/local/share/canna/dic/

としてみると、jvim上のCanna選択状態でローマ字入力による日本語入力ができるようになった。

See more ...

Posted at 19:25 in UNIX | WriteBacks (0)
WriteBacks

Oct 28, 2007

Module::Starter::PBP v0.0.3のエラー

ITProのページ「Webプログラミング実力アップ Part1 正しいPerl/CGIの書き方」を参考に、Module::Starter::PBPをインストールして、

perl -MModule::Starter::PBP=setup

を実行して、module-starterを実行すると、
Unknown placeholder <MAIN PM FILE> in Makefile.PL

というエラーが出た。

何かCPANのモジュールが足りないのか、1つ目のコマンドで生成された、~/.module-starter/configの内容が悪いのか、などと思って色々試したが、全く改善しなかった。
仕方なく、インストールされたModule::Starter::PBPの本体であるPBP.pmを解析した所、同じディレクトリのSimple.pmと整合していないことが判った。どうやら、CPANにてModule::Starter::Simpleがバージョンアップされて(今回インストールされたのはv0.0.3のPBP.pmとv1.44のSimple.pm)不整合が発生したようだ。

結局、PBP.pmのsub Makefile_PL_gutsとsub Build_PL_gutsの最初の方を以下のように修正した。
(#の後が元々の記述、#の後が無い行は新しく追加した行)

sub Makefile_PL_guts {
my $self = shift;
my $main_module = shift; #
my $main_pm_file = $self->_module_to_pm_file($main_module); #
my %context = (
'MAIN MODULE' => $main_module, #shift,
'MAIN PM FILE' => $main_pm_file, #shift,

sub Build_PL_guts {
my $self = shift;
my $main_module = shift; #
my $main_pm_file = $self->_module_to_pm_file($main_module); #
my %context = (
'MAIN MODULE' => $main_module, #shift,
'MAIN PM FILE' => $main_pm_file, #shift,

これにより、module-starterがエラー無く動くようになった。

それから、上記ITProのページに書かれている通りに、module-starterを実行した直後の状態の.pmに対して"perl Build test"までを実行すると、

Global symbol "$VERSION" requires explicit package name ...

というエラーが出る。どうせ雛形の中の書き換える部分のエラーなので放っておいても良いのだが、これを回避するには、同じくPBP.pmの中に書かれているModule.pmのテンプレートの
use version; $VERSION = qv('0.0.3');

use version; our $VERSION = qv('0.0.3');
に書き換えておけばよい。(書き換えた後は~/.module-starterを作り直す必要があるので注意)

See more ...

Posted at 22:37 in PC一般 | WriteBacks (1)
WriteBacks

[Perl]Module::Starter::PBPで最初のテストが通らなかった場合の対処メモ

TAKESAKOさんの「Part1 正しいPerl/CGIの書き方:ITpro」を参考にモジュールを書いてみようとしたら、perl Build test...[link]

Posted by at 11/26/2007 02:52:18 PM

Oct 20, 2007

mod_proxyでmod_perlを分離

先週のエントリーで、mod_perlはポート待ち受けする全てのhttpdの内部にperlを常駐させるのでメモリを使いまくって困る、と書いたが、当然その課題については色々考えられてきたようで、mod_perlの様々な文書に対策が書かれていることがわかった。

最初に見つけたのは、単純にもman mod_perlの中だった。"MEMORY CONSUMPTION"という章があり、メモリ消費量が増える理由や、Perlスクリプトを書く時のノウハウが書かれている。さらにman mod_perl_tuningにずばり"REDUCING MEMORY USE"という章があり、次のような方法が紹介されている。
(1) httpdのプロセス数を減らす
(2) httpdが子プロセスをforkする前にPerlモジュールをできるだけ事前にロードして子プロセス間のRAMの共有化を図る(OSによってはあるメモリ領域に書き込みが発生するまではそのメモリ領域のコピーを子プロセスに作らないため)
(3) 通常のコンテンツ用のhttpd(多数の接続を許す)とmod_perlするhttpd(少数の接続のみ)とを分ける

mod_perlのサイトのDocumentationの"Choosing the Right Strategy""Performance Tuning"の所にも色々な情報があるが、大まかには上記の3通りの方法にまとめられると思う。

このWeblogを動かしているサーバーに関しては、(1)はhttpd.confのMaxSpareServersもMaxClientsも最少限にしてあるので無理、(2)は前回の設定で半分程度はなされており、これ以上はMovableTypeに手を加えることを意味し大変なので、(3)のように2種類のhttpdを動かす選択が妥当だ。
そして、複数のhttpdをシームレスに動かすと言えば、Apacheのmod_proxyだ。httpdに届いたHTTPリクエストを他のHTTPサーバーに転送できる機能だ。Apacheを使っていてHTTPサーバーの連携にmod_proxyを使わない手は無い。

ところで、このサーバーにはApacheとTomcatとが動いていて、それぞれ待ち受けポート番号が異なり、2つのポートをインターネットに公開しないといけないことと、一方のコンテンツのURLにポート番号が含まれるのが気になっていた。先々週、Apacheのmod_proxyのことを知り、それを使えば解決することがわかったので、mod_perlを組み込むのと同時に、mod_proxyを使えるようにApache 1.3を再コンパイルしていた。
そのmod_proxyを使って、mod_perlを外したApacheのhttpdとmod_perlを組み込んだApacheのhttpdを繋げれば良いのだ。実に幸便、渡りに船だ。

今回mod_proxyを使って作成した環境を大まかに説明する。
HTTPサーバーは上述のように3つの構成(同一PCで動く)とした。
(A) mod_proxyを組み込んだApacheのhttpd
(B) mod_perlを組み込んだApacheのhttpd
(C) Tomcat
インターネットからのHTTPリクエストは全て(A)が受け取り、リクエストのURLを見て、Perlを起動するべきコンテンツであればリクエストを(B)に転送し、Tomcatの管轄のコンテンツであればリクエストを(C)に転送する。

●mod_proxyの設定
特に細かいことをしなければ、mod_proxyの設定は至って簡単だ。
今回は、上記(A)のhttpd.confに以下を追加した。ここでは(B)はポート81、(C)はポート8080で待ち受けているとする。


ProxyPass /mt/ http://localhost:81/mt/
ProxyPassReverse /mt/ http://localhost:81/mt/
ProxyPass /cgi-bin/mt/ http://localhost:81/cgi-bin/mt/
ProxyPassReverse /cgi-bin/mt/ http://localhost:81/cgi-bin/mt/
ProxyPass /cgi-bin/mt/mt/app http://localhost:81/mt/app
ProxyPass /cgi-bin/mt/mt-search.cgi http://localhost:81/mt/search
ProxyPass /servlet/ http://localhost:8080/servlet/
ProxyPassReverse /servlet/ http://localhost:8080/servlet/
(10/29訂正:取り消し線部分2行削除、その下に2行追加)

言うまでも無く上4行が(B)への転送、下2行が(C)への転送の設定だ。

●httpd二重化の設定
2種類のhttpdを動作させるために、通常、最低
・httpd.conf
・ロックファイル、PIDファイル
・起動スクリプト(/etc/rcまたはそこから呼ばれるもの)
を別々にする必要があると思われる。

httpd.confは、異なるファイル名で2つ用意し、httpdの起動時に"-f"オプションを指定して区別させれば良い。
ロックファイルやPIDファイルの指定は、httpd.confの中で行う。それぞれ"LockFile"、"PidFile"の行で別々のものを設定する。

今回、最終的に(A)と(B)のhttpd.confの差分は次のものとなった。
・LockFile/PidFileの設定
・ErrorLogの設定
・ポート番号
・httpdプロセスの数に関係する値(MaxSpareServers, MinSpareServers, StartServers, MaxClients)
・mod_proxyの設定
・mod_perlの設定(LoadModuleやAddModuleも含めて)

起動スクリプトについては、本サーバーはFreeBSD 4.xなので、それに特化した話になるが、/usr/local/etc/rc.d/にapache-backend.shというファイルを追加した。apache.shとの差分は次の通り。
・apache_flagsの行("-f (config)"によるhttpd.confの指定)
・apache_pidfileの行(httpd.confのPidFileと同じものにする。httpdを通さない処理に必要になる)

See more ...

WriteBacks

上記のmod_proxyの設定で、MovableTypeの全てのCGIへの要求をmod_perlサーバーに転送するようにしていたが、それだとMovableType的にまずいことがわかった。コメントのCGI(mt-comments.cgi)への要求がproxyされると、コメントの送信元IPアドレスが全てlocalhostになってしまい、IPアドレスによる迷惑コメントのフィルタリングが効かなくなり、さらにMovableTypeによってlocalhostが勝手に「禁止IP」に追加されてしまい、一切のコメントが投稿できなくなってしまうのだ。従って、mod_perlで処理されるCGI要求だけをmod_perlサーバーにproxyするように設定を変更した。同様の理由で、このサーバーではコメントのCGIをmod_perl化できないことが確定した。

Posted by ynomura at 10/29/2007 06:01:24 PM

Oct 14, 2007

MovableType3.35をmod_perlで動かす(2/2)

前のエントリーに書いたように、mod_perlのApache::Registryを使ってMovableTypeを動かすのに失敗した後、改めてMovableType3.2のマニュアルを基点に調べていると、MovableType DocumentationのページMovableType3.3のインストールガイド(PDF)にもmod_perl化の方法が書かれていることに気付いた。こちらにはApache::Registryを使う方法は書かれていない。

そこでMovableType3.3のインストールガイドに従ってやってみた所、いくつかのトラブルがあったが、何とかMovableTypeをmod_perlで動かすことができた。

●mod_perlの設定(MovableType自体をPerlHandlerにする)
最終的にhttp.confの末尾に書いた設定は以下の通り。/path/to/…となっている部分は、実際のものから書き換えている。


#(a) library path descriptions passed as-is to the Perl interpreter
<Perl>
use lib '/path/to/mt/lib';
use lib '/path/to/mt/extlib';
use lib '/path/to/mt/plugins/WidgetManager/lib';
use lib '/path/to/mt/plugins/StyleCatcher/lib';
use lib '/path/to/mt/plugins/GoogleSearch/lib';
use lib '/path/to/mt/plugins/spamlookup/lib';
</Perl>

#(b) just as the installation guide says
Alias /mt/mt-static/ /path/to/mt-static/

#(c) definition of the Perl handler, set to MovableType
PerlModule MT::App::CMS
<Location /mt/app>
SetHandler perl-script
PerlHandler MT::App::CMS
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
Allow from 192.168
</Location>

#(d) corresponding to "$CGIPath/$AdminScript" in mt-config.cgi
<Location /cgi-bin/mt/mt/app>
SetHandler perl-script
PerlHandler MT::App::CMS
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
Allow from 192.168
</Location>

(a)のPerlのライブラリパス設定の部分は、インストールガイドには最初の2行しか書かれていないが、実際にはインストールしてるプラグイン全ての分が必要だ。プラグインの分の設定が無いと、MovableTypeの管理画面で時々、例えば下のようなエラーが出る。

Can't locate object method "get_handle" via package "StyleCatcher::L10N" at /usr/local/www/cgi-bin/mt/lib/MT/Plugin.pm line 459.

(b)の部分はインストールガイドのままの記述だ。おそらくhttpd.conf内のaliasが誤って適用されないようにするための処置だと思われ、必須ではないような気がするが、念の為加えている。

(d)の部分は後述の"$CGIPath/$AdminScript"の対策だ。

●mt-config.cgiの設定
インストールガイドに書かれている通り、下の設定を加える。

StaticWebPath http://hostname/mt/mt-static
AdminScript mt/app

StaticWebPathのhostnameより右の部分は、httpd.confの(b)で定義したエイリアスにする。実際には、StaticWebPathは既存の設定のままでも、少し使った感じでは問題なく動いたように見えた。

●起動確認
さて、インストールガイドに従ってhttpd.confとmt-config.cgiを書き換えてhttpdを再起動し、いざmod_perl経由のMovableTypeの管理画面にアクセスしようとすると、URLがわからない。もちろん既存のURLにアクセスすると、別プロセスのPerlのCGIが起動してしまう。上記の設定の場合、正解は、

http://hostname/mt/app
だ。なぜインストールガイドに書かれてないのだろう。httpd.confをいじるなら、それくらい判れということだろうか。

当初、上記(d)の設定をしていない状態で、ブラウザでhttp://hostname/mt/appにアクセスするとログイン画面が表示され、パスワードを入力すると、mt-config.cgiのCGIPATHとAdminScriptとを繋げたURL(http://hostname/…/mt/mt/appのような感じ)にジャンプしてしまい、ページが見つからないというエラーになってしまった。
それで思わずCGIPATHをhttp://hostname/に書き換えてしまった。それから出てくるエラー(プラグインが見つからないというエラーもここで出た)に対処すると、そこそこ動作するようになった。エントリーの追加、サイトの再構築もできたので、これでバッチリかと思い始めた頃、コメントの投稿ができないことに気付いた。CGIPATHを書き換えてしまったため、MovableTypeが生成したページから呼ばれる他のCGIが起動できないのだ。

正直な所、この管理画面のURLが"$CGIPATH/$AdminScript"になる問題への適切な対処はわからない。
インストールガイドに書かれてる方法で、必要な全てのCGIをmod_perl化すれば良いかも知れないが、そうするとテンプレートに書いている全てのCGIへのリンクをmod_perlのものに書き換えないといけなくなるので大変だ。
という訳で、上記(d)の設定を加えて、$CGIPATHと$AdminScriptとを繋げたURLについても/mt/appと同じ動作をするようにした。もしかして、インストールガイドの<Location /mt/app>は、CGIPATHのホスト名より下の部分を付け加えたものとして読めということだろうか。

●検索機能(mt-search.cgi)のmod_perl化
インストールガイドには、同様の方法でMovableTypeのどのCGIもmod_perl化できると書かれており、このサーバーではmt-search.cgiが非常に遅く、サイト内の検索に1分くらいかかっていたので、これをmod_perl化することにした。

httpd.confに追加する必要があるのは、PerlModuleの行と、それに続く<Location>のブロックだ。インストールガイドでMT::App::CMSとなっている部分(アプリ起動メソッド)を何にすべきかは、mt-search.cgiの中身を見ればわかる。

use MT::Bootstrap App => 'MT::App::Search';

とあるので、MT::App::Searchだ。従って、

PerlModule MT::App::Search
<Location /mt/search>
SetHandler perl-script
PerlHandler MT::App::Search
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
</Location>

というのをhttpd.confの末尾に追加し、httpdを再起動した。
それから、MovableTypeの検索機能のURLがhttp://hostname/mt/searchに変わったので、テンプレート内のmt-search.cgiの部分を書き換えて、ページを再構築した。
以上の手順で、検索機能をmod_perlで起動することができるようになった。

ただ、httpd起動直後は、なぜか検索を実行するとノータイムでエラーとなってしまい、何回か検索を実行しないと初回の検索がなされない。httpdのログに何も出ないし、ブラウザの画面には「エラーが発生しました」とだけ出るので、何が悪いのかさっぱり分からない。

ついでに、テンプレートを全て書き換えるのが大変なので、httpd.confの上記の<Location>ブロックの直後に


<Location /cgi-bin/mt/mt-search.cgi>
SetHandler perl-script
PerlHandler MT::App::Search
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
</Location>

を加えてみた所、自信は無いが、とりあえず以前のCGI起動のURLでもmod_perl起動するようになった。

●その他の設定
mod_perlでPerlを常駐化すると、httpdの子プロセスのそれぞれにPerlが常駐することがわかった。
MovableType常駐後は子httpd1つ当たり約30Mものメモリを占有してしまう。swapと合わせてもメモリが192Mしかないこのサーバーでは空きメモリがあっという間に無くなってしまったので、子httpdの数、すなわちhttpd.confのMaxClientの数を減らした。

See more ...

WriteBacks

Oct 13, 2007

MovableType3.35をmod_perlで動かす(1/2)

今週、某サイトのApacheの記事を読んでいて、mod_proxyというモジュールに興味を惹かれてApacheのマニュアルやhttpd.confを眺めてると、mod_perlという単語が目に止まった。この単語は私にはかなり昔から見覚えがあって、何だろうこれは、とずっと気になっていたので、少し調べてみると、どうやらApacheのモジュールで、Perlのプロセスを常駐させてCGIを速く動かせるもののようだった。(あくまでmod_perlの利点の1つで、mod_perlの役割はそれだけではない)

ということは、CGIとJavaのServletを比べた場合にServletの利点とされる、HTTPサーバーの一部として動くことによる効率の良さが、Perlでも実現できるということだ。(PHPを使ってる人は何を今更と言うかも知れないが)

このサーバー(CPU: Pentium 150MHz, OS: FreeBSD 4.11)では、これまでMovableTypeが遅く、管理画面でサーバーにアクセスする度に14秒以上かかっており、何かいい方法が無いものかと思っていたので、MovableTypeをmod_perlで動かせないかと思い、Webで調べてみると、Six ApartのMovableType3.2のマニュアルにやり方が書いてあった。

今日、早速それに従って試してみた。
上記のマニュアルには、MovableTypeをmod_perlで動かす方法として、Apache::Registryを使う方法と、MovableType自体をPerlHandlerとする方法の2つが書いてあり、前者の方が手軽にできそうだったので、まずApache::Registryを使う方法を試そうとした。
結論としては、この方法はうまくいかなかった。

●mod_perlのインストール
MovableType3.2のマニュアルによると、MovableTypeを動かすにはmod_perlのバージョンが1.xでないといけないので、今回はFreeBSDのportsを使ってバージョン1.3をインストールした。mod_perl 1.xを使うにはApacheは1.xである必要があるが、元々1.3を使っていたので問題なかった。
mod_perlの動作確認は、mod_perlのページに従って、以下のような設定をhttpd.confの末尾に追加して試した。
(インデントは省略)

Alias /perl/ /…/cgi-bin/

PerlModule Apache::Registry
<Location /perl/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
Allow from all
</Location>


httpd.confを書き換えて、httpdを再起動して、ローカルで既存の簡単なPerlのCGIにhttp://localhost/perl/….cgiというURLでアクセスすると、CGIとして動作させた場合と同じ出力が得られた。なお、あらゆるPerl CGIがそのまま動くわけではないので注意が必要だ。

●Apache::Request, Apache::Cookieのインストール
MovableType3.2のマニュアルによると、mod_proxy(Apache::Registry)を使ってMovableTypeを動かすには、PerlモジュールのApache::RequestとApache::Cookieが必要だ。
Perlモジュールのインストールは、CPANのシェルを使って、下記の要領でできる。

> perl -MCPAN -e shell
cpan[1]> install Apache::Request Apache::Cookie

cpanコマンドが存在する場合は、下記のようにしてもできる。
cpan -i Apache::Request Apache::Cookie

CPANによるインストールには、このサーバーではRAMの空きが60M~70M程度必要だった。メモリ不足になると、メモリ不足だとわかるメッセージを出さずに、"Killed."とだけ出て終了してしまう。

なお、root権限で、作業ディレクトリをroot権限でしかアクセスできない場所(/rootとか)にして、CPANを使ってApache::Requestをインストールしようとすると、途中のmake testの時に

[ error] You are running the test suite under user 'root'.

The problem is that the path (including all parent directories):
/root/.cpan/build/libapreq-1.33/t
must be 'rwx' by user 'nobody', so Apache can read and write under that path.

というエラーが出る。しかし、
Skip the test suite? [No]

と尋ねられた時に"Yes"と答えれば、インストールは続行できる。今回は、インストールした後に、作業ディレクトリを/usrに移して、make testだけ手動で起動して全てOKとなることを確認した。
やはりコンパイルまではユーザー権限で行って、インストールだけをrootで行うべきだった。一般論としても、その方がインストール準備まででトラブルが発生してもシステムに影響が無いようにできるので、rootでのコンパイルは避けるべきである。

●mod_perlの設定(Apache::Registry)
MovableType3.2のマニュアルに従い、httpd.confの末尾に

PerlModule Apache::Registry
<Location /cgi-bin/mt/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>

を追加して、httpdを再起動してブラウザからhttp://…/cgi-bin/mt/mt.cgiにアクセスすると、MovableTypeのログイン画面は表示されたが、ログインすると、ページが見つからないというエラーになり、その後はログイン画面も表示されなくなった。
Perlのプロセスは新規に立ち上がることは無く、httpdのプロセスにPerlが常駐しているらしいことが確認でき、他のPerlスクリプトはmod_perl経由で正常に実行できたので、常駐してるMovableTypeがおかしな状態になったようだった。
CGIの設定と不整合を起こしてるのかと思い、httpd.confの設定を

Alias /perl/ /…/perl/ # out of cgi-bin directory

PerlModule Apache::Registry
<Location /perl/mt/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>


という風にして、MovableTypeをApacheのcgi-binディレクトリ以外の所に移して試したが、動作は変わらなかった。

See more ...

WriteBacks

Oct 08, 2007

MovableType3.35インストール

何ヶ月か前から、このweblogのトップページに表示される最近のエントリーの末尾の「コメント (*)」「トラックバック (*)」というリンクがおかしくなっており、辿っても何も表示されなくなっていたが、原因がわからなかった。おそらくコメントデータの不整合だろう、Berkeley DBからMySQLに移行すれば直るかも知れないと思って、少し前にSix Apartのサイトのマニュアルを参考にしてMySQLデータベースへの変換を試みたが、日本語が文字化けしてしまった。これも原因がわからなかった。

同じバージョンであるMovableType3.33と全く同じBerkeley DBのデータを用いて、予備の環境でMySQLデータベースへの変換を行うと、文字化けしなかったので、問題は本環境のMySQLにあると思い、MySQLのcharset周りを調べて色々試したが、解決しなかった。本環境と予備環境の違いは、FreeBSDのバージョンの違い(4.11/5.5)とMySQLのバージョンの違い(5.0/5.1)と、いくつかのPerlモジュールのバージョンの違いしか無い。

今日、これまでの調査結果を踏まえて再度調べていると、MySQLに移行して文字化けしたデータでもサイトの再構築はでき、「コメント」「トラックバック」のリンクの問題は全く解決しないことに気付いた。これはMovableTypeを4.xにバージョンアップするしかないか、と思ったが、4.xにバージョンアップして直らなかったら立ち直れないと思い、3.xのままでまともに解析することにした。

どうせ4.xにするとテンプレート総入れ替えになるだろうから、と思って、試しにテンプレートを3.xのデフォルトのものに戻すと、エントリー毎のコメントやトラックバックへのリンクが正常に動作した。そのことから突き詰めると、結局、この環境では、テンプレート内の<$MTCommentScript$>(mt-comments.cgiに置換される)、<$MTTrackbackScript$>(mt-tb.cgiに置換される)は無効であるらしいことがわかった。MovableType3.17の頃は問題なく使えていたのだが。
代わりに"<$MTEntryPermalink$>#comments" "<$MTEntryPermalink$>#trackback"を使うことで、リンクの問題は解決した。

文字化けの問題はもっと単純で、Six Apartのニュースによると、MovableType3.34から3.35の変更点として

convert-dbおよびmt-db2sql.cgiで別のデータベースに移行すると移行先のデータが文字化けする可能性がありました。この不具合を修正しました。

と書かれており、それで解決することを信じてMovableTypeを3.33から3.35へバージョンアップすると、文字化けせずにSQLデータベースへの移行ができてしまった。

ついでに、以前のエントリーのコメントに書いた、エントリー投稿時にエラーが発生することについても修正されていることを確認した。

See more ...

WriteBacks