[devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Pavel Mironchik]

Пусть в orphaned - нет apache2, нет смысла

On Thu, 13 May 2004 15:20:58 +0400 (MSD)
QA Team Robot <qa@altlinux.org> wrote:

> Package: mod_mono-0.6-alt1
> Packager: Pavel Mironchik <tibor@altlinux>
> Status: rebuild failed.
> Cannot build this package for 12 week(s) (since Tue Feb 17 2004).
> Please investigate.
> 
> Why:
> 
> ar cru .libs/libmod_mono.a  mod_mono.o 
> ranlib .libs/libmod_mono.a
> creating libmod_mono.la
> (cd .libs && rm -f libmod_mono.la && ln -s ../libmod_mono.la libmod_mono.la)
> /bin/sh ../libtool --mode=link gcc  -I/usr/include/apr-0 -I/usr/include/apu-0 -I/usr/include/apache  -I/usr/include/apr-0  -DAPACHE13 -DEAPI   -o libmod_mono_old.la -rpath /usr/lib    
> rm -fr .libs/libmod_mono_old.la .libs/libmod_mono_old.* .libs/libmod_mono_old.*
> gcc -shared    -Wl,-soname -Wl,libmod_mono_old.so.0 -o .libs/libmod_mono_old.so.0.0.0
> (cd .libs && rm -f libmod_mono_old.so.0 && ln -s libmod_mono_old.so.0.0.0 libmod_mono_old.so.0)
> (cd .libs && rm -f libmod_mono_old.so && ln -s libmod_mono_old.so.0.0.0 libmod_mono_old.so)
> ar cru .libs/libmod_mono_old.a  
> ranlib .libs/libmod_mono_old.a
> creating libmod_mono_old.la
> (cd .libs && rm -f libmod_mono_old.la && ln -s ../libmod_mono_old.la libmod_mono_old.la)
> make[1]: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> make[1]: Entering directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> make[1]: Nothing to be done for `all-am'.
> make[1]: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> make: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> + pushd src
> ~/RPM/BUILD/mod_mono-0.6/src ~/RPM/BUILD/mod_mono-0.6
> + make -f makedll.mak
> make: Entering directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> mcs /debug+ /debug:full /nologo /r:System.Web.dll /target:library /out:ModMono.dll ApacheApplicationHost.cs ApacheWorkerRequest.cs MonoWorkerRequest.cs IApplicationHost.cs Request.cs
> make: mcs: Command not found
> make: *** [ModMono.dll] Error 127
> make: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> error: Bad exit status from /usr/src/RPM/tmp/rpm-tmp.75664 (%build)
> 
> RPM build errors:
>     Bad exit status from /usr/src/RPM/tmp/rpm-tmp.75664 (%build)
> 2.35user 1.99system 0:09.57elapsed 45%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (107686major+121002minor)pagefaults 0swaps
> rebuild: rebuild of `mod_mono-0.6-alt1.src.rpm' failed.
> 
> -- 
> Sincerely yours,
> ALT QA Team Robot

[devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On Thu, May 13, 2004 at 03:25:15PM +0300, Pavel Mironchik wrote:
> Пусть в orphaned - нет apache2, нет смысла

Bad apache, no bisquit?..

Давайте эту тему тоже на LF попробуем заготовить -- apache2?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Anton Farygin]

Michael Shigorin пишет:
> On Thu, May 13, 2004 at 03:25:15PM +0300, Pavel Mironchik wrote:
> 
>>Пусть в orphaned - нет apache2, нет смысла
> 
> 
> Bad apache, no bisquit?..
> 
> Давайте эту тему тоже на LF попробуем заготовить -- apache2?

А может быть просто взять сборку RH и пересобрать в нашей среде ?

Rgds,
Rider

[devel] apache2, again (was: [JT] Re: mod_mono-0.6-alt1: rebuild failed [12])

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Thu, May 13, 2004 at 08:26:41PM +0400, Anton Farygin wrote:
> >Давайте эту тему тоже на LF попробуем заготовить -- apache2?
> А может быть просто взять сборку RH и пересобрать в нашей среде ?

Может и так.  Правда, все равно лучше тогда посмотреть еще
Debian, Conectiva и PLD (особенно первых двух).

Понимаешь, есть задумка сделать из этого всего правильную
хостинг-платформу из коробки, но не хватает времени и мотивации.

А портить задумку переразбивками-триггерами потом -- не хочется.
Вот и сижу ни с чем. :)

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Alexander Bokovoy]

On Thu, May 13, 2004 at 08:26:41PM +0400, Anton Farygin wrote:
> Michael Shigorin пишет:
> >On Thu, May 13, 2004 at 03:25:15PM +0300, Pavel Mironchik wrote:
> >
> >>Пусть в orphaned - нет apache2, нет смысла
> >
> >
> >Bad apache, no bisquit?..
> >
> >Давайте эту тему тоже на LF попробуем заготовить -- apache2?
> 
> А может быть просто взять сборку RH и пересобрать в нашей среде ?
Она не предназначена для сосуществования с Apache 1.x, что является
главным препятствием наряду с отсутствием выделенного человека на
поддержку пакета, согласно всем нашим предыдущим обсуждениям.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Anton Farygin]

Alexander Bokovoy пишет:
> On Thu, May 13, 2004 at 08:26:41PM +0400, Anton Farygin wrote:
> 
>>Michael Shigorin пишет:
>>
>>>On Thu, May 13, 2004 at 03:25:15PM +0300, Pavel Mironchik wrote:
>>>
>>>
>>>>Пусть в orphaned - нет apache2, нет смысла
>>>
>>>
>>>Bad apache, no bisquit?..
>>>
>>>Давайте эту тему тоже на LF попробуем заготовить -- apache2?
>>
>>А может быть просто взять сборку RH и пересобрать в нашей среде ?
> 
> Она не предназначена для сосуществования с Apache 1.x, что является
> главным препятствием наряду с отсутствием выделенного человека на
> поддержку пакета, согласно всем нашим предыдущим обсуждениям.

Она должна быть conflicts с apache 1.x. И это IMHO правильно (я слабо 
представляю себе в одной системе apache 1 и apache 2 одновременно).

Rgds,
Rider

Re: [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Yury Konovalov]

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

Пятница 14 Май 2004 09:24, Anton Farygin написал:
> Она должна быть conflicts с apache 1.x. И это IMHO правильно (я слабо
> представляю себе в одной системе apache 1 и apache 2 одновременно).
Тем не менее, это вполне возможно. Именно так опакечен apach2 у меня. И даже 
функционирует уже с пол года.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApGWKBMpuqP3w7LgRAqQ+AJ4xuFNDAh+DvXuWQkT16LzVdzRPAQCggtFj
uQL90Uam2Rj82NMERskOVeg=
=UfIb
-----END PGP SIGNATURE-----

Re: [devel] [JT] Re: apache2

[Anton Farygin]

Yury Konovalov пишет:

Юра, может быть выложите в incoming ?

Без обязательств мантейнить ? Дальше мы понемногу его будет 
обновлять/исправлять.

Rgds,
Rider

P.S.

Может быть для apache сделать что-то вроде kernel-cvs ?

Re: [devel] [JT] Re: apache2

[Yury Konovalov]

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

Пятница 14 Май 2004 11:49, Anton Farygin написал:
> Yury Konovalov пишет:
>
> Юра, может быть выложите в incoming ?
Ok. Постараюсь на днях выложить.

> Без обязательств мантейнить ? Дальше мы понемногу его будет
> обновлять/исправлять.
> Может быть для apache сделать что-то вроде kernel-cvs ?
А еще мне нравится идея, высказанная Sviataslau Svirydau 
"организовать Packager: Apache Development Team 
<apache@packages.altlinux.org>, как это сделано для многих других пакетов и 
пригласить всех желающих?"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApJRFBMpuqP3w7LgRAoO3AJ9SEiAyqETO+fDR242ZlFSFvYwTywCfWbq4
3qB3d0IIFgAuN8ARnn4tHpM=
=dO1B
-----END PGP SIGNATURE-----

[devel] Re: apache2

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Fri, May 14, 2004 at 01:41:15PM +0400, Yury Konovalov wrote:
> > Юра, может быть выложите в incoming ?  Без обязательств

Ух ты, а бывает и так?

> > Может быть для apache сделать что-то вроде kernel-cvs ?

А смысл?

> А еще мне нравится идея, высказанная Sviataslau Svirydau
> "организовать Packager: Apache Development Team
> <apache@packages.altlinux.org>, как это сделано для многих
> других пакетов и пригласить всех желающих?"

Именно.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: apache2

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

On Fri, May 14, 2004 at 11:49:50AM +0400, Anton Farygin wrote:
> Yury Konovalov пишет:
> 
> Юра, может быть выложите в incoming ?
> 
> Без обязательств мантейнить ? Дальше мы понемногу его будет 
> обновлять/исправлять.

Без обязательств maintainить apache* нельзя включать никуда.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: apache2

[Anton Farygin]

