カテゴリー: Development

PHP 5.0.5リリース

PHP 5.0.5がリリースされました。XMLRPCのセキュリティフィックスが含まれています。

他のディストリビューションも同じとは思いますが、Momonga LinuxのXMLRPCは現行リリース(5.0.4-6m)でもセキュリティ対策済みです。

pgbenchのpthread版

(やはりバグを発見したので修正)

JPUG広報Blogに「pgbenchのpthread版が欲しい」と書いていましたが、先週末にPHP関西のセミナー講師を引き受けていたのでその移動時間中にテキトーに作ってみました。テキトーに作ったので勘違いしてバグを入れていました。今度はたぶん正しい結果になっていると思います。

サーバ環境
Athlon64 3200/3GB Memory/SATA2 HDD/Momonga Linux x86_64
PostgreSQL 8.0.3(64bit)(全てのSQL文をホスト/ポート付きで記録。他はほぼデフォルト。)

クライアント環境
AthlonXP 2500+/2GB Memory

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 10 -t 100
starting vacuum…end.
starting full vacuum…end.
Warming up 15 seconds…
Start benchmarking…
End benchmarking….. (4.96586 seconds)
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 100
total number of transactions processed: 1000
tps = 235.404176 (excluding connections establishing)

real 0m25.739s
user 0m0.214s
sys 0m0.313s
[yohgaki@dev pgbench]$

こんな感じです。

