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

[Yury Konovalov <yurix@unixcenter.ru>]

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

Четверг 20 Май 2004 18:04, Michael Shigorin написал:
> > > %apache_datadir         %_var/www
> > > %apache_htdocsdir       %apache_datadir/html
> > > %apache_cgibindir       %apache_datadir/cgi-bin
> > > %apache_webmaster       webmaster
> >
> > На мой взгляд это уже специфичные вещи.
>
> Нет, ну переименовать их в httpd_* или еще как более нейтрально,
> понятное дело.
>
Я имел ввиду не имена, а сам принцип.

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

> Опять же может иметь смысл держать его тоже в /usr/share -- это
> нечто неизменяемое, в конце концов.
Тут не спорю -- можно сдвинуть docroot в /usr/share/apache{favour}. Однако 
здесь есть один момент (не связанный с /usr/share - просто вспомнил) -- 
некоторые сайты вообще не используют виртхосты. Для таких случаев нужно 
предусмотреть хорошие комментарии в конфигах, чтобы можно было просто 
раскоментировав строчку перебросить docroot в другое место (/var/www/htdoc?), 
чтобы увести личных контент из обновляемой пакетом области.

> > На сколько я понимаю, предлагается более тесная интеграция
> > апачей, предполагающая объединение контентов и разделения
> > общего docroot.  В свою очередь, предлагаю так далеко не идти
> > сходу, и для начала определить простую схему при которой апачи
> > смогут сосуществовать.
>
> А потом с ней героически сражаться? ;-)
>
> См. mod_ssl.spec свежего разлива.  А ведь тривиальная вещь,
> казалось бы...
>
Не вижу связи. Модулям нужно использовать макросы, предоставляемые апачем -- 
тогда им все-равно, какая будет схема.

> > Это, например, может выглядеть так:
> > /var/www/
> >
> > 	-apache1/
> >
> > 		-html/
> > 		-cgi-bin/
> > 		-manual/
> > 		-addon1/
> > 		-addon2/
>
> Что здесь? (ну manual понятно, хотя и он у нас обычно жил
> симлинком под html)

- -html - дефолтная страница с красивой картинкой alt и ссылками на доки
- -cgi-bin - cgi, поставляемые с апачем.
- -addonX - контент, поставляемый с модулями, работающими только с данной 
версией apache
для manual - думаю, лучше все-же alias.
Ещё нужно наверное добавить:
- -addons-manual/
	|
	-addon1/
	-addon2/

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

Всем -- чаще всего, видимо, вообще не будут пересекаться.

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

В /var/www/shared-cgis/webalizer + конфиг в 
оба /etc/httpd{favour}/conf/addon.d
Ну или если применить /usr/share, то в /usr/share/apache-shared/webalizer/

> > 	-shared-cgis/
> >
> > 		-mailman
> > 		-one_more_apache_favour_ignoring_project
>
> А не большинство ли их такое?  И нет ли смысла тогда здвать это
> просто cgi-bin/ ? :)
Можно конечно -- ведь это уже вопрос вкуса. Человек может просто запутаться 
если будет cgi-bin у каждого favour + cgi-bin, для разделяемых cgi. Может 
пусть в самом названии каталога отражается его суть.
Кроме этого, большинство проектов могут предоставлять sсriptalias в своём 
конфиге, и добавлять централизованный алиас нет смысла.

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

> > > А у нас есть настолько специфичные cgi, или речь о том, чтобы
> > > обеспечить эту возможность?  Просто получается множество
> >
> > За то, что уже есть в сизифе не скажу (там просто не откуда
> > взяться apache2-specific пакетам:), но я знаю такие пакеты,
> > которые будут предоставлять cgi, зависящие от модулей,
> > имеющихся только во втором апаче (WebAuth/WebKDC как пример).
>
> С другой стороны -- и что плохого, если они окажутся в
> разделяемом cgi-bin?  Максимум взорвется не под тем (и то уже дав
> намек требованием "того").
>
Эти "намёки" вряд ли будут содержательными, по крайней мере не укажут напрямую 
на необходимость сменить версию апача.
А намёк в виде каталога внутри apache{favour} должен восприниматься 
однозначно ;)

> > > мощностью Nflavour x Nvirthost.
> >
> > Я бы учёл, что на практике:
> > 1) Apache2 на данный момент решение скорее дополнительное к Apache1.
>
> Да, но уже не единственное.  Сам тоже собираюсь все boa опакетить
Разумеется!

> > 2) из первого вытекает, что большинство хостеров будут
> > использовать A2 в проксируемом посредством A1 режиме (что по
> > умолчанию действует в моем пакете почти также как и в
> > apache-mod_perl)
>
> А, вот как.  Не учел.
>
> Т.е. именно одновременная работа...
В том числе -- это просто трюк в инитскрипте и пара if в конфиге на случай, 
если A1 уже поднят. В остальном -- совершенно полноценная сборка A2

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

> > > > Вообщем все то, что попадет туда само-сабой, если изменить
> > > > 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.
>
> В последнем могу быть неправ.

Макросы сильно помогут :)
Да, но сейчас все, что есть в сизифе выглядит как apache1-specific по форме, а 
не по факту. Пусть мантейнеры решают как сделать пакет толерантным к версии 
апача. Тут всего два варианта:
1) Пакет идёт в shared-cgis (mailman для примера)
2) Пакет рождает отдельную сборку для A2 (mod_php как пример)

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

Это решать мантейнеру :)
На мой взгляд -- хороший пример для shared-cgis. Ему при сборке конечно нужно 
будет проsedить как apache.conf, так и apache2.conf. Причем, это даже слишком 
хороший пример - ему ведь по сути нужно знать где логи обоих апачей... Значит 
собираться ему без apache-макросов.

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

Он более чем полноценен! Правда! :)

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

Для этого и обсуждаем.

> > Иногда и с модулями идёт контент, который зависит от версии A.
>
> Кстати, можно пример?  (документация не в счет, с ней понятно)

mod_webkdc

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

Нужно будет посмотреть.

> Оно, конечно, per-webpackage, но...
>
> Хотя с другой стороны -- если бы rpm2 ориентировался на ситуацию
> "все равно все будут хачить по месту", так бы он и остался таром
> на стероидах -- большим, но глупым.
>
> Так что будем ориентироваться на mature web software.  Пилимое
> (плохое) -- в конце концов, руками по старинке разложить можно,
> раз все равно пилить.

Мы на это не ориентируемся -- просто пока не ясно, как сделать лучше.

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

iD8DBQFArgL7BMpuqP3w7LgRAkr0AKCHpjcw0y2doZ5eLNlicVz1hJC2XgCfSpQ9
d9ljxFXioZJ34LTRxshV6K0=
=hT7n
-----END PGP SIGNATURE-----