Dmitry V. Levin пишет:
> On Fri, May 14, 2004 at 11:49:50AM +0400, Anton Farygin wrote:
> 
>>Yury Konovalov пишет:
>>
>>Юра, может быть выложите в incoming ?
>>
>>Без обязательств мантейнить ? Дальше мы понемногу его будет 
>>обновлять/исправлять.
> 
> 
> Без обязательств maintainить apache* нельзя включать никуда.

В Sisyphus можно и нужно.. а к Master'у будет видно, может быть кто-то и 
подхватит.

Rgds,
Rider

Re: [devel] apache2

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Fri, May 14, 2004 at 04:16:57PM +0400, Anton Farygin wrote:
> Dmitry V. Levin пишет:
> >On Fri, May 14, 2004 at 11:49:50AM +0400, Anton Farygin wrote:
> >
> >>Yury Konovalov пишет:
> >>
> >>Юра, может быть выложите в incoming ?
> >>
> >>Без обязательств мантейнить ? Дальше мы понемногу его будет 
> >>обновлять/исправлять.
> >
> >
> >Без обязательств maintainить apache* нельзя включать никуда.
> 
> В Sisyphus можно и нужно.

Нет.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: apache2

[Yury Konovalov]

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

Пятница 14 Май 2004 16:04, Dmitry V. Levin написал:
> Без обязательств maintainить apache* нельзя включать никуда.
Я готов maintainить apache2 по крайней мере до выхода Master, готов и дальше 
его поддерживать, НО дальше 2-3 месяцев мне трудно глядеть по житейским 
обстоятельствам.
 Кроме того, после появления оного в репозитории будет легче расчитывать, что 
найдутся заинтересованные лица для Apache Development Team.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApMxGBMpuqP3w7LgRAiviAJ0bJjwtPH1m813mTqTFR96CTMdALQCeK0U1
SgvmT2DXh4eE783WLSr4mDQ=
=gtnX
-----END PGP SIGNATURE-----

[devel] Re: [JT] Re: apache2

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Fri, May 14, 2004 at 05:40:10PM +0400, Yury Konovalov wrote:
> Я готов maintainить apache2 по крайней мере до выхода Master,
> готов и дальше его поддерживать, НО дальше 2-3 месяцев мне
> трудно глядеть по житейским обстоятельствам.  Кроме того, после
> появления оного в репозитории будет легче расчитывать, что
> найдутся заинтересованные лица для Apache Development Team.

Разумно.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [JT] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Alexander Bokovoy]

On Fri, May 14, 2004 at 09:24:06AM +0400, Anton Farygin wrote:
> >>>Давайте эту тему тоже на LF попробуем заготовить -- apache2?
> >>
> >>А может быть просто взять сборку RH и пересобрать в нашей среде ?
> >
> >Она не предназначена для сосуществования с Apache 1.x, что является
> >главным препятствием наряду с отсутствием выделенного человека на
> >поддержку пакета, согласно всем нашим предыдущим обсуждениям.
> 
> Она должна быть conflicts с apache 1.x. И это IMHO правильно (я слабо 
> представляю себе в одной системе apache 1 и apache 2 одновременно).
То, что ты себе этого не представляешь, не означает, что этого быть не
может. Мы этот вопрос обсуждали и в sisyphus@, и в community@ неоднократно
и консенсус был именно с сосуществованием.

Нужны они оба -- apache2 нужен для жизни SVN-сервера, но это не означает,
что весь хостинг может быть на него переведен.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Fri, May 14, 2004 at 10:22:24AM +0300, Alexander Bokovoy wrote:
> > Она должна быть conflicts с apache 1.x. И это IMHO правильно
> > (я слабо представляю себе в одной системе apache 1 и apache 2
> > одновременно).
> То, что ты себе этого не представляешь, не означает, что этого
> быть не может. Мы этот вопрос обсуждали и в sisyphus@, и в
> community@ неоднократно и консенсус был именно с
> сосуществованием.

Гм.  И как именно?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Alexander Bokovoy]

On Fri, May 14, 2004 at 03:00:06PM +0300, Michael Shigorin wrote:
> On Fri, May 14, 2004 at 10:22:24AM +0300, Alexander Bokovoy wrote:
> > > Она должна быть conflicts с apache 1.x. И это IMHO правильно
> > > (я слабо представляю себе в одной системе apache 1 и apache 2
> > > одновременно).
> > То, что ты себе этого не представляешь, не означает, что этого
> > быть не может. Мы этот вопрос обсуждали и в sisyphus@, и в
> > community@ неоднократно и консенсус был именно с
> > сосуществованием.
> 
> Гм.  И как именно?

Что "как именно"? Все были согласны с тем, что нельзя делать вытесняющие
пакеты. Вопрос о том, как это должно быть организовано в техническом плане
не обсуждался в связи с отсутствием команды разработчиков пакета.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Yury Konovalov]

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

Четверг 13 Май 2004 16:25, Pavel Mironchik написал:
> Пусть в orphaned - нет apache2, нет смысла
Вообще-то спек для apache2 давно существует:
ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS/apache2-2.0.48-uc5.src.rpm

 Этот пакет даже реально используется, однако ему необходимо более широкое 
тестирование. Кроме того, он не пройдёт Sisyphus check из-за отсутствия FSH 
правил для него так как он по-умолчанию не вытесняет apache 1.x а 
устанавливается в параллельные каталоги (/var/www2 и т.д).
  Если A2 нужен, то я бы мог данный пакет осовременить и выложить.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApGg+BMpuqP3w7LgRAlaFAJ40lbCf/m//RJcP6YFzvF314exGbwCePSnH
eWcmAdOgQqS4Fn3uLEYjBZk=
=6CV9
-----END PGP SIGNATURE-----

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Alexander Bokovoy]

On Fri, May 14, 2004 at 10:33:34AM +0400, Yury Konovalov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Четверг 13 Май 2004 16:25, Pavel Mironchik написал:
> > Пусть в orphaned - нет apache2, нет смысла
> Вообще-то спек для apache2 давно существует:
> ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS/apache2-2.0.48-uc5.src.rpm
> 
>  Этот пакет даже реально используется, однако ему необходимо более широкое 
> тестирование. Кроме того, он не пройдёт Sisyphus check из-за отсутствия FSH 
> правил для него так как он по-умолчанию не вытесняет apache 1.x а 
> устанавливается в параллельные каталоги (/var/www2 и т.д).
>   Если A2 нужен, то я бы мог данный пакет осовременить и выложить.
Давайте осовременим.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Anton Farygin]

Alexander Bokovoy пишет:
> On Fri, May 14, 2004 at 10:33:34AM +0400, Yury Konovalov wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Четверг 13 Май 2004 16:25, Pavel Mironchik написал:
>>
>>>Пусть в orphaned - нет apache2, нет смысла
>>
>>Вообще-то спек для apache2 давно существует:
>>ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS/apache2-2.0.48-uc5.src.rpm
>>
>> Этот пакет даже реально используется, однако ему необходимо более широкое 
>>тестирование. Кроме того, он не пройдёт Sisyphus check из-за отсутствия FSH 
>>правил для него так как он по-умолчанию не вытесняет apache 1.x а 
>>устанавливается в параллельные каталоги (/var/www2 и т.д).
>>  Если A2 нужен, то я бы мог данный пакет осовременить и выложить.
> 
> Давайте осовременим.
> 

Присоединяюсь !!!

Rgds,
Rider

P.S.

/var/www2 можно переместить безболезненно в /var/www/apache2 ?

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Yury Konovalov]

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

Пятница 14 Май 2004 11:50, Anton Farygin написал:

> /var/www2 можно переместить безболезненно в /var/www/apache2 ?
Нет. По причине того, что regexp действует только для apache-common:
# grep apache /etc/sisyphus/fhs
apache-common           ^/var/www($|/)

Кроме того, на мой взгляд это не логично.
Предлагаю обсудить общую схему для апачей в отношении FHS.
Например, в последних стандартах для документов, обслуживаемых вэб-серверами 
предлагается использовать /srv/{что-то}

Почему бы не сделать так? :
/svr/www/vhosts - apache-common для всех апачей для размещения виртуальных 
хостов.
/srv/www/apache(1|2) - дефолтные document root c документами, предоставляемыми 
самим apache + модулями а также документацией apache
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApJpSBMpuqP3w7LgRAnQ6AJ0avdx6CHk6USGMs0nwZclefno7cQCfXM1M
n12qW6fAjTkzZaLCuwl6Nfw=
=mxEF
-----END PGP SIGNATURE-----

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Anton Farygin]

Yury Konovalov пишет:
 >Почему бы не сделать так? :
 >/svr/www/vhosts - apache-common для всех апачей для размещения 
виртуальных
 >хостов.
 >/srv/www/apache(1|2) - дефолтные document root c документами, 
предоставляемыми
 >самим apache + модулями а также документацией apache

Схема мне нравится. А что скажет ldv ?

Rgds,
Rider

