ApacheのCGIモードでは、ウェブマスターはメモリ使用量を減らすことができます。 それは多くの低い交通ウェブサイトを動かす好まれた方法である。
しかし、CGIモードは、アクセス許可やファイルエンコーディングなどのものにかなり敏感であり、500内部サーバーエラーにつながります。
ウェブホストのサポートエンジニアとしての私たちの役割では、このエラーの原因の広い範囲を見てきました。
いくつかの一般的な原因とその修正は次のとおりです:
- 間違ったファイルまたはフォルダの権限–スクリプトファイルとディレクトリには正確に755の権限が必要です。 一部のサーバーでは、ディレクトリに750のアクセス許可が必要な場合があります。
- 所有権が間違っています（ユーザー&グループの問題）–ファイルの所有権は、Apacheの設定に応じて”USER:ApacheUser”または”USER:USER”に設定する必要があります。
- 不正なエンコード–バイナリモードでアップロードされたファイルは実行に失敗し、ASCIIとして再アップロードする必要があります。
エラー500の問題のほぼ80％は、これらの修正によって解決されます。
この記事は、見つけて修正するのが難しい原因の残りの20％についてです。
Apache CGI内部サーバーエラーの珍しい原因
500内部サーバーエラーは、webサーバーの「ページを表示しようとしたときに何か問題が発生しました。 何がわからない。”
許可や所有権の問題ではない場合、アプリケーションのバグ&Apacheの設定ミスからファイアウォールブロック&ファイルシステムエラーまで、何でも可
ここでは、私たちが仕事の過程で見てきたトップ10の珍しい問題があります。
不足しているモジュール
Webアプリケーションは、特定の機能のために多くのPHPまたはPerlの”モジュール”に依存しています。
そのようなモジュールの中には、標準的なサーバー設定の一部ですが、多くはそうではありません。
移行後や新しいwebサイトのセットアップ中に、必要なモジュールがすべて存在しないためにスクリプトが失敗することがよくあります。
エラーログには、”未定義の”関数があるか、”メソッド”が存在しないと表示されます。
これを修正するには、アプリの要件仕様を確認し、不足しているすべてのモジュールをインストールします。
ネットワークタイムアウト(API呼び出し、リモートスクリプトなど))
一部のwebアプリは、リモートサーバーからデータを取得します。 気象データ）。
何らかの理由でリモートサーバーへの接続が中断された場合、webアプリはしばらく待ってからタイムアウトエラーを表示します。
Apacheはこの状態をエラー500として報告します。
この問題は、ログエントリを残さない可能性があるため、トラブルシューティングが困難な場合があります。
私たちは、長い保留中の発信接続を検査することにより、タイムアウトの問題を検出し、発信接続を必要とするアプリの機能を無効にすることによ
古いプログラム(コンパイラ)パス
すべてのCGIアプリ(Shebangと呼ばれる)の最初の行には、それを実行するはずのプログラムへのパスが含まれています。
Perlスクリプトには次のパスがあります:
#!/usr/bin/perl
ただし、このパスは、オペレーティングシステムのベンダーやカスタムコンパイル設定に応じて異なる場合があります。
したがって、スクリプトは特定の場所にあるプログラムファイルを検索し、そこに見つからない場合、スクリプトはエラー500を表示します。
二つの効果的な方法は次のとおりです:
- サーバー環境で定義されたパスを使用する–すべてのプログラムのパスは、サーバーの”環境”変数に格納されます。 したがって、次のように、環境を呼び出すことによって最初の行を変更します:
#!/usr/bin/env perl- これにより、Perlが設定されている場所に関係なく、スクリプトのパスが使用できるようになります。
- Apacheの設定でプログラムパスを定義する–Apacheの”AddHandler”ディレクティブと”Action”ディレクティブを使って、適切なプログラムですべてのファイルを実行します。 例えばのために。 PHPをCGIとして設定する方法は次のとおりです:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
アプリケーションコードのエラー
ウェブサイトの所有者は、アプリケーションや設定ファイルの編集中に”;”を削除したり、浮遊文字を挿入したりするなど、
これにより、アプリケーションの実行に失敗しますが、Apacheは不可解な”Internal Server Error”メッセージのみを吐き出します。
ログファイルを分析することでこのような問題を検出し、コードエラーを修正するか、エラーの原因となっているplugin/addon/themeを無効にすることで解決します。
間違ったモジュールパスを持つ古い設定ファイル
Webサイトは、多くの場合、サーバーの環境とプログラムパス用にカスタマイズされています。
サイトが移行されると、その構成ファイルにはこれらの古いパスが含まれますが、これは新しいサーバーと互換性がない可能性があります。
webアプリケーションがカスタム設定ファイル（phpなど）を使用するケースを見てきました。ini)ライブラリ関数をロードします。 これは、新しいサーバーでパスが変更されると失敗します。
そのような場合、ハードコードされたプログラムパスを削除し、代わりに環境変数を使用してプログラムの場所を自動的に取得します。
セキュリティ制限(Webアプリケーションファイアウォール、SELinuxなど))
最近のほとんどのサーバーは、mod_securityやComodoWAFなどのWebアプリケーションファイアウォールを持っています。
これらのファイアウォールは、ページ要求を攻撃として解釈すると、エラー500を引き起こす可能性があります。
外部ファイル呼び出しがmod_securityによるリモートファイル包含攻撃として解釈されたため、webアプリが失敗するのを見てきました。
このような場合、サーバーのセキュリティには影響しませんが、アプリがブロックされなくなるように、カスタムファイアウォール除外ルールを作成します。
SELinux設定を”Enforcing”から”Permissive”に変更すると、このエラーを修正するのにも役立ちました。
パーティションにExec(実行なし)制限なし
CGIアプリはプログラムとして実行されます。
そのためには、”実行”特権と呼ばれるものが必要です。
この”実行”権限は、マルウェアの実行を防ぐために、”/tmp”などのパブリックアクセス可能なパーティションと”/backup”などのデータストアパーティションに対してオフ
ウェブサイトのホームでこの”実行”ビットがオフになっているため、スクリプトの実行が失敗するケースが見られました。
:
# mount -o remount,exec /home
アパッチ&htaccessの設定ミス（ExecCGIなし、AllowOverrideなしなど）)
ApacheはどのディレクトリにCGIスクリプトが含まれているかを知る必要があります。
これはディレクティブ”ExecCGI”を使用して示されます。
/cgi-bin/をCGIディレクトリとして表すには、Apacheは次のように設定する必要があります:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
一部のサーバーでは、Apache confファイルまたはanの設定ミスのためにcgi-binで”ExecCGI”が無効になっているのを見てきました。親ディレクトリ内のhtaccess。
同様に、CGI関連のディレクティブを見てきました。htaccessが無効になっているため。apache設定の”AllowOverride”ディレクティブでhtaccessが有効になっていませんでした。
このすべてがスクリプトの実行に失敗し、結果としてエラー500になる可能性があります。ホームディレクトリ
間違ったアクセス許可
CGIディレクトリは、通常、ホームディレクトリ内に配置されます。 例えばのために。 cPanelサーバーのcgi-binへのパスは次のとおりです:
/home/username/public_html/cgi-bin/
多くのウェブマスターは、cgi-binディレクトリとwebアプリケーションディレクトリの許可を755に変更するように注意しますが、ホームディレクトリの許可を確認することを忘れてしまいます。
いくつかのApache設定では（例えば。 SuExecを使用している場合は、ホームディレクトリにも755の権限が必要です。 それ以外のもの（例えば。 777)では、スクリプトの実行が失敗します。
だから、我々はスクリプトファイルの権限と一緒にチェックする最初のものの一つは、ファイルのパス内のすべてのディレクトリの権限をチェッ
私たちは、スクリプトがエラーなしで実行されることを確認するためにちょうどそれのすべてを設定します。
ファイルパスを壊すChroot関連のエラー
一部の共有サーバーでは、各ユーザーを投獄された環境に限定することによってセキュリティが強制されます。
これにより、あるユーザーが他のユーザーのファイルにアクセスできなくなります。
しかし、そのような環境では、プログラムファイルへのソフトリンクを壊す可能性があります。
プログラムが”/opt/php/bin/”に格納されていて、”/usr/bin/php/”からリンクされている場合、それらの参照が壊れてしまう可能性があります。
これらは非常にまれなケースであり、ソフトリンクの代わりに正しいパスを使用するようにサーバー（またはサイト）を再設定することで修正します。