From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 24 May 2004 11:50:50 +0300 From: Michael Shigorin To: ALT Devel discussion list Message-ID: <20040524085050.GW20197@osdn.org.ua> Mail-Followup-To: ALT Devel discussion list References: <20040513112058.5D4721327@basalt.office.altlinux.org> <200405201707.17676.yurix@unixcenter.ru> <20040520140436.GX3087@osdn.org.ua> <200405211724.37571.yurix@unixcenter.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200405211724.37571.yurix@unixcenter.ru> User-Agent: Mutt/1.4.2.1i Subject: [devel] Re: apache2, apache1, /var/www, web packaging policy X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2004 08:50:53 -0000 Archived-At: List-Archive: List-Post: 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 ------ Linux.Kiev http://www.linux.kiev.ua/