From: Yury Konovalov <yurix@unixcenter.ru> To: ALT Devel discussion list <devel@altlinux.ru> Subject: Re: [devel] Re: apache2, apache1, /var/www, web packaging policy Date: Mon, 24 May 2004 20:50:40 +0400 Message-ID: <200405242050.46342.yurix@unixcenter.ru> (raw) In-Reply-To: <20040524085050.GW20197@osdn.org.ua> -----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-----
next prev parent reply other threads:[~2004-05-24 16: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 ` [devel] Re: apache2, apache1, /var/www, web packaging policy Michael Shigorin 2004-05-24 9:17 ` 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 [this message] 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=200405242050.46342.yurix@unixcenter.ru \ --to=yurix@unixcenter.ru \ --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