Package: postfix

This bug report is done because of the ask of an ubuntu/launchpad report
from me. I was given with the request to report this to the upstream. The
report itself:

https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1791139

I'm sorry, but I don't know what package version is affected in the Debian
distribution because of right now, I don't have any Debian system
accessible to check that out. The report itself from above:

I wanted to upgrade my bionic system. Some postfix related packages has
been upgraded:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  base-files postfix postfix-ldap postfix-mysql postfix-pcre
  python3-problem-report qemu-guest-agent
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

# ls /var/cache/apt/archives/postfix*deb
/var/cache/apt/archives/postfix_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-ldap_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-pcre_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-cdb_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-mysql_3.3.0-1ubuntu0.1_amd64.deb

After the installation, I saw this error message:

Setting up postfix-mysql (3.3.0-1ubuntu0.1) ...
Adding mysql map entry to /etc/postfix/dynamicmaps.cf
/var/lib/dpkg/info/postfix-mysql.postinst: 33: [: =: unexpected operator

But anyway, installation seemed to be succeeded. However, I noticed, that
according to my mail logs, all mysql based postfix tables does not work at
all with "unsupported map type". Just noticed, that even with ldap tables,
not only mysql tables ...

restarting postfix seems to cured the problem, but I think, it shouldn't
work this way ...

What I found: in /var/lib/dpkg/info/postfix-mysql.postinst the
corresponding context, where the problem is (line 33):

    configure)
        addmap mysql
       if [ $(postconf |grep alias_database | awk '{print $3}'|awk -F \: \
           '{print $1}') = 'mysql' ]; then
           runnewaliases
       fi
    ;;

I guess, the problem is the following: I have the main.cf with empty
alias_database directive, since I don't use aliases at all, so in main.cf,
I have:

# grep ^alias /etc/postfix/main.cf
alias_maps =
alias_database =
# postconf |grep alias_database
alias_database =
# postconf |grep alias_database | awk '{print $3}'|awk -F \: '{print $1}'
#

So you see, because of my config, I get empty string ... And it seems the
postinst script is not prepared to have this, as the empty string is
represented in the script this way then:

if [ = 'mysql' ]; then

So it is understandable now, that I get this error:

/var/lib/dpkg/info/postfix-mysql.postinst: 33: [: =: unexpected operator

Because of the postinst script runs with "set -e", this error is "fatal".
Surely, I guess the same issue happens with postfix-ldap package as well, I
guess, maybe with others, I am not sure (postfix-pcre, etc?).

I think, this should be fixed, since it can break things for everyone using
empty value for alias_database directive in main.cf

Though I am still not sure, why postfix thought these are unsupported map
types after the upgrade, and postfix restart cured the problem, shouldn't
the upgrade restart postfix anyway?

As a workaround, I put an empty hash map file into main.cf for with option,
now there is no error message in postinst script, but still, it's a strange
situation ...

Also, the logic in the script to "extract" table type is a bit complicated
I guess, I would use something like this:

if [ "$(postconf -h alias_database | cut -f1 -d:)" = "mysql" ]; then
....

Maybe there are better solutions than mine above, still, it's just a quick
idea (rather than multiple awk's and a grep) ....
Btw, maybe an even better solution for that "if":

if postconf -h alias_database | grep -q '^mysql:' ; then

Reply via email to