Архитектура Apache

Это называется "статья, описывающая общие архитектурные решения Apache"?

Краткая историческая справка плюс ещё более краткий обзор httpd.conf с рекламой .htaccess :) Об архитектуре сервера ни слова.

спасибо за перевод

>Об архитектуре сервера ни слова.

не правда, слов очень много, тока их ещё не перевели :)

Оригинал статьи. Есть PDF, и много схем.

http://apache.hpi.uni-potsdam.de/document/Apache_Modeling_Project.html

Вот что что а модель безопасности в Apachie - полное **вно. И обидно то, что они никак не хотят её менять. Есть слабые попытки что-то сделать (Peruser MPM), но он ещё в стадии альфа. Отсюда следует что и модель безопасности в нем тоже в альфа стадии. Откуда следует, что кроме IIS http серверов вообще в природе нет.

Особенно если посмотреть на netcraft.com И вспомнить как весело валился IIS от бага в Unicode :)

Если говорить про обслуживание статического контента (картинок, текстов), то модель безопасности Apache вполне нормальная. Но сейчас невозможно представить себе серверное ПО без каких-либо скриптов, программ и пр. выполняющихся на стороне сервера. И для этого модель безопасности Apache не приспособлена в принципе. Разработчики модулей, выполняющих скрипты или программы на стороне сервера вынуждены выдумывать различные "костыли". Вопрос: зачем он такой вообще нужен, если статический контент может обслуживать ПО использующее более передовые технологии (kqueue, epoll) и менее нагруженые кодом и какими-то слоями абстракций типа библиотеки apr?

То, что показывает неткрафт - это не показатель. Альтернативы то apache просто нет и всё. И они как монополисты (ASF) ведут себя очень некрасиво.

мы сейчас заплачем от сочуствия твоим выдуманным проблемам.

зы. бери компилер в руки и пиши свой httpd демон

Почему это они выдуманные? Вот например vsftpd, sshd (хехе), dovecot и т.п. почемуто меняют uid и gid процесса и делает некоторые делают chroot при обслуживании клиента, а apache нет. Почему?

>Почему это они выдуманные? Вот например vsftpd, sshd (хехе), dovecot и т.п. почемуто меняют uid и gid процесса и делает некоторые делают chroot при обслуживании клиента, а apache нет. Почему?

Потому, что иначе придется на каждого клиента форкать по процессу, что приведет к катастрофическому падению производительности. И ко всему прочему - потребует часть времени работать от рута, что недопустимо с точки зрения безопасности системы.

P.S. 1) Статья тему не раскрывает

2) Все уже дано описано в

Writing Apache Modules with Perl and C

By: Lincoln Stein and Doug MacEachern

Published: O'Reilly & Associates, Inc. - March 1999 Copyright © 1999 by O'Reilly & Associates, Inc.

>Есть слабые попытки что-то сделать (Peruser MPM), но он ещё в стадии альфа.

Оно если и будет работать, то только при маленьком количесве юзеров. А для массового высокопосещаемого виртуального хостинга такая схема неработоспособна -- завалится все от неимоверного количества процессов.

Можно, конечно, сделать fork и в child process делать setuid/setgid и запускать мультитредный сервер для каждого юзера, но это все равно не выход для больших хостингов.

Зачем для каждого клиента форкать процесс?
Нужно форкать процесс для каждого виртуального хоста.
В апаче вполне отлаженая технология менеджмента процессов. Нет запросов - киляем детей. Есть запросы - форкаем дополнительных.

Зачеми работать от рута? данные о запросе можно передавать через сокет от мультиплексора работающего от непривилегированного пользователя к процессам обработчикам, которые в процессе создания уже поменяли uid и gid.

Не говорите ничего о производительности апача - это тоже очень скользкая тема.

Peruser MPM у его автора работает на среднего размера хостинге. Зато это хостинг. А не тюрьма, в которой заставляют работать на апаче.

Так или иначе ASF не желает даже думать об этих вопросах. Почему?

>Зачем для каждого клиента форкать процесс? Нужно форкать процесс для каждого виртуального хоста.

Имелось в виду разумеется "клиент хостинга", то есть - хостинговая площадка, объединяющая один или более виртуальных серверов.

>Есть запросы - форкаем дополнительных.

Вот тут и начнутся проблемы, когда надо нафоркать кучу детей -- процесс этот относительно долгий и дорогой по ресурсам.

>Зачеми работать от рута? Для этого, чтобы выполнить bind (2) -- при старте и setuid(2)/setgid(2) - при переключении под пользователя.

>данные о запросе можно передавать через сокет от мультиплексора работающего от непривилегированного пользователя к процессам обработчикам, которые в процессе создания уже поменяли uid и gid.

Тогда в такой схеме (правильно ли я понял), будет один процесс (назовем master), слушаюший сокет и куча процессов (slave), гоняющих данные через master посетителю?

