[devel] Re: apache2, apache1, /var/www, web packaging policy

[Michael Shigorin]

PreScriptum: хочется попросить yurix@, ab@ и других
заинтересованных в том, чтобы подумать над:

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

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

PreS2: положительные ответы на "действительно ли" принимаются
_исключительно_ с прикладными соображениями на тему реализации.

On Fri, May 21, 2004 at 05:23:43PM +0400, Yury Konovalov wrote:
> > > > %apache_datadir         %_var/www
> > > > %apache_htdocsdir       %apache_datadir/html
> > > > %apache_cgibindir       %apache_datadir/cgi-bin
> > > > %apache_webmaster       webmaster
> > > На мой взгляд это уже специфичные вещи.
> > Нет, ну переименовать их в httpd_* или еще как более
> > нейтрально, понятное дело.
> Я имел ввиду не имена, а сам принцип.

А я -- то, что именно эти четыре макроса, вообще говоря,
кроссапачевые как минимум :-) (при условии, что для действительно
специфических пакетов отдельно предоставляем %apache[12]_* etc)

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

Generic page, которую все равно давно пора переписывать (та, что
в apache-1.3.x, все равно давно не соответствует
действительности), может быть и более generic, чтобы не
заморачиваться даже не с альтернативами, а с runtime switching в
инитскриптах.

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

Возможно, это как раз и стоит написать на пресловутой generic
page?

> > > Это, например, может выглядеть так:
> > > /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/
> > И чем отличается то, что здесь?
> Всем -- чаще всего, видимо, вообще не будут пересекаться.

Гм.  Другой вопрос -- а нам нужны те cgi, которые "штатно идут с
апачем", с учетом того, что /var/www/cgi-bin по умолчанию не
ограничен Allow from localhost и Deny остальным?

> > Бишь если я собираю webalizer -- куда он кладет свой контент?
> > (собирать два webalizer просто так -- не буду :)
> В /var/www/shared-cgis/webalizer + конфиг в 
> оба /etc/httpd{favour}/conf/addon.d

Вот это "в оба" мне и не нравится с учетом того, что он как бы
простой как два полена и переносимый.  Можно играться в симлинки,
можно думать еще что-то -- но не хотелось бы нарваться по статье
"на каждого мудреца довольно простоты".

Все-таки есть предложение _оставить_ дефолтные назначения
(/var/www/{html,cgi-bin} таковыми именно как _разделяемый_
ресурс, а выносить -- специфичные вещи, потому как там в принципе
надо изменять идентификацию в любом случае.

Извиняюсь за путаность, просто каждый раз восстанавливать
контекст мучительно долго приходится.

> Ну или если применить /usr/share, то в
> /usr/share/apache-shared/webalizer/

У этого специфика в том, что статический контент все-таки
генерируемый, т.е. /usr/share отпадает.

Собственно, это не cgi -- запускается из-под cron, но при этом
кладет контент в указанное место.

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

Вот именно.  А какие бития головой об монитор будут при схемах с
раскидыванием per flavour идентичных копий -- "я его правлю,
сношу, а ему все равно!!!" -- уже сейчас можно представить.

Кстати.  А никто не смотрел, вообще где-то эту проблему решали
или нет?

> Может пусть в самом названии каталога отражается его суть.

Но при этом не стоит менять привычек, если они не являются
необоснованными: сохранение опыта при его разумности лучше, чем
изменения к даже более "говорящим", но yet another именам.

> Кроме этого, большинство проектов могут предоставлять
> sсriptalias в своём конфиге, и добавлять централизованный алиас
> нет смысла.

Угу.  А при подключении $project к $virthost достаточно будет
перетащить (скопировать) именно ScriptAlias.

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

А я -- за один в общем случае. :)  Собственно, вокруг чего и вся
беготня.

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

Именно поэтому я и противился требованиям обеспечить не то что
устанавливаемость, а функционирование двух версий apache
одновременно.

