огромное спасибо majordomo за "подарок" на новый год

Я не очень сильна в вышеозвученных настройках. Так сапа работать будет или нет, по предварительным прогнозам? Неужели там мало саповодов на хостинге, что к ним (=нам) такое пренебрежительное отношение...

suphp - это был удачный костыль для apache 1.3, который являлся вполне сносным решением 3 года назад. На сегодня он уже устарел. Как и сам apache 1.3. Все плюшки suphp сегодня можно получить за счет других средств, которые обеспечивают более высокую производительность и являются более универсальными.

В посте выше я имел в виду apache prefork + mod_php.

itk безусловно можно использовать и проблем с правами не будет.

Вы видимо еще и в форумах не разбираетесь, представители вашего хостинга пишут своим клиентам обычно на своих форумах или в личных кабинетах через тикеты ... и.т.п, по этому тут вам мало вероятно кто-то даст ответ на указанный выше вопрос. Но вопросительные предложения начинающиеся словом "так", звучат угрожающе :D

---------- Добавлено 31.12.2012 в 03:22 ----------

Немного пруфов не помешает, всегда рад ознакомиться с новой для себя информацией.

Я использую Apache/2.2.22 + mod_suphp, это сильно плохо? ;)

Об этом только хостеру известно.

Тут дело не в сапе. Ваша сапа - это частный случай одной большой, давно известной проблемы, которой уже есть много решений. Тут дело в непонимании техническим персоналом базовых, фундаментальных вещей.

Я от них сбежал еще года два назад :)

Romka_Kharkov, вы, вероятно, не пользуетесь хостингом Мажордомо ;). Иначе вы бы знали, что отвечают они мягко говоря, не сразу. Зачастую - на следующий день.

Какие Вам нужны пруфы? Вы на архитектуру посмотрите. suPHP - это модуль апача, который занимается только тем, что в момент запроса он дергает РНР интерпретатор, ставит ему setUID и подсовывает интерпретатору скрипт для выполнения. "Дергание" интерпретатора на каждый запрос - операция накладная (в терминологии ресурсов). Поскольку каждый раз нужно "подымать" с диска в память сам интерпретатор, ворох модулей к нему, приклеивать модули к нему, лепить это все в одно целое и только после этого РНР сможет начать заниматься обработкой скрипта. Т.е. перед тем как запрос начнет обрабатываться должно пройти какое-то время, которое будет потрачено на накладные расходы - "компилирование" интерпретатора.

Совсем другая ситуация в случае ITK, который по своей сутки является префорком, который позволяет использовать mod_php. Тут алгоритм обработки несколько иной. Во-первых интерпретатор компилируется один раз - в момент запуска апача. Дальше экземпляры интерпретатора размножаются путем дешевого (в терминологии затрат ресурсов) fork'а. Во-вторых, в памяти постоянно префоркнуто несколько экземпляров. При поступлении запроса картина его обработки выглядит следующим образом: пришел запрос на выполнение скрипта, готовому интерпретатору делается setUID и передается скрипт для выполнения. Как видите накладная операция компилирования интерпретатора отсутствует.

Если провести аналогии с арендой серверов, то это примерно выглядит так:

suPHP: пришел клиент, попросил сервер в аренду. Едем к поставщику шасси, берем шасси, по пути заезжаем к другому поставщику за процессором, потом на другой конец города за винтами, звоним четвертому, просим подвезти память, приезжаем, собираем, выдаем. Клиент доволен.

prefork: Пока у нас было свободное время - мы заранее подготовили 10 серверов типичных конфигураций. Пришел клиент, попросил сервер в аренду. Оплатил и моментально получил сервер, который был установлен нами заблаговременно. Клиент счастлив.

Есть еще peruser, который префоркает уже setUID'нутые процессы, что еще более ускоряет обработку запроса. Но проблема в том, что ему нужно держать в памяти минимум один процесс на каждый виртуалхост. Что при нескольких сотнях виртуалхостов будет иметь примерно такие же последствия как если взять и просто отстрелить себе ногу. Не настолько накладен setUID, чтобы сотни апачей в памяти висели.

Тут вот еще почитать можно:

http://blog.stuartherbert.com/php/2008/01/18/using-suphp-to-secure-a-shared-server/

http://blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/

http://blog.stuartherbert.com/php/2008/03/20/using-mpm-peruser-to-secure-a-shared-server/

аналогичная проблема с мажордомо

осталось там несколько сайтов :(

написал им тоже в поддержку, лайв-чат целый день сегодня был недоступен

ответа никакого :(

Нет, не сильно. Латентность suPHP клиенты на глаз вряд ли увидят, а если и увидят, то она будет скорее всего не значительной. Разница хорошо будет видна только на графике загрузки CPU и, возможно, DISK IO.