PHPの 5.0 より SQLite がデフォルト対応になるみたいなので、りぼんさんにも SQLite を入れて今後に備えよう色々しました。というか、本当はレッツ PHP!さんところのトップを見てうごかねえ〜って言われたので、とりあえず入れようと思っただけなのですけどね。
さて php のモジュールなのですが、perl の CPAN のような感じで pear ってのがあるのですが、これがちょーーーーーーーーーーーーーーーーーーーーーーーーー曲者で、これのおかげで一日仕事になりました。
本来なら pear install sqlite とすれば、あっという間に SQLite が入るはずなのですけどね。
まあ初めは blue サーバだけに入れようと軽い気持ちで居たのですが、blue サーバで入れようとすると /usr/local/bin/php に phpize が存在しないってエラーが出てストップ。多分 PATH の問題だと思う。そこで、OS は同じの red サーバにて行うと同様のエラーが出るのかなあと思っていたら、次のようなエラーが出た。ちなみに php のバージョンは 4.3.3 。
checking whether ln -s works... yes
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
理由が全然わからないけど、pear の文献を調べていると libtool , autoconf , automake のバージョンが少なからず関わるようなので、最新版にアップデートするも状況は変わらず。
ここらへんで pear へ対する信頼感がゼロに近づいてきたけど、本当に出来るか確かめるために Redhat7.3 が入っているりぼんさんのメインサーバにて pear install sqlite を実行すると、「おぅ！SQLite なんてパッケージ無いぜ HeHeHe!」という訳のわからない応答をされたので、php バージョンが 4.3.4 だったのが悪いのかと思い 4.3.5 にアップデート。そして pear を実行すると、さっきのは何だったのかとしつこく問いつめたいぐらい、あっけなくインストール完了。めちゃめちゃバージョン依存するやんけぇぇぇぇ!! 古いバージョンを使わないとダメな場合は pear は使えないのか？？
そんなわけで早速ユーザサーバも 4.3.5 に入れ替え。さて一発で通るだろうと意気揚々にリターンキーを押すと
checking whether ln -s works... yes
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
またかよ。blue は相変わらず phpize が見つからないって言うし。つか、pear はすごい不便だ。ログを取ったり、途中でステップを止めたり、失敗したファイルをそのまま残したりが全然出来ない。なので、悪いところの検証は最後のだけ。だいたい ltconfig なんてのに --no-verify コマンドを付けろといわれても、pear から渡す事が出来ないんだから不可能なことを言うなって感じだ。いくら pear install sqlite --no-verify なんてやってもコマンドエラーって言われるだけだし。なんて使えないプログラムだとものすごく思います。だいたい ltconfig なんてファイルも pear のコンパイル中に作成されるだけで、それも解析できないので対処のしようがない。
こうなったら pear を使わずに直接コンパイルする必要があるので、ソースをpear の SQLiteからダウンロード
とりあえず展開。先ほどの pear の展開している順番から見ると、いつもの configure の前に、phpize ってコマンドを打たないとダメなようなので、phpize と入力。ずらずらっと configure やさっきから出ている ltconfig などがディレクトリに作成される。何故か blue でも問題なしに動作。どうやら pear が使う環境変数がセットされていないみたい。ltconfig が出来たところで見てみると、どうやら $host という環境変数に値がセットされないのでエラーになっているみたい。$host って何？これはデフォでセットされる物では無さそうで色々とプログラムを追っていかないとダメそうなので、非常に面倒そう。しかしメインサーバでは成功したのを思い出し、メインサーバにソースを展開して phpize を実行して ltconfig に echo $host って書けば何かわかるヤン、えらい！って自己陶酔しながら早速 phpize と打つと、ltconfig 出来ねええええええっ！ここでもバージョン依存しまくりかよ！
意気消沈しながら、力業で $host はセットされない物と勝手に解釈し、この configure がおかしいということで、エラーで止められる次の行にある exit をエスケープし、無理矢理コンパイル。ここをエスケープするといとも簡単に成功。make, make install と順調に行ったけど、モジュールが出来るはずのディレクトリには libsqlite.a しか出来ていない。本来なら sqlite.so が出来るはずであるし、だいたいサイズが違いすぎる。やはり $host には意味があるみたいだ。
こうなったら configure の内容に
checking host system type... i686-pc-linux-gnu
という行が出てきたのと、ltconfig の下の方に
host_cpu=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'`
host_vendor=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'`
host_os=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'`
というのが出たので、その正規表現に合わせるとどうやらこれであっているようなので、ltconfig の以下の部分の前に host="i686-pc-linux-gnu" と書いて、無理矢理対応させました。
if test "$verify_host" = yes; then
あとは、呪文のようにいつもの手順をすれば OK でした。ちゃんと /usr/local/lib/php/extensions/no-debug-non-zts-20020429/ に sqlite.so が出来ましたわ。
最後に次の頃をすれば終わりです。
-----
vi /usr/local/lib/php.ini
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20020429/"
extension=sqlite.so
------
さてこれで一応動きます。
ただ、最初 blue サーバに入れたときに mb 系のコマンドが通らなかったので、何でかなあと思ったらコンパイル時に enable-mbstring を忘れていました。そりゃダメだわ。
とりあえずこれで、SQLite のモジュールを入れるという大仕事は終わり。
さて、ここからがユーザにどのようにすれば安全且つ SQLite を提供できるかと言うことの試行錯誤になりました。とりあえず、現状で SQLite を動作させようとするとファイルが作成できないためテンポラリが作れないかそこらへんの理由だと思うけど、/tmp に書き込めて DB ファイルがユーザ権で作ってあっても更新することが出来ません。読むことは出来るけどね。そのために、ファイルを作成できるように変更。その代わりといっては何ですが、「php で作成されたファイルは全て問答無用で削除」するスクリプトを組んで、仕掛けておきました。まあファイルアップローダは open_basedir に /tmp を加えないとどうやら使えないみたいなので大丈夫なのですが、ログ解析なんかに使う人がいるからねえ。そう言うのの対策です。
で、red と yellow はそう言う設定でうまく動きましたが、blue はユーザ領域も /tmp も同じパーティションにあるため、open_basedir に /tmp を許可しなければ SQLite が更新できないため blue だけはアプローダ系を使える環境ではあります。まあ消されるけどね。
本日の気分：疲れた：0 時間( 計 0 時間 ),明日のラッキーアイテム：巻き尺
|