Слишком много логики надо вбивать и неочевидностей вылазит.

Кто тут это требовал -- Саша Боковой?  Саш, давай-ка помогай
разруливать. :-)

> А намёк в виде каталога внутри apache{favour} должен
> восприниматься однозначно ;)

См. выше насчет frustration.  Просто не раз видел, как наши
неочевидности доводили до походов на стенку и бывалых людей.

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

Ну, это можно подсмотреть в init.d/apache* как они есть сейчас --
там сучковатые, но обычно работающие костыли для предотвращения
неочевидности в виде запущенного при лежавшем httpd httpd-perl и
ломания всего подряд от неожиданности.

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

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

Ну, он у нас по умолчанию отключен => все равно надо
разбираться/смотреть, чтоб включить, и если это будет делать
чайник -- он все равно огребет по независящим от нас
обстоятельствам, а для профи пары пометок хватит, if any.

Я про дефолты в первую очередь.

> > > > > Вообщем все то, что попадет туда само-сабой, если изменить
> > > > > apache_home.
> > > > Э, не.  Тогда туда и разделяемого много упадет.
> > > Можно сказать, что это даже хорошо -- пусть сначала пакет
> > > осознает свой контент разделяемым. Так постепенно все
> > > образуется и не будет резких изменений.
[...]
> > Т.е. 1) дело не в макросах :-) и 2) незачем априори полагать,
> > что софт является apache1-specific.  В последнем могу быть
> Макросы сильно помогут :)

Угу, но их надо _внедрять_, менять пока просто нет смысла. :)
Т.е. есть, но _пока_ это практически ни на что не влияет.

> Да, но сейчас все, что есть в сизифе выглядит как
> apache1-specific по форме, а не по факту.

Почему?

> Пусть мантейнеры решают как сделать пакет толерантным к версии
> апача. Тут всего два варианта:
> 1) Пакет идёт в shared-cgis (mailman для примера)

...или так и остается в /var/www/cgi-bin. :)

> 2) Пакет рождает отдельную сборку для A2 (mod_php как пример)

...в /var/www/apache2/cgi-bin или /usr/lib/cgi-bin/apache2/
(мне больше импонирует последнее)

> > > Здесь только хотелось сказать, что на данный момент, если
> > > отказаться от идеи одного docroot'а, следует определить тот
> > > список макросов, достаточный для сборки модулей, и
> > > использовать одинаковые имена, при взаимно вытесняющих
> > > -devel.
> > А что тогда делать с webalizer? ;-)
> Это решать мантейнеру :)
> На мой взгляд -- хороший пример для shared-cgis. Ему при сборке
> конечно нужно будет проsedить как apache.conf, так и
> apache2.conf. Причем, это даже слишком хороший пример - ему
> ведь по сути нужно знать где логи обоих апачей... Значит
> собираться ему без apache-макросов.

А он может не только апачьи логи, а обобщенные CLF, combined и
xferlog.

Т.е. *если* конкретно по apache[12] у нас штатный формат логов не
варьируется *и* избежать ситуации, когда оба процесса могут быть
запущены и пытаться писать в одни файлы -- их можно даже дружно
писать в /var/log/httpd.

[кстати: а нет ли смысла переезжать с CLF на Combined как более
информативный по умолчанию, или "народу не нужны..."?]

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

О чем и спич.  Посмотрите /etc/init.d/httpd* от первого, и что с
ними будет, если у нас будет смесюка httpd + httpd-perl + apache2
с такой колбасой проксей.  (можно поставить конфликт apache2 с
apache1-mod_perl, но кому-то непременно понадобится именно это)

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

Угу.

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

И, кстати, про "куда класть и как включать" (при условии
доступности дюжины веб-серверов) тоже надо будет освежить, я
как-то разглядывал только в контексте "а, у нас все равно один
apache сейчас".

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

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

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