Tweet

第41回　エラーメッセージをどう扱うか？

←←連載第1回へ｜｜←前回へ｜第41回｜

本番環境ではエラー表示は不要

　第37回から、PHPの実行時設定の中でもサーバ全体にかかわる設定、つまりphp.ini）で設定するものについて解説しています。特に、初期設定のままにしておかない方が良いものを選んで、変更すべき理由と、変更する方法を解説してきました。

　前回までの3回では、リクエストデータの取り扱いに関する設定を解説しました。この設定を誤ると、思わぬところに脆弱な点ができてしまい、セキュリティの面で問題になってしまいます。

　今回のテーマは、エラーログ関係の設定項目です。PHPスクリプトを実行したとき、エラーが発生すると、エラーの内容を説明するメッセージがWebブラウザ上に現れてしまいます（図1）。スクリプトの文法エラーだけでなく、存在しない変数や関数へのアクセスといったバグを原因とするエラーでも、発生するとその内容を説明するメッセージが出てきます。メモリ不足のような例外が発生したときも同じことです。

図1　メモリが足りなくなると、エラーが発生し、このメッセージがそのままWebブラウザに表示される。クリックすると拡大

　エラー発生を知らせる警告は、アプリケーション開発中やテスト中には、アプリケーションの問題点を知り、バグを潰すために役立つ情報となりますが、実際の本番環境では表示すべきものではありません。まず、Webアプリケーションの利用者が戸惑います。そして、ファイルやディレクトリの構造、PHPアプリケーションの中身や、バグの存在など、攻撃者を喜ばせるようなヒントを与えることになります。つまり、セキュリティ上のリスクになり得るのです。

　では、エラーメッセージの出力を止める方法はあるのでしょうか。PHPでは、「display_errors」ディレクティブの設定を変更することで、エラー表示を出すか、あるいは止めるかを選択できます。開発中は設定値をOn（エラーを表示する）にしておいたとしても、本番環境では必ずOff（エラーを表示しない）に変えましょう。以降の説明では、本番環境を想定してdisplay_errorsディレクティブの設定をOffにしたものとして説明を続けます。

余計なヒントは与えない

　これまでも、第38回などで、サーバ上で動作しているのがPHPスクリプトであることを隠すための設定方法をいくつか紹介しています。さらに、display_errorsの設定をOffにすることで、Webブラウザなど、表に現れる情報を調べても、動作しているのがPHPスクリプトであるとは分からなくなります。

　PHPスクリプトを実行していることを隠す方法をまとめると、Apache HTTP Server（以下Apache）の設定を変更して、拡張子を「.php」ではなく「.html」などにしたPHPファイルを実行可能にすること。Apacheの設定ディレクティブ「ServerTokens」の設定を「Prod」にして、ApacheやPHPのバージョンを隠すこと。PHPの設定ではexpose_phpの設定をOffにして、ヘッダ情報に、PHPを使っているという事実を入れないこと。 そして、先ほど説明した、display_errorsの設定をOffにして、余計なヒントになりかねないエラーメッセージの表示を止めることです。

　display_errorsににている部分を制御するディレクティブに、「display_startup_errors」があります。display_errorsはPHPスクリプト実行中のエラー表示の可否を決めますが、display_startup_errorsはスクリプト実行前の、初期化時に発生するエラーに関係するディレクティブです。この設定も、余計なヒントを与えないために、本番環境ではOffにしておくべきでしょう。ちなみに、初期化時に発生するエラーとは、前回に例として挙げたリクエストデータのサイズ超過などによって発生するエラーです。

　前回、POSTメソッドで受け取るリクエストデータの最大サイズを指定する「post_max_size」ディレクティブについて解説しました。設定値を超えたデータをサーバに送りつける例もお見せしました。しかし以下のように、エラーの発生を知らせるメッセージは何も出てきませんでした。

$ curl -X POST --data 'foo=bar&baz=12345' http://www3026ub.sakura.ne.jp/print_post.php
Array
(
)

　これは、display_startup_errorsディレクティブの設定値がOffになっているからです。このディレクティブの設定値は初期状態がOffになっています。そこで、試しに設定をOnに変更して同じテストを実行してみましょう。

　リクエストデータの長さが制限を超えていることを知らせるエラーメッセージが返ってきます。先に説明したように、この設定は標準ではOffになっていますが、アプリケーション開発時やテスト時はOnに変えておくべきです。初期化時に問題が起きたとしても、手掛かりがないと、問題解決もままなりません。もちろん、この設定は本番環境ではOffにしましょう。

