Re: [devel] non-strict dependency in apache2

[Aleksey Avdeev <solo@solin.spb.ru>]

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

24.01.2013 23:15, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 09:58:12PM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 15:25, Dmitry V. Levin пишет:
>>> On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote:
>>>> 24.01.2013 10:44, Dmitry V. Levin пишет:
>>>> ...
>>>>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
>>>>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
>>>>> списка разрешенных пар нестрогих зависимостей:
>>>>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
>>>>
>>>>   Прошу уточнения:
>>>>
>>>> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
>>>> зависимости на любой другой пакет из него же?
>>>>
>>>> 2. В каком виде должны присутствовать имена пакетов в списке:
>>>> %name-<subname> или достаточно <subname>?
>>>
>>> Имеется в виду, что каждый случай применения этого макроса стоит проводить
>>> через обсуждение в этом списке, хотя бы только для того, чтобы убедиться,
>>> что нестрогие зависимости в данном конкретном пакете действительно имеют
>>> смысл, а не являются следствием приземления благих намерений.
>>
>>   Тогда давайте обсуждать apache2, то что сейчас собираю (см.
>> <http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=blob;f=apache2.spec;h=c9e9fad9fb4dc01789edc90d6757de8c77b734dd;hb=ALT/apache2/spec>):
>>
>> error: apache2: non-strict dependency on apache2-cgi-bin
>> error: apache2: non-strict dependency on apache2-html
>> error: apache2: non-strict dependency on apache2-icons
>>
>>   Вызвано зависимостями:
>>
>> Requires: webserver-cgi-bin
>> Requires: webserver-html
>> Requires: webserver-icons
>>
>>   Данные зависимости предоставляют не только пакеты
>> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
>> apache2 _действительно_ всё равно, какие именно пакеты данные
>> зависимости реализуют.
> 
> Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
> От этого действительно может быть какая-то польза?  Или все это
> разнообразие упаковывается просто потому, что это возможно?

  Действительно нужно: у нас сейчас содержимое
/var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
собой, вариантах: "от apache" и "от apache2" (см.
<http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
(см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
дискуссии):

1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
apache2 ставлю." -- решается пакетом apache2-full, вытягивает
apache2-{cgi-bin,html,icons}.

2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
ставлю." -- решается пакетом apache-full, вытягивает
apache-{cgi-bin,html,icons}.

3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
вытягиваущими apache2-{cgi-bin,html,icons} по факту).

4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
apache{,2}-base.

> 
>> error: apache2-base: non-strict dependency on apache2-common
>>
>>   apache2-base это в основном сборище конфигов, каталогов и пр. не
>> исполняемых файлов. Бинарные вспомогательные утилиты там тоже есть, но
>> от бинарного содержимого apache2-common (и его ABI) они не зависят.
>> Несовместимости учтены зависимостями вида
>> Requires: %name-common > 2.2.22-alt11 в самом пакете и конфликтами вида
>> Conflicts: apache2-base <= 2.2.22-alt11 в apache2-common.
> 
> Есть ли смысл использовать apache2-base и apache2-common от разных сборок
> одновременно?  Мне кажется, что здесь чем проще, тем лучше.

  Да. apache2-base это: конфиги (и их примеры), стартовые файлы httpd2
(для init/systemd), вспомогательные утилиты, сообщения об ошибках и пр.
инфраструктура. apache2-common же это в основном модули и конфиги (и
утилиты) для них (хотя куски инфраструктуры там тоже есть). Для закрытия
большинства багов связанных с безопасностью (CVE и подобные) достаточно
обновить только apache2-common (если проблемный модуль там, или другой
нужный apache2-mod_*) и используемый apache2-httpd-* (причём, в заметном
числе случаев, когда бага и исправление затрагивают только модуль, его
тоже трогать не нужно).

