Debian vs FreeBSD

пробовал. но объясняльщик из меня - никакой.

мне проще удалённо, без КВМ, ОС переставить =))

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

А еще всегда можно dget http://.../bla-bla...dsc; cd bla-bla*/; vi debian/; debuild; Во фре не короче, макефайл все-равно править придется, если захотите сделать шаг в сторону.

Вообще-то, "настройками" программ принято управлять в конфигурационных файлах, а не в момент компиляции (последнее как-бы не самый хороший тон). И к базовым настройкам в debian есть универсальный фронтенд debconf, а во фре...?

Ой. Тады плохо. Ведь весь Ваш карточный "все так как у апстрима" - разваливается.

Если можно так нижнюю грань числа воркеров поставить в 0 - это прокатит. Если нет - никакого быдлохостинга за < 1$ не получится.

И Вы в дальнейшем отвечаете за такой сетап? С черти-каким оборудованием. Или по принципу "настроил и забыл"?

Ну, т.е. если кривая поддержка ОС данного оборудования вызывает проблемы в эксплуатации - Вы будете все это бесплатно чинить?

Некоторые пакеты нельзя сконфигурить, будучи собранными - например, модули nginx, путь до suexec, и так далее.

Тем не менее, до gcc-4.5.1-vanilla, linux-2.6.35-vanilla и прочего я обновился без проблем, и искал баги уже там.

А это уже зависит от умений :)

1) Технически можно, конечно. Собрать несколько разных пакетов nginx с кастомными наборами модулей (под работу nginx разными ролями). Уж такой он nginx - вечная бета, что с него взять. Надеюсь, что со временем может быть поддержка подгружаемых модулей. Хотя есть большая вероятность, что до релиза оно никогда и не доживет, будет вечное 0.xxxx.

2) Немного непонятно, зачем кому-то "путь до suexec" менять?

Я имел в виду - знаете ли Вы готовое решение, которое это "умеет"?

Если брать предложенное - "запустить своего апача под каждого клиента", то там такого нету.

>1) Технически можно, конечно. Собрать несколько разных пакетов nginx с кастомными наборами модулей (под работу nginx разными ролями). Уж такой он nginx - вечная бета, что с него взять. Надеюсь, что со временем может быть поддержка подгружаемых модулей. Хотя есть большая вероятность, что до релиза оно никогда и не доживет, будет вечное 0.xxxx.

Под N модулей -- 2^n пакетов :) Разработчик весьма ясно объясняет в рассылке, почему на данный момент нет возможности делать выносные модули.

>2) Немного непонятно, зачем кому-то "путь до suexec" менять?

А путь до suexec, например, нужно менять, если хочется держать сайты не /var/www, а в /home. (точнее, это не путь до suexec, а путь внутри него).

Давайте уже перестанем заниматься снисхождением от абстрактного к конкретному, а займёмся восхождением от конкретного к абстрактному :)

>Я имел в виду - знаете ли Вы готовое решение, которое это "умеет"?

>Если брать предложенное - "запустить своего апача под каждого клиента", то там такого нету.

Если брать готовый апач, то он и не умеет разбиваться на несколько пользователей, и балансироваться между ними :) Всегда придётся писать конфиги или скрипты. В данном случае я даже представляю, как это делать без модификации кода апача или nginx.

Можно поправить даже прямо в бинарнике =)

Не, меньше. Я же сказал, роли. Ну какие могут быть роли у nginx? Прозрачный прокси (только HTTP, аналог для imap+pop можно вынести отдельно) и/или кеширующий - один/два пакета. Бакенд (там встроенный перл есть, не забыли?). Какой-нить специализированный тип хостинга, например "свой ютуб". И т.п. Наборы модулей будут встроенны перекрывающиеся в чем-то, естественно. Наконец, сборка где "все-все-все".

Вот это (поста Игоря я сходу не нашел)?

Из перечисленного только стабильный ABI является реальной "проблемой" для nginx. Вытекающий из сказанного выше про то, что он вечная бета (или альфа - на вкус и цвет...).

А это меняется на ура в дебиане, например. Бинарником, который "немного умеет быть конфигурируемым" (пакет apache2-suexec-custom).

