前言撤回日記

MT3@localhost(前編)

phpMyAdmin経由でのバックアップに挫折したのでMovable Typeをインストールしてバックアップ用のサイトをローカルに構築する事にした。その方がテンプレートの編集やプラグインのテストも手元でできて都合がいいだろう。
ちなみにOSはMacOS X 10.4.7 Tiger、DBはmySQL。

まずはMovable Type3.33の個人ライセンス版をECバイヤーズからダウンロード。

ワーキングディレクトリに展開してフォルダ名をmtへリネーム。
以下のサイト構成で、かつCGIが使えるようにシンボリックリンクも作成してあると仮定する。

サイトルート

├―hogehoge
  |
  ├―blog
  |
  ├―cgi-bin

まずmtフォルダを~ユーザ名/hogehoge/cgi-bin/に置き、さらにその中のmt-staticフォルダを外に出して、~ユーザ名/hogehoge/blog/に置く。
それぞれパーミッションを777に。

~ユーザ名/hogehoge/cgi-bin/mt/mt-config.cgi-originalを~ユーザ名/hogehoge/cgi-bin/mt/mt-config.cgiにリネームして編集。

CGIPath http://www.example.com/path/to/mt/



CGIPath http://127.0.0.1/~ユーザ名/hogehoge/cgi-bin/mt



StaticWebPath http://www.example.com/mt-static

StaticWebPath http://127.0.0.1/~ユーザ名/hogehoge/blog/mt-static

Database DATABASE_NAME

Database ブログで使用するDB名

DBUser DATABASE_USERNAME

DBUser ブログで使うDBのユーザー名

DBPassword DATABASE_PASSWORD

DBPassword ブログで使うDBユーザのパスワード


さらにその他の各DB用の設定をコメントアウトする。

ブラウザからhttp://127.0.0.1/~ユーザ名/hogehoge/cgi-bin/mt/mt-upgrade.cgiを実行。

さらにhttp://127.0.0.1/~ユーザ名/hogehoge/cgi-bin/mt/にアクセスして初期画面からmt-check.cgiを実行する。

Movable Typeのシステム・チェックは、無事に完了しました。

と出るので初期画面からログインしようとするもエラー。

Can’t locate DBI/DBD.pm in @INC

とか言っている。
再度システムチェック画面を見ると、どうやらDBIモジュールとDBD::mysqlモジュールがインストールされていないという事のようだ。

060930error02.jpg
というワケでCPANからのモジュールインストール初体験。
しかし案の定ここでもドハマりした。面倒くさいので手順のみメモっておく。

まずデフォルトのOSXにはmakeコマンドがない(!)。makeコマンドを追加するためにはWebObjectsをインストールする必要があるのだが、WebObjectsをインストールするためにはその前にXcodeToolsをインストールしなくてはならない(ややこしい)。
なのでまずAppleのサイトからXcodeToolsをダウンロードし、同梱されているmpkgをXcodeTools.mpkg、WebObjects.mpkgの順でインストールする。

その後ターミナルからsudo suでルートになり、

# perl -MCPAN -e shell

と打ち込んでリターン。
初期設定の項目がズラズラ出て来るが基本的にはリターンキーを押し続ければいい。
CPANサーバの選択の時は適当なサーバを選択して先頭の数字をタイプし、リターン。
プロンプトが「cpan> 」に変わったら準備完了。
まず、

cpan> install DBI

とタイプ。
インストールログがダラダラ出たあと大概エラーになるので
qとタイプしてリターンでcpanから抜け、

# cd ~/.cpan/build/DBI-1.52/

でcpanディレクトリのダウンロードフォルダ内にあるDBI-1.52(今さっきダウンロードしたフォルダ)へ降りて

# perl Makefile.PL

とタイプ。またもやダラダラとログが表示されるがプロンプトが出てくるまでボンヤリ待つ。

その後

# make
# make test
# make install

の順でコマンドを実行する。
成功したら(失敗したらやりなおそう)今度はDBD::mysqlモジュールのインストール。

# cpan

でcpanに入り、

cpan> install DBD::mysql

どうせ失敗するので先ほどと同じように

# cd ~/.cpan/build/DBD-mysql-3.0007/
# perl Makefile.PL
# make
# make test
# make install

の順で実行する。エラーが出たら日頃の行いを悔い改め、再ダウンロードしてやり直す。

成功したらmt-check.cgiを実行。

DBI (version >= 1.21)
サーバーには、DBIがインストールされています。(バージョン: 1.52)

DBD::mysql
サーバーには、DBD::mysqlがインストールされています。(バージョン: 3.0007)

となっていれば無事Movable Typeが起動できるハズ。
060930error03.jpg
ところがそれで終わりじゃないんである。
以下次回。

phpMyAdmin