　直前にお見せした例では、コンソールからcurlコマンドを使って大きなリクエストデータを送りました。帰ってきたエラーメッセージをよく見ると、HTML形式になっています。ブラウザで表示することを想定しているのです。ただしこれは、ApacheにPHPを組み込んでいるときに見られるエラーメッセージです。コマンドライン版のPHPではHTMLではなくテキストのエラーメッセージになります。ちなみに、ApacheにPHPを組み込んだときでも「html_errors」ディレクティブの設定をOffにすると、エラーメッセージがテキスト形式になります。

エラー情報はログに蓄積

　エラーの情報は、Webブラウザに表示するだけでなく、ログに記録することもできます。Webブラウザへの表示はその場限りで、Webブラウザを閉じてしまえば情報は消えてしまいます。

　一方、ログであればすべての情報を蓄積しておいて、あとから確認することができます。開発環境だけでなく、本番環境でも、ログ記録の機能は利用すべきです。特に、本番環境ではdisplay_errorsをOffにしますので、エラーが発生したとしても、その事実をつかむにはログに情報を記録させるように設定するしかありません。

　ログ記録機能は「log_errors」ディレクティブをOnにすると動き出し、Apacheのエラーログファイルを記録するようになります。すなわちApacheの「ErrorLog」ディレクティブで指定しているファイルです。例えば図1で示したようなエラーなら、その情報は次のような形式でエラーログファイルに残ります。

[Thu Feb 02 00:30:42 2012] [error] [client 49.212.32.64] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 32 bytes) in /srv/httpd/www3026ub.sakura.ne.jp/webspace/memtest.php on line 2

　スクリプト実行前の初期化時に発生するエラーの情報は、前述の通り標準の状態ではWebブラウザには表示されませんが、エラーログには残ります。post_max_sizeの指定を超えたサイズのデータをサーバが受け取ると、次のようなログが残ります。

[Thu Feb 02 00:46:58 2012] [error] [client 49.212.32.64] PHP Warning:  Unknown: POST Content-Length of 17 bytes exceeds the limit of 16 bytes in Unknown on line 0

　Apacheのエラーログへの記録は、PHPではなく、PHPからログ内容を受け取ったApacheが処理しています。そのためログの記録先は、Apacheの設定によっ て決まっているファイルになりますが、他のファイルに記録することもできます。「error_log」ディレクティブにファイル名を指定すると、PHPに よって指定ファイルにログが出力されます。

　ここで注意しなければならないのは、Apacheのエラーログファイルはroot権限で書き込むのに対し、error_logで指定したログファイルにはApacheの実行権限でアクセスするということです。ログファイルを書き込むディレクトリのオーナーやパーミッションを正しく設定しておかないと、ファイルにログを書き込めませんので、十分注意してください。

　筆者の個人的な意見を言うと、素直にApacheのエラーログを使う方が良いと思います。バーチャルホストごとに設定できることやファイルへのパーミッション設定の手間を考えると、標準設定で使う方が楽だと思います。

　ただし、Apacheのエラーログにあまりに多くのログが残るような場合は、PHPのログは分離したいと考える方もいるでしょう。そのときはphp.iniで設定するのではなく、各バーチャルホストごとにApacheのディレクティブ「PHP_Value」（第36回参照）を利用して、バーチャルホストごとにログファイルを設定するとよいでしょう。ディレクトリごとにログファイルを分けることもできます。

どのエラー情報が必要なのか？

　これまでに例として挙げてきたエラーを知らせるログをよく見ると、冒頭が「PHP Fatal error」となっているものと「PHP Warning」になっているものの2種類があることが分かります。UNIX/Linuxのsyslogにはerror、warning、noticeなど、エラーの深刻さを示すレベルがあることをご存じの読者も多いと思いますが、PHPのログにも、同じようなレベル分けがあるのです。

　とはいえ、PHPの場合はレベルというよりも、種類といった方が適切です。syslogのレベルは上下関係が成立していて、例えば「warning以上のエラー」というような表現で設定したり、技術者同士コミュニケーションしたりできますが、PHPではそうは行きません。それぞれのログの種類に上下関係はないのです。

　PHPがどのような種類のログを残すのかということは、PHPのマニュアルで確認できます。「エラー処理」の中の「定義済み定数」の部分をご覧ください（図2）。それぞれのエラーの種類は、定義済みの定数として表すようになっています。例えば「E_ERROR」は1、「E_WARNING」は2、「E_PARSE」は4、という具合です。この値を指定して、どの種類のログを出力させるかを設定できます。

