PC総合研究所

PHPでメールを送るのには大変苦労していたけど、pearのMail.phpモジュールを使うことでなんとか形になっていた。はずなんだけど、最近になってメールが送られない不具合が発生！

新しいサーバになってから、perl系のメールは確認したけどPHPは。。。 もしかしたら、モジュール毎にインストールが必要だったり。。。 ログを確認したら、Mail.phpがない、と。Pathは/usr/share/php, /usr/share/pearだっていうけど、どちらのディレクトリもない。どうもMail.phpはphp-mailにあるらしい。php-mail-mimeも関連しそうだからこれらをsynapticでインストールするとついでにphp5-cliとphp-pearもインストールされる。

しかし、それでもメールは送られない。またログを見ると、今度はphp-net-smtpがない、と。じゃ、synapticでいれましょ（いいのか、こんな行き当たりばったりで。。。）。php-net-smtpとついでにlibphp-phpmailerにも関係ありそうなのでチェック（いいのか、こんないいかげんなことで。。。）。すると、php-net-socketもついでにインストールされ無事にメール送信成功。

引き続きWordpress MUプラグイン関連。というか、ここしばらくはこの話題中心になりそう。

plugins-muディレクトリに入れるプラグインファイルの最後を改行で終わらせるとログアウトページでエラーが大量に吐き出されます。最後は?>［改行］で終わらせると問題ない。これで30分くらい悩んだ。

Wordpress MUには二つのプラグインがある。mu-pluginsとplugins。mu-pluginsはすべてのブログに対して無条件に有効になるのに対して、pluginsでは普通のWordpress同様にブログ管理者が任意に有効／無効を切り替えることができる。

で、pluginsのほうはWordpressでも馴染み深いが、mu-pluginsはドキュメントがあまりない。フォーラムでの投稿を読み漁るとどうもmu-pluginsにディレクトリ毎放り込む形のプラグインは動かないとのこと。確かに見よう見まねでWordpress流のプラグインディレクトリをmu-pluginsに作って、中に極シンプルなプラグインを入れても動かない。mu-pluginsフォルダ直下に移動させると動く。

Wordpress MU用プラグインはファイル名を統一するか、代表となるファイル一つと残りのファイルをディレクトリに入れるかのどちらかになるのかな？ これはどうやら実際に試してみないといけないな。mu-plugins直下にファイルがワサワサあるのは好きじゃないけど、代表ファイル＋ディレクトリはWordpressの流儀ではないし。。。

ホストOSがUbuntu 8.04.1 LTS Server x64であるVMware Server 2.0にて、ゲストOSにWinXPのVMとUbuntu 8.04.1 LTS Desktop x64のVMが作成されている。

WinXPのVMを起動させておくとホストOSのCPU周波数が1GHzになることはあまりないんだけど、UbuntuのVMでは放っておけば大体1GHzに落ち着く。VMにのせるゲストOSによってホストの負荷が変わるんだ。まあ、Windowsは元々ハードウェアリソースには厳しいからね。

もちろん、Microsoft Wireless Intellimouse Explorer 3.0なんてないです。でも、Microsoft Intellimouse Explorer 3.0（MIE3）はMicrosoft Natural Wireless Laser Mouse（MNWLM）と並んでお気に入りです。しかも、MIE3復刻版ではなくオリジナル！（どこもエラくないけど）

MIE3は握りやすく、クリック感がよく、ホイールもクリックするし、追従性もいい。けど、唯一の弱点が有線であること。有線だから電池がなくて軽いとか、ポインタの追従性（”つながってる”感）がいいんだけど、なんともUSBケーブルが硬くて重い。どこにも引っ掛からなければまだいいんだけど、キーボードの角なんかにぶつけがちだし、大きく移動するときにケーブルの存在感がでてしまう。

まあ、それはそうと、最近ホイールの滑りが悪くなってきたのでお掃除をすることにした。それと同時にUSBケーブルも極細のものに交換してしまおうと。。。 ちょうど先人がUSBマウスケーブルの交換にきれいにまとめてあったので参考にした。

まずは分解。硬質ゴムパッチが接着されているので、細いマイナスドライバーで引っ剥がす。すると４ヶ所ともネジがみえるので、それをはずす。

中はいたって質素で、ホイールもすぐ外れる。ホイールのゴムの部分が劣化して油脂がベットリだったので食器洗剤とスポンジでゴシゴシと洗う。あと、殻側のホイール穴にも埃が溜まっていたのでここもゴシゴシお掃除する。これだけで完璧にホイールは復活したんだけど、どうもホイール本体と穴のクリアランスがなくすぐ詰まりそうなので、穴を少しだけヤスリ掛けして広げた。う～む、これでホイールは完全復活！ 新品より調子よくってホイールをクリクリするのが癖になりそう。

