FastCGI

Имеется spawn-fcgi (не настроен или его не надо настраивать).

Насколько я понимаю, php должен быть собран с поддержкой FastCGI
Как узнать собран он с поддержкой или нет?

Далее есть nginx, в нем нужно прописать порт для fastcgi верно?

http://www.howtoforge.com/nginx_php5_fast_cgi_xcache_ubuntu7.04

Что-то я совсем запутался...
Выше описанное пока отложу... попробую пока так:

У меня стоит Plesk в нем я указал использовать PHP не как mod apache, а как FastCGI
Что мне это дает? Снижение нагрузки или выполнение быстрее скриптов PHP?

>Что мне это дает? Снижение нагрузки или выполнение быстрее скриптов PHP?

У mod_php м php-fast-cgi скорость ноздря в ноздрю.

Выигрышь обычно получают на том, что Апач сам по себе на статике тормоз. А lighttpd или nginx отдают статику много быстрее. Но они работают только с fast-cgi. Отсюда и предпочтения к последнему.

По скорости:

mod_php = fast-cgi

но:
mod_php + static/apache < fast-cgi + static/(lighttpd|nginx)

Ааа... теперь понятно!
У меня еще стоит nginx на статику, могу ли я перевести nginx сразу не не на apache, а на fast-cgi?

[root@ddd ~]# php-cgi -v
PHP 5.1.6 (cgi-fcgi) (built: Jan 21 2009 01:35:04)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

>могу ли я перевести nginx сразу не не на apache, а на fast-cgi? 

Да, но придётся повозиться побольше, чем с mod_php+apache (который
«работает из коробки») или с lighttpd+fast-cgi (там тоже всё на себя
берёт сервер).

- Нужно поднять отдельный сервер spawn-fcgi (в Gentoo отличный
вариант, как раз, с lighttpd идёт - у меня сейчас все три web-сервера
в деле и nginx работает с fast-cgi из пакета lighttpd).

- Нужно настроить nginx на соединение с ним

- Нужно будет написать следящий серверс, который будет поднимать
упавший PHP-бэкенд, т.к. сам nginx, в отличии от lighttpd за этим не
следит.

У меня скрипт простой:

/usr/bin/wget -q --timeout=5 --tries=3 --spider 'http://navy.balancer.ru/'

if [[ "$?" == "1" ]]; then
    /etc/init.d/spawn-fcgi-navy restart
    /etc/init.d/nginx restart
fi

fcgi позволяет крутить сайты от юзера отлично от того юзера из-под которого настроен апач. Есть ещё нюансы, но они не существенны.

Может, проще поставить лайти бэкендом к джину?

>fcgi позволяет крутить сайты от юзера отлично от того юзера из-под которого настроен апач

Смысла нет. Всё равно сам веб-сервер будет для всех веб-хостов статику отдавать от одного пользователя. Соответственно, полного разграничения юзеров не достичь.

Полное разграничение пока только на mpm_itk в Apache возможно. Но он (itk) тормозноооой, собака... Статика отдаётся в 10 раз медленнее, чем под чистым lighttpd :) Поэтому у себя зоопарк и держу. Для пользователей хостинга с невысокой нагрзкой - Апача. себе - Лайти и ЭнжинИкс.

>Может, проще поставить лайти бэкендом к джину?

Тогда проще один Лайти оставить :) Они ж с энджинксом - два сапога пара.

Ну и что что статика из-под одного пользователя. Это статика и один юзер не сможет посмотреть статику другого юзера.

Забыл добавить. Когда у тебя стоит nginx у тебя тоже статика отдаётся от одного пользователя :)

>Ну и что что статика из-под одного пользователя.

Можно читать чужие скрытые данные :)

>Это статика и один юзер не сможет посмотреть статику другого юзера.

Может, если делать «всё как всегда».

Чтобы web-сервер мог отдавать статику любого пользователя он должен уметь читать данные и того, и другого. В обычной системе это заставит, как минимум, поместить web-сервер и пользователей в одну группу.

Обойти можно, но геморройно - добавить web-сервер в группы всех пользователей. Ну и на каждого юзера, соответственно, свою группу делать.

>Забыл добавить. Когда у тебя стоит nginx у тебя тоже

Так мы про него и говорили :)

Если ты опечатался и имел в виду Лайти, то - да. Там такая же история. Я же говорю - они два сапога пара. Только что nginx чуть попроще, а Лайти несколько функциональнее.

А противопоставлял я им apache с mpm_itk.

> В обычной системе это заставит, как минимум, поместить web-сервер и пользователей в одну группу.

Абсолютно нет. Группа будет наследоваться автоматически от группы каталога в котором лежат файлы. Под линухом для этого надо sgid-бит поставить, под фрёй автоматом.

>Абсолютно нет. Группа будет наследоваться автоматически от группы каталога в котором лежат файлы.

Э... Ещё раз и по буквам.

Кем наследоваться?

Файлами которые будет создавать юзер.

3) The SGID bit is the same as of SUID, only the case is that it runs with the permission of the group. Another use is it can be set on folders,making nay files or folders created inside the SGID set folder to have a common group ownership.

(c) http://www.linuxquestions.org/questions/linux-general-1/what-is-sticky-bit-mo...

>Файлами которые будет создавать юзер.

И что дальше? Я, наверное, торможу, но в упор не вижу логику - как SGID поможет в этом случае.

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

При чём тут SGID. Он же только на права программы, запущенной чужим юзером влияет, как и SUID.

Покажи, где в этом рассуждении у меня ошибка?

Юзер не состоит в группе nginx. А у файлов права 640 и user:nginx. Поэтому и юзер сможет прочитать свой файл и nginx сможет. Но юзер не сможет прочитать файлы другого юзера(у которых chown anotheruser:nginx и chmod 640) потому что он не в группе nginx.

Всё, понял.

Да, реально должно работать. Нужно попробовать :) Спасибо!