.
WEB/DB 関連 => CMSサイト制作環境の構築 > 3.PHPをそれぞれのユーザー権限で動かすには(CentOS 6.x)
Linux 活用ガイド:目次

サーバ構築ガイド

レンタル ガイド

ショップ 構築ガイド

情報漏洩対策

PHPをそれぞれのユーザー権限で動かすには(CentOS 6.x)

引き続き、PHPをそれぞれのユーザー権限で実行させる場合の具体的な手順についてみていきます。これもサーバー管理者の視点になります。

注意:前ページの続きになります。本項の内容は、かなり限定した用途について述べています。本稿の目的はコンテンツトップから参照して下さい。一般的に推奨される内容ではありませんのでご注意下さい。

本稿で想定しているサーバー利用者の規模について

本稿はホスティングサービスのような公共のネットワーク(インターネット)を利用して第三者に提供する目的出はなく、限られたネットワーク(イントラネット)での用途、CMS を利用したサイト制作環境の構築を目的にしています。

具体的にはせいぜい十数名規模で、社内のデザイナー、制作スタッフに提供する用途を想定していますが、同じLAN内の利用においても、大学や専門学校などの教育現場では、利用者数が多く、出入りの多い場合も想定されます。

扱うユーザー数や規模に応じて、適切なアプローチは異なります。決まった方法ではないことに留意して下さい。

PHPをそれぞれのユーザー権限で動かす方法

PHPをそれぞれのユーザー権限で実行させる方法には幾つかの方法があります。

suPHP(モジュール方式)

suEXEC の PHP 版です。suEXEC は Perl(CGI)をそれぞれのユーザー権限で動かすための仕組みであり、CentOS6.x で提供される Apache でも、suEXEC がモジュールとして組み込まれています。

suPHP はこの suEXEC の PHP版に該当します。後述する CGI 方式に比べて実行時の手続きに無駄がない分、パフォーマンスの面では優れますが、本稿の導入目的や規模においては、体感するほどの差はありません。また、suEXEC を前提とした PHP-CGI の場合と違って下準備から考えると設定は容易です。

ただし、suPHP は CentOS6.x のパッケージには含まれていないので、ソースからコンパイルするか、Fedora 等からパッケージを引っ張ってくる必要があります。CentOS のメリットはやはり安定性なので、なるべく標準のパッケージで保守管理したいという観点から本稿では suPHP は採用していません。

PHP-CGI(CGI方式)

suEXEC を利用して PHP を実行させる方法です。Apache Webサーバーが suEXEC に対応していることが前提になります。

CGI の suEXEC に Wrapper して動かすため、実行時の手続き等の構造上の理由からモジュール形式に比べるとパフォーマンスの面では不利になりますが、本稿の用途や規模では体感するような大きな差がでる訳ではありません。

本稿で採用するメリットは、CentOS6.x において標準のパッケージで管理出来る点です。デフォルトでは suEXEC が動作するようになっていませんが、suEXEC は設定を変更すれば、直ぐに使えるようになっています。

ただし、既に Webサーバーを運用している場合は、suEXEC を有効にする事によって稼働している CGI に修正が必要になる場合や、ディレクトリの構成を変更する必要に迫られる可能性もあります。(後述)

従来の環境から suEXEC 環境移行時に想定される問題

suEXEC で個々のユーザー権限で実行させるときの大原則として、当該ユーザーのドキュメントルート以下に、全てのプログラムが存在している必要があります。これは suEXEC CGI も、それを利用した PHP-CGI の場合も、それぞれのユーザー権限で実行させる場合に共通するルールです。

また、CGI の場合は AP_DOC_ROOT= で指定されたディレクトリ(CentOS の場合は /var/www)以下に実行する CGI が存在している必要がありますが、/var/www を経由して実行させる PHP-CGI に関してはその必要はありません。

つまり、PHP-CGI でそれぞれのユーザー権限で PHP を動作させる場合、必ずしも /var/www 以下に PHPプログラムを置く必要はないので、それ以外のディレクトリで、ドキュメントルートを置くことは出来ますが、

