dkLab Apache (http://dklab.ru/lib/dklab_apache/) - это дистрибутив для тех, кто собирается использовать Apache в Unix для обслуживания нескольких полностью независимых друг от друга сайтов, работающих под разными, полностью разграниченными друг от друга пользователями Unix.
По сути это Apache 1.3.34, на который наложены некоторые "самодельные" патчи. Вот функциональность, которую они добавляют:- Запуск различных виртуальных хостов под различными Unix-пользователями. То, под каким пользователем работает виртуальный хост, задается в его стандартных директивах User и Group. Все скрипты, включая скрипты для mod_php, CGI и т. д., работают с правами указанного пользователя и группы и не могут получить доступ к файлам другого виртуального хоста. Долой safe_mode и проблемы с правами доступа в PHP!
- Возможность создавать виртуальные хосты по шаблону: ABC.example.com -> /home/example/ABC. Вы можете ссылаться в директиве DocumentRoot на нужную часть доменного имени, например, так: /home/example/$-3+ (в данном примере это будет /home/example/ABC). Просто создайте директорию, чтобы добавить на сайт новый поддомен!
- Модуль mod_rewrite защищен от любого рода "зацикливаний". Неосторожно или злонамеренно написанные директивы в .htaccess не могут "подвесить" весь сервер.
URL: http://dklab.ru/lib/dklab_apache/
Новость: http://www.opennet.me/opennews/art.shtml?num=10329
Может, туплю с утра, но разве такой функционал не дают стандартные средства апача? suexec + vhost_alias ...
Ага, тупишь. Как ты через suexec прикрутишь mod_php?
mod_php не дает стандартные средства.
Скажи мне дорогой друг, я правильно понимаю, что предложенный вариант отличается твоего же от варианта пятилетней давности наличием некоего нового аналога mod_vhost_alias (я, кстати, не понимаю, почему ещё никто этого не сделал :) и тем, что keepalive теперь принимаются? Если это так, я сейчас твой roadmap раскритикую. Я ещё когда честно украл по ещё не убитым ссылкам на тот древний вариант алгоритм работы имел много чего сказать :)
Нет, неправильно. Отличия от варианта пятилетней давности:
1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
2. Порождение потомков происходит асинхронно, что значительно ускоряет обработку запросов - делает ее более "гладкой", т.к. апач сам умеет следить за тем, чтобы в наличии всегда находилось несколько "свободных" апачей.
3. Даже этот асинхронный fork делается не на каждый запрос, а на каждое соединение - для типовых случаев это в 5-10 раз быстрее (по числу картинок на средней странице).
4. Нету дыры в безопасности с register_shutdown_function в mod_php, которая была в патче пятилетней давности (из-за которой этот патч и был убран, собственно). Ее там даже чисто теоретически быть не может.
1. Это я понял.
2. А можно чуток подробнее про асинхронные форки? (не хочу в код лезть без пояснений).Я чего хотел сказать... Некоторая проблема есть с fork(). Конечно, fork() (как и пять лет назад) делается действительно странно и забавно, но практика показывает, что в нашем случае это помогает слабо. Не знаю как в твоей практике, а я с форком так и не смог заставить работать адекватно apache. 15qps для него предел, на котором он начинает заниматься самодиспетчеризацией. KeepAlive вроде даже и действительно сильно помог бы... но пять лет назад. При том, что сейчас чуть ли не большинство посетителей сайтов - роботы поисковиков... все ли они этот самый keepalive держат? Тоже самое с акселераторами - весь смысл keepalive на уровне apache пропадает при наличии того же nginx.
Я много думал на эту тему. Единственный хороший универсальный вариант, который я вижу - писать свой MPM, который работать примерно как perchild, но при этом держать в запасе только те процессы, к которым часто обращаются. Туда же можно воткнуть систему всяких ренайсов и т.п. Но пока я думал, хостинг как отрасль повернулась на путь в небытие - когда я додумаю, слово "хостинг" будет странным понятием из прошлого, а в индивидуальном порядке это всё не нужно :) Опоздал.
>Тоже самое с акселераторами - весь смысл keepalive на
>уровне apache пропадает при наличии того же nginx.
А высказанные соображения касательно предела касаются одного apache?>когда я додумаю, слово "хостинг" будет странным понятием из прошлого
В смысле виртуальный?Я почему спрашиваю (c) Печкин: с одной стороны, поддерживаю apache-1.3 в ALT Linux, с другой -- весной выходит серверный 4.0, в пререлизах которого ovz VE делаются из веб-морды.
>>Тоже самое с акселераторами - весь смысл keepalive на
>>уровне apache пропадает при наличии того же nginx.
>А высказанные соображения касательно предела касаются одного apache?Хм? Ну да. Один апач на одном сервере. Целерончик что ли у меня тогда был 2.4GHz...
>>когда я додумаю, слово "хостинг" будет странным понятием из прошлого
>В смысле виртуальный?Да. Он уже есть "паровой автомобиль", просто люди ещё об этом не знают.
При наличии nginx также практически пропадает вероятность, что вы - хостер, а не отдельный крупный проект с единственным пользователем httpd, которому и стандартного апача вполне достаточно. :-)
>При наличии nginx также практически пропадает вероятность, что вы - хостер, а
>не отдельный крупный проект с единственным пользователем httpd, которому и стандартного
>апача вполне достаточно. :-)
Ну почему, я вот -- хостер (специфический -- бесплатно хостим проекты free software), и существованию/работе nginx очень даже рад. ;-)
> При наличии nginx также практически пропадает вероятность, что вы - хостерМда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука на непредсказуемых нагрузках.
>Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
>nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
>на непредсказуемых нагрузках.
Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и поливайте бабушку :)
>>Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
>>nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
>>на непредсказуемых нагрузках.
>Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и
>поливайте бабушку :)Да и замечательно. Это намного лучше, чем демонстрация не имеющих художественной ценности песочных часов. Это 5xx-фобия меня всегда удивляла. Чёткая ошибка против неясного ожидания...
>Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох
А нектррые, междпррочим, ещё и monit выписывают... :)
>Нет, неправильно. Отличия от варианта пятилетней давности:
>1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
Означает ли это что он памяти жрет еще больше чем просто апач? Ж8-О
Читайте маны по fork, ключевые слова "copy on write".
http://packages.debian.org/unstable/net/apache2-mpm-itk
Очень внушительное хорошее и подробное описание...
действительно, а чем это лучше, чем apache2 с mpm-itk?
То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие существенные отличия, я не знаю. Если кто-то увидит - пишите сюда.
>То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние
>процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать
>так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие
>существенные отличия, я не знаю. Если кто-то увидит - пишите сюда.
>Как обстоят дела с модулем user_dir, который "управляет" домашними каталогами владеьцев?
Коих (владельцев) может быть гораздо больше чем вирт.хостов.Как обстоят дела владельцами, которые не пользователи данной юникс-системы, а например из LDAP?
Спасибо за mpm-itk, буде пробовать.
mpm-itk тормозит, что не намного лучше простого cgi.
fastcgi выигрывает в пару раз
>mpm-itk тормозит, что не намного лучше простого cgi.
>fastcgi выигрывает в пару разХуже, что он память при большом числе виртуальных хостов кушает страшно. Минимум один висящий процесс на пользователя.
Как я понял dkLab патч заставляет дочерние процессы обрабатывать запрос работая под root. Нет в жизни счастья.
Под root работает только начальная дочка. Обработка уже идёт под пользователем. Не вижу ничего страшного. Основной процесс апача тоже под root работает и никого это не пугает. Естественно, есть небольшое отличие в том, что здесь владелец назначается динамически, но несколько проверок в код дают определённую уверенность.
Зачем под рутом?
Достаточно под рутом открыть сокеты 80 и 443 и потом понизить привилегии, chroot, fork, и новые непривилегированные дочерние процессы. Тогда вообще не будет рутовских процессов (только на момент запуска)
главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить remote root.
>главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить
>remote root.Не давайте рута ни при каких обстоятельствах. Все карты в руках - перед setuid проверяйте на кого setuid делаете.
причем ту давайте/ не давайте, я несколько о другомтот child который разбирает заголовки, ищет какой это vh и делает set*id() работает под рутом. заголовки он получает от клиента, следовательно если будет ошибка в коде разбора заголовков, то потенциально удаленно можно получить рута. кстати упомянутый вами master процесс иметь от рута вполне безопасно потому что он с внешним миром никак не связал и удаленно его уронить намного сложнее.
а чем это отличается от mod_suid?
Тем, что не нужно ставить модуль ядра. А также тем, что не нужно молиться, чтобы какое-нибудь переполнение буфера в mod_php не заставило выполниться setuid-функции.
А может еще добавить что-нить вроде DocumentChroot или нафиг оно?
Я считаю, что "нафиг оно". Потому что замучаешься для chroot-а окружение готовить и потом за ним следить. В него же должны войти все утилиты хостинга - perl там, python и т.д. А разделение прав на уровне пользователей в Unix и так работает прилично, без всякого chroot-а.Что касается виртуального хостинга - я вот тоже последние несколько лет думал, что это "паровая машина", которая скоро канет в лету (потому и не публиковал патч, в частности). Но больной все еще скорее жив, чем мертв, и в ближайшие годы я не вижу, чтобы тенденция серьезно изменилась.
По поводу разбора заголовков под рутом - там достаточно простой код в апаче, вероятность того, что за 5 лет в нем появилась уязвимость, достаточно маленькая. Так что тут просто некуда деваться - все остальные патчи и модули тоже под рутом разбирают заголовки (за исключением разве что тех, что работают через модуль ядра, но у них свои тараканы с setuid-функциями).
> Что касается виртуального хостинга - я вот тоже последние несколько лет думал,
> что это "паровая машина", которая скоро канет в летувсе это реально, вот делают же nginxhosting.com