Summary: | dir.conf is not loaded with upgrade | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Sergey Kurakin <kurakin> |
Component: | apache2 | Assignee: | Anton Farygin <rider> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | aen, asy, naf, rider, vitty |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Sergey Kurakin
2010-09-17 22:19:54 MSD
У меня ещё apreq отключен оказался... Проблема не ограничивается mod_dir. И не ограничивается Sisyphus. В 5.1 пришёл 2.2.16-alt1.M51.1, в котором ряд конфигураций модулей перенесён из extra-available/ в mods-available/ - с описанными последствиями. Из пойманного, это _как минимум_: mod_dir mod_dav_fs mod_deflate mod_disk_cache mod_log_config mod_mem_cache mod_mime_magic Причём, отсутствие описания формата логов 'combined' обнаруживается далеко не так быстро, как пропавшие DirectoryIndex. Лечение на обновляемых установках: cd /etc for i in dir dav_fs deflate disk_cache log_config mem_cache mime_magic; do [ -e httpd2/conf/mods-enabled/$i.load ] && (a2dismod $i;a2enmod $i) done service httpd2 condreload Алексей, можешь подумать, как это исправить ? Ситуация действительно не приятна - в процессе обновления нужно постараться не убить работающую конфигурацию. Здесь всё-таки два разных вопроса, которые лучше не путать. Случай 1. Приплывает dir.conf в добавок к уже существующему и активированному dir.load. Причем загрузка dir прописана в mods-start.d/000-default.conf и он успешно загружается. Но a2enmod не замечает вновь приплывшего dir.conf. Он считает, что раз "Module dir is already enabled!", то и говорить не о чем. Решение: научить a2enmod обращать внимание не только на modname.load, но и на modname.conf, если таковой имеется. Случай 1-штрих. Сейчас проверил, что при удалении активного .conf, a2chkconfig работает как следует: удаляет битую ссылку. То есть исчезновение .conf обрабатывается корректно. Случай 2. Активные модули переплыли из extra в mods при отсутствии их упоминания в *-start.d. Из extra-enabled битые ссылки a2chkconfig удалил, а в mods-enabled, разумеется, никто их не создал. (Кстати, #2 у меня не подтверждается, dav_fs как был включен, так и остался. Но у меня Сизиф, а в #2, как я понял -- 5.1.) Решение 1, простое, но неправильное -- прописать все переезжающие модули в mods-start.d. Тогда они включатся в любом случае, даже если были отключены до переезда. И будут включаться при каждом последующем вызове a2chkconfig. Это плохо. Решение 2, сложное и неправильное -- придумать механизм для сохранения статуса переезжающих модулей и восстановления этого статуса на новом месте. Из пушки по воробьям... В добавок к "случаю 2, решение 2". Сохранение/восстановление статуса при обновлении реализуется при помощи control(8). Но есть существенные недостатки: 1. Пакеты apache2-modname-control придется потом всю жизнь таскать с собой. 2. Вывод control загромоздится до полной нечитаемости. 3. Глупо иметь control для модулей apache2, учитывая наличие штатного средства a2enmod/a2dismod. В сущности, при таком решении control однажды выполняет задачу сохранения/восстановления статуса переехавшего модуля, а потом становится рудиментом и мешается всю жизнь. (In reply to comment #4) > Здесь всё-таки два разных вопроса, которые лучше не путать. > .... Откуда? Вопрос в обновлении установленного Apache2 до конкретной версии пакета. Есть a2{en,dis}mod. Они прекрасно справляются с включением/выключением модулей. Директивы загрузки модулей лежат в mods-available/X.load, для некоторых модулей есть дополнительная конфигурация по-умолчанию в mods-available/X.conf. При включении модуля на эти файлы создаются символьные ссылки в mods-enabled, и они подключаются из httpd.conf. Если вдруг конфигурация по-умолчанию не устраивает, соответствующую ссылку на X.conf можно и удалить - на подключение модуля оно не повлияет. Всё это - файлы конфигурации, при обновлении пакета внесённые в них изменения сохраняются. Символьные ссылки тоже сохраняются. Это всё работало, и работает сейчас. Проблема в другом - до 2.2.16-alt1 часть модулей хранило конфигурацию в extra-available/, а не в mods-available/. В 2.2.16-alt1 проведена унификация - это хорошо. Но, например, extra-available/DirectoryIndex_default.conf в mods-available/dir.conf переместился, а символьная ссылка на него из extra-enabled/ в mods-enabled/ не переехала. Соответственно, если до обновления конфигурация по-умолчанию для модуля загружалась, то после - нет. При этом a2enmod, вызываемый в процессе обновления пакета, работает абсолютно корректно: ссылка mods-enabled/dir.load присутствует (а dir.load не менялся) - модуль включен, делать ничего не надо. А то, что ссылка на dir.conf отсутствует - так, возможно, конфигурация по-умолчанию не устраивала администратора истемы, и была удалена. Иными словами - это проблемы разового действия, связанные с обновлением до конкретной версии пакета. Какие-либо изменения в a2{en,dis}mod, или тем более внедрение control, тут не требуются, таким _одноразовым_ правкам конфигурации место в %post пакета. (In reply to comment #6) > Откуда? Да, я недостаточно внимательно прочел #2. Прошу прощения. "Случая 2" из моих комментариев в действительности не существует. > А то, что ссылка на dir.conf отсутствует > - так, возможно, конфигурация по-умолчанию не устраивала администратора > истемы, и была удалена. Такую возможность я не учел. Плохая практика, кстати. Администратор, вручную удаляющий ссылки на .conf, будет иметь проблемы, когда эта ссылка вдруг восстановится (a2dismod && a2enmod). Вносить изменения надо непосредственно в .conf, на то они и noreplace. Впрочем, свои предложения об изменении логики работы a2enmod я отзываю. > таким _одноразовым_ правкам конфигурации > место в %post пакета. Да, пожалуй. (В ответ на комментарий №3) > Алексей, можешь подумать, как это исправить ? > > Ситуация действительно не приятна - в процессе обновления нужно постараться не > убить работающую конфигурацию. Исправленную версию планирую залить завтра. (В ответ на комментарий №8) > (В ответ на комментарий №3) > > Алексей, можешь подумать, как это исправить ? > > > > Ситуация действительно не приятна - в процессе обновления нужно постараться не > > убить работающую конфигурацию. > > Исправленную версию планирую залить завтра. Изменения см. http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=commitdiff;h=8cd89174679b1dffff89eea8fb762d34fd833169 и http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=commitdiff;h=e9faf71d80a11f005ee9fc895da293dc13f9b205 |