Назад | Перейти на главную страницу

Что мне следует использовать для виртуального хостинга - suphp или mod_php?

Я рассматриваю возможность использования suphp. Кажется, что вновь созданные файлы в php получают право собственности на apache.apache, и это может стать проблемой. Также кажется, что мониторинг отправленного спама и загрузки с помощью скриптов php легче контролировать с помощью suphp.

Однако я боюсь, что это снизит производительность серверов. Я использую панель управления Plesk и DirectAdmin для серверов и размещаю около 200 доменов на каждом сервере, но я не хочу видеть сильного увеличения нагрузки при использовании suphp. Также я не уверен, что suphp - это просто причудливое имя для php через cgi.

suphp

mod_php

Итак ... предлагает ли suphp повышенную безопасность? и предлагает ли он много преимуществ в мониторинге угроз (спам), тестировании (добавление скриптов php) и т. д.? И насколько велик сток в производительности?

suphp - это не то же самое, что PHP, есть ряд функциональных отличий.

Запуск стандартного интерфейса CGI намного медленнее, чем у модуля fastCGI / webserver. AFAIK suphp не поддерживает fastCGI, но теперь есть версия модуля apache. Он предоставляет некоторые настройки безопасности, которые недоступны в стандартном PHP, однако последний в этом отношении не совсем плох. Наиболее важные вопросы заключаются в том, согласны ли вы поддерживать программное обеспечение из архивов и будут ли ваши пользователи довольны версией PHP, которая отстает от официальной версии по своей функциональности.

Какую бы версию вы ни выбрали, она обеспечит только ту степень безопасности, которую вы настроили. Если вы выбрали стандартный PHP, убедитесь, что:

1) вы устанавливаете open_basedir, чтобы ограничить пользователей их собственными каталогами

2) вы можете отключить allow_url_fopen

3) обязательно отключите allow-url-include

4) если вам нужна очень строгая система, отключите eval и create_function

5) установите для каждого пользователя include_path

6) измените sendmail_path, чтобы он указывал на сценарий оболочки, который регистрирует используемую учетную запись (вы должны иметь возможность решить это из cwd) и квоты imlpements

7) установите session.save_path для каждого пользователя

Мне ничего не известно в suphp, что конкретно касается спама, но вы можете легко добавить свой собственный сценарий оболочки, как описано выше. Обратите внимание, что большинство описанных выше шагов будут применяться к suphp to - это просто упрощает добавление параметров в директивы файла конфигурации, а не заменяет их в конфигурации apache или через .htaccess.

Я рекомендую использовать ИТК МПМ вместо. Вам нужно будет запустить отдельный VirtualHost для каждого пользователя, но вы все равно можете это делать. Однако, если вы используете mod_userdir, вам не повезло, и вам придется использовать suphp для правильного разделения.