че, в упор не видим failcnt в выводе /proc/user_beancounters ?
в других vps лимиты те же, или настроено как-то иначе чем в этой? Другие тарифные планы и т.п.
смотрим документацию по openvz, конкретно по проблемному параметру. что это такое, с чем его едят и как исправить лимиты для контейнеров.
Спорно. Если сделать по-уму, грамотно разбить на такие роли - может быть и удобнее. Просто ставим нужный пакет и конфигурируем модули в нем.
Мейнтейнера ждет, конечно, известный геморой в написании правил сборки - но это ведь его проблемы, а не конечных пользователей.
Там принципиальное что-то пропущено?
Т.е. единственная реальная проблема - переменчивый ABI.
Вот я в последнее время и беру апач в типичной роли nginx-а, как прокси перед фронтендом :) Работает (c event mpm) не сильно хуже nginx, без "сюрпризов", которые время от времени сопровождают обновление последнего до новой "стабильной" версии. В squeeze можно будет искаропки такое делать даже на одном сервере (т.е. держать пару апачей с разными MPM; фронтенд/бакенд, к примеру).
Из файла. Риск есть, наверно, но читающий этот файл код достаточно примитивен, что дырку там подозревать сложно. Разве где-то в недрах stdio функций...
Вот весь патч, если интересно:
http://svn.debian.org/wsvn/pkg-apache/trunk/apache2/patches/202_suexec-custom.dpatch
Но есть и другие варианты решения - я их упоминал. Сборка своего suexec, как Вы предложили - вариант самый последний, по-хорошему.
X-Accel-Redirect - хорошая идея. Думаю, с учетом этого - годится решение с proxy_next_upstream. Если бакенд юзера не запущен - следующий универсальный бакенд как раз выполняет что-то вроде Вашего "скрипта". В общем-то, должно работать и с POST.
Это кто-то пожадничал денюшку заплатить, чтобы сервер грамотно настроили и обслуживали, а не решали проблемы телепатически.
Не, меньше. Я же сказал, роли. Ну какие могут быть роли у nginx? Прозрачный прокси (только HTTP, аналог для imap+pop можно вынести отдельно) и/или кеширующий - один/два пакета. Бакенд (там встроенный перл есть, не забыли?). Какой-нить специализированный тип хостинга, например "свой ютуб". И т.п. Наборы модулей будут встроенны перекрывающиеся в чем-то, естественно. Наконец, сборка где "все-все-все".
Вот это (поста Игоря я сходу не нашел)?
Из перечисленного только стабильный ABI является реальной "проблемой" для nginx. Вытекающий из сказанного выше про то, что он вечная бета (или альфа - на вкус и цвет...).
А это меняется на ура в дебиане, например. Бинарником, который "немного умеет быть конфигурируемым" (пакет apache2-suexec-custom).
Плюс есть еще варианты решения проблемы (bind mounts например), без ковыряний в исходниках suexec.
Ничего там не нужно править "в бинарнике", нужно знать где правильный мёд ;)
Я думал имелась в виду более простая ситуация. 1 простой скрипт - "пускальщик" апача под всю пачку пользователей (по одному на каждого) + конфиг nginx, который проксирует обработку своих виртуалхостов соответствующим апачам.
Далее апачи плодят себе сколько позволено детей для обработки запросов. Но минимум один апач под каждого пользователя - вынужден жить.
Как прибить такого апача под пользователем - понятно, по бездействию. А вот как запустить - менее очевидно. Есть гипотеза, что сработает какой-то вариант на proxy_next_upstream. Т.е. если апач у юзера прибит - направляем запрос сначала на универсальный upstream, который "пускает" нужный бакенд (судя по виртуалхосту), затем снова на этот бакенд. Но это вариант как-то, того... Не поделитесь что Вы имели в виду?
"такие ошибки", да не такие...
Это нормально, что "апатч прерывает соединение"? По-моему, от хорошей жизни он такого делать не должен. А неумение обнаружить проблему не является критерием того, что ее "нету".
rm -rf /
:D
Шутко.
man yum
man rpm
- вот правильные команды
Никакого. Не нужно это менять, пока Вам не объяснят зачем (а объяснять выше - отказались).
Вы поняли, какой ответ дали на вопрос?
Нда уж. Правильное - это когда Вы как минимум понимаете что делаете.
1) Технически можно, конечно. Собрать несколько разных пакетов nginx с кастомными наборами модулей (под работу nginx разными ролями). Уж такой он nginx - вечная бета, что с него взять. Надеюсь, что со временем может быть поддержка подгружаемых модулей. Хотя есть большая вероятность, что до релиза оно никогда и не доживет, будет вечное 0.xxxx.
2) Немного непонятно, зачем кому-то "путь до suexec" менять?
Я имел в виду - знаете ли Вы готовое решение, которое это "умеет"?
Если брать предложенное - "запустить своего апача под каждого клиента", то там такого нету.
Так и хорошо, что нельзя. Зато то, что рулится обычно настройками портов (менюшкой) - как правило, есть в бинарных дистрибутивах в альтернативных версиях пакетов. Т.е. штатным образом ставите себе нужный пакет.
А еще всегда можно dget http://.../bla-bla...dsc; cd bla-bla*/; vi debian/; debuild; Во фре не короче, макефайл все-равно править придется, если захотите сделать шаг в сторону.
Вообще-то, "настройками" программ принято управлять в конфигурационных файлах, а не в момент компиляции (последнее как-бы не самый хороший тон). И к базовым настройкам в debian есть универсальный фронтенд debconf, а во фре...?
Ой. Тады плохо. Ведь весь Ваш карточный "все так как у апстрима" - разваливается.
Если можно так нижнюю грань числа воркеров поставить в 0 - это прокатит. Если нет - никакого быдлохостинга за < 1$ не получится.
И Вы в дальнейшем отвечаете за такой сетап? С черти-каким оборудованием. Или по принципу "настроил и забыл"?
Ну, т.е. если кривая поддержка ОС данного оборудования вызывает проблемы в эксплуатации - Вы будете все это бесплатно чинить?
