[Typo3-UG Russia] Hosting + php-accelerator

[Michael Shigorin]

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

On Fri, Jun 17, 2005 at 04:35:39PM +0300, Dmitry Dulepov wrote:
> >   У меня все хостящиеся имеют свой логин, и все их скрипты
> >   запускаются из под них, это требование безопасности.
> Чем это лучше Апачевского юзера?

Тем, что "каждому своё", а не одной строкой находим чужие
конфиги, другой выковыриваем параметры доступа к базе,
а потом чудим чего угораздит.

> Требование должно иметь какую-то логику. В чём тут логика?
> Что конкретно достигается выполнением скрипта из под
> пользовательского логина?

Пообщайтесь с хостерами, много интересного узнаете...

> >   Я гораздо больше верю в системную безопасность, чем в
> >   безопасность на уровне PHP.
> Это из серии "Винды - плохо, Линукс - хорошо".

Разумеется.

> Нет обоснования такой "веры".

Переформулирую: это опыт, приобретённый, небось, не одной шишкой.

> А слепая вера - это плохо.

Вопросы веры и технологии вообще мешать неуместно, равно как 
и воспринимать дословно подобные пассажи.  С другой стороны,
как ещё кратко объяснить -- "тудой нэ хады, сюдой хады"?

> >   Проблема mod_php в том, что все сайты работают под одним
> >   системным логином, тем же под которым Apache, это дыряво.
> Почему именно это дыряво?

Потому что приводит к возникновению возможности неавторизованного
доступа, причём очевидной.

> В конце концов, можно сделать chroot-ed environment, будет
> доступ только к самому Апачу и каталогу пользователя...

Ха-ха.  Очень смешно, главное, что если страшными словами chroot
и vserver оперировать без понимания смысла и уровня решаемой
проблемы -- то от вышеобрисованной проблемы кохостинга это не
спасёт.  Не, поможет при разносе каждого сайта в свой кубрик, 
но тут как раз vserver (VPS) куда уместней и удобней простого
чрута.

> >   1. Никакой код модуля mинтерпретатора PHP не может
> >   навредить самому Apache, или экземпляру интерпретатора PHP
> >   другого клиента.  Более того, я могу для каждого клиента
> >   использовать его собственные настройки PHP (php.ini).
> И много клиентов имеют собственные настройки?

Обычно начиная прямо с safe_mode.

> >   2. Системно исключены проблемы параллельного выполнения
> >   кода (мы же говорим о множестве клиентов), т.к. для
> >   параллелизации используется системный механизм
> >   многозадачности, а не реализованный в mod_php.
> А в чём проблема с параллельным выполнением кода в пхп?

Этого пассажа тоже не понял.  Проблемы с множеством клиентов -- 
скорее в лимитах, (не)применимости copy-on-write для конкретного
сервера и хоста и вообще говоря -- лучше решаются фронтэндовым 
nginx, чем тюнингом апача.

(внимание тех, кому тема действительно актуальна:
http://sysoev.ru/nginx)

> >   3. Код выполняется в системном окружении пользователя и
> >   подчиняется системным ограничениям и правам установленным
> >   для него, т.е. UNIX обеспечивает безопасность.
> Ничего не мешает это сделать на уровне Апача.

Не смешно.  "Это" где-то как-то сделали в apache2, вот только 
у нас на хостинг-серверах 1.3.33 и в ближайший год это вряд ли
изменится -- слишком сырой и дырявый пока второй.

> К тогу же для Апачевского юзера обычно более жёсткие
> ограничения в системе установлены. Какие дополнительные
> ограничения устанавливаются юзеру?

"Обычно" и данный подход к устройству системы мало пересекаются.

> >   4. Даже с CGI-ем можно задосить сервак (Deny of Service),
> >   через FastCGI - сервер убить нельзя. Т.к. если не один из
> >   запущенных экземпляров интерпретатора не освободился к
> >   моменту очередного обращения, посетитель сайта (именно
> >   этого сайта) будет послан с ошибкой, сервер ничего делать
> >   не будет!
> Это не мешает устроить DoS другим путём, преимущество перед
> mod_php никакое.

Это ограничивает (регулируемо) максимальную нагрузку, создаваемую
данным конкретным виртхостом.

Вы бы хоть тему изучили прежде тем, как обрушиваться с такой
забавной критикой :-(

(нас как-то слэшдотили, хорошо, что после первой волны
с какого-то блога подготовились и дальше уже упёрлось
в канал, но трупиком не валялись)

> >   Друзья, дешевизна враг хорошего!
> Ну, да... Некоторые (несознательные) даже используют дешёвый
> (бесплатный) Линукс, потому что не знают альтернатив: Sun
> Solaris или HP-UX всего за несколько килобаксов...

Не путайте тёплое с мягким, тут:

- Linux -- хорошее (и живое);
- Solaris -- хорошее, дорогое, помирающее;
- HP-UX -- уродливое и давно мёртвое.

> Считать это хорошо, только надо иметь основания. В сети есть
> статистика по производительности разных акселераторов. Стоит её
> поискать, а потом ещё раз подумать почему используют mmcache.

Я -- по привычке.  Работает -- не трогай :)

> phpA проигрывает mmcache и достаточно сильно.

Вам выше объяснили про mod_php vs (Fast)CGI.  Я вот сказал
"спасибо" за упоминание нюансов именно с аппликейшн-серверным
сетапом и закинул это письмо десятку знакомых.

> Бардак-с у Вас, батенька... :)

Дмитрий, Вы уж примите конструктивно, но бардак -- у Вас.
Причём на понятийном уровне, уже не говорю про экспириенс
именно по части организации хостинга.

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/