>Не говорите ничего о производительности апача - это тоже очень скользкая тема.

Она (производительность) весьма невысока по сравнению с thttpd /nginx / 0w-httpd. Другое дело, что перечисленные серверы имеют несколько другую нишу.

>Peruser MPM у его автора работает на среднего размера хостинге. Зато это хостинг. А не тюрьма, в которой заставляют работать на апаче.

И сколько пользователей?

Ну да неважно. Наверное, решение неплохое.

На самом деле, для проектов требующих чего-то большего, чем простой массовый вебхостинг за 5 - 15$ в месяц, проще (и логичнее) поставить выделенный сервер или завести виртуальную машину и не иметь проблем с безопастностью, масштабируемостью и ресурсами.

Ну создание виртуальных машин для каждой хостинговой площадки это конечно не ресурсоемкое решение. И для каждой площадки нужен будет реальный IP адрес, которые стремительно заканчиваются в адресном пространстве Internet I.

Что такое "простой" "массовый" хостинг? Почему я даже за эти деньги $5 - $10 должен "мучаться" в тюрьме? Зачем в mod_php и mod_perl всякие костыли типа safe mode? С решением проблемы setuid/setgid решится так много проблем и появится возможность добавить так много возможностей.... мечта!

>Ну создание виртуальных машин для каждой хостинговой площадки это конечно не ресурсоемкое решение. И для каждой площадки нужен будет реальный IP адрес, которые стремительно заканчиваются в адресном пространстве Internet I.

Разумеется, ресурсоемкое. И, конечно, будет нужен IP. Однако таких пользователей, которым нужна целая виртуальная машина / выделенный сервер гораздо меньше тех, кому вполне подходит простой массовый вебхостинг. Более того, реальных IP адресов не так уж и мало, если рассматривать проблему вебхостинга. Во всяком случае, ПОКА их вполне хватает.

> Разумеется, ресурсоемкое. И, конечно, будет нужен IP

TIP of the day: используйте SQUID в качестве front end и тогда можно хоть 1000 апачей на один ip посадить. У нас же сидит :)

>TIP of the day: используйте SQUID в качестве front end и тогда можно хоть 1000 апачей на один ip посадить. У нас же сидит :)

Причем тут акселератор в виде Squid?

Разговор шел про то, что существующая схема неудобная, а попытки выхода из ситуации не решаются при помощи Apache.

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

Дело в том, что можно запускать множество апачей на одном IP но на разных портах из верхнего диапазона(не нужен root для bind), а потом, обратным прокси всё сводить на один IP и порт 80. Ну или как-то можно ещё извратится посмачнее.

Я вообще толкую о том, что тут ходит полно приличных программеров и сисадминов и я очень надеюсь, что многоуважаемая аудитория обратит внмание на очень нужный и важный проект для всего apache:

Peruser MPM: http://www.telana.com/peruser.php

И хоть как-то поможет его автору.

>>Есть слабые попытки что-то сделать (Peruser MPM), но он ещё в стадии альфа.

>Оно если и будет работать, то только при маленьком количесве юзеров. А для массового высокопосещаемого виртуального хостинга такая схема неработоспособна -- завалится все от неимоверного количества процессов.

прикинь,а :

ps faxu | grep apache | wc -l

44

netstat -na | grep :80 | wc -l

7137

uptime

14:58:37 up 30 days, 21:40, 1 user, load average: 4.88, 5.45, 5.98

самая фигня в том что peruser с ssl не работает просто никак, и автор peruser не особо принимает патчи, я ему 2 месяца назад еще отправил исправление для 2.0.54, чтобы тот при POST не сегфолтился, а воз и ныне там.

>Дело в том, что можно запускать множество апачей на одном IP но на разных портах из верхнего диапазона(не нужен root для bind), а потом, обратным прокси всё сводить на один IP и порт 80. Ну или как-то можно ещё извратится посмачнее.

будет бардак мама не горюй.

Кой какие апаческие модули, ZendAccelerator да и что-то ещё я уже не помню не работает в многопотоковом апаче.

Дык надо патч запостить в его список рассылки. Пусть люди тестируют.

# ps faxu | grep apache | wc -l 196 Один вопрос - сколько чайлдов запущено и совершенно другой - в том, сколько весит каждый child -- 5M или 50M. Тут вопрос не в изменении длины полового органа (у кого чайлдов больше или аптайм круче), тут вопрос в том, будет ли экономически оправданным отладка и введение в эксплуатацию Peruser MPM.

15M

Проблема с uid и gid легко решается написанием своего модуля, который создает песочницу для mod_php & mod_perl и расставляет uid и gid. Среда MPM. 2 года назад делали такую систему для буржуев, вроде не жалуются, но и стоит немало :))