さて、お次はUSBケーブルの交換。極細USBケーブルはGreen Houseのものを安くゲットでき、巻き取り機構はいらないから撤去。

さらに、きれいに仕上げようと思ってケーブルとマウス本体をつなぐコネクタを買ってきた。これを極細ケーブルと接続できたら。。。

結線はお手の物、と思ったら大間違い。参考にしたサイトにもあるけど、ポリイミド樹脂コーティングされた極細銅線はまず半田ごてでコーティングを溶かして、コネクタピンを圧着するわけだけど。。。 これが細くてもろくてすぐ切れちゃう。圧着する際にピンの金具がハサミのようにもろい銅線を切ってしまうのである。ピンを鉄線に圧着してこれに半田付けすれば。。。 って手段はあったけど夜も遅く、そんなに汎用性持たせてどうする、ということで本体のコネクタ部分に直接半田付け。。。 あとはホットボンドで線を数ヶ所固定すれば完了。

で、生まれ変わったMIE3はほぼワイヤレス！（笑） ケーブルを意識することは皆無になり、マウス本体も軽いのでと～っても使ってて気持ちいい。すぐそばにMNWLMがあるけど、重いし追従性が劣るし、クリック感もホイールのヌルヌル感も嫌いじゃないけどいまいち。

これでMIE3改がほぼ完璧なマウスとなった！ あとはMNWLMのような形状になっていたら言うことなしなんだけど。あれ？ もしかしたらMIE3の内部をMNWLMに移植するといいのかも？？？

実はWordpress MUをインストールするだけならそんなに大したことはない。フォーラムを見ているとホスティングサーバにインストールするのにてこずっているケースはちらほらあるけど。

けど、いざブログを作ろうと思うと作れない。いや、作成に成功したようなページが表示されるし、設定自体は正常に保存されている。実はブラウザに表示されないだけなのである。かなりふかくはまったのが.htaccessを有効にさせるところ。Wordpress MUは、Sub-directoryでもSub-domainでも同じだと思うけど、Apacheのmod_rewriteと.htaccessによって仮想的に複数のブログが存在するかのように振舞う。で、.htaccessが利用できるようApacheに設定が必要なのだった。それがDirectoryのAllowOverrideで、これはデフォルトではNoneになっている。これはようするに、.htaccessによる設定を無効にする働きがある。これを面倒なのでAllにした。

たとえば、/etc/apache2/sites-available/defaultで、DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory />

<Directory /var/www>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory />などと設定する。

これで小一時間悩んでしまった。。。

あと、これはreadme.txtにも書いてあるけど見逃しがちなのがインストールディレクトリの注意。http://user.blog.domain.comやhttp://hoge.domain.com/blog/userとしてアクセスできるようにインストールするにはダウンロードして展開したディレクトリ wordpress-mu-2.6.3 を blog にリネームしないといけないということ。

今は無事ブログもユーザも問題なく作れて、普通のWordpressのテーマを適用させて、これからプラグインを試してみようとしているところ。。。

Wordpress.comのようなマルチユーザのサイトを作ってみたいな。。。 と思ってググるとWordpress MUなるものがあるそうな。Wordpressは1.x時代から使ってるけど、真剣に調べたのは初めてだったりする。

Wordpress.comはAkismetのAPIキーをゲットするために登録して少し使ったことがあるけど、なかなかいい。Wordpress MUを使っているとのことだから、これは試してみないといけませんね。

テスト用にVMを用意して、ゲストOSはUbuntu 8.04.1 LTS Server x64を入れてある。tar.gz版を /home/user/puglic_html にダウンロードして、解凍する。そうすると wordpress-mu-2.6.3 というディレクトリができるので、wordpress-muとリネームしてどうせテスト環境なので http://127.0.0.1/wordpress-mu としてアクセスすることにする。ちなみに、http://localhost/wordpress-muでアクセスするとlocalhostではインストールできないと怒られる。なぜだろ。。。

http://127.0.0.1/wordpress-muにアクセスするといろいろと指示が英語で書かれているんだけど、ようするに

• 空のデータベースを作ってね
• /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentのアクセス権を 777 にしてね
• Apacheのmod_rewriteが有効にしてね

ということを言っている。

順に作業すると、ます空のデータベースは、
$ mysql -u user -p
パスワードを入力
> create database wordpress_mu;
> quitで作る。ちなみに、データベース名に “-” は使えないらしい。アクセス権は$ chmod 777 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentを実行すればＯＫ。Apacheのモジュール有効化は$ sudo a2enmod rewriteのコマンドを実行する。

