nginx user

[Anton Bessonov]

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

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

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