何だか遅くなってしまたのでコードをもう少し効率化してみました。
今度はオリジナル版よりは速くなりました。

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
Warming up 0 seconds…
Start benchmarking…
End benchmarking….. (1.16363 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 429.689481 (excluding connections establishing)

real 0m2.655s
user 0m0.047s
sys 0m0.088s

オリジナル版

[yohgaki@dev pgbench]$ time pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
number of transactions actually processed: 500/500
tps = 337.674248 (including connections establishing)
tps = 379.093451 (excluding connections establishing)

real 0m1.615s
user 0m0.043s
sys 0m0.210s

と、多少スレッド版の方が速いです。今度は繰り返し実行してみてもスレッド版の方が速い傾向は変わりませんでした(汗

ベンチマークを開始する前にウォーミングアップの時間を設定したかった事、クエリ実行間隔をランダムに設定したかった事もpthread版が欲しかった他の理由でした。そこで

-w ウォームアップ時間(秒)
-r ランダム遅延(マイクロ秒)

も設定できるようにしました。よくあることですがサーバに負荷をかけた直後は良い性能がでるためウォームアップ時間は設定できた方が便利です。

ウォームアップ時間を5秒に設定した場合

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10 -w 5
starting vacuum…end.
starting full vacuum…end.
Warming up 5 seconds…
Start benchmarking…
End benchmarking….. (1.48874 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 335.854481 (excluding connections establishing)

real 0m6.671s
user 0m0.124s
sys 0m0.260s

とこの様な感じです。オリジナル版にウォームアップ時間オプションを追加して欲しいな、と書いておいたら石井さんが追加してくれるはず :)

ソースは
http://www.ohgaki.net/wiki/index.php?PostgreSQL%2Fppgbench
からダウンロードできます。変更するかもしれないので日付を入れておきました。日付が入っていないソースは古いソースです。もし古いソースをお持ちの場合、新しいソースを使ってください。古い物にはバグがあります。

PHPのE_STRICTエラー

PHPのエラーレポートレベルはphp.ini設定のerror_reportingで設定されています。

PHP5から追加されたE_STRICTで「あれ」と思われるかもしれない状況があるので書いておきます。

PHP5でE_ALLをerror_reportingに設定してもE_STRICTレベルのエラーは報告されません。デフォルト設定ファイルではE_STRICTは無視されるようになっています。

error_reporting = E_ALL | E_STRICT

と設定しないとより厳しいエラーチェックが行われません。

開発時には言語が用意しているエラーチェックを出来る限り多く使用するべきです。しかし、E_STRICTレベルのエラーレポートを行う設定を行った場合に問題が発生する場合があります。次のコードがどのように処理されるか考えると分かります。

<?php
error_reporting(E_ALL); // E_STRICTは不必要

class foo {
  var $bar;
}
?>

E_STRICTで報告されるエラーには”var”宣言されたプロパティにpublic/private/protectedを使用するよう推奨するエラーがあります。このエラーはコンパイル時に発生するため、スクリプト中でerror_reporting関数を使ってエラー報告レベルと変更してもE_STRICTエラーを無視できません。E_STRICTエラーが有効な環境で、error_reporting関数で確実にE_STRICTエラーが発生しないようにするには、E_STRICTエラー出力を抑制するには最初に読み込まれるファイルのコード中にE_STRICTエラーが発生しないしerror_reporting関数を使用してエラー報告レベルを変更しなければなりません。

# E_STRICTは開発時だけ使う、という方針がお勧めです。
# PHP4用に作ったアプリの修正は手間な場合は、INSTALL
# ファイルなどにE_STRICTは無効にするよう書くだけでも
# 良いかもしれません。

備考:
E_NOTICEレベルのエラーは全て実行時に発生するエラーであるため、E_STRICTの様な問題は発生しません。念のため。

追記:
今時のPHPアプリケーションならE_STRICTエラーも発生しないようにプログラムを作成すべきす。

 

関数の戻り値と定数値(リテラル)への参照

追記:このエントリへのアクセスが多いので加筆修正しました。

Fatal error: Only variables can be passed by reference

直訳すると「致命的エラー:変数のみ参照渡しが可能です」となります。エラーメッセージの通りvariable(以外)の値は参照として渡せないのでエラーになっています。エラーメッセージが適切かどうかは微妙ですが、意訳すると「致命的エラー:ソースコード中に記述した定数値(リテラル)へのアクセスはできません」あたりが妥当と思います。当然ですがdefineで定義した定数値を返す事は可能です。PHP内部では定数は変更できない「変数」の様に実装されているからです。このエントリの「定数値」を正確に書くと「ソースコード中に記述された定数値」となります。

もっと読む

QRコードを短冊に

メモ。QRコードに関するblog。本文もQRコードならコメントもQRコードです(気付くのが遅すぎ?

とろこでトップページの「QRコード読み取りのコツ」に

■QRコードの真正面から撮影

とありますが、真正面から読まないとQRコードが読み取れないリーダ(携帯)があるのですね。と、書いている自分も正面から読み取るようにしていますが、QRコードは印刷面が平たければ、ななめから読み取っても読み取れる設計になっています。QRコードの仕様を知らない方も多いと思うので簡単な説明を付けておきます。隅の大きめの■が斜めからも読み取れるようにするための役割を持っています。全ての隅に大きめの■が無いのは読み取り開始位置を判別できるようにするためです。カメラの解像度やQRコードが写されている領域の影響もあるので正面から撮らないと読み取りに失敗する確立は高くはなると思います。エラー補正情報をQRコード内にたくさん入れていれば読み取りに成功する確立は高くなりますが、QRコードが大きくなります。微妙ですね。

allow_url_fopen

追記:
現在のPHPではリモートファイル読み込みを制御するphp.ini設定としてallow_url_fopen(URL等のファイルとして読み込むフラグ)とallow_url_include(URLなどをPHPスクリプトとして読み込むフラグ)があります。php://input(標準入力用のURL。Webアプリの場合、POSTリクエストなどが読み込める)もallow_url_include=Offでは利用できません。このためallow_url_include=Offの場合、リモートスクリプトからの読み込みを防止できます。

基本的には

  • allow_url_includeは常に無効(JSONなどでなくPHPスクリプトとしてリモートデータを読む、などの場合は局所的に有効化)
  • allow_url_fopenは全く必要ないなら無効

とすると良いでしょう。

PHPを使っている方はHTTP/FTP/SSH等のプロトコルでリモートサーバ上のファイルをローカルファイルの様に読み書きできる事をご存知と思います。この機能はphp.ini設定のallow_url_fopenディレクティブで有効/無効を設定できるようになっています。PHP 4.3.4より前のPHPではこの機能のスクリプト中からも無効/有効に設定を変更する事ができました。(INI_ALLの設定項目であった)

驚いたことにPHP 4.3.4からphp.iniからしかこの設定を変更できなくなってしまいました。(INI_SYSTEMの設定項目になった)誰かがセキュリティ強化を目的として変更したのだとは思いますが、セキュリティも強化できず、有用なリモートファイルアクセス機能も使えなくする非常に拙い変更です。

例えば、phpBB(BBSアプリケーション)ではinclude/require文に不適切に処理されたユーザ入力が利用されている為、リモートスクリプトを読み込み実行できてしまう非常に深刻なセキュリティ上の問題がまた最近見つかりました。phpBBはallow_url_fopen機能が無効であっても動作するので

allow_url_fopen = Off

と設定するか必ず読み込まれる設定ファイルで

ini_set(‘allow_url_fopen’, 0);

とすると、phpBBのようなアプリケーションでも比較的安全に運用することができました。

しかし、allow_url_fopenがINI_SYSTEMの設定項目になった為、前者の方法を取ると他のアプリケーションで、場合によっては非常に有用な、allow_url_fopen機能を使えなくなってしまいました。後者の方法は、特定のアプリケーションのみの設定を変更するのに有効ですが、INI_SYSTEM設定項目であるため実際には無効に設定できなくなってしまいました。

セキュリティ上の意味は容易に理解できるであろうと、internals@list.php.net にallow_url_fopenの設定を

デフォルトOFF
INI_ALLへ変更

するように提案して見たところ議論が結構荒れています…
この設定が安全かつ不必要な機能制限が無く、最も良い設定と思うのですが…

# allow_url_fopen_includeのようにinclude/require文用の設定
# を追加するのも良いですが、デフォルトOFF、INI_ALLであるべき
# と思います。

php-rast

Rastとはネットワーク応用通信研究所が開発している全文検索システムです。

本ソフトウェアは,あらかじめ対象となる文書群から検索に必要な情報を格納するデータベースを作成しておき,それに対して検索を行う全文検索システムです.

検索方式は N-gram 方式や分かち書き方式から選べます.また,必要に応じて文字列処理モジュールを差し替えることができます.

なお,本ソフトウェアは IPA の平成16年度オープンソフトウェア活用基盤整備事業の委託を受けて開発を行っています.

このRast用のPHPモジュールを冨田冨田隆三さんが公開されています。

名古屋市立大学の冨田です

以前、全文検索エンジンRast のモジュールを公開したところ、ここでライセンス違反の可能性を指摘されて公開を止めていましたが、Rast-0.2.0 で BSD ライクな緩いライセンスに変更されたようなのでまた公開してみます。

ダウンロードはこちらからどうぞ。
http://a157.debian.co.jp/php_rast/

冨田

サンプルの動作は良い感じです。サンプルコードもざっと見てみましたが使いやすそうです。

_php_stream_passthru

php-usersのMLに投稿した内容の補足です。コードはPHP 4.4の開発ブランチのソースです。

main/stream.cに_php_stream_passthru関数が定義されています。reafile関数(ファイルの中身を全て出力)、fpassthru関数(ファイルリソースの中身を全て出力)に利用されています。

PHPAPI size_t _php_stream_passthru(php_stream * stream STREAMS_DC TSRMLS_DC)
{
    size_t bcount = 0;
    int ready = 0;
    char buf[8192];
#ifdef HAVE_MMAP
    int fd;
#endif

#ifdef HAVE_MMAP
    if (!php_stream_is(stream, PHP_STREAM_IS_SOCKET)
            && stream->filterhead == NULL
            && php_stream_tell(stream) == 0
            && SUCCESS == php_stream_cast(stream, PHP_STREAM_AS_FD, (void*)&fd, 0))
    {
        struct stat sbuf;
        off_t off;
        void *p;
        size_t len;

        fstat(fd, &sbuf);

        if (sbuf.st_size > sizeof(buf)) {
            off = php_stream_tell(stream);
            len = sbuf.st_size - off;
            p = mmap(0, len, PROT_READ, MAP_SHARED, fd, off);
            if (p != (void *) MAP_FAILED) {
                BG(mmap_file) = p;
                BG(mmap_len) = len;
                PHPWRITE(p, len);
                BG(mmap_file) = NULL;
                munmap(p, len);
                bcount += len;
                ready = 1;
            }
        }
    }
#endif
    if(!ready) {
        int b;

        while ((b = php_stream_read(stream, buf, sizeof(buf))) > 0) {
            PHPWRITE(buf, b);
            bcount += b;
        }
    }
    return bcount;
}

注目すべきは以下です。

            if (p != (void *) MAP_FAILED) {
                BG(mmap_file) = p;
                BG(mmap_len) = len;
                PHPWRITE(p, len);
                BG(mmap_file) = NULL;
                munmap(p, len);
                bcount += len;
                ready = 1;
            }

PHPWRITEマクロは最終的に出力バッファに書き出します。PHPからの出力は最終的にWebサーバにバッファされる場合があります。つまり、一度に大量のデータを出力するとメモリを大量に必要とする可能性があります。

Momoery Mapped I/Oの利点がバッファ無しでデータを読める事は分りますが、大きなファイルを送信するには不適切な事は明らかです。データを適切なチャンクサイズに区切ってPHPWRITEに書き込むよう変更しなければならないですね…

DokuWiki

久しぶりにmadwifiの設定をしようとmadwifiのページを見てみると見慣れないWikiを使っていたのでどんなWikiかさらっと見てみました。インストールやソースを読んでいないので見てみた感想です。

基本的なWiki機能はそろっているようです。ページの場所 “top>a page>another page”の様に表示されるのも便利です。ログインユーザ登録もサポートしているようで、Eメールアドレスを登録してから編集を許可する、という運用ができるのはSPAM対策やセキュリティ対策に役立つと思います。

次のような機能を持っているようです。

DokuWiki Features here

* works on plain text files, no database needed
* simple syntax and easy editing with quickbuttons and accesskeys
* Section Editing allows you to edit small parts of a page
* automatic generation of content tables
* unlimited page revisions
* colored side by side diff support
* support for read only pages
* syndication of recent changes as RSS Feed
* namespaces
* Interwiki Links
* uploading and embedding images
* image caching and resizing
* easy navigation through breadcrumbs
* Customizing with templates and plugins
* Multilanguage Support
* Spam blacklist
* custom text replacements
* pagecaching
* locking to avoid edit conflicts
* full UTF-8 support
* and more

Wiki機能の比較は見るだけでも興味深いと思います。

Tipsのページを見てみると色々な機能が追加できる事が分かります。SVGをPNGやGIFに変換、ページをPostscriptに変換、HTMLからDokuWiki形式への変換方法が記載されています。

面白かったのはNanoWebをサポートするWebサーバとして記載されている所です。NanoWebはPHPで記述されたWebサーバで

Nanoweb’s main features are :

– HTTP/1.1 compliance
– Powerful and easy configuration
– Modular architecture
– FastCGI, CGI and Server side includes support
– Name and port based virtual hosts
– Access control lists
– htpasswd, MySQL, PostgreSQL and LDAP authentication support
– Themes for server generated content
– Apache compatible log format, MySQL logging
– Directory browsing
– inetd support and SSL via external helpers
– Denial of Service protection
– Proxy Server extension
– Filters and gzip support
– RBL support (mail-abuse.org)
– Extension Protocols (request methods) support
– … and a lot more

と色々盛り沢山です。

コマンドラインのPHPさえインストールされていれば自分でWebサーバを立てる事ができます。NanoWebのソースは以前に読んだ事があるので多少は分かります。pluginの作成は簡単そうでした。速度的にも普通(?)のリクエスト数であれば十分処理できるパフォーマンスでした。(思ったより速くて驚いたと思います)

PHP4でpublic

PHP本家の開発ML internals@lists.php.net ではPHP4でpublic宣言を行えるようにするかどうかで盛り上がっています。

PHP5を使っている方はご存知の通り、PHP5からオブジェクトのプロパティはpublic, protected, privateにアクセスレベルを限定できるようになりました。それと同時に古いプロパティ宣言であるvar宣言は使わないよう推奨されています。

初めの頃のPHP5のリリースではPHP5で追加されたE_STRICTエラーを表示する為の記述に間違いがありました。E_ALLではE_STRICTエラーでは表示されず、E_ALL | E_STRICTにしなければなりません。E_STRICTエラーにはvar宣言についてもvarではなくpublic, private, protectedを使用する旨のエラーが発生します。E_STRICTエラーを表示する設定方法に間違いがあったため、E_STRICTエラーには気が付きづらかったと思います。E_STRICTレベルエラーを有効にしてエラーの数に驚いた方も多いかも知れません。

しかし、var宣言エラーの問題さえクリアすればほとんどE_STRICTレベルのエラーを回避し、PHP4とPHP5の両方で実行できるコードを書くことも可能になります。現状ではPHP4ではクラス定義の際、プロパティは必ずvar宣言しなければならないのでクラスを使えばE_STRICTエラーは必ず発生します。

class foo {
public $var;
}

をPHP4でも使えるようにするメリットはあります。PHP4用のコードと言いつつPHP4.4より古いPHP4では実行できなくなるのも困るというのも分かります。

私はPHP4の文法は拡張せず最初に読み込むアプリケーションの設定ファイルなどで


error_reporting(E_ALL);

を実行する方がよいのではないかと思っています。
この方法には最初に読み込まれるファイルが在ること、そのファイルにクラス定義が含まれないと前提条件もありますがこれでも十分ではないかと思います。

# 最悪、auto_prependでerror_reporing設定を変える方法も使えます。

S2PHP5

S2PHP5は名前の通りPHP5専用のフレームワークだそうです。

説明

Java版のSeasar2を、PHP5に移植します。

 マイルストーン
M1: Java版Seasar2をPHP化する (バージョン 0.9x)
パッケージ構成やインタフェースを統一し、Javaのソースをできるだけ変更することなくPHP5に書き換えます。
M2: PHPらしくリファクタリング (beta バージョン)
リリース1.0 に向けて、移植もれ、移植ミス、動作不具合への対応。
また、実装方法、命名規則、名前空間、クラス定義の読込み方法や設定ファイルの在り方等々、ユーザ様からの声を検討、反映し、「 易しく・優しく・PHPらしく 」 を目標にリファクタリングします。
ご意見・要望など Seasar-User ML までお願いします。

最初のリリース(0.92)は5/29のようです。現在は0.93(6/9)が最新リリースのようです。

面白そうなので近いうちに時間を作って試して見たいです。

# 私のアンテナあまり広くないので、面白そうな情報があった
# ら是非教えてください :) 

Rails

Rubyを使っている方やMLを覘いている方(私はこちらです)はWebフレームワークのRuby on Railsをご存知と思います。Ruby使いではないのでMLをさらっと横目で見ている程度なので詳しくは知らなかったのですが

http://www.rubyonrails.org/

QuickTimeの紹介ムービーがあったので見てみました。10分ほどのムービーですが簡単にWebアプリケーションが作れる事が分かります。

Rails、面白そうですね。MLで盛り上がる訳ですね :)

Serendipity – PHP Blog System

Blogツールの選択肢は多すぎてどれを選べば良いか迷う程ですがSerendipityというPHPで記述されたBlogシステムを知りました。

WYSIWYG HTMLエディタも利用できたり、全てのRSSとATOMに対応、イメージのリサイズサポート等、割と良くできていると思います。PHP5ならSQLiteをデータベースとして利用できるのでDBサーバ無しでも利用できる点が良いと思います。

Developer Team
Jannis Hermanns
Sterling Hughes
George Schlossnagle
Wez Furlong
Sebastian Bergmann
Garvin Hicking
Tom Sommer
Joyce Park
Christian Mühlhaeuser
Joseph Tate

開発者の名前を見るとPHPプロジェクトのコミッターが多いですね。
# 私が知らないだけで、全員コミッターかも知れませんが。

b2evolutionから乗り換えるには、統計情報、SPAM排除機能等が必要ですね。これらの機能はまだないようです。

PHP 5.1でgoto!?

なんだかPHP 4.4ブランチが出来たりして??と思っていたところ「goto文をPHP 5.1で!」と言う事でinternals@lists.php.netが盛り上がっています。

goto文が無くて困ることは無いのですが、あって困る事は沢山あります。自分だけがコードを書くわけではありませんしgoto文の乱用は簡単です。しかし、今まで無くて困らなかったのに何故今頃、という感じです。

万が一goto文がサポートされても使わないようにしましょう(笑