[devel] Re: apache2, apache1, /var/www (was: /srv)

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1: Type: text/plain, Size: 8451 bytes --]

On Thu, May 20, 2004 at 05:06:51PM +0400, Yury Konovalov wrote:
> > Это понятно, так я (ниже) и предлагаю вытянуть максимум
> > независимостей в отдельный *-devel.
> <skipped>
> > %apache_datadir         %_var/www
> > %apache_htdocsdir       %apache_datadir/html
> > %apache_cgibindir       %apache_datadir/cgi-bin
> > %apache_webmaster       webmaster
> На мой взгляд это уже специфичные вещи.

Нет, ну переименовать их в httpd_* или еще как более нейтрально,
понятное дело.

> Я исхожу из того, что разные ветки апачей не должны иметь один
> и тот-же htdocsdir (какой апач наполнит его, если у каждого
> свой контент для этого?) и cgibindir также имеет пару cgi,
> предоставляемых самим апачем.

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

Опять же может иметь смысл держать его тоже в /usr/share -- это
нечто неизменяемое, в конце концов.

> На сколько я понимаю, предлагается более тесная интеграция
> апачей, предполагающая объединение контентов и разделения
> общего docroot.  В свою очередь, предлагаю так далеко не идти
> сходу, и для начала определить простую схему при которой апачи
> смогут сосуществовать.

А потом с ней героически сражаться? ;-)

См. mod_ssl.spec свежего разлива.  А ведь тривиальная вещь,
казалось бы...

> Это, например, может выглядеть так:
> /var/www/
> 	|
> 	-apache1/
> 		|
> 		-html/
> 		-cgi-bin/
> 		-manual/
> 		-addon1/
> 		-addon2/

Что здесь? (ну manual понятно, хотя и он у нас обычно жил
симлинком под html)

> 	-apache2/
> 		|
> 		-html/
> 		-cgi-bin/
> 		-manual/
> 		-addon1/
> 		-addon2/

И чем отличается то, что здесь?

Бишь если я собираю webalizer -- куда он кладет свой контент?
(собирать два webalizer просто так -- не буду :)

> 	-shared-cgis/
> 		|
> 		-mailman
> 		-one_more_apache_favour_ignoring_project

А не большинство ли их такое?  И нет ли смысла тогда здвать это
просто cgi-bin/ ? :)

Опять же, разделяемый html -- это то, на что (сейчас) заряжен
default vhost.  Было бы разумно вообще исключить запись туда
вебмастером (права+README) и тут же "удобнизировать" создание
нормального виртхоста -- в т.ч. дефолтного, но не здесь, в
пакетной местности.

> 	-vhosts/
> 		|
> 		-vhost1/
> 			|
> 			-htdoc/
> 			-log/
> 			-cgi/
> 		-vhost2/
> 		...

Тут вопросов нет.

> > > Все, что специфично для данной версии Apache - manual,
> > > default docroot, доки модулей, специфицные cgi и т.п.
> > А у нас есть настолько специфичные cgi, или речь о том, чтобы
> > обеспечить эту возможность?  Просто получается множество
> За то, что уже есть в сизифе не скажу (там просто не откуда
> взяться apache2-specific пакетам:), но я знаю такие пакеты,
> которые будут предоставлять cgi, зависящие от модулей,
> имеющихся только во втором апаче (WebAuth/WebKDC как пример).

С другой стороны -- и что плохого, если они окажутся в
разделяемом cgi-bin?  Максимум взорвется не под тем (и то уже дав
намек требованием "того").

> > мощностью Nflavour x Nvirthost.
> Я бы учёл, что на практике:
> 1) Apache2 на данный момент решение скорее дополнительное к Apache1.

Да, но уже не единственное.  Сам тоже собираюсь все boa опакетить
:)

> 2) из первого вытекает, что большинство хостеров будут
> использовать A2 в проксируемом посредством A1 режиме (что по
> умолчанию действует в моем пакете почти также как и в
> apache-mod_perl)

А, вот как.  Не учел.

Т.е. именно одновременная работа...

> 3) В свою очередь, из второго вытекает, что A2 будет
> действовать лишь для малой части виртхостов (или даже части
> контента виртхоста), а центральный cgi-bin дотачивается
> по-месту. Т.е мы здесь все-равно не угадаем.

Ммм.... хорошо.  А наблюдались несовместимые снизу вверх CGI?

