次のガイドを使用して、LinodeからUbuntu 10.04サーバーにLEMP(Linux、Nginx、MySQL、およびPHP)をセットアップします。 http://library.linode.com/lemp-guides/ubuntu-10.04-lucid ==
基本的に、私はPHPスクリプトを/srv/www/mysite.com/public_html
で指定されたディレクトリ(/etc/nginx/sites-available/mysite.com.conf
)にアップロードしました。
ブラウザでサイトにアクセスすると、500内部サーバーエラーが発生します。 PHPコードにエラーがあると思いますが、これは問題ありません。ただし、PHP、FastCGI、Nginxのコンポーネントがいくつかあるため、これをデバッグする方法がまったくわかりません。 。
私の質問は、これらのエラーをブラウザに表示する方法、または少なくともログに表示して、何が起こっているのかを把握できるようにする方法です。 Nginxにエラーをどこかにログに記録するように指示する必要があるのか、FastCGIに指示する必要があるのか、php.iniを編集する必要があるのかわかりません。
私はこれを解決するためにサーバーへのフルルートアクセス権を持っています。ただし、私が従ったガイドではある種のデーモンを使用しているため、PHP/FastCGIを再起動する方法がわかりません(Nginxを再起動する方法は知っていますが)。
あなたが私に与えることができるどんな助けにもたくさん感謝します。
短い答え:
最も可能性の高いシナリオは、Nginxでわずかな設定ミスがあり、その結果、PHP-FPMに誤ったパスが送信されることです。ルートディレクティブがロケーションブロックの外側にあることを確認し、fastcgi_intercept_errors
をオンにして、error_logの詳細度を上げ(通知など)、詳細についてはそれらのログを参照してください。
長い答え-問題の診断
まず、私はUbuntuの人間ではありません(CentOSの人間です)。そのため、いくつかのパス/パッケージがオペレーティングシステムに固有のものではない場合は、ご容赦ください。
あなたが言ったように、あなたは一緒に働く必要があるあなたのセットアップに複数の部分があります。
診断へのこのアプローチでは、物事をシンプルに保ちたいと思います-WordpressのようなCMSをロードしようとしてテストしないでください-1つの独立したファイルが必要です。
テストファイル:
静的-「test.txt」というテキストファイルを使用してみましょう。
test.txt:
Hello world
PHP-phpinfo()関数を使ってみましょう。
test.php:
<?php
phpinfo();
?>
Nginxのテスト:
Nginxが静的ファイルを提供できる場合は、基本的なセットアップとソフトウェアが機能していることを確認できます。
server {
listen *:80 default;
server_name mysite.com www.mysite.com;
root /srv/www/mysite.com/public_html;
error_log /var/log/nginx/mysite.com/error.log notice;
access_log /var/log/nginx/mysite.com/access.log main;
}
言及のいくつかのポイント:
「test.txt」を「/srv/www/mysite.com/public_html」にコピーし、ユーザー「nginx」(nginxが実行されるデフォルトのユーザー)が読み取り可能であることを確認します。644の権限で十分です。 public_htmlより上のすべてのディレクトリに「other」に対する「execute」権限があることを確認してください(つまり、「other」はディレクトリ構造をトラバースできます)。
構成の変更を有効にするためにNginxを再起動します(必要に応じて、再起動する代わりに再読み込みできます)。
Nginxをセットアップしたのと同じサーバーからテストします。
curl --header "Host: mysite.com" 127.0.0.1/test.txt
ここで注目すべき点:
理想的には、上記のコマンドは「Helloworld」(テキストファイルに入力したテキスト)を返します。
PHP:
PHPが正しく機能することを確認するのはかなり簡単です:
Public_htmlフォルダーにファイル「test.php」(上記のとおり)を作成し、次のコマンドを実行します。
php /srv/www/mysite.com/public_html/test.php
PhpInfo()ページに通常表示されるすべての情報を含む長い出力が得られるはずです。
上記が機能しない場合:
display_errors
をオンにして、php.iniファイルのerror_reportingの詳細度を上げます(まず、php -i | grep 'Loaded Configuration'
を使用して適切なphp.iniファイルを見つけます)これで、PHPと簡単なテストファイルが機能することを確認できたと思います。
PHP-FPM:
残念ながら、FastCGIはプレーンテキストを「話す」ことはありません。ここで私たちを助けるために通訳が必要です。 cgi-fcgi
バイナリが必要です。 (CentOSでは、EPELのパッケージ「fcgi」で入手できます。Ubuntuには同じものを提供するパッケージlibfcgi
があると思います)。
cgi-fcgi
は環境変数を読み取り、FastCGIプロセスマネージャー(PHP-FPM)に正しい要求を渡します。
まず、PHP-FPMを設定しましょう。デフォルトのグローバルオプションでほぼ十分ですが、ロギングを有効にします。デバッグ時には、入手できる限り多くの情報が必要です(デフォルトのログプレフィックスは/ varです)。
error_log = log/php-fpm.log
log_level = notice
以下を指定して、基本プールを設定します。
[www]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 2
user = nginx
group = nginx
(もちろん、TCPリスナーの代わりにソケットを使用することはできますが、おそらくそうすべきですが、このアプローチはテストが簡単です(つまり、アクセス許可の問題が少ない)-明らかに、そこにあることを確認してください選択したポートをリッスンするだけです)ローカルマシンのみにアクセスを許可し、プロセスマネージャーの基本を設定し、プールに所有者を与える必要があります(もちろん、後でニーズに合わせて変更します)オン)。
service php-fpm restart
が機能します(実稼働環境でこれを行う必要がある場合は、代わりにreload
を使用してください)。 (/etc/init.dにそのためのinitスクリプトがあるかもしれません)以下を実行します。
SCRIPT_NAME=/test.php \
SCRIPT_FILENAME=/srv/www/mysite.com/public_html/test.php \
QUERY_STRING= \
REQUEST_METHOD=GET \
cgi-fcgi -bind -connect 127.0.0.1:9000
ここでは、PHP-FPMにファイルへのパス、ファイル名、および要求タイプ(GET)を通知し、cgi-fcgiに適切なホストとポートに接続するように指示しています。
以前と同じ出力が返されるはずですが、今回はphpバイナリを直接使用する代わりに、FastCGIを使用しました。これが機能する場合は、セットアップの各コンポーネントが正常に検証されています。
エラーが発生した場合は、/ var/log /php-fpm.logでエラーログを確認してください
すべてをまとめる:セットアップの各部分が機能する場合は、すべての部分が一緒に機能することを確認する必要があります。実際、ここに残っているのは1つの部分だけです。つまり、NginxにFastCGIを介して通信させることです。
最も単純な形式では、既存のnginxサーバーブロックに単一のロケーションブロックを追加するだけで済みます。
location ~ \.php {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
}
これをサポートするには、ファイル 'fastcgi_params'がかなり重要です。本当に重要な行は次のとおりです。
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
実際には、必要なFastCGIディレクティブをロケーションブロック内に直接含めることができますが、より複雑な設定を行うと、外部ファイルを保持する方がはるかに簡単であることがわかります。ここで、パスは$ document_rootに依存することに注意してください。ロケーションブロックの外側で正しく設定されていない場合(ルートディレクティブ)、通常、セットアップで問題が発生します。
一部のセットアップでは、次のような行も必要になる場合があります。
fastcgi_split_path_info ^(.+\.php)(/.+)$;
FastCGIセットアップエラーをデバッグするための便利なディレクティブの1つは、fastcgi_intercept_errors On
です。これにより、エラー(ファイルが見つからないなど)がnginxによってログに記録されます。
最後に、nginxを介してPHPページをロードしてみてください:
curl --header "Host: mysite.com" 127.0.0.1/test.php
うまくいけば、phpinfo()の出力が得られます。そうでない場合は、問題がnginxセットアップにあることがわかっています(他のすべてのコンポーネントはそれ自体で動作するため)nginxエラーログのチェックを開始します。この時点で、問題を特定するのに十分な情報がログに記録されているはずです。