>> Глянул в википедии и ничем энджин от вебсервера отличить не смог :(
>>
>> А разве для разгрузки мало разных лоадбалэнсеров? Тот же апачи прекрасно
>> справится с этой задачей. Давайте тогда исключим из энджина всю
>> функциональность, которая где-то уже реализована? Будет шустрее, меньше
>> багов и... меньше случаев применения энджина, вплоть до его бесполезности.
>> Абсурдно, неправда ли?
>>
>> Лично я (Игорь и Вы видете это иначе) вижу в энджине отличную замену апачи.
>> И нет, всю функциональность передёргивать не нужно. Но выборочно не помешает
>> и нахожу возможность устанавливать UID/GID весьма хорошей фичей независимо
>> от реализации в других продуктах.
>>
>> Кстати, не лекарство ли от http://forum.nginx.org/read.php?21,63166 ?
>>
> Дело в том, что nginx внутри устроен немного по-другому, чем apache с
> некоторые другие вебсервера. Поэтому он не сможет сделать setuid() для
> обработки запроса и генерировать конфиг на лету из .htaccess.
>
Я во внутрь не заглядывал, так как, к сожалению, недостаточно
разбираюсь. Но разве нельзя запускать воркеров под нужным UID, которые
будут обрабатывать соответствующие запросы? Я всего лишь хочу избежать
множество мастеров и init скриптов для каждой инстанции энджина.

Про хтэкцес - это отдельная тема. Комманды "перечитать конфиги" вполне
достаточно. Как и достаточно не разрешать эдитировать части конфига
(=инклуды) юзерам напрямую. (Но если у кого есть
фронт-энд/враппер/утилита/туль/whatever для подобного - тоже вэлкам).
> У всего есть границы применимости, и у nginx она уже четко
> обозначилась - высокая нагрузка, >=1 сервера на проект
>

Физического сервера? Да, без порно. А что же со многими, малькими
проектами, которые весьма вписываются в ресурсы одного сервера, если
апачи заменить на энджин? Я просто не люблю плодить софт и потому есть
аццкое желание отказаться от апачи вовсе.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru