共有ホスティングにsuphpまたはmod_phpを使用する必要がありますか？
Suphpの使用を検討しています。 phpで新しく作成されたファイルがApache.apacheの所有権を取得しているようで、これが問題になる可能性があります。また、phpスクリプトによる送信スパムと負荷の使用状況の監視はsuphpを使用すると簡単に監視できるようです。
ただし、これによりサーバーのパフォーマンスが低下するのではないかと心配しています。サーバーとホストにPleskとDirectAdminのコントロールパネルを使用していますが、サーバーごとに約200のドメインがありますが、suphpで負荷が大幅に増加することは望ましくありません。また、suphpがcgiを介したphpの単なる名前であるかどうかもわかりません。
suphp
- ほぼ10倍遅い？
- これはcgiの下のphpですか？ 10年前のやり方は？
- 監視が簡単で、すべてのスクリプトはユーザー名で実行されます。
- 最小権限= 640。
mod_php
- はるかに高速
- apacheとのより良い統合？
- スクリプトはApache：apacheで実行されます。
- 最小パーミッション= 64 4（！）、パスワードファイルの読み取りはopen_basedirによってのみ制限され、実際のLinuxのデフォルトのパーミッションシステムではありませんか？
それで... suphpはセキュリティを強化しますか？脅威の監視（スパム）、ベンチマーク（phpスクリプトのスパイク）などに多くの利点がありますか？そして、パフォーマンスの低下はどのくらいですか？
suphpはPHPと同じものではなく、機能上の違いがいくつかあります。
標準のCGIインターフェイスの実行は、fastCGI/webserverモジュールよりもはるかに低速です。 AFAIK suphpはfastCGIをサポートしていませんが、Apacheモジュールバージョンがあります。標準のPHPでは利用できないいくつかのセキュリティ調整を提供しますが、後者はこの点で完全に貧弱ではありません。最も重要な質問は、tarballからソフトウェアを維持することに満足しているかどうか、およびユーザーがその機能の公式バージョンよりも遅れているバージョンPHPに満足しているかどうかです。
どちらのバージョンを選択しても、構成したセキュリティと同じだけのセキュリティが提供されます。標準のPHPを決定する場合は、次のことを確認してください。
1）open_basedirを設定して、ユーザーを自分のディレクトリに制限します
2）allow_url_fopenを無効にすることをお勧めします
3）allow-url-includeを必ず無効にする必要があります
4）非常に制限の厳しいシステムが必要な場合は、evalとcreate_functionを無効にします
5）ユーザーごとのinclude_pathを設定します
6）sendmail_pathを変更して、使用されているアカウントをログに記録し（cwdからこれを解決できるはずです）、クォータを実装するラッパースクリプトを指すようにします。
7）session.save_pathをユーザーごとの場所に設定します
特にスパムに対処するsuphpの内容は何も知りませんが、上記のように独自のラッパースクリプトを簡単に追加できます。上記の手順のほとんどはsuphptoに適用されることに注意してください。これにより、Apache構成または.htaccessを介してパラメーターをオーバーライドするのではなく、構成ファイルディレクティブにパラメーターを簡単にドロップできます。
代わりに ITK MPM を使用することをお勧めします。ユーザーごとに個別のVirtualHostを実行する必要がありますが、とにかく実行している可能性があります。ただし、mod_userdirを実行している場合は、運が悪く、適切な分離を行うためにsuphpを使用する必要があります。