> 
>> error: apache2-base: non-strict dependency on apache2-httpd-worker
>> error: apache2-base: non-strict dependency on apache2-httpd-prefork
>> error: apache2-base: non-strict dependency on apache2-httpd-event
>> error: apache2-base: non-strict dependency on apache2-httpd-itk
>> error: apache2-base: non-strict dependency on apache2-httpd-peruser
>>
>>   Вызвано требованием:
>>
>> Requires: %apache2_sbindir/%apache2_dname
>>
>> т. к. файл %apache2_sbindir/%apache2_dname альтернатива, предоставляемая
>> всеми перечисленными подпакетами
>> (apache2-httpd-{worker,prefork,event,itk,peruser}).
> 
> Вот это очень похоже на реальную альтернативу, где неявность зависимости
> объективно связана с возможностью осмысленного выбора.
> 
>> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
>> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
>>
>>   Комплект конфигов. Совместимость учтена через зависимости.
> 
> Не понимаю.

$ rpm -ql apache2-configs-A1PROXIED
/etc/httpd2/conf/ports-available/http-A1PROXIED.conf
/etc/httpd2/conf/ports-enabled/http-A1PROXIED.conf
/etc/httpd2/conf/ports-start.d/020-A1PROXIED.conf
/etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf
/etc/httpd2/conf/sites-enabled/vhosts-A1PROXIED.conf
/etc/httpd2/conf/sites-start.d/020-A1PROXIED.conf

  Для пакета необходимо только чтобы существовали инклюдируемые файлы:
/etc/httpd2/conf/ports-available/http{,-localhost-8088}.conf для
/etc/httpd2/conf/ports-available/http-A1PROXIED.conf и
/etc/httpd2/conf/sites-available/vhosts{,-8088}.conf для
/etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf. Всё остальное (в
том числе _версия_ бинарников apache2 и содержимое инклюдируемых файлов)
-- данному пакету глубоко фиолетово.

> 
>> error: apache2-httpd-worker: non-strict dependency on apache2-common
>> error: apache2-httpd-prefork: non-strict dependency on apache2-common
>> error: apache2-httpd-event: non-strict dependency on apache2-common
>> error: apache2-httpd-itk: non-strict dependency on apache2-common
>> error: apache2-httpd-peruser: non-strict dependency on apache2-common
>>
>>   Фактически, здесь недолинкованные библиотеки (модули
>> в apache2-common) зависят от бинарников, подставляемых пакетми
>> apache2-httpd-{worker,prefork,event,itk,peruser} через альтернативу
>> %apache2_sbindir/%apache2_dname (/usr/sbin/httpd2), но направление
>> зависимостей выставлено обратным. Т. е. для rpm не модули
>> (apache2-common) зависят от исполняемых бинарников (/usr/sbin/httpd2),
>> что имеет место быть по факту, а бинарники (пакеты apache2-httpd-*) от
>> модулей (apache2-common). (Пакет apache2-common выбран центральной
>> сущностью.)
>>
>>   От проблем защищают:
>>
>> 1. Привязка к конкретному MMU (Module Magic Number, см.
>> <http://httpd.apache.org/docs/2.2/glossary.html>) (apache2-common
>> предоставляет %name-mmn = %mmn, а apache2-httpd-* его _строго_ требуют).
>>
>> 2. Есть защита от использования не той libaprutil1, через:
>>
>> а) Requires: libaprutil1 >= %n_aprutil_devel_ver в apache2-common
>> (%n_aprutil_devel_ver соответствует версии-релизу пакета
>> libaprutil1-devel использованного при сборке).
>>
>> б) Автозависимость вида libaprutil-1.so.0()(64bit) >= set:... (наши
>> set-version, или как их назвать правильно) в пакетах
>> apache2-httpd-{worker,prefork,event,itk,peruser}.
>>
>> Т. е. сейчас я считаю что пакет libaprutil1 такой-же или более новый чем
>> libaprutil1-devel использованный при сборке, скорее всего подойдёт для
>> модулей (в apache2-common). (С пакетами apache2-httpd-* проще -- там
>> set-version работает.)
>>
>>   Понятно что это тонкое место, и что для модулей нужно делать
>> автогенирацию нечто подобного /usr/sbin/httpd2 >= set:... (по аналогии
>> set-version сделанного для библиотек), но я не знаю как подступиться к
>> данной задачи.
>>
>>   Что здесь стоит сделать (могу, достаточно быстро):
>>
>> 1. Удалить устаревшие, не актуальные, условия (например, сейчас по
>> факту, от libssl зависит только apache2-mod_ssl).
>>
>> 2. Сделать защиту от использования не той libapr1 (по аналогии
>> сделанного для libaprutil1).
>>
>> 3. Сделать привязку к версии libpcre (требуется apache2-httpd-*, для
>> apache2-common похоже не нужно, но может потребоваться другим модулям).
> 
> Мне кажется, что здесь было бы вполне естественно просто поставить строгую
> зависимость apache2-httpd-* на apache2-common; мы ведь практически ничего
> не выигрываем от того, что существует возможность одновременно установить 
> apache2-httpd-worker и apache2-common от разных сборок.

  Здесь, пожалуй да: apache2-httpd-* пакеты маленькие. (Хотя релизы с
фактическим обновлением только кода модулей у apache2 бывают.)

