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

[Yury Konovalov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Среда 19 Май 2004 20:27, Michael Shigorin написал:
> Это понятно, так я (ниже) и предлагаю вытянуть максимум
> независимостей в отдельный *-devel.
<skipped>
> %apache_datadir         %_var/www
> %apache_htdocsdir       %apache_datadir/html
> %apache_cgibindir       %apache_datadir/cgi-bin
> %apache_webmaster       webmaster
На мой взгляд это уже специфичные вещи. Я исхожу из того, что разные ветки 
апачей не должны иметь один и тот-же htdocsdir (какой апач наполнит его, если 
у каждого свой контент для этого?) и cgibindir также имеет пару cgi, 
предоставляемых самим апачем.

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

Это, например, может выглядеть так:
/var/www/
	|
	-apache1/
		|
		-html/
		-cgi-bin/
		-manual/
		-addon1/
		-addon2/
	-apache2/
		|
		-html/
		-cgi-bin/
		-manual/
		-addon1/
		-addon2/
	-shared-cgis/
		|
		-mailman
		-one_more_apache_favour_ignoring_project
	-vhosts/
		|
		-vhost1/
			|
			-htdoc/
			-log/
			-cgi/
		-vhost2/
		...
 

> > Все, что специфично для данной версии Apache - manual, default
> > docroot, доки модулей, специфицные cgi и т.п.
>
> А у нас есть настолько специфичные cgi, или речь о том, чтобы
> обеспечить эту возможность?  Просто получается множество
За то, что уже есть в сизифе не скажу (там просто не откуда взяться 
apache2-specific пакетам:), но я знаю такие пакеты, которые будут 
предоставлять cgi, зависящие от модулей, имеющихся только во втором апаче 
(WebAuth/WebKDC как пример).
> мощностью Nflavour x Nvirthost.
Я бы учёл, что на практике:
1) Apache2 на данный момент решение скорее дополнительное к Apache1.
2) из первого вытекает, что большинство хостеров будут использовать A2 в 
проксируемом посредством A1 режиме (что по умолчанию действует в моем пакете 
почти также как и в apache-mod_perl)
3) В свою очередь, из второго вытекает, что A2 будет действовать лишь для 
малой части виртхостов (или даже части контента виртхоста), а центральный 
cgi-bin дотачивается по-месту. Т.е мы здесь все-равно не угадаем.

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

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

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

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

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArK2CBMpuqP3w7LgRArsnAJ9xNZRJWjMe71T70i+AQz3xPW/zRACfefuy
60NeXO5tQsa4TpGXREh05+0=
=1gLc
-----END PGP SIGNATURE-----