ちなみに、Wordpress MUの複数のブログをサブドメイン別（blog1.domain.com, blog2.domain.com …）にするのか、サブディレクトリ別（www.domain.com/blog1, www.domain.com/blog2 …）にするのか決める必要がある。サブドメイン別にするとDNSの設定とか必要だから、面倒だからサブディレクトリ別にする。フォーラムによるとサブドメイン型が推奨されているけど。。。

そのあと再び http://127.0.0.1/wordpress-mu にアクセスするとSub-domains/Sub-directories, Database Name, User Name, Password, Database Host, Server Address, Site Title, Emailを聞かれるので正しく設定するとadminのパスワードとログインページへのボタンが表示される。あと、アクセス権は755に戻してとも言われる。$ chmod 755 /home/user/public_html/wordpress-mu /home/user/public_html/wordpress-mu/wp-contentとアクセス権を元に戻す。

パスワードをコピーしてボタンを押すと、見慣れたwordpressログインページが現れる。すべて英語でメニュー構成もwordpressとちょっと違う。まずはusersのadminのパスワードを変更しよう。

次に、日本語化を行おう。ここはwpmu-jaに2.6.2用の日本語化情報および言語ファイルがあるので、書いてあるままに作業する。ちなみに、日本語を選択する箇所は２つあって、settingsのlanguageとsite admin→optionのlanguage。あと、日付のフォーマットも「Y/n/j l」に変更。これは普通のWordpressと同じ。

この後はテストサイト／ユーザの作成、プラグインの導入とテーマの設定かな。とりあえず、今回はここまで。

VMware Server 2.0のゲストOSであるWinXPにおいて音楽を再生していると途中に途切れることがあることについて前に書いたけど、あれからちょろちょろと調べてみた。

ホストOSであるUbuntu 8.04.1 LTS Serverのサウンド設定において、デフォルトで選択されるpulseaudioの動作が重い、とどこかに書いてあった。で、それをalsaに変えてみたけど音途切れは相変わらず発生する。それよりか、いろいろと弄っていたらホスト側で音が出ていないことに気付いた。あわててサウンド設定を自動検出に戻してみたけどだめ。

どうやら、VMware Remote ConsoleでゲストOSを起動していると音声はそちらにとられてしまうらしい。ゲストOSをシャットダウンしたらホストOSの音が戻った。ここら辺が微妙で、ホストOSでCDなんかを再生しちゃうとなぜかゲストOSをそれから起動させても音が鳴らない。UbuntuというかLinuxのマルチメディアはまだまだツメが甘いかな。

あと、音途切れの原因を探るべくゲストOSにてリソースを「パフォーマンス」でチェックしてみたら、CPU、メモリ使用率、HDD転送量が頭打ちするときに起こることが分かった。要するに、リソース不足である、と。テスト機であるからそもそも省リソースの方針で、リソース増強はなんか違う。限られたリソースの中で音楽再生の優先度を上げられればいいのだけど。。。

VMware Server 1.0ではあんなに苦労していたAMD系CPUの省電力機能のCool’n'Quietだけど、VMware Server 2.0では有効にしていてもゲストOSの時計が狂うことはない。ひどい時は2.1Ghz→1.0GHzだから目に見えてゲストOSの時計の進みが遅くなっていた。VMware Server 2.0ではCPU周波数が目まぐるしく2.1GHz、2GHz、1.8GHz、1GHzと変化してもゲストOSの時計は規則的に動く。まあ、もともとこうでなくっちゃいけないんだけど。

これで心置きなくCool’n'Quietを有効にできる。

先日HDDをSSDに換装して大いに快適になったテスト機。だけど、気がついたらVMが立ち上がらなくなっていた。原因はVMを入れていたドライブがマウントされていなかった。では、なぜマウントされなかったのか？ その原因は、HDDを取り外したときに今までhdaと認識されていたドライブがsdbと認識されるようになったためだと分かった。ドライブはIDEのSSDなのでhd*として認識されていいのに。。。

なぜsd*と認識されているのか？ を探索するより、こういうことがあるからUUIDが導入されたわけだからUUIDを使ってみよう、と思いたったのであった。

ドライブのUUIDをを調べるためには、コンソールにてsudo vol_id /dev/sdb1を実行すれば、ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_UUID_ENC=344391d7-3b8b-4a57-8652-a3b97c3138ac
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=と表示される。ID_FS_UUIDが求めるUUIDで、これを/etc/fstabに設定する。# /dev/hda1 /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0
UUID=344391d7-3b8b-4a57-8652-a3b97c3138ac /var/lib/vmware/Virtual\040Machines/Virtual_Machine ext3 auto,users,rw,relatime 0 0上の行が今までの設定でコメントアウトされている。

これでPCを再起動するとちゃんとドライブもマウントされ、VMもちゃんとVMware Serverに認識されVMが起動するようになった。