> 
>>
>> error: apache2-manual: non-strict dependency on apache2-base
>> error: apache2-manual: non-strict dependency on apache2-common
>>
>>   Это контент. Заведомо будет работать с любыми совместимыми версиями
>> (задано нестрогими зависимостями и конфликтами).

  Точнее это конфиги + ссылка на контент.

> 
> И в каких случаях такая свобода выбора могла бы быть полезна?

  Когда необходимо закрыть дыру (затронут один из используемых модулей)
используя минимальное количество пакетов. Например, когда пакеты
ставятся с носителя на которой их выкачивают вручную через GPRS. А если
ещё в режиме телефонного управления ("обезьяна на телефоне"), когда
действия с консолью выполняет неподготовленный пользователь, которым ты
управляешь по телефону (был у меня подобный опыт).
> 
>> error: apache2-mod_ldap: non-strict dependency on apache2-common
>>
>>   Фактические требования модуля совпадают с требованием модулей
>> находящихся в apache2-common. Но т. к. apache2-common выбран центральной
>> сущностью -- все завязано на него. Модуль не зависит от
>> %apache2_sbindir/%apache2_dname, но требуют:
>>
>> PreReq: %name-common
>> Requires: %name-mmn = %mmn
>> Requires: libaprutil1-ldap >= %n_aprutil_devel_ver
>>
>> error: apache2-mod_disk_cache: non-strict dependency on apache2-common
>> error: apache2-mod_ssl: non-strict dependency on apache2-common
>> error: apache2-suexec: non-strict dependency on apache2-common
>>
>>   Практически аналогично apache2-mod_ldap. (Но похоже нужно использовать
>> Requires: libaprutil1 >= %n_aprutil_devel_ver -- сейчас зависимости на
>> libaprutil1 сдесь нет.)
> 
> Опять же, не вижу, какая могла бы быть польза в возможность одновременно
> установить эти пакеты и apache2-common от разных сборок.

  Например, когда срочно нужно закрыть дыру в mod_ssl, mod_suexec или
mod_disk_cache (не затрагивающею httpd2 и модули apache2-common) в
условиях необходимости минимизации числа устанавливаемых пакетов (см.
пример выше).

  Кроме того, на этих пакетах решается, и тестируется, задача корректной
установки зависимостей для сторонних модулей apache2. Подробности в
соседнем письме (см.
<http://lists.altlinux.org/pipermail/devel/2013-January/196457.html>).

> 
>> error: apache2-compat: non-strict dependency on apache2-base
>> error: apache2-compat: non-strict dependency on apache2-common
>> error: apache2-mod_ssl-compat: non-strict dependency on apache2-common
>>
>>   Конфиги. С бинарниками напрямую не связанны. Oт apache2-{base,common}
>> нужна инфроструктура и работающие с ней утилиты.
>>
>> error: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
>> error: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs
>>
>>   CGI скрипты. С бинарниками напрямую не связанны.
>>
>> error: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache
>>
>>   Обусловлено требованием каталога, содержащегося
>> в apache2-mod_disk_cache:
>>
>> Requires: %apache2_htcacheclean_cachepath
> 
> За исключением альтернативных провайдеров %apache2_sbindir/%apache2_dname,
> все это выборное разнообразие выглядит самым что ни на есть сферическим
> индейцем в вакууме.

  Это разнообразие позволяет закрыть дыру, локализованную в неком
бинарном компоненте apache2 (в модуле или демоне), обойдясь точечным
обновлением минимального количества пакетов. И как правило оно удаётся.
(Кроме периодов инфраструктурных изменений в apache2 или системе.)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]