修理に出したG4が帰ってきた。修理費は一律で51,450円らしい。で、前回せっかく立てたwebサーバとmySQLサーバもすべて初期化してしまったので再度設定。

ついでに普段作業しているワーキングディレクトリでもCGIが動作するようにシンボリックリンクを作っておく。
/etc/httpd/users/ユーザー名.confを編集。

Options Indexes MultiViews ExecCGI Includes

Options Indexes MultiViews ExecCGI Includes FollowSymLinks


ターミナルから

$ ls -l ワーキングディレクトリへのパス サイトルートへのパス

以上で完了。

その後このblogのデータをローカルのデータベースにバックアップする事にした。
まずレンタルサーバで用意されているphpMyAdminを使ってファイルをエクスポート。

で、インポートするのにローカルにも同じ環境があった方がよかろうとphpMyAdminをインストール。
サイトルートに展開してフォルダネームをphpMyAdminにリネームする。
まあ、そのままじゃ動きっこないよな、と思いながらブラウザでアクセスすると、案の定エラー。期待を裏切らない。

060930error01.jpg
セットアップスクリプトとやらでウダウダやるも、ちっともうまく行かない。
とりあえずmySQLが動作している事は確認。さらにphpMyAdminディレクトリにphpinfo.phpを放り込み、パスが通っている事もPHPが正常に動作している事も確認。

そこでまずドキュメントに従ってphpMyAdminディレクトリ直下のconfig.sample.inc.phpをconfig.inc.phpにリネーム。

このconfig.inc.phpを以下のように編集。

$cfg['blowfish_secret'] = ”

$cfg['blowfish_secret'] = ‘半角英数モードでキーボードを適当に(48回以内で)タイプ’


$cfg['Servers'][$i]['controluser'] = ‘pmausr’;


$cfg['Servers'][$i]['controluser'] = ‘自分で決めたユーザーネーム’;

$cfg['Servers'][$i]['controlpass'] = ‘pmapass’;

$cfg['Servers'][$i]['controlpass'] = ‘自分で決めたパスワード’;


まだ動かないのでさらに調べてみると、どうやらlocalhostではなく127.0.0.1でアクセスする必要があるらしい。
なので続けてconfig.inc.phpを

$cfg['Servers'][$i]['host'] = ‘localhost’;

$cfg['Servers'][$i]['host'] = ’127.0.0.1′;

に書き換えた。

再度アクセスすると今度はベーシック認証のポップアップでパスワードを聞かれる。
ユーザ名とパスワードを入力。
エラー。メッセージは#2002以降、文字化けしていて不明。
でもエラーナンバーは最初に出たヤツと同じだから事態は好転してはいないようだ。

で、あれこれ調べた結果、phpのMYSQL_SOCKETのパスがmySQLのsocketのパスと食い違っているのが原因だった。

ターミナルから

sudo su

でrootになり

# /usr/local/mysql/bin/mysql -p

してMySql monitorに入る。

mysql>status;

で調べると

UNIX socket: /tmp/mysql.sock

となっている。

一方、phpinfo()でMYSQL_SOCKETを確認すると

/var/mysql/mysql.sock

となっていた。

というワケで/ect/php.iniを編集。
661行目を

mysql.default_socket =

mysql.default_socket =/tmp/mysql.sock

に編集し、apacheを再起動。phpinfo()でmysql.default_socketの項目を見るとno valueから/tmp/mysql.sockに変更されている。

これでようやくphpMyAdminのインストールが完了した。

……のだが、肝心のバックアップデータがインポートできない。
新規のデータベースも作れるし、特権も設定できるのに、何度トライしてもテーブルは0のままだ。
仕方がないのでローカルにMovable Typeをインストールして、そこから読み込む事にした(心地よい徒労感)。

作業環境報告

注文していた変換コネクタが来たので、雨の中ノジマ小平店へ。
ココの店員さんが親身になっていろいろ調べてくれたおかげでかなり助かった。家電量販店じゃこうはいかない。

というワケでようやくCinema HD DisplayとMacBookがつながった。
ディスプレイ←→ADC-DVI←→DVI-miniDVI←→ノート、というメンドくさい構成。

キーボードとマウスも普段使っているヤツをつないだので、とりあえず単純にハードが置き換わっただけ、というカタチにはなった。ことえりにも少し慣れてきたし、多少はストレスが減ったカンジ。

アプリケーションの切り替えがモタつく現象だが、どうもUB対応がどうとかではなくメモリ不足が原因の予感。

現在、プリセットの512MBなのだけれども、店員さんに、これに積んであるタイプのメモリはまだ高い、もう少し待てばグッと下がりますよ、というアドバイスを受けたので買い控えたのだ。
まったくショップ店員の風上にも置けないが、風下に置いたらバチが当たりそうないい人である。
メモリを追加するときはぜひまたここで買います。