Плюс есть еще варианты решения проблемы (bind mounts например), без ковыряний в исходниках suexec.

Ничего там не нужно править "в бинарнике", нужно знать где правильный мёд ;)

Я думал имелась в виду более простая ситуация. 1 простой скрипт - "пускальщик" апача под всю пачку пользователей (по одному на каждого) + конфиг nginx, который проксирует обработку своих виртуалхостов соответствующим апачам.

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

Как прибить такого апача под пользователем - понятно, по бездействию. А вот как запустить - менее очевидно. Есть гипотеза, что сработает какой-то вариант на proxy_next_upstream. Т.е. если апач у юзера прибит - направляем запрос сначала на универсальный upstream, который "пускает" нужный бакенд (судя по виртуалхосту), затем снова на этот бакенд. Но это вариант как-то, того... Не поделитесь что Вы имели в виду?

>Под N модулей -- 2^n пакетов

Не, меньше. Я же сказал, роли. Ну какие могут быть роли у nginx? Прозрачный прокси (только HTTP, аналог для imap+pop можно вынести отдельно) и/или кеширующий - один/два пакета. Бакенд (там встроенный перл есть, не забыли?). Какой-нить специализированный тип хостинга, например "свой ютуб". И т.п. Наборы модулей будут встроенны перекрывающиеся в чем-то, естественно. Наконец, сборка где "все-все-все".

Но не будете же Вы говорить, что это - удобнее, чем make config?

>Из перечисленного только стабильный ABI является реальной "проблемой" для nginx. Вытекающий из сказанного выше про то, что он вечная бета (или альфа - на вкус и цвет...).

0) Вообще, Вы нашли достаточно старый пост. Было в англ. рассылке недавно.

1) ABI меняется даже от ключей конфигурации - например, функции для openssl/pcre/md5, члены структур для них же, и из-за этого не получается бинарной совместимости.

2) И, наконец, архитектура заточена именно под такое использование. Не надо делать из nginx apache, достаточно взять apache (c) кто-то.

>А это меняется на ура в дебиане, например. Бинарником, который "немного умеет быть конфигурируемым" (пакет apache2-suexec-custom).

А откуда он берёт конфигурацию? Если из какого-то файла, то это - потенциальная уязвимость.

Если он, как предложил himiko, пишет по какому-то оффсету нужное значение, то это костыль, а не конфигурируемый бинарник.

>Как прибить такого апача под пользователем - понятно, по бездействию. А вот как запустить - менее очевидно. Есть гипотеза, что сработает какой-то вариант на proxy_next_upstream. Т.е. если апач у юзера прибит - направляем запрос сначала на универсальный upstream, который "пускает" нужный бакенд (судя по виртуалхосту), затем снова на этот бакенд. Но это вариант как-то, того... Не поделитесь что Вы имели в виду?

Мне виделся вариант с

location / { proxy_pass user_backend; error_page 402 = @start_backend; }

location @start_backend { fastcgi_pass starter; fastcgi_param USER username; fastcgi_param URI $request_uri; }

starter.pl:

...

start_backend($user)

print "X-Accel-Redirect: ${uri}"

...

Но можно придумать и более красивые варианты и работающие с POST варианты, используя всякие фичи вроде ssi, или простой модуль.

Можно сделать какой-нибудь простой враппер, который будет слушать все вхосты, тупо проксировать бит-в-бит и проверять запущенность/нагрузку на какой-то сокет, и лично я, скорее всего, так бы и сделал.

Спорно. Если сделать по-уму, грамотно разбить на такие роли - может быть и удобнее. Просто ставим нужный пакет и конфигурируем модули в нем.

Мейнтейнера ждет, конечно, известный геморой в написании правил сборки - но это ведь его проблемы, а не конечных пользователей.

Там принципиальное что-то пропущено?

Т.е. единственная реальная проблема - переменчивый 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.

а вы не отвечаете за вашу работу?

=======

если клиент чё-то начал крутить и отломал - то саппорт платный.

а если я настроил отдал в эксплуатацию - значит работа стабильная. и падать может только по причине смерти железа/действия хозяина сервера

или не так?

P.S.

чинят - только штаны. всё остальное - ремонтируют.