Activity log for bug #1791139

Date Who What changed Old value New value Message
2018-09-06 17:27:56 LGB [Gábor Lénárt] bug added bug
2018-09-07 10:46:15 Christian Ehrhardt  bug added subscriber Ubuntu Server
2018-09-07 10:46:22 Christian Ehrhardt  tags bitesize
2018-09-07 10:48:06 Christian Ehrhardt  tags bitesize bitesize needs-upstream-report
2018-09-07 13:49:54 LGB [Gábor Lénárt] bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908221
2018-09-10 18:38:02 Andreas Hasenack bug task added postfix (Debian)
2018-09-10 18:42:46 Andreas Hasenack postfix (Ubuntu): status New Triaged
2018-09-10 18:42:52 Andreas Hasenack postfix (Ubuntu): importance Undecided Medium
2018-09-10 21:29:18 Karl Stenerud description 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) .... Thanks for your attention. [Impact] If a user's /etc/postfix/main.conf has an empty alias_database setting, postfix-mysql.postinst fails when upgrading. [Test Case] Install the previous postfix and postfix-mysql: # apt install -y postfix=3.3.0-1 postfix-mysql=3.3.0-1 * Install type: Local Only * System mail name: anything Clear the alias settings in /etc/postfix/main.cf, then upgrade to the latest: # sed -i 's/\(alias_.* =\).*/\1/g' /etc/postfix/main.cf # service postfix reload # apt upgrade -y You'll get the following error: Adding mysql map entry to /etc/postfix/dynamicmaps.cf /var/lib/dpkg/info/postfix-mysql.postinst: 33: [: =: unexpected operator [Regression Potential] The fix only affects the package installation scripts. [Original Description] 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) .... Thanks for your attention.
2018-09-10 22:53:19 Andreas Hasenack merge proposal linked https://code.launchpad.net/~kstenerud/ubuntu/+source/postfix/+git/postfix/+merge/354654
2018-09-11 13:44:07 Andreas Hasenack postfix (Ubuntu): assignee Karl Stenerud (kstenerud)
2018-09-11 13:44:13 Andreas Hasenack postfix (Ubuntu): status Triaged In Progress
2018-09-11 17:48:31 Bug Watch Updater postfix (Debian): status Unknown New
2018-10-04 01:18:41 Launchpad Janitor postfix (Ubuntu): status In Progress Fix Released
2018-10-04 12:36:12 Andreas Hasenack nominated for series Ubuntu Bionic
2018-10-04 12:36:12 Andreas Hasenack bug task added postfix (Ubuntu Bionic)
2018-10-04 12:36:53 Andreas Hasenack postfix (Ubuntu Bionic): assignee Karl Stenerud (kstenerud)
2018-10-11 20:12:35 Andreas Hasenack postfix (Ubuntu Bionic): assignee Karl Stenerud (kstenerud) Andreas Hasenack (ahasenack)
2018-10-11 20:12:38 Andreas Hasenack postfix (Ubuntu Bionic): status New In Progress
2018-10-11 20:23:43 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/postfix/+git/postfix/+merge/356620
2018-10-23 22:51:23 Brian Murray postfix (Ubuntu Bionic): status In Progress Fix Committed
2018-10-23 22:51:26 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2018-10-23 22:51:27 Brian Murray bug added subscriber SRU Verification
2018-10-23 22:51:32 Brian Murray tags bitesize needs-upstream-report bitesize needs-upstream-report verification-needed verification-needed-bionic
2018-10-26 17:46:29 Andreas Hasenack tags bitesize needs-upstream-report verification-needed verification-needed-bionic bitesize needs-upstream-report verification-done-bionic verification-needed
2018-11-08 00:26:55 Bug Watch Updater postfix (Debian): status New Fix Released
2018-12-13 08:40:21 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2018-12-13 08:50:23 Launchpad Janitor postfix (Ubuntu Bionic): status Fix Committed Fix Released
2021-08-12 13:18:24 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paride/ubuntu/+source/postfix/+git/postfix/+merge/407023