Category: PHP
PHP 5.2.1
February 11th, 2007portsの方のlang/php5が、PHP 5.2.1になっていた（今まで、5.2.0を使用していた）。
その他のportsも含めて更新したかったので、
# portupgrade -aRr
としたところ、途中、なぜか、
cd: can't cd to /usr/ports/databases/pecl-PDO
と表示され、php5-extensions等のいくつかのportsの更新に失敗。
どうやら、
にあるように、こちらの方で以前からインストールしてあったpecl-PDO
が、php5-pdoに変更された事が原因らしい（typo?）。
そこで、一旦、
# pkg_delete -f /var/db/pkg/pecl-PDO-1.0.3
と古いのを削除してから、再度、
# portupgrade -aRr
を実行したところ、うまく行った。
追記
修正されました。
PHP 5.2.0
November 7th, 2006portsnap(8)したら、lang/php5のportが、5.1.6のバージョンから5.2.0に更新されていた。
ということで、依存するものを含めてportupgrade(8)した*1。
以前のバージョンのphp.iniは使い回せなかったので、後はこれを修正した程度。
- *1 普段は、癖で、バージョンに変更があったportsだけを更新するため、「
portupgrade -aRr」のようにして更新している。www/eacceleratorを使っている場合、上記のようなやり方では、通常、eacceleratorの方は更新してくれない。
PHPをApache moduleとして使っていて、PHPに大きな変更があったのに、eacceleratorの方を再構築し直さないと、Apacheが起動できなくなる。
（自分がたまに忘れる）
関連情報
PHP4からPHP5に乗り換えた
July 23rd, 2006先日、www/mediawikiのportを更新して、MediaWikiを1.7のバージョンのものにしようとしたが、MediaWiki 1.7はPHP4には対応していなかったため、やむを得ず、www/mediawiki16のportに切替えた。
この間、更新したb2evolution 1.8-betaは、PHP5には対応しているようだし、そろそろ全面的にPHP5の環境に乗り換えるのも悪くないと考え、今回、思い切って、www/php4からwww/php5のportに移行してみました。
portupgrade等を使って置き換える方法もあると思うけど、今回は、一旦、全部PHP関係のportsを削除し、新しいバージョンを新たにインストールするという手法を選びました。
まず、備忘のため、一応、
# cp /var/db/pkg/php4-4.4.2_2/+REQUIRED_BY /var/tmp/
とインストール済みのPHP4に依存するportsを控えておく。
続いて、
# cat /var/db/pkg/php4-4.4.2_2/+REQUIRED_BY | xargs pkg_delete -f # pkg_delete php4-4.4.2_2
とPHP4とそれに依存するportsを削除。
そして、
# portinstall lang/php5
と、PHP5のportをインストールし*1、先ほどバックアップした情報を参考に、
# portinstall lang/php5-extensions
を利用して、（必要な）主だった拡張モジュールをインストール。
後は、先ほど削除したそれ以外のportsを、インストールし直し、サーバを再起動する*2だけです。
- *1 以前にも書いたように、PHPのportsは標準では、CLI版とCGI版がビルドされて、Apacheモジュールは標準ではコンパイルされないので注意。
- *2 その前に、
/usr/local/etc/php.iniを新たに作成するのも忘れずに（新しくインストールされた/usr/local/etc/php.ini-recommendedをテンプレートとして使った）。
ただ、従来、.htaccessなどで、
<Files "FreeBSD"> SetHandler php-script </Files>
と記述し、PHPスクリプトとしてハンドルしていたものは、
<Files "FreeBSD"> SetHandler php5-script </Files>
のように、書き直さなければ駄目でした（でないと、ソース丸見えになった）。
MediaWiki の port を www/mediawiki16 に変更
July 18th, 2006/usr/ports/UPDATINGの20060714によると、
www/mediawiki version is 1.7 now. 1.6 version was preserved on www/mediawiki16 port.
と、www/mediawikiのportは、1.7系列のバージョンのものに切り替わったらしい。
一応、このサーバにもMediaWikiはインストールしてあるんだけど、
私の環境で、更新しようとしても、
cannot install: doesn't work with PHP version : 4 (Doesn't support PHP 4)
と怒られてしまう。
どうやら、1.7系列ではPHP4は、サポートされていないらしい・・。
でも、弱ったことに、PHP4でしか動かないアプリもいくつか、このサーバには存在する。
身動きが取れないけど、そのまま放置しておくのも何なので、とりあえず、
# portupgrade -o www/mediawiki16 -f mediawiki
のように、www/mediawiki16のportに変更しておいた。
そろそろ、PHP5に乗り換える準備に取り掛からねば・・。
PHPのslave portsが取り除かれていたこと
May 8th, 2006/usr/ports/UPDATINGの20060506によると、
The old PHP slave ports (phpN-cli, phpN-cgi and mod_phpN) were removed
されたらしく、lang/php4もしくは、lang/php5のportsに統合された。
それに伴い、
Before the upgrade you *should* run 'make config' in lang/php4 or lang/php5
する必要がある。
現在のところ、make configの画面のデフォルト値は、CLIとCGIバージョンの方がビルドされるようにチェックが入っていて、Apacheモジュールの方が標準では、ビルドされないようになっているので、使用している場合は注意。
コンテント ネゴシエーション経由でPHPにリクエストを渡すのをやめた
April 5th, 2006この間まで、PHPスクリプトをデフォルトの
AddType application/x-httpd-php .php
ではなく、
SetHandler php-script .php AddType text/html .php
と設定して、扱うようにしていた（過去の経緯については、p89参照）。
このブログのように、PHPスクリプト自体に.phpという拡張子が付いてるにも拘らず、それを含めないような形でアクセスさせるようにしている場合、接続クライアントが、
GET /blog/FreeBSD Accept: text/html,*/*
のようにアクセスして来れば問題ないけど、
GET /blog/FreeBSD Accept: text/html
とワイルドカードを含めず、Acceptタイプを限定してきた場合、サーバ側には、FreeBSD.phpは存在するけど、それのタイプは、application/x-httpd-phpであって、クライアントの要求するtext/htmlのタイプではない。他に代替するものがないと、
406 Not Acceptable
というエラーをサーバが返してしまうので、それを回避するため上記のような設定をした（ただし、ACCEPTヘッダにワイルドカードを付けずにリクエストを送信してくるクライアントは、Ask Jeeves/Theomaなど、ごく一部）。
通常、以上で問題ないはずなんだけど、b2evolutionには、静的なHTMLファイルを生成する機能があって、一番アクセス頻度が高いと予想されるトップ ページの部分を、予め静的なファイルとして、書き出しておくことが出来る（b2evolutionで静的なファイルを生成できない場合の回避策は、p88参照）。
問題は、同一のURLで、これらを使い分けようとすると生じて来る。
この場合、サーバ上には、同じタイプ（text/html）の
FreeBSD.phpFreeBSD.html
という２つのファイルが存在するようになって、
GET /blog/FreeBSD
とした場合、どれを選択していいのか判らなくなるからである。
mod_writeを使って、
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{PATH_INFO} ^$
RewriteRule ^blog/FreeBSD$ /blog/FreeBSD.html
と引数がない場合は、静的な方（FreeBSD.html）を表示しようとしても、なぜかPHPの方に横取りされてしまって、機能しなかった。
もっとも、静的なHTMLの方は、FreeBSD.htmlといった名前にしておく必要もないので、
static-FreeBSD.html
と改名し、ついでに、FreeBSD.phpの方も拡張子を取り除いて、FreeBSDとし、
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{PATH_INFO} ^$
RewirteRule ^blog/FreeBSD$ /blog/FreeBSD.html
RewirteRule ^blog/FreeBSD$ /blog/static-FreeBSD
<Files ~ ^FreeBSD$> SetHandler php-script AddType text/html </Files>
のように設定したら、とりあえず、意図した動作になった。
（これは要するに、コンテント ネゴシエーションで、リクエストをPHPに渡すのをやめたということだな…）
せっかく、Apacheに、コンテント ネゴシエーションの機能を導入しているので、静的なファイルの方を
static-FreeBSD.html.jastatic-FreeBSD.html.ja.gz
といろいろ作って、遊んでたけど、
Content-Type: application/x-gzip Content-Language: ja
なもの（上記の場合では、FreeBSD.html.ja.gz）は、ある種のプロキシ経由じゃ、閲覧できないみたい。
graphics/pecl-imagickが更新
February 21st, 2006PHPの拡張モジュールであるgraphics/pecl-imagickのportが更新。
ImageMagickから枝分かれした、GraphicsMagickのライブラリを使用することが出来るようになった（標準では、GraphicsMagickが選択される）。
どちらを選んでも構わないのだが、現在のところ、ImageMagickのライブラリを使用したimagick.soをロードしていると、
<?php phpinfo(); ?>
が正常に出来ない問題が確認されています。
ちなみに、こちらの環境（i386 FreeBSD 6.0 / Apache 2.0 / PHP 4.4.2）でも、同じ問題が起こって困っていたんだけど、GraphicsMagickを使ってビルドし直して、Apacheを再起動したら、発生しなくなったみたい。
FreeBSD上のPHPで、データのシリアル化を高速化する方法
February 16th, 2006で知ったけど、FreeBSD上のPHPではserialize()のパフォーマンスが悪いらしい。
にパッチが配布されているので、適用してみた。
# cd /usr/ports/lang/php4/files/ # fetch http://freebie.miraclenet.co.th/tmp/patch-php_smart_str.h # cd .. # portupgrade -f # /usr/local/etc/rc.d/apache2.sh restart
サンプルの構造化データとプログラム（test_serialize.tgz）*1で、試してみたところ、適用前は、
version:4.4.2 Length: 2798041 Serialize time: elapse(5.213405)
だったのに対し、適用後は、
Serialize time: elapse(0.382622)
と十倍以上高速化されてる。
- *1 サンプルを実行するためには、PHPで使用する
memory_limitを30MBぐらい確保しないと実行できない。
ちょっといいかも。いくらmemcachedとかでキャッシュさせて高速化をはかったとしても、前処理の段階でロス食ってちゃね。
PHP Screwを使ってPHPスクリプトを暗号化してみた
February 13th, 2006最近、PHP + MySQLなアプリケーションが増えて来て、自分でもよく利用している。
でも、せっかくデータベースの接続のためにパスワード認証を設けても、PHPのソースに生パスワードで記入するものが多く、気分的に不安が付きまとう。
普通、ローカルのユーザじゃないと、ソースコードは覗けないと思うけど、過去、ApacheにPHPをハンドルさせるのを忘れたりして、ソース丸見えな状況になった例もなきにしもあらずだし…。
見られて困るものなら、見られないようにすれば良いだけの話で、パスワード等を記述したファイルは、ドキュメントルート外に移動させて、パーミッションを落とし、それをインクルードするだけの同名のPHPスクリプトに置き換えるって手法をまま利用している。
でも、所詮、平パス。いっそ、人間には読めなくしてみれば、不安も減るだろうということで、
というロイヤリティー フリーなPHP暗号化モジュールを使ってみました。
インストール
portsからインストールする場合は、
# cd /usr/ports/www/php-screw # make CRYPTKEY="11152, 368, 192, 1281, 62" # make install
とします。
ここで、CRYPTKEYとして指定するのは、short型の数値の任意の長さの配列です。自由に置き換えて下さい。ただし、一旦指定したものは忘れないで下さい。次回、再ビルドした際、CRYPTKEYの値が前に指定したものと違っていると、既に暗号化した分のPHPスクリプトを復号できなくなってしまいますので。
設定
インストールが済んだら、有効化するために、
- /usr/local/etc/php/extensions.ini
に、
extension=php_screw.so
と復号化モジュールを追加し、Apacheを再起動させます。
これで暗号化されたPHPスクリプトあっても、実行できるようになります。
PHPスクリプトの暗号化
PHPスクリプトを暗号化するのは簡単です。同時に
/usr/local/bin/scew
というコマンドがインストールされますので、これを使用します。
例えば、データベースのパスワード等が書かれたLocalSettings.phpというファイルがある場合、
# screw LocalSettings.php
とするだけで暗号化されます。オリジナルのファイルは、同じ場所に「.screw」という拡張子がついてリネームされます。適宜、見えない場所に保管するなりして下さい（そのまま放置するなら、暗号化した意味がない）。
使用感
見られたとしても、実害はないと思うけど、主だったデータベース接続用のパスワードなどが書かれたPHPスクリプトを暗号化してみた。この手のものは、商用のものが少なくないけど、気軽に使えていい感じ。もっとも、私の場合、ほとんど気休め（ぱっと見わからなくするだけ）が目的で、本来の用途とは違うようだが…。（ローカルで詳しい人に粘着されたら終わり）
関連情報
このページより、
が参考になります。
MediaWikiのインストール メモ
February 7th, 2006以下は、FreeBSDにMediaWikiをインストールした際のメモです。データベースとWebサーバは、別々のjail環境下において動作させることにしています。
|
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
コメントスパム対策４
January 27th, 2006最近、また公開プロキシを利用して、アクセス元のIPアドレスや、ユーザエージェントを切替え、コンテンツを巡回しながらスパム投稿してくるロボットがやって来るようになった。
の対策でとった、外部JavaScriptから適当なクッキーを書き込ませ、投稿時、そのクッキーがない場合は、.htaccessにてアクセスを拒否するといった設定は、今回も有効でどのスパム投稿も無駄な努力に終わってる。
しかし、そういったロボットに巡回されること自体、鬱陶しい等という理由から、
においては、Distributed Sender Blackhole ListのDNSに登録されているIPアドレスでは、コンテンツの閲覧自体を拒否するように設定してみた。
でも、DSBLは、そういった公開プロキシに特化したものではなく、そのチェックにおいては、かなりザルだったので、代わりに、某巨大掲示板でも採用されている
- BBQ - あらしお断りシステム
というシステムを利用して、公開プロキシ経由のアクセスを排除してみることにした（使い方はDSBLと同じ）。
直近のログを通して確認して見たところ、DSBLでは引っかかったものが49件に対し、BBQでは289件と、このブログにアクセスしてきた公開プロキシ経由と思われるほぼ全てのアクセスが引っかかり、満足のいくレベル。
コメントスパム対策３
January 3rd, 2006新年早々、スパムクローラーがご活躍のようで、そこそこアクセスがある。見た感じ、サイト内を巡回してコンテンツを取得し、フォーム内容を解析して、スパム投稿するタイプのよう。
ユーザエージェントやアクセス元は、バラエティーに飛んでいて、リファラもこのサイト内のものなので、一意に弾くことは難しい。画像等を読み込んでないので、かろうじてロボットと推定しているのだが。
ま、でも、先日の外部スクリプトからクッキーを書き込ませ、投稿時そのクッキーがなければ拒否するという方法は、かなり、効果的なようで、現在、どのスパム投稿も全滅させている。
しかし、ここ数日のように連日数百件の規模で、スパム投稿されるのも、いい加減うんざりしてきたので、とりあえず、Distributed Sender Blackhole Listに登録されている公開プロキシ経由では、ブログ自体アクセスできないことにしてみました。
すなわち、
if ( isset($_SERVER['REMOTE_ADDR']) ) {
// AA.BB.CC.DD to DD.CC.BB.AA.list.dsbl.org
$dsbl_name = implode('.',
array_reverse(explode(".", $_SERVER['REMOTE_ADDR'])) ).'.list.dsbl.org';
if ( checkdnsrr($dsbl_name, 'A') ) {
require(dirname(__FILE__)."/b2evocore/_410_stats_gone.page.php");
}
}
といった感じで、ブログの各スタブ ファイル等に書いておき、アクセス元がdsbl.orgのDNSに登録されているIPアドレスの場合は、アクセスを拒否するといった設定。
ま、でも、効率に関しては、全ての公開プロキシを網羅しているわけではなく、かなりザルともいえるので、あくまでも気休めといった感じ。
Apache2でのPHPスクリプトのコンテントネゴシエーション
December 11th, 2005先日、このブログの
に、Apache2のコンテントネゴシエーションを使用して、PHPスクリプトに対して拡張子を含まないURIでアクセスした場合、リクエストヘッダにAccept: */*などとワイルドカードの指定がないと、
406 Not Acceptable
というエラーが返されると書いた。
サーバ側で.phpの拡張子の扱いが、application/x-httpd-phpであるため、ブラウザの要求する適切なコンテンツを見付けられないのが原因。一応、問題は解決したのだが、先日の解決方法より、もっとましな方法が、
に書いてあったので、試みてみました。
要するに、現在、httpd.conf内でのPHPスクリプトは、
AddType application/x-httpd-php .php
と扱われているけれども、問題のディレクトリ内の.htaccessに、
AddHandler php-script .php AddType text/html .php
と書いて、設定を上書きすれば、該当する拡張子のものをPHPとしてハンドルしてくれ、ネゴシエーションの際は、text/htmlとして扱われるというものです。
こっちの方が、合理的なので、この方法を採用することにします。様子を見て、問題がなければ、httpd.confの記述に改めます。
New pear bootstrap code
December 10th, 2005- archivers/pear-Archive_Tar
- devel/pear-Console_Getopt
- devel/pear-PEAR
- devel/pear-XML_RPC
- devel/php4-pear
が
で統合されたので、
# pkg_delete -f /var/db/pkg/pear-* /var/db/pkg/php4-pear-* # portinstall devel/pear
としておき、依存するものを構築し直した。
406 Not Acceptable
December 9th, 2005サーバのログを見てると、406という奇妙なエラーが出ている。どうやら、
にあるように、クライアント側がAcceptヘッダにMIMEタイプを明示してリクエストしてきた時、サーバが適切なコンテンツを見付けられなかった場合に発生するらしい。
通常、Webブラウザは、どのデータも受け取れるように、
Accept: */*
などワイルドカードを付けてリクエストしてくる場合が多いけど、例えば、サーバ側にtest.xmlというファイルが存在して、クライアントがMIMEタイプを
GET /test Accept: text/html
などと明示してきた場合、サーバ側にはtest.xmlは存在するにも拘らず、test.htmlは存在しないので、
HTTP/1.1 406 Not Acceptable
Alternates: {"test.xml" 1 {type application/xml} {length 1234}}
などと、代替案として、存在するもののリストを返して終了する（HTTP/1.1のコンテントネゴシエーションを使用している場合）。
ま、このエラーがHTTPDのログに出ていたケースでいえば、PHPスクリプトに拡張子を付けてないURIにアクセスされた時、要するに、このブログ（b2evolutionのスタブファイル）に拡張子なしでアクセスした時で、
% curl -I http://www.xdelta.net/blog/FreeBSD -H 'ACCEPT: text/html'
HTTP/1.1 406 Not Acceptable
Date: Fri, 09 Dec 2005 13:09:28 GMT
Server: Apache
Alternates: {"FreeBSD.php" 1 {type application/x-httpd-php} {length 2374}}
Vary: negotiate
TCN: list
Content-Type: text/html; charset=iso-8859-1
で再現できる。
でも、このエラーを出してるUser-Agentは、見た感じ、今のところは、
- Mozilla/2.0 (compatible; Ask Jeeves/Teoma; +http://sp.ask.com/docs/about/tech_crawling.html)
だけだし、どうしようかな？ クライアントが悪いような気がしないでもない。
該当するPHPスクリプトの拡張子を取り除いて.htaccessなんかに
<Files ~ ^FreeBSD$> SetHandler php-script </Files>
って書いてPHPスクリプトとしてハンドルさせれば解決すると思うけど、あまり多用はしたくないし・・
XML Feeds
