From: Michael Shigorin <mike@osdn.org.ua> To: ALT Devel discussion list <devel@altlinux.ru> Subject: [devel] Re: apache2, apache1, /var/www, web packaging policy Date: Mon, 24 May 2004 11:50:50 +0300 Message-ID: <20040524085050.GW20197@osdn.org.ua> (raw) In-Reply-To: <200405211724.37571.yurix@unixcenter.ru> 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/
next prev parent reply other threads:[~2004-05-24 8:50 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-05-13 12:25 ` [devel] Re: mod_mono-0.6-alt1: rebuild failed [12] Pavel Mironchik 2004-05-13 13:01 ` [devel] [JT] " Michael Shigorin 2004-05-13 16:26 ` Anton Farygin 2004-05-13 16:56 ` [devel] apache2, again (was: [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]) Michael Shigorin 2004-05-13 19:49 ` [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12] Alexander Bokovoy 2004-05-14 5:24 ` Anton Farygin 2004-05-14 6:21 ` Yury Konovalov 2004-05-14 7:49 ` [devel] [JT] Re: apache2 Anton Farygin 2004-05-14 9:41 ` Yury Konovalov 2004-05-14 12:01 ` [devel] " Michael Shigorin 2004-05-14 12:04 ` [devel] [JT] " Dmitry V. Levin 2004-05-14 12:16 ` Anton Farygin 2004-05-14 12:56 ` [devel] apache2 Dmitry V. Levin 2004-05-14 13:40 ` [devel] [JT] apache2 Yury Konovalov 2004-05-14 15:58 ` [devel] " Michael Shigorin 2004-05-14 7:22 ` [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12] Alexander Bokovoy 2004-05-14 12:00 ` [devel] " Michael Shigorin 2004-05-14 17:28 ` Alexander Bokovoy 2004-05-14 6:33 ` Yury Konovalov 2004-05-14 7:23 ` Alexander Bokovoy 2004-05-14 7:50 ` Anton Farygin 2004-05-14 10:07 ` Yury Konovalov 2004-05-14 10:39 ` Anton Farygin 2004-05-14 11:58 ` [devel] apache2 (was: mod_mono-0.6-alt1: rebuild failed [12]) Michael Shigorin 2004-05-15 15:37 ` Yury Konovalov 2004-05-16 17:05 ` [devel] " Michael Shigorin 2004-05-14 12:06 ` [devel] /srv Dmitry V. Levin 2004-05-15 15:11 ` Yury Konovalov 2004-05-16 16:54 ` [devel] /srv Michael Shigorin 2004-05-19 13:50 ` Yury Konovalov 2004-05-19 14:34 ` [devel] apache2, apache1, /var/www (was: /srv) Michael Shigorin 2004-05-19 15:39 ` Yury Konovalov 2004-05-19 16:27 ` [devel] " Michael Shigorin 2004-05-20 13:06 ` Yury Konovalov 2004-05-20 14:04 ` Michael Shigorin 2004-05-21 13:23 ` Yury Konovalov 2004-05-24 8:50 ` Michael Shigorin [this message] 2004-05-24 9:17 ` [devel] Re: apache2, apache1, /var/www, web packaging policy Vladimir Lettiev 2004-05-24 9:16 ` Klimchev Konstantin 2004-05-24 9:44 ` Michael Shigorin 2004-05-27 8:45 ` Денис Смирнов 2004-05-27 9:59 ` Denis Ovsienko 2004-05-27 14:11 ` Michael Shigorin 2004-05-29 10:42 ` Денис Смирнов 2004-05-24 15:57 ` Yury Konovalov 2004-05-24 16:50 ` Yury Konovalov 2004-05-14 7:46 ` [devel] Re: mod_mono-0.6-alt1: rebuild failed [12] Stanislav Ievlev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040524085050.GW20197@osdn.org.ua \ --to=mike@osdn.org.ua \ --cc=devel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git