図2　PHPがログに残すメッセージには4種類ある。クリックすると拡大

　定数の値が、1、2ときて次が3ではなく4になっていますが、これはビットフィールドで保持する値であるからです。1、2、4のそれぞれを2進数にすると、1、10、100となります。1になっている部分（けた）が、ログの種類を表しているのです。例えば、「E_PARSE」と「E_ERROR」を選択したと考えてください。それぞれを指し示す2進数のけたを1にすると、101になります。これは、十進数にすると5です。5を設定すると、この2つを指定したことになります。こういった値の使い方を、ビットフィールドと呼びます。

　この2進数の計算は、ビット演算子で表現できます。「E_PARSE」と「E_ERROR」であれば「|」というビット演算子で結合し、「E_PARSE | E_ERROR」のようにします。すべての種類のログを出力したいときは、定数をすべて「|」で連結すれば良いのですが、PHPはかなり多くの種類のログを出力するので、ビット演算ですべてを表現するのは面倒です。そこで別途、「E_ALL」という、すべての種類のログを表す定数が用意されています。

　PHP 5.3系では、正確には「E_ALL」はすべてのログではなく「E_STRICT」が除いたものを指します。すべてのログを指定するには「E_ALL | E_STRICT」としなければなりません。5.4系になると「E_ALL」だけですべてのログになります。

　開発中はすべてのログを表示するようにしておき、ささいな警告も見逃さない環境を作るのが理想です。最終的には警告が出なくなるように開発することで、バグをつぶせます。しかし、既存のアプリケーションを利用するときなどは、警告が大量に出ることがあります。このような場合は、ログ出力を抑止したいと考えることもあるでしょう。

　そういったときは「E_ALL」からいくつかの種類のエラーを除いて、エラーを出力させるようにするのです。この指定もビット演算子でできます。「E_ALL & ~E_NOTICE」とすると「E_ALL」から「E_NOTICE」を取り除くという意味になります。なお、「E_ALL | E_STRICT」から取り除きたい場合は、「(E_ALL | E_STRICT) & ~E_NOTICE」とします。「|」と「&」では、「&」の方が優先順位が高いので、カッコで優先順位を変えなくてはならないためです。

　E_NOTICEと指定すると、エラーとは言えないが、「バグにつながる可能性がある」という程度の警告も出します。出力が大量にになるようなら、上記の手法で絞り込むと良いでしょう。

まとめ

　ここまで説明してきた内容を反映させると、php.iniの記述は次のようになります。

memory_limit = 32M
max_execution_time = 30
expose_php = Off
magic_quotes_gpc = Off
variables_order = GPCS
register_long_arrays = Off
register_argc_argv = Off
post_max_size = 64K
max_input_vars = 100
upload_tmp_dir = /home/uploads
upload_max_filesize = 1
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL | E_STRICT

　次回は、ファイルの取り扱いを決める設定について解説します。

←←連載第1回へ｜｜←前回へ｜第41回｜

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード

http://rss.rssad.jp/rss/artclk/_k62OMKmdUr3/9fab6de9080f159e72744c5b8c7a9cdf?ul=pJ7Dtc7e2wGv_qTKUrAnJiWQY_qph7IsNz2thFn.Q2oO_VownoYlIiLWTJ13Sywj9koc6QdyfXAbLEFNJPbuROEKPLub 　日本オラクルは1月31日、ミッド／ハイエンドのユニファイドストレージ「Pillar Axiom 600」を提供開始したと発表、併せて国内におけるストレージビジネスの強化を発表した。　Axiom 600は、高ストレージI/O用途に向けたストレージ製品。同社の既存製品「Su…

]]> 2012-02-01T15:25:00+09:00

Tweet

NewsInsight

国内におけるストレージ事業を強化へ

アプリに最適化できるオラクルのストレージ、「Plliar Axiom」とは

2012/02/01

　日本オラクルは1月31日、ミッド／ハイエンドのユニファイドストレージ「Pillar Axiom 600」を提供開始したと発表、併せて国内におけるストレージビジネスの強化を発表した。

　Axiom 600は、高ストレージI/O用途に向けたストレージ製品。同社の既存製品「Sun ZFS Storage Appliance」が高コストパフォーマンスと拡張性／柔軟性でクラウドサービス事業者に評価されているのに対し、企業向けアプリケーションで安定した性能が要求される場面に向けた製品という。従って、この製品における最大の力点は、高スループットとQoS管理だ。特に、アプリケーション単位で、ストレージI/OのQoSを最適化できる点をウリとしている。