[devel] apache2 (was: mod_mono-0.6-alt1: rebuild failed [12])

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

On Fri, May 14, 2004 at 02:07:14PM +0400, Yury Konovalov wrote:
> > /var/www2 можно переместить безболезненно в /var/www/apache2 ?

Ужыс (tm)

Конфликт честнее и естественней.

> Кроме того, на мой взгляд это не логично.

Именно.

> Предлагаю обсудить общую схему для апачей в отношении FHS.
> Например, в последних стандартах для документов, обслуживаемых
> вэб-серверами предлагается использовать /srv/{что-то}

Честно говоря, не уверен, что осмысленно гнаться за FHS в этом
плане.  Пусть другие лбом стенки проламывают (в т.ч. привычек).

> Почему бы не сделать так? : /svr/www/vhosts - apache-common для
> всех апачей для размещения виртуальных хостов.
> /srv/www/apache(1|2) - дефолтные document root c документами,
> предоставляемыми самим apache + модулями а также документацией
> apache

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

Бишь нужно добавить хостерского опыта по организации разделяемого
хостинга (как худшего варианта по проблемности разделения
доступа) и обдумать, где живет контент, куда класть логи, в
идеале с тем, чтобы можно было их и создавать каким-нибудь
"vhostadd" из какого-нибудь "vhostskel".

Желаемый результат -- чтобы в максимально большом количестве
случаев минимизировать изменения для запуска в разумном виде, а
также свести к минимуму необходимость полного перелопачивания как
пакета, так и системы настроек.  Особенно по части размещения
контента и с учетом того, что зачастую стараются предоставлять
доступ в чрут, где должны быть и странички/скрипты, и логи.

Я просто этим не занимаюсь, разве что в рамках linux.kiev.ua.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] apache2 (was: mod_mono-0.6-alt1: rebuild failed [12])

[Yury Konovalov]

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

Пятница 14 Май 2004 15:58, Michael Shigorin написал:
> Честно говоря, не уверен, что осмысленно гнаться за FHS в этом
> плане.  Пусть другие лбом стенки проламывают (в т.ч. привычек).
Пусть. Хотя, опять же - не вижу осложнений, разумеется, кроме ломки 
привычек ;)

> На мой взгляд, тут главная проблема не в том, от какого места
> файловой системы у нас начинаются земли апачей, а в том, как они
> поделены между жилищами (виртхостами).
Согласен на все 100.

> Бишь нужно добавить хостерского опыта по организации разделяемого
> хостинга (как худшего варианта по проблемности разделения
> доступа) и обдумать, где живет контент, куда класть логи, в
> идеале с тем, чтобы можно было их и создавать каким-нибудь
> "vhostadd" из какого-нибудь "vhostskel".
Это крайне интересно, тем более, что каждый провайдер имеет свои методы 
управления хостингом.
Я, например, готов поделиться своим опытом и скриптами управления, а так же 
увидить альтернативные варианты.

(Возможно, было-бы не плохо сделать список isp@altlinux.ru что-бы люди могли 
обсуждать все вопросы, касающиеся провайдеров трафика и услуг.)
 
 
> Желаемый результат -- чтобы в максимально большом количестве
> случаев минимизировать изменения для запуска в разумном виде, а
> также свести к минимуму необходимость полного перелопачивания как
> пакета, так и системы настроек.  Особенно по части размещения
> контента и с учетом того, что зачастую стараются предоставлять
> доступ в чрут, где должны быть и странички/скрипты, и логи.
Да - так и есть.

> Я просто этим не занимаюсь, разве что в рамках linux.kiev.ua.
Этого мало ?! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApjkpBMpuqP3w7LgRAhi/AKCm/WZ9bKjqCPnuT/PWfuRo0MbfyQCdFxuI
y+TzcZxyxLHTgfvyrWXvuEI=
=xkKM
-----END PGP SIGNATURE-----

[devel] Re: apache2 (was: mod_mono-0.6-alt1: rebuild failed [12])

[Michael Shigorin]

On Sat, May 15, 2004 at 07:37:12PM +0400, Yury Konovalov wrote:
> > Бишь нужно добавить хостерского опыта по организации
> > разделяемого хостинга (как худшего варианта по проблемности
> > разделения доступа) и обдумать, где живет контент, куда
> > класть логи, в идеале с тем, чтобы можно было их и создавать
> > каким-нибудь "vhostadd" из какого-нибудь "vhostskel".
> Это крайне интересно, тем более, что каждый провайдер имеет
> свои методы управления хостингом.

Именно.  Но что-то, в частности обрывки общения по теме, наводит
на мысль об общих чертах в распространенных случаях.  И выловить
и сделать _их_ кажется грамотным.

У нас тут через неделю будет провайдеровка, попробую понависать.

> Я, например, готов поделиться своим опытом и скриптами
> управления, а так же увидить альтернативные варианты.

Аналогично (с учетом крайне незначительного опыта).

> (Возможно, было-бы не плохо сделать список isp@altlinux.ru
> что-бы люди могли обсуждать все вопросы, касающиеся провайдеров
> трафика и услуг.)

Кстати да.  Только, наверное, task-isp@ -- с тем, чтобы такие
"специалистские" списки на манер samba@ в дальнейшем было проще
идентифицировать?  С другой стороны, samba@, music@, legal@ уже
есть, почему бы не быть isp@.

> > Я просто этим не занимаюсь, разве что в рамках linux.kiev.ua.
> Этого мало ?! :)

Редко, каждый раз как небольшой аврал, который решается useradd,
mkdir, chown, copy-paste в Vhosts.conf, service httpd reload и
доточкой опций по надобности.

Попросту говоря, не скриптовалось именно потому, что редко и
каждый раз нужен результат, а не скрипт.  А когда есть время и
настроение -- ни разу не вспоминал эту задачу, чтобы нарисовать
для последующего использования.  Именно потому, что для меня оно
нетипично :)

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

Re: [devel] /srv

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

On Fri, May 14, 2004 at 02:07:14PM +0400, Yury Konovalov wrote:
> > /var/www2 можно переместить безболезненно в /var/www/apache2 ?
> Нет. По причине того, что regexp действует только для apache-common:
> # grep apache /etc/sisyphus/fhs
> apache-common           ^/var/www($|/)
> 
> Кроме того, на мой взгляд это не логично.
> Предлагаю обсудить общую схему для апачей в отношении FHS.
> Например, в последних стандартах для документов, обслуживаемых вэб-серверами 
> предлагается использовать /srv/{что-то}
> 
> Почему бы не сделать так? :
> /svr/www/vhosts - apache-common для всех апачей для размещения виртуальных 
> хостов.
> /srv/www/apache(1|2) - дефолтные document root c документами, предоставляемыми 
> самим apache + модулями а также документацией apache

Аргументируйте переход с /var на /srv, пожалуйста.
Кивать на fhs-2.3 нельзя, у нас fhs-2.2 и freeze на носу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /srv

[Yury Konovalov]

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

Пятница 14 Май 2004 16:06, Dmitry V. Levin написал:
> Аргументируйте переход с /var на /srv, пожалуйста.
> Кивать на fhs-2.3 нельзя, у нас fhs-2.2 и freeze на носу.
Аргументы такие:
1)Апачам необходимо общее хранилище данных пользователей (хостеров) в силу 
того, что они (апачи) сущестуют ровно для обслуживания этих данных.
2)Даже оставаясь в рамках fhs-2.2 пункт1 реализуем только пересборкой apache1 
и перемещением его docroot в /var/www/apach1
3)Пересборка apache1 с перемещением docroot не должна мешать сайтам (по 
крайней мере с виртуальными хостами, работающим на сизифе, поскольку конфиги 
останутся старые.
4)Это когда-то нужно делать с учётом того, что apache1 уготована долгая жизнь, 
а apache2 все-же пора появиться на свет.
5)Неясное размещение файлов путает людей и делает вещи субъективно более 
сложными чем они есть на самом деле.

Для меня НЕ принципиален переход на /srv (хотя почему-бы не пойти на шаг 
вперёд остальных). В итоге видны три варианта:
1) Оставаясь в рамках fhs-2.2 переносим docroot apache1 в /var/www/apache1; 
делаем пакет apache-fs, который предоставляет /var/www, и /var/www/vhosts 
(возможно ещё что-то) и который естественно требуют как apache1, так и 
apache2;
2) Делаем пункт1 только в /srv 
3)Оставляем в покое apache1 и просто кладем apache2 по параллельным путям. В 
такой постановке остаётся fhs-2.2, но vhosts будут отдельные.

Как будем делать?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApjMjBMpuqP3w7LgRAohDAJ94lw8qbw7GFkiI4YYOcC6kbsywSQCfbauB
lBrZV1ko4wtHTQhF3/taSV4=
=Kmri
-----END PGP SIGNATURE-----

[devel] Re: /srv

[Michael Shigorin]

On Sat, May 15, 2004 at 07:11:13PM +0400, Yury Konovalov wrote:
> 2)Даже оставаясь в рамках fhs-2.2 пункт1 реализуем только
> пересборкой apache1 и перемещением его docroot в
> /var/www/apach1