そのドキュメントルートから外れたディレクトリに配置されたPHPプログラムを、Alias 指定や シンボリックなどで実行させることは出来ません。必ず、ドキュメントルート配下に設置する必要があるので注意が必要です。

suEXEC の環境を調べるには以下のようにします。

# suexec -V
-D AP_DOC_ROOT="/var/www"

AP_DOC_ROOT で表示されるディレクトリ以下に CGI が存在していないと、ScriptAlias で指定しても CGI は動作しません。ここがみそです。上記説明を整理すると以下のようになります。

●CGI の場合(suEXEC)

/var/www/user/hoge/public_html ~ DOCルート
/var/www/user/hoge/cgi-bin
× /home/hoge/public_html
× /home/hoge2/public_html (Alias、シンボリック不可)

DOCルートから外れても AP DOCルート配下なので ScriptAlias で指定すればCGI は suEXEC で動きますが、AP DOCルート配下にない CGI は ScriptAlias で指定されていても動かせません。

●PHP-CGI の場合(& suEXEC)

/var/www/user/hoge/cgi-bin ~ ここを経由してPHPを実行
/home/hoge/public_html(Doc Root)
× /home/hoge/cgi-bin (CGI動作不可)
× /home/hoge2/public_html (Alias、シンボリックPHP動作不可)

/var/www 配下に設置したプログラムを経由する形になるので、必ずしもドキュメントルートを AP DOCルート /var/www 配下に置く必要はありませんが、DOCルート /home/hoge/public_html 配下に、全てのPHPプログラムを配置する必要があります。

つまり、DOCルートから外れた場所に配置したディレクトリにあるPHPファイルを Alias 処理して動かす事は出来ません。PHP-CGI で動かす場合は、必ず DOCルート配下に配置する必要があります。

単に PHPで書かれている WordPress がそれぞれのユーザー現権限で動けばいいと言うのであれば、必ずしも AP_DOC_ROOT= で指定されたディレクトリ(CentOS の場合は /var/www)に Doc Root を置く必要はありませんが、それでは CGI は使えない事になります。

例えば、MovableType のように Perl(CGI) で書かれた CMS もありますので、これら CGI は使えません。という開発環境になってしまうので、結論として、/var/www ディレクトリ配下に、それぞれのユーザーディレクトリを配置する必要が出てきます。

他に考えられる suEXEC 環境への以降時のトラブルとして、使用中の CGI や PHP 等で書かれたプログラムの一部では、プログラム側に何らかの修正が必要になる場合が出てくる場合もあります。

こうしてみると既にある程度のサービスをLANのユーザーに提供している既存のイントラ用サーバーに対して suEXEC 等による開発環境の提供を考えた場合は、移行に伴いちょっとした作業が必要になることも想定されます。

補足:AP_DOC_ROOT(/var/www)の変更について

よくネット界隈では /home ディレクトリに AP_DOC_ROOT を変更するため、Apache をコンパイルをし直す方法について書かれてるのを見かけます。このディレクトリを変更するにはコンパイルを行う必要がありますが、一考の余地があります。

ただ、紹介されている規模や目的を考慮すれば /var/www 以下でそれぞれのユーザーのルートディレクトリを管理する方がずっと理にかなっているケースが多いように思えます。

そもそも /home ディレクトリというのは、サーバープログラムによって違いはありますが、これらの様々なユーザー毎の情報が、それぞれのユーザのディレクトリを管理しているディレクトリです。

ssh や ftp、メールディレクトリを一括してユーザーディレクトリで管理するような高機能なホスティングサービスを利用者に提供するわけでもないのに、Webサーバーの運用に限った目的で /home ディレクトリに変更するのは本稿の目的や多くの場合は適切ではないと思われるので補足します。

引き続き、PHP-CGI + suEXEC の設定手順について見ていきます。

CMSサイト制作環境の構築

bottom_mark
ページ最上部
ページ最上部 前のページ