　Axiom 600は独特な構成を持つ。Axiomで「Slammer」と呼ばれるストレージコントローラは、SAN／NASインターフェイス、デュアルのコントローラCPU、I/O制御エンジン、および48GBのキャッシュを備えるが、RAIDコントローラは持たない。

　RAIDコントローラ（こちらも少量キャッシュを備える）はドライブエンクロージャにつけられており、これを「Brick」と呼んでいる。SlammerとBrickをブロックのように組み合わせて、スケールアウト的に拡張できる（ほかに管理モジュールも必要）。Slammerは1システムに4ユニットまで増設可能。1筺体に2つのRAIDコントローラと、12あるいは13基のドライブを備えたBrickは、1システムに64ユニットまで増設できる。

「Slammer」「Brick」などを組み合わせて構成する

　Slammerには、アクセスプロトコルによってFibre Channel、iSCSI、NAS（CIFS／NFS）の3種類がある。Brickには、搭載する記憶媒体により、Fibre Channel、SATA、SSDの3種類がある。

　Axiom 600では、利用するアプリケーションそれぞれに対し、優先度（「Premium」「High」「Medium」など）とI/O特性（「シーケンシャル」「ランダムリード重視」「ランダムライト重視」など）を設定する。これに応じ、このアプリケーション用のLUN／ボリューム作成時に記憶媒体（SSD、FC、SATAのいずれか）、RAIDレベル（RAID5あるいはRAID10）、ストライプドライブ数が決まる。さらに、SlammerのコントローラのCPUサイクルおよびキャッシュ占有率が設定される。特定アプリケーションのトラフィックに、別個のSlammerを割り当てることもできる。Axiomでは、1つのLUN／ボリュームを1つのアプリケーションが利用することを前提としている。すなわち、結果的にはLUN／ボリュームに対して優先度を割り当てていることになる。

アプリケーションに基づき、CPUやキャッシュの利用率、ストライプドライブ数、ドライブタイプなどを設定してQoSを確保する

　こうした設定に基づき、Axiomはストレージアクセスを受けると、そのアクセス先LUN／ボリュームに応じ、適切な優先度を適用して処理する。

　なお、ストレージトラフィックの増減を自動的に監視し、これによって優先度を動的に変更するような機能はないようだ。また、ミッド／ハイエンドのストレージで一般化しつつある自動階層化管理のような、記憶媒体の階層間でデータブロックを自動的に移動する機能もない。すなわち、SSDを使う設定がなされた（アプリケーションのデータを管理する）LUN／ボリュームは、トラフィックパターンがどう変わろうともSSDを使い続けることになる。

　だが、決算処理時期などで特定アプリケーションの優先度を上下したい場合には、そのアプリケーションのQoS設定を管理者が変更すると、これに応じてCPUやキャッシュ利用の優先度が自動的に再設定され、さらに管理者が望む場合には適切な記憶媒体にデータを自動移行することが可能。

　アプリケーションの特性に応じたQoS設定については、主要アプリケーションのテンプレートを用意しているという。

　Axiom 600は、このほかにシン・プロビジョニング、ストレージの論理分割（ドメイン分割）、LUNや NASファイルシステムの複製、スナップショットなどの機能を持つ。オラクル製品に対応した機能としては、ハイブリッドカラム圧縮への対応、Oracle Enterpirse Managerからの管理、Oracle VM管理ツールからの管理、他のオラクルストレージ製品との統合による階層型ストレージの構築、などがあるという。

　Pillar Axiom 600の日本市場における展開として、日本オラクルはまず自社による直接提案で、導入実績を積み上げるつもりという。パートナーについては、既存パートナーに働きかける一方、Axiomに特化したパートナープログラムを拡充していくという。

　日本オラクルは、ストレージ関連製品としてAxiomのほかに、前述のZFS Storage Appliance、そして旧ストレージテックの「StorageTekテープ・ストレージ」を持っている。特にテープ装置は安定的な売り上げを見せているようだ。だが、旧サンマイクロシステムズの販売パートナーが離れていってしまっているのではないかという問いに、日本オラクル 執行役員 システム事業統括の野々上仁氏は、製品の魅力でパートナーの支持を取り戻したいと答えた。

（＠IT 三木泉）

情報をお寄せください：

TechTargetジャパン

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード

キャリアアップ

RSSリーダーで読むために変換しています

まるごとRSS

]]>