Natz's Digital 漂流記

つい最近存在を知った EC サイト構築ツール Live Commerce を検証するため、我が家のテスト用 Web サーバー (CentOS 5.5) にインストールを試みると、PHP が 5.2.4 以上でないとダメと言われて先に進まない。確かに CentOS (と言うより RHEL) 5.x の PHP が 5.1.6 な点については思うところがないでもないが、安定性重視で枯れたバージョンを採用するディストリビューションと言うことは承知の上で使っているし、「PHP は 5.2 以上を推奨」 と言いつつ 5.1.6 でも実質的に問題がない Web アプリケーションはけっこうあるので、まァ何とかなっていた。

しかし今回の Live Commerce は Zend Framework の上に乗っているだけに、Zend Framework のシステム要件がそのまま適用されると言うことだろう。インストーラーを騙して PHP 5.1.6 で強行する方法もあるようだが、インストールはできても不具合発生時の原因特定が面倒になりそうなので、PHP を入れ替えて根本解決を図ることにする。

「どうせ入れ替えるなら、なるべく新しいバージョンがいいな」 と Web で検索してみると、"Les RPM de Remi" リポジトリで CentOS 用の PHP 5.3.3 パッケージが配布されていることがわかった。タイムリーなことに、5.3.3 は 07/22 にリリースされたばかりの (現時点での) 最新安定版だ。

インストール方法は以下の通りだが、PHP の入れ替えに伴い、依存関係で MySQL もアップグレードを強いられる点に注意。また remi リポジトリはデフォルトで無効になっているので、remi のパッケージを利用する場合は、事前に /etc/yum.repos.d/remi.repo の "remi" セクションで "enabled=1" にしておくか、yum を実行する度に "--enablerepo" オプションを併用して、一時的に有効にする必要がある。

・現状のバージョンを確認
# rpm -qa | grep php | sort
# rpm -qa | grep mysql | sort

・epel リポジトリを登録
rpm -ivh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

・remi リポジトリを登録
# rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

・PHP 5.3.3 の存在を確認
# yum info php --enablerepo=remi　← remi リポジトリを一時的に有効化

・既存 PHP と MySQL をアンインストール
# yum remove php php-* mysql
Removed:
  php.i386 0:5.1.6-27.el5            php-adodb.noarch 0:4.81-1.el5.rf
  php-cli.i386 0:5.1.6-27.el5        php-common.i386 0:5.1.6-27.el5
  php-devel.i386 0:5.1.6-27.el5      php-gd.i386 0:5.1.6-27.el5
  php-imap.i386 0:5.1.6-27.el5       php-ldap.i386 0:5.1.6-27.el5
　　：
(※ アンインストールされたパッケージをメモしておく)

・アンインストールされたのと同名パッケージを、remi リポジトリからインストール
(※ remi に存在しなければ、他のリポジトリのものが使われる)
# yum install php php-adodb php-cli php-common php-devel ... --enablerepo=remi

・新しいバージョンを確認
# rpm -qa | grep php | sort
# rpm -qa | grep mysql | sort

これで Apache と MySQL を再起動すれば、めでたく PHP 5.3.x (+ MySQL 5.1.x) 環境が出来上がる。Live Commerce も無事にインストールできた (Live Commerce インストール時の環境チェックで "DOM" が 「×」 になっている場合は、php-xml が足りない)。

かつてはソースからのコンパイルに拘っていた時期もあったが、常に最新版を追いかけ続けるのはけっこう消耗するし、追いかけるプログラムの数が多ければ、それだけで一仕事になってしまう。プログラムのコンパイルは、「チマチマ設定してオラッと実行。出来上がるのを待つ」 と言う、3D CG のレンダリングにも似た 「ワクワク感」 があって個人的には好きだが (設定ミスに気付いて慌ててやり直すのも CG に似ている)、台数が増えたときの管理上の手間を考えると、最新機能を使いたいとかソース版でしか解決できない問題がなければ、素直にパッケージを利用した方が断然楽だ。

ところで CG や動画のレンダリングと言えば、制作現場では複数台のマシンで行う分散レンダリング (ネットワーク･レンダリング) が一般的。ではプログラムのコンパイルを分散する方法はあるのかと探してみると、いくつか見つかった。でも計算に参加するマシン間で CPU やアーキテクチャーが違うと、さすがにダメかな？

One Response to this entry.