ALT Linux Bugzilla – #12282

У меня при обновлении с транспортом всё в порядке.
Необходимы примеры конфигурации, на которой этот эффект воспроизводится.

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' и отсутствию действий с моей стороны обновление проходит нормально.