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

[Yury Konovalov]

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

Понедельник 24 Май 2004 12:50, Michael Shigorin написал:
> - действительно ли нам нужны два апача, которые одновременно
>   - устанавливаемы (затрудняет завязку по пакетным завивимостям);
Нужны.
>   - запускаемы (переносит множество проверок в стартап-тайм);
Нужны на хостингах однозначно.
> - "как это сделано у других" (если вообще где-то сделано).
Не всем нужен mod_charset... Тут можно и даже apache2-only себе представить. 
Но это не отвечает требованиям хостинга по security, features и т.д.
  
> Пока у меня зреет ощущение, что то, на что замахиваемся, у меня в
> голове не укладывается в достаточной мере (вместе с
> последствиями).  По каковой причине, собственно, и не пытался
> сделать то же самое раньше, хотя "счастья всем даром",
> разумеется, хотелось давно.
Похоже, Михаил, вы переоцениваете то на что замахивается предлагаемый пакет:)

Дальше нить потерена...

> 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)

Здесь разница в том, что я говорю о том, с каким Layout собирать apache, а не 
о том как это в %install переложить.
Давайте это просто отложим на время.
 
> > Да, но именно на "свой" контент должен глядеть docroot
> > по-умолчанию. Это по-моему правильно. Иначе что показывать
> > по-умолчанию?
>
> Generic page, которую все равно давно пора переписывать (та, что
> в apache-1.3.x, все равно давно не соответствует
> действительности), может быть и более generic, чтобы не
> заморачиваться даже не с альтернативами, а с runtime switching в
> инитскриптах.
Generic page в комплекте с A2 многоязыковая. Можно конечно сделать общую, но 
на данном этапе ее нет. Давайте вернемся к этому позже.
 
> > Тут не спорю -- можно сдвинуть docroot в
> > /usr/share/apache{favour}. Однако здесь есть один момент (не
> > связанный с /usr/share - просто вспомнил) -- некоторые сайты
> > вообще не используют виртхосты. Для таких случаев нужно
> > предусмотреть хорошие комментарии в конфигах, чтобы можно было
> > просто раскоментировав строчку перебросить docroot в другое
> > место (/var/www/htdoc?), чтобы увести личных контент из
> > обновляемой пакетом области.
>
> Возможно, это как раз и стоит написать на пресловутой generic
> page?

Хорошая идея.

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

Из-за принципа . На практике видел cgi, которые дергают printenv, например.

> > > Бишь если я собираю webalizer -- куда он кладет свой контент?
> > > (собирать два webalizer просто так -- не буду :)
> >
> > В /var/www/shared-cgis/webalizer + конфиг в
> > оба /etc/httpd{favour}/conf/addon.d
>
> Вот это "в оба" мне и не нравится с учетом того, что он как бы
> простой как два полена и переносимый.  Можно играться в симлинки,
> можно думать еще что-то -- но не хотелось бы нарваться по статье
> "на каждого мудреца довольно простоты".
Тут как раз можно посмотреть "как у других". Я бы сделал "в оба" , но можно 
вообще ничего не делать в расчете на то, что админ догадается, что можно 
просто повторить ручками то, что поставляется для A1... бррр

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

> > Под default vhost я понял просто docroot  и его дефолтное
> > содержимое. Тут я опять-же за разные docroot для каждого favour
> > апача. С остальным согласен.
>
> А я -- за один в общем случае. :)  Собственно, вокруг чего и вся
> беготня.
Да.

> Именно поэтому я и противился требованиям обеспечить не то что
> устанавливаемость, а функционирование двух версий apache
> одновременно.
Если взять реальный хостинг -- увы мы, IMHO обречены еще относительно долго 
жить на конфигурациях вроде
apare-ru
 |
 ->apache-ru-mod_perl
 |
 ->apache2

> Слишком много логики надо вбивать и неочевидностей вылазит.
Предлагаю все обдумать и сделать как попало :))
Если серьёзно -- было много интересных вопросов поднято. Нужно все как следует 
обдумать, прежде чем брать курс на интеграцию апачей -- пусть даже 
defdocroot'а

> > В том числе -- это просто трюк в инитскрипте и пара if в
> > конфиге на случай, если A1 уже поднят. В остальном --
> > совершенно полноценная сборка A2
>
> Ну, это можно подсмотреть в init.d/apache* как они есть сейчас --
> там сучковатые, но обычно работающие костыли для предотвращения
> неочевидности в виде запущенного при лежавшем httpd httpd-perl и
> ломания всего подряд от неожиданности.
Уже :)
Будет слушать 80 только если "лежат" оба A1

> > Макросы сильно помогут :)
>
> Угу, но их надо _внедрять_, менять пока просто нет смысла. :)
> Т.е. есть, но _пока_ это практически ни на что не влияет.
>
> > Да, но сейчас все, что есть в сизифе выглядит как
> > apache1-specific по форме, а не по факту.
>
> Почему?
Просто потому что, пока не знают об A2.

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

> > 2) Пакет рождает отдельную сборку для A2 (mod_php как пример)
>
> ...в /var/www/apache2/cgi-bin или /usr/lib/cgi-bin/apache2/
> (мне больше импонирует последнее)
Мне пока это не понятно.

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

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

> > Он более чем полноценен! Правда! :)
>
> О чем и спич.  Посмотрите /etc/init.d/httpd* от первого, и что с
> ними будет, если у нас будет смесюка httpd + httpd-perl + apache2
> с такой колбасой проксей.  (можно поставить конфликт apache2 с
> apache1-mod_perl, но кому-то непременно понадобится именно это)
У меня такая "смесюка" даже работает. Не вижу проблем. Колбаса-то простенькая, 
кроме того -- кто сам не захочет -- ни за что не получит колбасы. Тут я имею 
ввиду тех, кто будет ставить A1/A2-only.

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

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

Вообщем, давайте, я выложу пакет -- на практике все проще осознать.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAsifkBMpuqP3w7LgRAsHMAJ9RvrG5l4Ve2aGAHb+JvMrtMo6DnwCff83X
vAIEEOA8h4o4XRBE8fxLPRY=
=QSrf
-----END PGP SIGNATURE-----