URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 91926
[ Назад ]

Исходное сообщение
"Разница между PHP as CGI & suPHP"

Отправлено dmitry_sairus , 11-Июл-11 19:27 
Подскажите какая разница между запуском php как cgi и использования модуля suphp? Где лучше использовать тот или иной вариант?

Содержание

Сообщения в этом обсуждении
"Разница между PHP as CGI & suPHP"
Отправлено PavelR , 11-Июл-11 21:15 
> Подскажите какая разница между запуском php как cgi и использования модуля suphp?

в первом случае скрипты должны содержать shebang-line (#!/usr/bin/php)
Или надо использовать mod_action.

//mod_action example:

    ScriptAlias /php5-cgi /usr/bin/php-cgi
    Action php5-cgi /php5-cgi
    AddHandler php5-cgi .php

(ну и suexec в обязательном порядке, это добавляет интересных моментов :-) )


suphp делает "грязную работу" самостоятельно, а также он содержит различные бонусные доп-фичи.


> Где лучше использовать тот или иной вариант?

Попробуйте...



"Разница между PHP as CGI & suPHP"
Отправлено dmitry_sairus , 12-Июл-11 00:10 
Спасибо)
> suphp делает "грязную работу" самостоятельно, а также он содержит различные бонусные доп-фичи.

Может подскажите где почитать об этих фичах, вдруг они перевесят над CGI.

Я в данный момент использую ИСП Панель и там как раз устанвлен php as cgi, но к примеру в доках CPanel рекомендуют использовать suPHP (О CGI сказано: This method is neither fast nor secure, regardless of whether or not suEXEC is enabled. - что очень насторожило)

Что скажете?


"Разница между PHP as CGI & suPHP"
Отправлено PavelR , 12-Июл-11 08:43 
> Спасибо)
>> suphp делает "грязную работу" самостоятельно, а также он содержит различные бонусные доп-фичи.
> Может подскажите где почитать об этих фичах, вдруг они перевесят над CGI.
> Я в данный момент использую ИСП Панель и там как раз устанвлен
> php as cgi, но к примеру в доках CPanel рекомендуют использовать
> suPHP (О CGI сказано: This method is neither fast nor secure,
> regardless of whether or not suEXEC is enabled. - что очень
> насторожило)
> Что скажете?

ну оно не fast, хотя имхо suPHP не много быстрее (по принципу работы)  - бенчмарки можете сделать самостоятельно :-)

насчет secure - я не знаю, какие там могут быть проблемы если оно под suexec.

читать - google и оф сайты... конкретного из "статей" порекомендовать не могу.


"Разница между PHP as CGI & suPHP"
Отправлено dmitry_sairus , 14-Июл-11 18:20 
>[оверквотинг удален]
>> php as cgi, но к примеру в доках CPanel рекомендуют использовать
>> suPHP (О CGI сказано: This method is neither fast nor secure,
>> regardless of whether or not suEXEC is enabled. - что очень
>> насторожило)
>> Что скажете?
> ну оно не fast, хотя имхо suPHP не много быстрее (по принципу
> работы)  - бенчмарки можете сделать самостоятельно :-)
> насчет secure - я не знаю, какие там могут быть проблемы если
> оно под suexec.
> читать - google и оф сайты... конкретного из "статей" порекомендовать не могу.

Может тогда еще приемущества apache-itk по сравнению с suphp расскажете, насколько видно с описаний - и то и другое запускает процессы от имени пользователя. Видел много советов ставить именно itk, какие Ваши взгляды на это?



"Разница между PHP as CGI & suPHP"
Отправлено PavelR , 15-Июл-11 14:20 
> Может тогда еще приемущества apache-itk по сравнению с suphp расскажете, насколько видно
> с описаний - и то и другое запускает процессы от имени
> пользователя. Видел много советов ставить именно itk, какие Ваши взгляды на
> это?

Честно говоря я itk не ставил. Его плюсы не только в сравнении с suphp. По идее, оно сможет крутить и остальные mod_ - mod_perl, mod_python и какие там еще надо - от имени нужных пользователей - для меня это основной плюс, хотя в данный момент я предпочитаю fastcgi-стыковку на своих мелких хостингах. Это позволяет делать легкий оверселл (неиспользующиеся процессы прибиваются, что в среднем позволяет поэкономить память :-) )

Не помню, как в itk обрабатываются статические файлы. Если статика также отдается рабочим процессом, который работает от имени пользователя сайта - то это также повысит безопасность:

- процесс не сможет открыть по симлинку файлы недоступные пользователю (в стандартном апаче - FollowSymlinks какбэ на самом-то деле архитектурно-дыряво-неотключаемая фича и один пользователь может прочитать любой файл любого другого пользователя  данного хостинга (пусть и через race condition))

минус - когда то считалось нестабильным :-) На практике не запускал ни разу. Только сравнивал различные исходники...