Хуже -- туда (под /var/www) уже пишет толпа пакетов.

> 4)Это когда-то нужно делать с учётом того, что apache1
> уготована долгая жизнь, а apache2 все-же пора появиться на
> свет.
> 5)Неясное размещение файлов путает людей и делает вещи
> субъективно более сложными чем они есть на самом деле.

Ага.

> Для меня НЕ принципиален переход на /srv (хотя почему-бы не
> пойти на шаг вперёд остальных).

А смысла тоже нет, зато лишняя инконсистентность создается.

> 1) Оставаясь в рамках fhs-2.2 переносим docroot apache1 в

Докрут _документации_ или апача?  Потому как если выше шел спич о
разделяемом контенте -- так это как раз документация и подобное
может ездить, а непакетный контент -- наоборот, лежать где
сказано.

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

Re: [devel] Re: /srv

[Yury Konovalov]

[-- Attachment #1: Type: Text/Plain, Size: 2661 bytes --]

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

Воскресенье 16 Май 2004 20:54, Michael Shigorin написал:
> On Sat, May 15, 2004 at 07:11:13PM +0400, Yury Konovalov wrote:
> > 2)Даже оставаясь в рамках fhs-2.2 пункт1 реализуем только
> > пересборкой apache1 и перемещением его docroot в
> > /var/www/apach1
>
> Хуже -- туда (под /var/www) уже пишет толпа пакетов.
# grep "/var/www" ..../contents_index |awk '{print$2}'|sort|uniq
apache-common
apache-mod_perl
awstats
bugzilla
bugzilla-ru
cvsweb
darcs-server
horde
htdig
imp
ipac-ng
mailgraph
mailman
midgard-data
mnogosearch-cgi
mod_fastcgi
mod_log_sql
mrtg
nut-cgi
packhouse
php-mmcache
phpMyAdmin
phpPgAdmin
squirrelmail
w3c-validator
webalizer

Итого  --  менее 24.

Если пакеты используют макросы apache-devel, то в крайнем случае это простая 
пересборка.
Ну и главное -- многие не требуется пересобирать немедленно.

> > 1) Оставаясь в рамках fhs-2.2 переносим docroot apache1 в
>
> Докрут _документации_ или апача?  Потому как если выше шел спич о
> разделяемом контенте -- так это как раз документация и подобное
> может ездить, а непакетный контент -- наоборот, лежать где
> сказано.
Да.
Причем, именно разделяемый контент предоставляют большенство из 
вышеперечисленных пакетов.

В качестве варианта подхода к решению этих вопросов предлагается:
1)Создать пакет vhosts-filesystem, который будет предоставлять 
каталоги /var/www и /var/www/vhosts и пакет vhosts-filesystem-devel, который 
будет предоставлять RPM макросы %srv_dir(/var/www) и 
%vhosts_dir(/var/www/vhosts) для заинтересованных пакетов.
Пакет уже создан и готов к отправки в incoming.
2)Пересобрать apache1 с тем чтобы убрать предоставление /var/www и 
переключиться на использование макросов vhosts-filesystem-devel. DocRoot 
можно пока не двигать.
3)Заменить regexp в /etc/sisyphus/fhs с apache-common на vhosts-filesystem
4)Выложить apache2, который тоже уже готов.

Прилагаю патч к текущему spec'у apache1, который не меняет расположение файлов 
apache1, но убирает предоставление /var/www и добавляет зависимость на 
vhosts-filesystem.

С готовыми к отправки в incoming пакетами vhosts-filesystem и apache2 можно 
при желании ознакомиться здесь:  
ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS

Для того, чтобы отправить apache2 в incoming нужно сначала:
- - поменять regexp для fhs с apache-common на vhosts-filesystem ( вопрос к 
Диме, как я понимаю?)
- - принципиальное согласие принять изменения в apache1 плюс сама пересборка

Что скажете?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAq2YMBMpuqP3w7LgRApD4AKCIwPC2C9+UV/ro1ebHcQemN6rvoQCgma6y
ip++GbI6Cki22forDyq7ils=
=KjBF
-----END PGP SIGNATURE-----