> > > Вообщем все то, что попадет туда само-сабой, если изменить
> > > apache_home.
> > Э, не.  Тогда туда и разделяемого много упадет.
> Можно сказать, что это даже хорошо -- пусть сначала пакет
> осознает свой контент разделяемым. Так постепенно все
> образуется и не будет резких изменений. Я имею ввиду, что
> пакеты(основанные на apache), даже без внесения изменений будут
> собираться под A1, пока мантейнер не решит, что можно
> предоставлять что-либо в %srv_dir

Кажется, потерял контекст, но имелось в виду, что сейчас скорее
типично использование /var/www, нежели %_apache/home:

RPM/SPECS/classic> grep var/www * | cut -f1 -d: | uniq | wc -l
29
RPM/SPECS/classic> grep %apache_home * | cut -f1 -d: | uniq | wc -l
3

(это apache, packhouse, phpPgAdmin)

Т.е. 1) дело не в макросах :-) и 2) незачем априори полагать, что
софт является apache1-specific.

В последнем могу быть неправ.

> > > > Кстати, тут еще Большаков справшивал про макросы сегодня в
> > > > свете желания собрать tclhttpd.  Т.к. "общей частью" вопроса
> > > > я тут вижу не виртхосты как таковые, подумал -- может, это
> > > > httpd-common и httpd-devel?
> > > > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
> > > Тут мне не совсем понятно -- эти пакеты будут предоставлять
> > > макросы для обоих версий apache?
> > Частично.  Каждый апач может носить с собой оставшуюся часть
> > сугубо своих макросов.
> Это пересекается со сказанным в начале.

Да, конечно.  Особенно с учетом того, что я *подразумевал* там
замену apache обобщенным httpd :-)

> Здесь только хотелось сказать, что на данный момент, если
> отказаться от идеи одного docroot'а, следует определить тот
> список макросов, достаточный для сборки модулей, и использовать
> одинаковые имена, при взаимно вытесняющих -devel.

А что тогда делать с webalizer? ;-)

Просто когда народ очень так интересовался, почему mod_perl так
экстравагантно заведен -- я подумал-подумал, чего может стоить
его вытаскивание из-под этой схемы (даже если течь не будет и
вообще все замечательно теперь), и объявил, что делать этого в
1.3.x -- не собираюсь.

Соответственно если apache2 будет этаким довеском, то когда ему
придет времябыть _платформой_ -- изначальная завязка на
"неполноценность" и обособленность может сыграть злую шутку.

Хочется по возможности избежать в его будущем нетривиальных
скриптов по обеспечению миграции и продумывания ночами
%triggerpostun...

> > > Я себе это представлял так: при сборке модуля, например,
> > > под apache1 - в buildreq указывается apache-devel, а при
> > > желании собрать под apache2 - соответственно apache2-devel.
> > > Devel-пакеты должны выпихивать друг-друга ибо макросы
> > > должны быть одноименные для упрощения "кросапачной:)"
> > > сборки.
> > Ммм... угу.  Но модули и контент-часть -- штуки разные по
> > степени зависимости от сервера/версии.
> Иногда и с модулями идёт контент, который зависит от версии A.

Кстати, можно пример?  (документация не в счет, с ней понятно)

> > Если забегать в раздел мыслей по web packaging policy, то мне
> > очень нравится размещение скриптов под /usr/share и
> > подцепление их или алиасами, или симлинками.  Особенно в
> > свете +/- распухшего хостинга с приличной дупликацией кода,
> > который не изменяется per-instance, но порой дыряв и хорошо
> > бы, чтобы его можно было обновлять одним махом.
> Да - это конечно мечта, но пока у меня нет чёткого
> представления. Похоже, на данном этапе это скорее усложнение.

А посмотрите дебиановские пакеты.

Там есть и, например, возможность сказать, в какую именно БД
ходить создавать штатные базы, и это очень симпатичная
автоматизация нудной и тупой "деятельности".

> > Здесь для меня главный вопрос именно с выделением
> > неизменяемой части (остальное симлинкуется куда-нибудь в
> > /var), а также с определением реально неизменяемой части.
> Да в этом все и дело. 

Оно, конечно, per-webpackage, но...

Хотя с другой стороны -- если бы rpm2 ориентировался на ситуацию
"все равно все будут хачить по месту", так бы он и остался таром
на стероидах -- большим, но глупым.

Так что будем ориентироваться на mature web software.  Пилимое
(плохое) -- в конце концов, руками по старинке разложить можно,
раз все равно пилить.

> По моим наблюдениям, админы часто переносят содержимое
> web-пакетов в свой каталог, где хачат напильниками и
> выкладывают. Видимо уже есть "доточенные" вэб-пакеты,
> обновление которых на 99% пройдёт без негативных последствий --
> их и искать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]