G4は今日、引き取りに来る予定。
パーツがあれば一週間から十日で修理は終わるとのこと。つまりしばらくはこの環境での作業が続くのである。
先は長いなあ。

ストレスフル

すんごいストレスです。インテルMac。

使ってるソフトも動く事は動くんだけど、ユニバーサルバイナリ対応じゃないヤツばっかりだからか、二昔前のPower Macで作業してるみたいに遅い。
アプリケーションを切り替えるだけで1分くらい待たされる。

原稿を確認するのに一分、それをみてデザイン修正するために一分、テキストをコピーするために一分、ペーストするのに一分、メールを見るのに一分、といった具合。
普段の半分以下の作業効率だ。

サファリの文字化けも僕のG4固有の問題なのかなあ、とうっすら思っていたのだが、新しい環境でもガンガン化ける。

ATOKのダウンロード版を買おうとジャストシステムの販売サイトに行ったのだが、ユーザーIDだのキーワードだのいろいろ聞かれてメンドくさい事この上ない。しかもキーワード入力しても受け付けてくれないし。
かったるくなったので購入をあきらめ、ことえりの辞書を鍛えまくって使う事にした。
ことえりもだいぶ賢くはなったものの普段使ってるATOKとキー操作が違うためにここでも微妙にストレスを感じる。

こりゃ早くG4修理に出さないとヤバいっす……。

book

なんつーかITバイオリズム低下中。

ちょっと前のWinノートに引き続き、メインマシンのG4が壊れた。
システム云々ではなく、そもそも基盤に通電していないので手の施しようがない。
これでは仕事にならないということで、仕方なく(いちばんショボい)MacBookを買ってきた。ユニバーサルバイナリ対応のソフトなんてひとつも持ってないのに。

まあ、サブの作業環境は必要だとは思っていたのでそれはいいのだけれども、僕の持っている古いCinema HD Displayにダイレクトに繋げないので、注文した変換コネクタが来るまではこのノートの液晶モニタで作業しなくてはならない。
セットアップに半日かかって今日はけっきょく仕事にならなかったのだが、明日からしばらくモニタが狭くてしんどそう。

それにしてももう少し早く、つまりはG4がイカれる前にコイツを買っていれば再設定とかも少しは楽だったろうになあ。

足踏みSQL

さて仕事も少し詰まってきたものの、しばしそれらをうっちゃったままサーバ関連をいじくっていた。
まずはDBで遊ぼうと思ってmySQLをインストール。
これは公式サイトからパッケージをダウンロードしてダブルクリックするだけだったのでめちゃくちゃ簡単。おそらくMac OSX版が一番簡単なのではないだろうか。起動や停止もMySQL.prefPaneを使えばシステム環境設定パネルから行える。

そのあとがハマった。

PHP本の巻末に載っていたmySQLのインストール手順を見ながらrootのパスワードを設定し、anonymousユーザーを削除した。

mysql> SELECT Host,User,Password FROM mysql.user;

とすると、Userはrootのみになり、先ほど設定したパスワードが表示されている。
よしよし、今日はこれぐらいにしておこう。

翌日、さてテスト用のDBでもCREATEするか、と思ったらmysqlにアクセスできない。前日に設定したパスワードを間違いなく入力しているのにである。

$ /usr/local/mysql/bin/mysql
ERROR 1045 (28000): Access denied for user ‘kohashijunji’@'localhost’ (using password: NO)

$ /usr/local/mysql/bin/mysql -p
Enter password:
ERROR 1045 (28000): Access denied for user ‘kohashijunji’@'localhost’ (using password: YES)

$ /usr/local/mysql/bin/mysql -u root
ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: NO)

$ /usr/local/mysql/bin/mysql -u root -p
Enter password:
ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: YES)

と言った具合。
suしてroot権限で実行しても結果は同じ。ことごとくアクセス拒否される。
さんざん悩んで、とりあえずパスワードを確認する事にした。
mySQLは起動時に–skip-grant-tablesオプションを指定するとユーザー確認用のデータを読み込まずに起動できる。
一旦mySQLを終了してからターミナルで

$ /usr/local/mysql/bin/mysqld_safe –skip-grant-tables

と打ち込んで起動する。
新規シェルを開いて

$ /usr/local/mysql/bin/mysql

でmySQLに無事アクセス。
前日のようにmysql> SELECTするとやはりrootユーザーと昨日設定したパスワードが表示される。でもアクセスはできない。さっぱり判らん。

再度あきらめてさらに翌日。ハタと思いついてMySQLのリファレンスに沿ってパスワードを再設定したところ、今度はちゃんとrootでアクセスできるようになった。
つまり、本に書かれていたパスワード設定のコマンドが間違っているようなのだ。
mySQLは設定されたパスワードを符号化してから入力されたものと比較する(あるいは入力された物を暗号化してから比較するのかも)。
本の解説ではrootのパスワード設定は

