| 1.1, Salvator (?), 09:55, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Может, туплю с утра, но разве такой функционал не дают стандартные средства апача? suexec + vhost_alias ... | | |
| 1.4, Phil Kulin (?), 10:24, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Скажи мне дорогой друг, я правильно понимаю, что предложенный вариант отличается твоего же от варианта пятилетней давности наличием некоего нового аналога mod_vhost_alias (я, кстати, не понимаю, почему ещё никто этого не сделал :) и тем, что keepalive теперь принимаются? Если это так, я сейчас твой roadmap раскритикую. Я ещё когда честно украл по ещё не убитым ссылкам на тот древний вариант алгоритм работы имел много чего сказать :) | | |
| |
| 2.13, Дмитрий Котеров (?), 12:19, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Нет, неправильно. Отличия от варианта пятилетней давности:
1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
2. Порождение потомков происходит асинхронно, что значительно ускоряет обработку запросов - делает ее более "гладкой", т.к. апач сам умеет следить за тем, чтобы в наличии всегда находилось несколько "свободных" апачей.
3. Даже этот асинхронный fork делается не на каждый запрос, а на каждое соединение - для типовых случаев это в 5-10 раз быстрее (по числу картинок на средней странице).
4. Нету дыры в безопасности с register_shutdown_function в mod_php, которая была в патче пятилетней давности (из-за которой этот патч и был убран, собственно). Ее там даже чисто теоретически быть не может. | | |
| |
| 3.15, Phil Kulin (?), 12:50, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
1. Это я понял.
2. А можно чуток подробнее про асинхронные форки? (не хочу в код лезть без пояснений).
Я чего хотел сказать... Некоторая проблема есть с fork(). Конечно, fork() (как и пять лет назад) делается действительно странно и забавно, но практика показывает, что в нашем случае это помогает слабо. Не знаю как в твоей практике, а я с форком так и не смог заставить работать адекватно apache. 15qps для него предел, на котором он начинает заниматься самодиспетчеризацией. KeepAlive вроде даже и действительно сильно помог бы... но пять лет назад. При том, что сейчас чуть ли не большинство посетителей сайтов - роботы поисковиков... все ли они этот самый keepalive держат? Тоже самое с акселераторами - весь смысл keepalive на уровне apache пропадает при наличии того же nginx.
Я много думал на эту тему. Единственный хороший универсальный вариант, который я вижу - писать свой MPM, который работать примерно как perchild, но при этом держать в запасе только те процессы, к которым часто обращаются. Туда же можно воткнуть систему всяких ренайсов и т.п. Но пока я думал, хостинг как отрасль повернулась на путь в небытие - когда я додумаю, слово "хостинг" будет странным понятием из прошлого, а в индивидуальном порядке это всё не нужно :) Опоздал. | | |
| |
| 4.20, Michael Shigorin (?), 17:22, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Тоже самое с акселераторами - весь смысл keepalive на
>уровне apache пропадает при наличии того же nginx.
А высказанные соображения касательно предела касаются одного apache?
>когда я додумаю, слово "хостинг" будет странным понятием из прошлого
В смысле виртуальный?
Я почему спрашиваю (c) Печкин: с одной стороны, поддерживаю apache-1.3 в ALT Linux, с другой -- весной выходит серверный 4.0, в пререлизах которого ovz VE делаются из веб-морды. | | |
| |
| 5.27, Phil Kulin (?), 20:38, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Тоже самое с акселераторами - весь смысл keepalive на
>>уровне apache пропадает при наличии того же nginx.
>А высказанные соображения касательно предела касаются одного apache?
Хм? Ну да. Один апач на одном сервере. Целерончик что ли у меня тогда был 2.4GHz...
>>когда я додумаю, слово "хостинг" будет странным понятием из прошлого
>В смысле виртуальный?
Да. Он уже есть "паровой автомобиль", просто люди ещё об этом не знают.
| | |
|
| 4.22, Дмитрий Котеров (?), 20:06, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
При наличии nginx также практически пропадает вероятность, что вы - хостер, а не отдельный крупный проект с единственным пользователем httpd, которому и стандартного апача вполне достаточно. :-) | | |
| |
| 5.24, Michael Shigorin (?), 20:16, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>При наличии nginx также практически пропадает вероятность, что вы - хостер, а
>не отдельный крупный проект с единственным пользователем httpd, которому и стандартного
>апача вполне достаточно. :-)
Ну почему, я вот -- хостер (специфический -- бесплатно хостим проекты free software), и существованию/работе nginx очень даже рад. ;-) | | |
| 5.25, Phil Kulin (?), 20:32, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> При наличии nginx также практически пропадает вероятность, что вы - хостер
Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука на непредсказуемых нагрузках. | | |
| |
| 6.30, eSupport.org.ru (?), 08:20, 03/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
>nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
>на непредсказуемых нагрузках.
Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и поливайте бабушку :)
| | |
| |
| 7.31, Phil Kulin (?), 10:26, 03/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
>>nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
>>на непредсказуемых нагрузках.
>Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и
>поливайте бабушку :)
Да и замечательно. Это намного лучше, чем демонстрация не имеющих художественной ценности песочных часов. Это 5xx-фобия меня всегда удивляла. Чёткая ошибка против неясного ожидания...
| | |
| 7.32, Michael Shigorin (?), 11:35, 03/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох
А нектррые, междпррочим, ещё и monit выписывают... :) | | |
|
|
|
|
| 3.19, вуглускр (?), 16:29, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Нет, неправильно. Отличия от варианта пятилетней давности:
>1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
Означает ли это что он памяти жрет еще больше чем просто апач? Ж8-О | | |
|
|
| |
| 2.14, Дмитрий Котеров (?), 12:37, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие существенные отличия, я не знаю. Если кто-то увидит - пишите сюда. | | |
| |
| 3.16, гость (?), 13:16, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние
>процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать
>так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие
>существенные отличия, я не знаю. Если кто-то увидит - пишите сюда.
>
Как обстоят дела с модулем user_dir, который "управляет" домашними каталогами владеьцев?
Коих (владельцев) может быть гораздо больше чем вирт.хостов.
Как обстоят дела владельцами, которые не пользователи данной юникс-системы, а например из LDAP? | | |
|
|
| 1.9, аноним (?), 11:36, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
mpm-itk тормозит, что не намного лучше простого cgi.
fastcgi выигрывает в пару раз | | |
| |
| 2.10, Аноним (-), 11:54, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>mpm-itk тормозит, что не намного лучше простого cgi.
>fastcgi выигрывает в пару раз
Хуже, что он память при большом числе виртуальных хостов кушает страшно. Минимум один висящий процесс на пользователя.
Как я понял dkLab патч заставляет дочерние процессы обрабатывать запрос работая под root. Нет в жизни счастья.
| | |
| |
| 3.11, Phil Kulin (?), 12:06, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Под root работает только начальная дочка. Обработка уже идёт под пользователем. Не вижу ничего страшного. Основной процесс апача тоже под root работает и никого это не пугает. Естественно, есть небольшое отличие в том, что здесь владелец назначается динамически, но несколько проверок в код дают определённую уверенность. | | |
| |
| 4.12, q (??), 12:12, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Зачем под рутом?
Достаточно под рутом открыть сокеты 80 и 443 и потом понизить привилегии, chroot, fork, и новые непривилегированные дочерние процессы. Тогда вообще не будет рутовских процессов (только на момент запуска) | | |
| 4.17, si (?), 14:18, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить remote root. | | |
| |
| 5.26, Phil Kulin (?), 20:35, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– |
>главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить
>remote root.
Не давайте рута ни при каких обстоятельствах. Все карты в руках - перед setuid проверяйте на кого setuid делаете. | | |
| |
| 6.28, si (?), 22:34, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
причем ту давайте/ не давайте, я несколько о другом
тот child который разбирает заголовки, ищет какой это vh и делает set*id() работает под рутом. заголовки он получает от клиента, следовательно если будет ошибка в коде разбора заголовков, то потенциально удаленно можно получить рута. кстати упомянутый вами master процесс иметь от рута вполне безопасно потому что он с внешним миром никак не связал и удаленно его уронить намного сложнее.
| | |
|
|
|
|
|
| |
| 2.23, Дмитрий Котеров (?), 20:08, 02/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Тем, что не нужно ставить модуль ядра. А также тем, что не нужно молиться, чтобы какое-нибудь переполнение буфера в mod_php не заставило выполниться setuid-функции. | | |
|
| |
| 2.33, Дмитрий Котеров (?), 13:12, 03/04/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Я считаю, что "нафиг оно". Потому что замучаешься для chroot-а окружение готовить и потом за ним следить. В него же должны войти все утилиты хостинга - perl там, python и т.д. А разделение прав на уровне пользователей в Unix и так работает прилично, без всякого chroot-а.
Что касается виртуального хостинга - я вот тоже последние несколько лет думал, что это "паровая машина", которая скоро канет в лету (потому и не публиковал патч, в частности). Но больной все еще скорее жив, чем мертв, и в ближайшие годы я не вижу, чтобы тенденция серьезно изменилась.
По поводу разбора заголовков под рутом - там достаточно простой код в апаче, вероятность того, что за 5 лет в нем появилась уязвимость, достаточно маленькая. Так что тут просто некуда деваться - все остальные патчи и модули тоже под рутом разбирают заголовки (за исключением разве что тех, что работают через модуль ядра, но у них свои тараканы с setuid-функциями). | | |
| |
| 3.34, Gregory Veritikov (?), 09:24, 31/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Что касается виртуального хостинга - я вот тоже последние несколько лет думал,
> что это "паровая машина", которая скоро канет в лету
все это реально, вот делают же nginxhosting.com
| | |
|
|
|
