ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | пропадает transport.cdb | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Zerg <anubix> | ||||||||
| Component: | postfix | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||||
| Status: | REOPENED --- | QA Contact: | qa-sisyphus | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P2 | CC: | aen, glebfm, ldv, rider, zerg | ||||||||
| Version: | unstable | ||||||||||
| Hardware: | all | ||||||||||
| OS: | Linux | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 27685, 30940 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Zerg
2007-07-09 14:53:59 MSD
У меня при обновлении с транспортом всё в порядке. Необходимы примеры конфигурации, на которой этот эффект воспроизводится. Created attachment 2083 [details]
postconf.bz2
Created attachment 2084 [details]
transport.bz2
postfix-pcre-2.3.11-alt1 postfix-control-1.6.1-alt1 postfix-2.3.11-alt1 postfix-tls-2.3.11-alt1 Что-нибудь еще? Хорошо бы сравнить вывод от "postconf -n" до и после обновления. (In reply to comment #5) > Хорошо бы сравнить вывод от "postconf -n" до и после обновления. Я не против. Но раньше следующей версии postfix в 4.0 не смогу. Обновил до 2.3.11-alt1, transport.cdb пропал, разницы в выводе от `postconf -n` вообще нет в выводе от postconf ьез параметров разница только в mail_release_date и mail_version Zerg, у тебя скорее всего local misconfiguration. # postconf -n transport_maps ? (In reply to comment #9) > Zerg, у тебя скорее всего local misconfiguration. > # postconf -n transport_maps transport_maps = cdb:$config_directory/transport # postconf -n config_directory config_directory = /etc/postfix Если подставить значение $config_directory, то работает правильно. Эта ошибка при обновлении postfix появилась очень давно. Fixed in 2.4.6-alt1. Уря! не исправлено в postfix-2.9.4-alt1 *** Bug 27621 has been marked as a duplicate of this bug. *** в postfix-2.9.4-alt1 опять (В ответ на комментарий №16) > в postfix-2.9.4-alt1 опять в postfix-2.9.4-alt2 Кстати, это уже на другой системе (и на Сизифе вместо "последнего бранча"). Да, postconf -E просто выкинули из апстрима :((, соответственно если в main.cf использовать подстановки, они больше не резолвялся Будем думать. Пока workaround: указывать /etc/postfix вместо $config_directory (В ответ на комментарий №19) > Будем думать. Пока workaround: указывать /etc/postfix вместо $config_directory Если ничего не придумаете, то хотя бы в дефолтных файлах конфигов заменить в пакете. (В ответ на комментарий №19) > Да, postconf -E просто выкинули из апстрима :((, соответственно если в main.cf > использовать подстановки, они больше не резолвялся > > Будем думать. Пока workaround: указывать /etc/postfix вместо $config_directory Придумали? (В ответ на комментарий №20) > Придумали? Да, но с оговоркой. postconf -E работал не так, как от него ожидалось, уже в P6 (возможно, всегда). Все макросы, значения которых не заданы явно (хотя и непусты по умолчанию), превращались в пустую строку, потому что рекурсивная подстановка возможна только в явно прочитанных из файла данных. Теперь этот код в апстриме полностью убрали и переписали логику, но ситуация не изменилась: настройки по умолчанию подставить нельзя. Соответственно, я переписал часть с явным вызовом рекурсивной подстановки, попутно исправив две наведённые ошибки: 1. Рекурсивная подстановка в текущей реализации выдаёт ошибку на $-конструкцию, не являющуюся макроподстановкой. Пришлось написать довольно прямой хак, предварительно обрабатывающий строку для подстановки. 2. Несмотря на синтаксическую идентичность задания cdb-карты $alias_database и прочих cdb-карт, $alias_database нельзя собирать с помощью postmap. Соответствующая проверка в chroot-сценарии была довольно наивной, $alias_database теперь упоминается чаще, пришлось её тоже переписать. Ситуация на 2.9.4-alt3 аналогична 2.5.14, данная ошибка не воспроизводится. Вопрос в том, рыть ли дальше. 2zerg: закроете? (В ответ на комментарий №23) > 2zerg: закроете? Не против. Закрываю. Опечатываю ;-) Всё еще не починено. И на работе и дома пропадает transport.cdb, после чего почта идет непойми куда. Не. У меня какая-то другая проблема после обновления postfix. Оказалось, bug#31867 Всё ещё пропадает. Created attachment 8120 [details]
postconf.bz2
Сейчас сервис перезапускается и работает, но начинает слать молча почту куда попало и вскрывается это только после явной пропажи письма. (In reply to comment #32) > Сейчас сервис перезапускается и работает, но начинает слать молча почту куда > попало и вскрывается это только после явной пропажи письма. По умолчанию transport.cdb не создаётся и не используется. Там, где у меня используется transport.cdb, обычно сконфигурировано примерно так: $ /usr/sbin/postconf -n |grep transport transport_maps = cdb:/etc/postfix/transport При этом я не наблюдаю никаких аномалий. (В ответ на комментарий №33) > По умолчанию transport.cdb не создаётся и не используется. Дык, использовался всегда, если `postmap /etc/postfix/transport`. > transport_maps = cdb:/etc/postfix/transport Попробую. Как раз светит обновление postfix. ;-) > transport_maps = cdb:/etc/postfix/transport
Судя по одинаковой дате изменения aliases.rpmnew aliases.cdb и transport.cdb при 'transport_maps = cdb:/etc/postfix/transport' и отсутствию действий с моей стороны обновление проходит нормально.
|