[-- Attachment #2: apache.spec.patch --]
[-- Type: text/x-diff, Size: 1552 bytes --]

--- apache-old.spec	2004-05-19 15:17:59 +0400
+++ apache.spec	2004-05-19 17:02:53 +0400
@@ -11,7 +11,7 @@
 # EAPI tarball is subset of mod_ssl tarball
 
 %define apache_root %_sysconfdir/httpd
-%define apache_home %_var/www
+%define apache_home %srv_dir
 %define old_apache_home /home/httpd
 %define apache_user apache
 %define apache_group apache
@@ -104,6 +104,7 @@
 BuildRequires: libdb1-devel libgdbm-devel libmm-devel perl-BSD-Resource perl-CGI perl-Devel-Symdump perl-HTML-Parser perl-URI perl-devel perl-libwww-perl
 
 BuildRequires: altlinux-release
+BuildRequires: vhosts-filesystem-devel
 
 # have to rip libdb4*-devel manually from buildreq'ed line
 %if_with Master
@@ -235,6 +236,7 @@
 Summary(uk_UA.KOI8-U): Сп╕льн╕ файли для ╕нсталяц╕╖ apache та apache-mod_perl
 Group: System/Servers
 PreReq: shadow-utils
+PreReq: vhosts-filesystem
 
 %description common
 This package contains files required for both apache and apache-mod_perl
@@ -671,7 +673,11 @@
 %_sysconfdir/httpd/conf/apache-mime.types.default
 %_sysconfdir/httpd/conf/tables
 %apache_root/logs
-%attr(-,root,%apache_webmaster) %dir %apache_home/
+# Uncomment the following line when apache_home will
+# be different with %srv_dir e.g. when it will be
+# something like %srv_dir/apache1 (/var/www/apache1),
+# but not /var/www.
+#%attr(-,root,%apache_webmaster) %dir %apache_home/
 %attr(2775,root,%apache_webmaster) %dir %apache_home/html/
 %attr(664,root,%apache_webmaster) %config(noreplace) %apache_home/html/*html*
 %attr(664,root,%apache_webmaster) %apache_home/html/*.gif

[devel] apache2, apache1, /var/www (was: /srv)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]

On Wed, May 19, 2004 at 05:50:03PM +0400, Yury Konovalov wrote:
> > Хуже -- туда (под /var/www) уже пишет толпа пакетов.
> # grep "/var/www" ..../contents_index |awk '{print$2}'|sort|uniq
> Итого  --  менее 24.  Если пакеты используют макросы
> apache-devel, то в крайнем случае это простая пересборка.

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

> > > 1) Оставаясь в рамках fhs-2.2 переносим docroot apache1 в
> > Докрут _документации_ или апача?  Потому как если выше шел
> > спич о разделяемом контенте -- так это как раз документация и
> > подобное может ездить, а непакетный контент -- наоборот,
> > лежать где сказано.
> Да.  Причем, именно разделяемый контент предоставляют
> большенство из вышеперечисленных пакетов.

Угу.

> В качестве варианта подхода к решению этих вопросов
> предлагается:
> 1)Создать пакет vhosts-filesystem, который будет предоставлять
> каталоги /var/www и /var/www/vhosts и пакет
> vhosts-filesystem-devel, который будет предоставлять RPM
> макросы %srv_dir(/var/www) и %vhosts_dir(/var/www/vhosts) для
> заинтересованных пакетов.  Пакет уже создан и готов к отправки
> в incoming.

Тогда там еще чуть-чуть макросов не помешает, см.
apache-devel#/etc/rpm/macros.d/apache

> 2)Пересобрать apache1 с тем чтобы убрать предоставление
> /var/www и переключиться на использование макросов
> vhosts-filesystem-devel. DocRoot можно пока не двигать.

Угу.

> 3)Заменить regexp в /etc/sisyphus/fhs с apache-common на
> vhosts-filesystem
> 4)Выложить apache2, который тоже уже готов.
> Прилагаю патч к текущему spec'у apache1, который не меняет
> расположение файлов apache1, но убирает предоставление /var/www
> и добавляет зависимость на vhosts-filesystem.

Боюсь, если оставлять возможности сборки на/под ALM2.2 --
придется еще чуточку попрыгать с #if.

Этот кусочек тоже не уверен, что осмыслен:

+# Uncomment the following line when apache_home will
+# be different with %srv_dir e.g. when it will be
+# something like %srv_dir/apache1 (/var/www/apache1),
+# but not /var/www.
+#%attr(-,root,%apache_webmaster) %dir %apache_home/

что из _не_разделяемого контента у нас предназначено для
/var/www/apache1 ? (if any)

> С готовыми к отправки в incoming пакетами vhosts-filesystem и
> apache2 можно при желании ознакомиться здесь:  
> ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS

Кстати, тут еще Большаков справшивал про макросы сегодня в свете
желания собрать tclhttpd.  Т.к. "общей частью" вопроса я тут вижу
не виртхосты как таковые, подумал -- может, это httpd-common и
httpd-devel?

Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.

> Для того, чтобы отправить apache2 в incoming нужно сначала:
> - поменять regexp для fhs с apache-common на vhosts-filesystem
> (вопрос к Диме, как я понимаю?)

Видимо.

> - принципиальное согласие принять изменения в apache1 плюс
> сама пересборка

> Что скажете?

Согласен, осталось сесть и сделать.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] apache2, apache1, /var/www (was: /srv)

[Yury Konovalov]

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

Среда 19 Май 2004 18:34, Michael Shigorin написал:
> Тогда там еще чуть-чуть макросов не помешает, см.
> apache-devel#/etc/rpm/macros.d/apache
Идея как раз не завязываться на апачи -- эти макросы просто показывают где у 
нас место, выполняющее роль /srv в fhs-2.3 и где виртуальные хосты. Это по 
идее должно использоваться разными службами а не только httpd. По-этому пусть 
макросы apache предоставляет apache-devel. Или какие конкретно макросы 
имелись ввиду?

> Боюсь, если оставлять возможности сборки на/под ALM2.2 --
> придется еще чуточку попрыгать с #if.
Да - это не учитывалось.
>
> Этот кусочек тоже не уверен, что осмыслен:
>
> +# Uncomment the following line when apache_home will
> +# be different with %srv_dir e.g. when it will be
> +# something like %srv_dir/apache1 (/var/www/apache1),
> +# but not /var/www.
> +#%attr(-,root,%apache_webmaster) %dir %apache_home/
>
> что из _не_разделяемого контента у нас предназначено для
> /var/www/apache1 ? (if any)
Все, что специфично для данной версии Apache - manual, default docroot, доки 
модулей, специфицные cgi и т.п. Вообщем все то, что попадет туда само-сабой, 
если изменить apache_home.

> > С готовыми к отправки в incoming пакетами vhosts-filesystem и
> > apache2 можно при желании ознакомиться здесь:
> > ftp://ftp.unixcenter.ru/UnixCenter/Wider/SRPMS
>
> Кстати, тут еще Большаков справшивал про макросы сегодня в свете
> желания собрать tclhttpd.  Т.к. "общей частью" вопроса я тут вижу
> не виртхосты как таковые, подумал -- может, это httpd-common и
> httpd-devel?
> Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
Тут мне не совсем понятно -- эти пакеты будут предоставлять макросы для обоих 
версий apache?
Я себе это представлял так: при сборке модуля, например, под apache1 - в 
buildreq указывается apache-devel, а при желании собрать под apache2 - 
соответственно apache2-devel. Devel-пакеты должны выпихивать друг-друга ибо 
макросы должны быть одноименные для упрощения "кросапачной:)" сборки.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAq3++BMpuqP3w7LgRAicsAJ4uzsG1G4NKKVdjTvDxluVHXVjdygCfYU7Y
Xdz+zMzZjdIbapu7OVDoBeU=
=M70n
-----END PGP SIGNATURE-----

[devel] Re: apache2, apache1, /var/www (was: /srv)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]

On Wed, May 19, 2004 at 07:39:35PM +0400, Yury Konovalov wrote:
> > Тогда там еще чуть-чуть макросов не помешает, см.
> > apache-devel#/etc/rpm/macros.d/apache
> Идея как раз не завязываться на апачи

Это понятно, так я (ниже) и предлагаю вытянуть максимум
независимостей в отдельный *-devel.

> -- эти макросы просто показывают где у нас место, выполняющее
> роль /srv в fhs-2.3 и где виртуальные хосты. Это по идее должно
> использоваться разными службами а не только httpd.

Да, конечно.

> По-этому пусть макросы apache предоставляет apache-devel. Или
> какие конкретно макросы имелись ввиду?

%apache_datadir         %_var/www
%apache_htdocsdir       %apache_datadir/html
%apache_cgibindir       %apache_datadir/cgi-bin
%apache_webmaster       webmaster

> > Этот кусочек тоже не уверен, что осмыслен:
> > +# Uncomment the following line when apache_home will
> > +# be different with %srv_dir e.g. when it will be
> > +# something like %srv_dir/apache1 (/var/www/apache1),
> > +# but not /var/www.
> > +#%attr(-,root,%apache_webmaster) %dir %apache_home/
> > что из _не_разделяемого контента у нас предназначено для
> > /var/www/apache1 ? (if any)
> Все, что специфично для данной версии Apache - manual, default
> docroot, доки модулей, специфицные cgi и т.п.

А у нас есть настолько специфичные cgi, или речь о том, чтобы
обеспечить эту возможность?  Просто получается множество
мощностью Nflavour x Nvirthost.

> Вообщем все то, что попадет туда само-сабой, если изменить
> apache_home.

Э, не.  Тогда туда и разделяемого много упадет.

> > Кстати, тут еще Большаков справшивал про макросы сегодня в
> > свете желания собрать tclhttpd.  Т.к. "общей частью" вопроса
> > я тут вижу не виртхосты как таковые, подумал -- может, это
> > httpd-common и httpd-devel?
> > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
> Тут мне не совсем понятно -- эти пакеты будут предоставлять
> макросы для обоих версий apache?

Частично.  Каждый апач может носить с собой оставшуюся часть
сугубо своих макросов.

> Я себе это представлял так: при сборке модуля, например, под
> apache1 - в buildreq указывается apache-devel, а при желании
> собрать под apache2 - соответственно apache2-devel.
> Devel-пакеты должны выпихивать друг-друга ибо макросы должны
> быть одноименные для упрощения "кросапачной:)" сборки.

Ммм... угу.  Но модули и контент-часть -- штуки разные по степени
зависимости от сервера/версии.

Если забегать в раздел мыслей по web packaging policy, то мне
очень нравится размещение скриптов под /usr/share и подцепление
их или алиасами, или симлинками.  Особенно в свете +/- распухшего
хостинга с приличной дупликацией кода, который не изменяется
per-instance, но порой дыряв и хорошо бы, чтобы его можно было
обновлять одним махом.

Здесь для меня главный вопрос именно с выделением неизменяемой
части (остальное симлинкуется куда-нибудь в /var), а также с
определением реально неизменяемой части.

Дело ровно в том же, почему пакеты для маленького линукса были
бессмысленны -- все равно по ходу дела доводилось рихтовать и о
целостности пакетов говорить особо не приходилось.  Так и тут --
будет ли осмысленна та часть веб-продуктов, которая достаточно
созрела для лежания as is в /usr/share?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: apache2, apache1, /var/www (was: /srv)

[Yury Konovalov]

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

Среда 19 Май 2004 20:27, Michael Shigorin написал:
> Это понятно, так я (ниже) и предлагаю вытянуть максимум
> независимостей в отдельный *-devel.
<skipped>
> %apache_datadir         %_var/www
> %apache_htdocsdir       %apache_datadir/html
> %apache_cgibindir       %apache_datadir/cgi-bin
> %apache_webmaster       webmaster
На мой взгляд это уже специфичные вещи. Я исхожу из того, что разные ветки 
апачей не должны иметь один и тот-же htdocsdir (какой апач наполнит его, если 
у каждого свой контент для этого?) и cgibindir также имеет пару cgi, 
предоставляемых самим апачем.

На сколько я понимаю, предлагается более тесная интеграция апачей, 
предполагающая объединение контентов и разделения общего docroot.
В свою очередь, предлагаю так далеко не идти сходу, и для начала определить 
простую схему при которой апачи смогут сосуществовать.

Это, например, может выглядеть так:
/var/www/
	|
	-apache1/
		|
		-html/
		-cgi-bin/
		-manual/
		-addon1/
		-addon2/
	-apache2/
		|
		-html/
		-cgi-bin/
		-manual/
		-addon1/
		-addon2/
	-shared-cgis/
		|
		-mailman
		-one_more_apache_favour_ignoring_project
	-vhosts/
		|
		-vhost1/
			|
			-htdoc/
			-log/
			-cgi/
		-vhost2/
		...
 

> > Все, что специфично для данной версии Apache - manual, default
> > docroot, доки модулей, специфицные cgi и т.п.
>
> А у нас есть настолько специфичные cgi, или речь о том, чтобы
> обеспечить эту возможность?  Просто получается множество
За то, что уже есть в сизифе не скажу (там просто не откуда взяться 
apache2-specific пакетам:), но я знаю такие пакеты, которые будут 
предоставлять cgi, зависящие от модулей, имеющихся только во втором апаче 
(WebAuth/WebKDC как пример).
> мощностью Nflavour x Nvirthost.
Я бы учёл, что на практике:
1) Apache2 на данный момент решение скорее дополнительное к Apache1.
2) из первого вытекает, что большинство хостеров будут использовать A2 в 
проксируемом посредством A1 режиме (что по умолчанию действует в моем пакете 
почти также как и в apache-mod_perl)
3) В свою очередь, из второго вытекает, что A2 будет действовать лишь для 
малой части виртхостов (или даже части контента виртхоста), а центральный 
cgi-bin дотачивается по-месту. Т.е мы здесь все-равно не угадаем.

> > Вообщем все то, что попадет туда само-сабой, если изменить
> > apache_home.
>
> Э, не.  Тогда туда и разделяемого много упадет.
Можно сказать, что это даже хорошо -- пусть сначала пакет осознает свой 
контент разделяемым. Так постепенно все образуется и не будет резких 
изменений. Я имею ввиду, что пакеты(основанные на apache), даже без внесения 
изменений будут собираться под A1, пока мантейнер не решит, что можно 
предоставлять что-либо в %srv_dir

> > > Кстати, тут еще Большаков справшивал про макросы сегодня в
> > > свете желания собрать tclhttpd.  Т.к. "общей частью" вопроса
> > > я тут вижу не виртхосты как таковые, подумал -- может, это
> > > httpd-common и httpd-devel?
> > > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
> > Тут мне не совсем понятно -- эти пакеты будут предоставлять
> > макросы для обоих версий apache?
> Частично.  Каждый апач может носить с собой оставшуюся часть
> сугубо своих макросов.
Это пересекается со сказанным в начале. Здесь только хотелось сказать, что на 
данный момент, если отказаться от идеи одного docroot'а, следует определить 
тот список макросов, достаточный для сборки модулей, и использовать 
одинаковые имена, при взаимно вытесняющих -devel.

> > Я себе это представлял так: при сборке модуля, например, под
> > apache1 - в buildreq указывается apache-devel, а при желании
> > собрать под apache2 - соответственно apache2-devel.
> > Devel-пакеты должны выпихивать друг-друга ибо макросы должны
> > быть одноименные для упрощения "кросапачной:)" сборки.
>
> Ммм... угу.  Но модули и контент-часть -- штуки разные по степени
> зависимости от сервера/версии.
Иногда и с модулями идёт контент, который зависит от версии A.

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

> Здесь для меня главный вопрос именно с выделением неизменяемой
> части (остальное симлинкуется куда-нибудь в /var), а также с
> определением реально неизменяемой части.
Да в этом все и дело. 

> Дело ровно в том же, почему пакеты для маленького линукса были
> бессмысленны -- все равно по ходу дела доводилось рихтовать и о
> целостности пакетов говорить особо не приходилось.  Так и тут --
> будет ли осмысленна та часть веб-продуктов, которая достаточно
> созрела для лежания as is в /usr/share?
По моим наблюдениям, админы часто переносят содержимое web-пакетов в свой 
каталог, где хачат напильниками и выкладывают. Видимо уже есть "доточенные" 
вэб-пакеты, обновление которых на 99% пройдёт без негативных последствий -- 
их и искать.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArK2CBMpuqP3w7LgRArsnAJ9xNZRJWjMe71T70i+AQz3xPW/zRACfefuy
60NeXO5tQsa4TpGXREh05+0=
=1gLc
-----END PGP SIGNATURE-----

[devel] Re: apache2, apache1, /var/www (was: /srv)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 8451 bytes --]

On Thu, May 20, 2004 at 05:06:51PM +0400, Yury Konovalov wrote:
> > Это понятно, так я (ниже) и предлагаю вытянуть максимум
> > независимостей в отдельный *-devel.
> <skipped>
> > %apache_datadir         %_var/www
> > %apache_htdocsdir       %apache_datadir/html
> > %apache_cgibindir       %apache_datadir/cgi-bin
> > %apache_webmaster       webmaster
> На мой взгляд это уже специфичные вещи.

Нет, ну переименовать их в httpd_* или еще как более нейтрально,
понятное дело.

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

Насколько понимаю, "свой" (неразделяемый) контент, по-хорошему --
исключение из правила.

Опять же может иметь смысл держать его тоже в /usr/share -- это
нечто неизменяемое, в конце концов.

> На сколько я понимаю, предлагается более тесная интеграция
> апачей, предполагающая объединение контентов и разделения
> общего docroot.  В свою очередь, предлагаю так далеко не идти
> сходу, и для начала определить простую схему при которой апачи
> смогут сосуществовать.

А потом с ней героически сражаться? ;-)

См. mod_ssl.spec свежего разлива.  А ведь тривиальная вещь,
казалось бы...

> Это, например, может выглядеть так:
> /var/www/
> 	|
> 	-apache1/
> 		|
> 		-html/
> 		-cgi-bin/
> 		-manual/
> 		-addon1/
> 		-addon2/

Что здесь? (ну manual понятно, хотя и он у нас обычно жил
симлинком под html)

> 	-apache2/
> 		|
> 		-html/
> 		-cgi-bin/
> 		-manual/
> 		-addon1/
> 		-addon2/

И чем отличается то, что здесь?

Бишь если я собираю webalizer -- куда он кладет свой контент?
(собирать два webalizer просто так -- не буду :)

> 	-shared-cgis/
> 		|
> 		-mailman
> 		-one_more_apache_favour_ignoring_project

А не большинство ли их такое?  И нет ли смысла тогда здвать это
просто cgi-bin/ ? :)

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

> 	-vhosts/
> 		|
> 		-vhost1/
> 			|
> 			-htdoc/
> 			-log/
> 			-cgi/
> 		-vhost2/
> 		...

Тут вопросов нет.

> > > Все, что специфично для данной версии Apache - manual,
> > > default docroot, доки модулей, специфицные cgi и т.п.
> > А у нас есть настолько специфичные cgi, или речь о том, чтобы
> > обеспечить эту возможность?  Просто получается множество
> За то, что уже есть в сизифе не скажу (там просто не откуда
> взяться apache2-specific пакетам:), но я знаю такие пакеты,
> которые будут предоставлять cgi, зависящие от модулей,
> имеющихся только во втором апаче (WebAuth/WebKDC как пример).

С другой стороны -- и что плохого, если они окажутся в
разделяемом cgi-bin?  Максимум взорвется не под тем (и то уже дав
намек требованием "того").

> > мощностью Nflavour x Nvirthost.
> Я бы учёл, что на практике:
> 1) Apache2 на данный момент решение скорее дополнительное к Apache1.

Да, но уже не единственное.  Сам тоже собираюсь все boa опакетить
:)

> 2) из первого вытекает, что большинство хостеров будут
> использовать A2 в проксируемом посредством A1 режиме (что по
> умолчанию действует в моем пакете почти также как и в
> apache-mod_perl)

А, вот как.  Не учел.

Т.е. именно одновременная работа...

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

Ммм.... хорошо.  А наблюдались несовместимые снизу вверх CGI?

> > > Вообщем все то, что попадет туда само-сабой, если изменить
> > > apache_home.
> > Э, не.  Тогда туда и разделяемого много упадет.
> Можно сказать, что это даже хорошо -- пусть сначала пакет
> осознает свой контент разделяемым. Так постепенно все
> образуется и не будет резких изменений. Я имею ввиду, что
> пакеты(основанные на apache), даже без внесения изменений будут
> собираться под A1, пока мантейнер не решит, что можно
> предоставлять что-либо в %srv_dir

Кажется, потерял контекст, но имелось в виду, что сейчас скорее
типично использование /var/www, нежели %_apache/home:

RPM/SPECS/classic> grep var/www * | cut -f1 -d: | uniq | wc -l
29
RPM/SPECS/classic> grep %apache_home * | cut -f1 -d: | uniq | wc -l
3

(это apache, packhouse, phpPgAdmin)

Т.е. 1) дело не в макросах :-) и 2) незачем априори полагать, что
софт является apache1-specific.

В последнем могу быть неправ.

> > > > Кстати, тут еще Большаков справшивал про макросы сегодня в
> > > > свете желания собрать tclhttpd.  Т.к. "общей частью" вопроса
> > > > я тут вижу не виртхосты как таковые, подумал -- может, это
> > > > httpd-common и httpd-devel?
> > > > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
> > > Тут мне не совсем понятно -- эти пакеты будут предоставлять
> > > макросы для обоих версий apache?
> > Частично.  Каждый апач может носить с собой оставшуюся часть
> > сугубо своих макросов.
> Это пересекается со сказанным в начале.

Да, конечно.  Особенно с учетом того, что я *подразумевал* там
замену apache обобщенным httpd :-)

> Здесь только хотелось сказать, что на данный момент, если
> отказаться от идеи одного docroot'а, следует определить тот
> список макросов, достаточный для сборки модулей, и использовать
> одинаковые имена, при взаимно вытесняющих -devel.

А что тогда делать с webalizer? ;-)

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

Соответственно если apache2 будет этаким довеском, то когда ему
придет времябыть _платформой_ -- изначальная завязка на
"неполноценность" и обособленность может сыграть злую шутку.

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

> > > Я себе это представлял так: при сборке модуля, например,
> > > под apache1 - в buildreq указывается apache-devel, а при
> > > желании собрать под apache2 - соответственно apache2-devel.
> > > Devel-пакеты должны выпихивать друг-друга ибо макросы
> > > должны быть одноименные для упрощения "кросапачной:)"
> > > сборки.
> > Ммм... угу.  Но модули и контент-часть -- штуки разные по
> > степени зависимости от сервера/версии.
> Иногда и с модулями идёт контент, который зависит от версии A.

Кстати, можно пример?  (документация не в счет, с ней понятно)

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

А посмотрите дебиановские пакеты.

Там есть и, например, возможность сказать, в какую именно БД
ходить создавать штатные базы, и это очень симпатичная
автоматизация нудной и тупой "деятельности".

> > Здесь для меня главный вопрос именно с выделением
> > неизменяемой части (остальное симлинкуется куда-нибудь в
> > /var), а также с определением реально неизменяемой части.
> Да в этом все и дело. 

Оно, конечно, per-webpackage, но...

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

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

> По моим наблюдениям, админы часто переносят содержимое
> web-пакетов в свой каталог, где хачат напильниками и
> выкладывают. Видимо уже есть "доточенные" вэб-пакеты,
> обновление которых на 99% пройдёт без негативных последствий --
> их и искать.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: apache2, apache1, /var/www (was: /srv)

[Yury Konovalov]

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

Четверг 20 Май 2004 18:04, Michael Shigorin написал:
> > > %apache_datadir         %_var/www
> > > %apache_htdocsdir       %apache_datadir/html
> > > %apache_cgibindir       %apache_datadir/cgi-bin
> > > %apache_webmaster       webmaster
> >
> > На мой взгляд это уже специфичные вещи.
>
> Нет, ну переименовать их в httpd_* или еще как более нейтрально,
> понятное дело.
>
Я имел ввиду не имена, а сам принцип.

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

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

> > На сколько я понимаю, предлагается более тесная интеграция
> > апачей, предполагающая объединение контентов и разделения
> > общего docroot.  В свою очередь, предлагаю так далеко не идти
> > сходу, и для начала определить простую схему при которой апачи
> > смогут сосуществовать.
>
> А потом с ней героически сражаться? ;-)
>
> См. mod_ssl.spec свежего разлива.  А ведь тривиальная вещь,
> казалось бы...
>
Не вижу связи. Модулям нужно использовать макросы, предоставляемые апачем -- 
тогда им все-равно, какая будет схема.

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

Всем -- чаще всего, видимо, вообще не будут пересекаться.

> Бишь если я собираю webalizer -- куда он кладет свой контент?
> (собирать два webalizer просто так -- не буду :)

В /var/www/shared-cgis/webalizer + конфиг в 
оба /etc/httpd{favour}/conf/addon.d
Ну или если применить /usr/share, то в /usr/share/apache-shared/webalizer/

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

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

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

> > > мощностью Nflavour x Nvirthost.
> >
> > Я бы учёл, что на практике:
> > 1) Apache2 на данный момент решение скорее дополнительное к Apache1.
>
> Да, но уже не единственное.  Сам тоже собираюсь все boa опакетить
Разумеется!

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

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

> > > > Вообщем все то, что попадет туда само-сабой, если изменить
> > > > apache_home.
> > >
> > > Э, не.  Тогда туда и разделяемого много упадет.
> >
> > Можно сказать, что это даже хорошо -- пусть сначала пакет
> > осознает свой контент разделяемым. Так постепенно все
> > образуется и не будет резких изменений. Я имею ввиду, что
> > пакеты(основанные на apache), даже без внесения изменений будут
> > собираться под A1, пока мантейнер не решит, что можно
> > предоставлять что-либо в %srv_dir
>
> Кажется, потерял контекст, но имелось в виду, что сейчас скорее
> типично использование /var/www, нежели %_apache/home:
>
> RPM/SPECS/classic> grep var/www * | cut -f1 -d: | uniq | wc -l
> 29
> RPM/SPECS/classic> grep %apache_home * | cut -f1 -d: | uniq | wc -l
> 3
>
> (это apache, packhouse, phpPgAdmin)
>
> Т.е. 1) дело не в макросах :-) и 2) незачем априори полагать, что
> софт является apache1-specific.
>
> В последнем могу быть неправ.

Макросы сильно помогут :)
Да, но сейчас все, что есть в сизифе выглядит как apache1-specific по форме, а 
не по факту. Пусть мантейнеры решают как сделать пакет толерантным к версии 
апача. Тут всего два варианта:
1) Пакет идёт в shared-cgis (mailman для примера)
2) Пакет рождает отдельную сборку для A2 (mod_php как пример)

> > > > > Кстати, тут еще Большаков справшивал про макросы сегодня в
> > > > > свете желания собрать tclhttpd.  Т.к. "общей частью" вопроса
> > > > > я тут вижу не виртхосты как таковые, подумал -- может, это
> > > > > httpd-common и httpd-devel?
> > > > > Вопрос чуть ли не вкуса, но чтоб уж потом не трогать.
> > > >
> > > > Тут мне не совсем понятно -- эти пакеты будут предоставлять
> > > > макросы для обоих версий apache?
> > >
> > > Частично.  Каждый апач может носить с собой оставшуюся часть
> > > сугубо своих макросов.
> >
> > Это пересекается со сказанным в начале.
>
> Да, конечно.  Особенно с учетом того, что я *подразумевал* там
> замену apache обобщенным httpd :-)
>
> > Здесь только хотелось сказать, что на данный момент, если
> > отказаться от идеи одного docroot'а, следует определить тот
> > список макросов, достаточный для сборки модулей, и использовать
> > одинаковые имена, при взаимно вытесняющих -devel.
>
> А что тогда делать с webalizer? ;-)

Это решать мантейнеру :)
На мой взгляд -- хороший пример для shared-cgis. Ему при сборке конечно нужно 
будет проsedить как apache.conf, так и apache2.conf. Причем, это даже слишком 
хороший пример - ему ведь по сути нужно знать где логи обоих апачей... Значит 
собираться ему без apache-макросов.

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

Он более чем полноценен! Правда! :)

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

Для этого и обсуждаем.

> > Иногда и с модулями идёт контент, который зависит от версии A.
>
> Кстати, можно пример?  (документация не в счет, с ней понятно)

mod_webkdc

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

Нужно будет посмотреть.

> Оно, конечно, per-webpackage, но...
>
> Хотя с другой стороны -- если бы rpm2 ориентировался на ситуацию
> "все равно все будут хачить по месту", так бы он и остался таром
> на стероидах -- большим, но глупым.
>
> Так что будем ориентироваться на mature web software.  Пилимое
> (плохое) -- в конце концов, руками по старинке разложить можно,
> раз все равно пилить.

Мы на это не ориентируемся -- просто пока не ясно, как сделать лучше.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFArgL7BMpuqP3w7LgRAkr0AKCHpjcw0y2doZ5eLNlicVz1hJC2XgCfSpQ9
d9ljxFXioZJ34LTRxshV6K0=
=hT7n
-----END PGP SIGNATURE-----

[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/

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

[Vladimir Lettiev]

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

Michael Shigorin пишет:
| PreScriptum: хочется попросить yurix@, ab@ и других
| заинтересованных в том, чтобы подумать над:
|
| - действительно ли нам нужны два апача, которые одновременно
|   - устанавливаемы (затрудняет завязку по пакетным завивимостям);
|   - запускаемы (переносит множество проверок в стартап-тайм);
| - "как это сделано у других" (если вообще где-то сделано).
|
| Пока у меня зреет ощущение, что то, на что замахиваемся, у меня в
| голове не укладывается в достаточной мере (вместе с
| последствиями).  По каковой причине, собственно, и не пытался
| сделать то же самое раньше, хотя "счастья всем даром",
| разумеется, хотелось давно.
|
| PreS2: положительные ответы на "действительно ли" принимаются
| _исключительно_ с прикладными соображениями на тему реализации.

Прошу также учесть мнение простых смертных вебмастеров, которые будут
устанавливать только один апач и какого им будет при виде
перенагромождённой структуры каталогов для контента (излишней для них).
Какого будет уже существующим программам, которые имеют свои файлы в
/var/www/... ?
Читая тред создаётся впечатление, что совместить оба апача пытаются
только те, кому это нужно по каким-то личным специфичным потребностям,
вполне вероятно, что в реалии таких будет <1% от общего числа
пользователей апаче в дистрибутивах ALTLinux. Может не стоит мешать
личные интересы с общими? Я не видел, чтобы кто-нибудь ешё (другие
дистрибьюторы) пытался создать нечто подобное...

- --
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAsb25HjuOqBHxmZURAq7YAJ4tn6vY2g3qyPit7UmkDwFCxKT2WwCdEGVq
25BhidU2szvfozAqa4kg2KM=
=Qa1d
-----END PGP SIGNATURE-----

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

[Klimchev Konstantin]

On Mon, 24 May 2004 13:17:45 +0400
Vladimir Lettiev <crux@syktsu.ru> wrote:

> Прошу также учесть мнение простых смертных вебмастеров, которые будут
> устанавливать только один апач и какого им будет при виде
> перенагромождённой структуры каталогов для контента (излишней для них).
> Какого будет уже существующим программам, которые имеют свои файлы в
> /var/www/... ?
> Читая тред создаётся впечатление, что совместить оба апача пытаются
> только те, кому это нужно по каким-то личным специфичным потребностям,
> вполне вероятно, что в реалии таких будет <1% от общего числа
> пользователей апаче в дистрибутивах ALTLinux. Может не стоит мешать
> личные интересы с общими? Я не видел, чтобы кто-нибудь ешё (другие
> дистрибьюторы) пытался создать нечто подобное...

Наверное, я присоединюсь. Может не будем скрещивать?

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.atvc.ru)
ATK-Internet ISP, Arkhangelsk, Russia

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

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Mon, May 24, 2004 at 01:16:05PM +0400, Klimchev Konstantin wrote:
> > Читая тред создаётся впечатление, что совместить оба апача пытаются
> > только те, кому это нужно по каким-то личным специфичным потребностям,
> > вполне вероятно, что в реалии таких будет <1% от общего числа
> > пользователей апаче в дистрибутивах ALTLinux. Может не стоит мешать
> > личные интересы с общими? Я не видел, чтобы кто-нибудь ешё (другие
> > дистрибьюторы) пытался создать нечто подобное...
> Наверное, я присоединюсь. Может не будем скрещивать?

Ну, я и написал в PreScriptum, что это все выглядит очень хорошо,
но вот у меня голова треснет придумать, как это сделать, не
привнеся *немеряных* грабель в *большинстве* случаев.

Вообще не уверен, что оптимизация под маргиналов -- это
правильно.  Они или ССЗБ, или профи, которые все равно никогда не
удовольствуются умолчаниями и сделают все по-своему.

С другой стороны, делать схему для apache2 сейчас зажатой в
тесные рамки с учетом наличия apache, apache-mod_perl, еще
всякого-разного и так непростого наследства -- тоже не хочется.

Именно из этих соображений и предлагал их расконфликтовать и все.

Ну Юрий-то старается вырисовать схему, но больно громоздкой и
уникальной (никому не привычной) она получается.  А вот остальные
желающие всего и сразу (кто-то еще, кроме Саши, который понятно
чем занят, изъявлял) -- что-то разбежались. (или это в sisyphus@
было?)

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Mon, May 24, 2004 at 12:44:30PM +0300, Michael Shigorin wrote:

 MS> Ну Юрий-то старается вырисовать схему, но больно громоздкой и
 MS> уникальной (никому не привычной) она получается.  А вот остальные
 MS> желающие всего и сразу (кто-то еще, кроме Саши, который понятно
 MS> чем занят, изъявлял) -- что-то разбежались. (или это в sisyphus@
 MS> было?)

Ещё мне нужны одновременно apache2 и apache1. Причём нужны в таком виде,
чтобы переведение хоста с одного на другой и обратно требовало правки не
более одной строки в конфиге.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Denis Ovsienko]

> Ещё мне нужны одновременно apache2 и apache1. Причём нужны в таком виде,
> чтобы переведение хоста с одного на другой и обратно требовало правки не
> более одной строки в конфиге.
И сколько вы за это решение даёте?

-- 
    DO4-UANIC

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

[Michael Shigorin]

On Thu, May 27, 2004 at 12:59:21PM +0300, Denis Ovsienko wrote:
> > Ещё мне нужны одновременно apache2 и apache1. Причём нужны в
> > таком виде, чтобы переведение хоста с одного на другой и
> > обратно требовало правки не более одной строки в конфиге.
> И сколько вы за это решение даёте?

Ну, вполне принимается временем на реализацию.

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

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

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Thu, May 27, 2004 at 12:59:21PM +0300, Denis Ovsienko wrote:

 >> Ещё мне нужны одновременно apache2 и apache1. Причём нужны в таком виде,
 >> чтобы переведение хоста с одного на другой и обратно требовало правки не
 >> более одной строки в конфиге.
 DO> И сколько вы за это решение даёте?

Оно мне нужно в будущем. Когда оно мне станет нужно в настоящем я либо его
сделаю сам, либо, что вероятнее, гораздо раньше найду тех, кто заплатит
мне за то, что я это сделаю.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Yury Konovalov]

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

Понедельник 24 Май 2004 13:17, Vladimir Lettiev написал:
> Прошу также учесть мнение простых смертных вебмастеров, которые будут
> устанавливать только один апач и какого им будет при виде
> перенагромождённой структуры каталогов для контента (излишней для них).
> Какого будет уже существующим программам, которые имеют свои файлы в
> /var/www/... ?
Они ничего не заметят... :) Не забывайте, что httpd.conf не обновляется.

> Читая тред создаётся впечатление, что совместить оба апача пытаются
> только те, кому это нужно по каким-то личным специфичным потребностям,
> вполне вероятно, что в реалии таких будет <1% от общего числа
> пользователей апаче в дистрибутивах ALTLinux. Может не стоит мешать
> личные интересы с общими? Я не видел, чтобы кто-нибудь ешё (другие
> дистрибьюторы) пытался создать нечто подобное...
Тред получился сложнее самой задачи. Я как раз за то, чтобы НЕ скрещивать 
апачи а сделать их просто независимыми.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAshtZBMpuqP3w7LgRAl0yAJ9X2SKSgXBbMjkjWiwqum4yKAaZhwCff3Nj
aWGbcRU8TTEFXQAKRlijoxs=
=oYhE
-----END PGP SIGNATURE-----

Re: [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-----

Re: [devel] Re: mod_mono-0.6-alt1: rebuild failed [12]

[Stanislav Ievlev]

On Thu, May 13, 2004 at 03:25:15PM +0300, Pavel Mironchik wrote:
> 
> Пусть в orphaned - нет apache2, нет смысла
Готово, не забудьте потом воскресить.
> 
> On Thu, 13 May 2004 15:20:58 +0400 (MSD)
> QA Team Robot <qa@altlinux.org> wrote:
> 
> > Package: mod_mono-0.6-alt1
> > Packager: Pavel Mironchik <tibor@altlinux>
> > Status: rebuild failed.
> > Cannot build this package for 12 week(s) (since Tue Feb 17 2004).
> > Please investigate.
> > 
> > Why:
> > 
> > ar cru .libs/libmod_mono.a  mod_mono.o 
> > ranlib .libs/libmod_mono.a
> > creating libmod_mono.la
> > (cd .libs && rm -f libmod_mono.la && ln -s ../libmod_mono.la libmod_mono.la)
> > /bin/sh ../libtool --mode=link gcc  -I/usr/include/apr-0 -I/usr/include/apu-0 -I/usr/include/apache  -I/usr/include/apr-0  -DAPACHE13 -DEAPI   -o libmod_mono_old.la -rpath /usr/lib    
> > rm -fr .libs/libmod_mono_old.la .libs/libmod_mono_old.* .libs/libmod_mono_old.*
> > gcc -shared    -Wl,-soname -Wl,libmod_mono_old.so.0 -o .libs/libmod_mono_old.so.0.0.0
> > (cd .libs && rm -f libmod_mono_old.so.0 && ln -s libmod_mono_old.so.0.0.0 libmod_mono_old.so.0)
> > (cd .libs && rm -f libmod_mono_old.so && ln -s libmod_mono_old.so.0.0.0 libmod_mono_old.so)
> > ar cru .libs/libmod_mono_old.a  
> > ranlib .libs/libmod_mono_old.a
> > creating libmod_mono_old.la
> > (cd .libs && rm -f libmod_mono_old.la && ln -s ../libmod_mono_old.la libmod_mono_old.la)
> > make[1]: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> > make[1]: Entering directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> > make[1]: Nothing to be done for `all-am'.
> > make[1]: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> > make: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6'
> > + pushd src
> > ~/RPM/BUILD/mod_mono-0.6/src ~/RPM/BUILD/mod_mono-0.6
> > + make -f makedll.mak
> > make: Entering directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> > mcs /debug+ /debug:full /nologo /r:System.Web.dll /target:library /out:ModMono.dll ApacheApplicationHost.cs ApacheWorkerRequest.cs MonoWorkerRequest.cs IApplicationHost.cs Request.cs
> > make: mcs: Command not found
> > make: *** [ModMono.dll] Error 127
> > make: Leaving directory `/usr/src/RPM/BUILD/mod_mono-0.6/src'
> > error: Bad exit status from /usr/src/RPM/tmp/rpm-tmp.75664 (%build)
> > 
> > RPM build errors:
> >     Bad exit status from /usr/src/RPM/tmp/rpm-tmp.75664 (%build)
> > 2.35user 1.99system 0:09.57elapsed 45%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (107686major+121002minor)pagefaults 0swaps
> > rebuild: rebuild of `mod_mono-0.6-alt1.src.rpm' failed.
> > 
> > -- 
> > Sincerely yours,
> > ALT QA Team Robot
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://lists.altlinux.ru/mailman/listinfo/devel