mysql> UPDATE mysql.user SET Password=’abcd’ WHERE User=’root’;
mysql> FLUSH PRIVILEGES;

となっている。だがそれではパスワードは暗号化されないのだ。暗号化されていないパスワードをさらに符号化して入力と比較しても当然一致するはずがない。
正しくは

mysql> UPDATE mysql.user SET Password=PASSWORD(‘abcd’) WHERE User=’root’;
mysql> FLUSH PRIVILEGES;

なんである。

こうした後でmysql> SELECTすると今度は暗号化されたパスワードが表示された。

ひとまずはメデタシであるが、仕事が詰まってきていまだにテスト用DBは構築できていない。すなわちスタートラインから一歩も進んでいない状態。
まるで免許を取ったのにずっと駐車場の中でエンジンをかけたり切ったりブレーキ踏んでみたりしているようだ。
はやく公道に出るところまで行ってみたいです。

宗旨替え

この間までこのカテゴリーではPerlでウニウニやってみようかと思ってたんだけど、やっぱまずPHPからイジる事にする。
理由はカンタンそうだから。

あれだけ単純なファイル構成の「YukiWikiMini」でさえセッティングにえらく手間取ったので、より高機能な「PukiWiki」にいたっては相当ハマるに違いない、と思ったら拍子抜けするほどあっさり動いた。
単に初期設定ファイルに管理パスワードを書き込み、サーバに放り込んだら添付されているテキストの指示にしたがってディレクトリのパーミッションを設定していくだけ。
いじってるうちに2回くらいエラーが出たがそこに書かれているファイルのパーミッションを変更したら完了。

で、「YukiWikiMini」はPerl、「PukiWiki」はPHPで書かれていたんですな。
俄然PHPに興味がわいたので初心者向けPHP解説サイトをのぞき、サンプルコードをいくつも試したところ何一つ手こずる事がなかったという。

前回どハマりしたおかげで作業に慣れたせいもあるけど、なにせパスを通す必要すらないというのがいい。phpinfo.phpも何もしなくても動いたし、クソいまいましいInternal Server Errorを見なくて済むのもうれしい。

では何をするかというと具体的にはまだ決まってないのだが、とりあえずデータ送受信とDBとのやり取りを、サンプルコードの切り貼りでどこまでできるか試してみようかと思う。
って結局コード書かないのかよ、というハナシなのだが、僕がおもしろそうだな、と思うようなことは大抵、たとえばDBとやり取りした「先」にあるのだ。ところが僕のような単なるデザイナー風情にはそのDBとのやり取り、という所までの敷居がとんでもなく高い。プログラマーにはなんてことない作業がじつにシンドイ苦行なんである。
そんな面白くも何ともない所で足踏みしていたらやる気なくなっちゃいます。

あと、既存の物を組み合わせるだけでけっこう色んな事できちゃいそうな気がする、というのもある。

というワケでさっそくPHPサンプルコードの本とMySQLの本を一冊づつ買ってきた。さーて遊ぶぞー。

続 たがや

060902fireworks01.jpg
060902fireworks02.jpg
060902fireworks03.jpg
今回はノートリミング。
前回の反省点を踏まえて撮った……つもりが、なかなか一筋縄ではいかない。

望遠だとピントがけっこうシビアで、最後の何枚かは完全にピンボケだった。決まった位置で発火するわけではないので構図も難しい。
バルブで撮るのはわりといいカンジ。レンズキャップは使わず手のひらで遮光する方が柔軟に撮影できる。

あとはやはり撮影に気を取られると花火自体をあまり楽しめなくなる。これが意外にもったいない。
見事な花火なのに撮影がまずかったりすると、チッ、とか思ったりしてもうなんだか判らない。これでは花火師に失礼ではないか。

最近「プロフェッショナル 仕事の流儀」という番組で花火師の野村陽一さんの特集を観たばかりなので余計にそう思う。なにせ一発の花火ができあがるためには何ヶ月もの時間を要するのだ。
ちゃんと襟を正して鑑賞せえよ、と自分に言いたい。

ウルトラ

060901ultra01.jpg
060901ultra02.jpg
池袋でやっているウルトラマンフェスティバル2006に行ってきた。現在放映中の番組を中心としたアトラクションなどの他にウルトラQ、ウルトラマン、ウルトラセブンで当時使用された小道具や、そのレプリカなどの展示もあり、大人も楽しめる内容。展示物の図録も売ってくれればいいのになあ。
ま、こういうのはあくまで子供のための物であるべき、とは思うんだけどね。

写真は番組中で実際に使われていたウルトラ警備隊アンヌ隊員の制服。
科特隊の制服もあった。けっこうテロテロした素材感。科特隊の方は特に。
言ってしまえばヴィンテージだから当然といえば当然か。

Copyright © 2004 elbro.net