Problem with Postfix caused by Plesk update

[G_Oliver]

I have a VPS with
Ubuntu 14.04.1 LTS
Plesk 12.0.18
and I was using Postfix

When Plesk update v24 was automatically applied yesterday, incoming mail stopped being handled and there were log messages like this:

Nov 21 03:56:12 h2362021 postfix/pipe[21661]: 94ADB6A41418: to=<[email protected]>, orig_to=<[email protected]>, relay=plesk_virtual, delay=0.72, delays=0.71/0/0/0.01, dsn=5.3.0, status=bounced (Command died with status 127: "/usr/lib/plesk-9.0/postfix-local". Command output: /usr/lib/plesk-9.0/postfix-local: error while loading shared libraries: libtokyocabinet.so.9: cannot open shared object file: No such file or directory )


After some searching I decided to get Plesk to install Qmail in place of Postfix and this cured the problem. I am reluctant to try changing back to Postfix and so I don't know whether this was a build fault or some other problem.

 

[UFHH01]

There won't be any changes for your mailboxes itself, when you change your mail - server from qmail to postfix and the other way round.

If you experience problems with your mail - software, you can always change from postfix to qmail and backwards again, just to see, if the issue/problem was caused by an unfinished patch/update/upgrade.


Plesk has as well a repair script, which is called "mchk" for repair/rebuild mail server configurations. You could use this script first, if you experience issues/problems:

Command to restore all settings:

/usr/local/psa/admin/sbin/mchk --with-spam
​

If you would like to have additional options for "mchk", please use the string "--help"

/usr/local/psa/admin/sbin/mchk --help​

 

[burnleyvic]

Lovely broken mails system after applying that update.

we are seeing the same thing when going from MU#21 -> MU#26.

CentOS 5.11 (Final)
Plesk 12.0.18
Postfix.

error in mail logs:

Command died with status 127: "/usr/lib64/plesk-9.0/postfix-local". Command output: /usr/lib64/plesk-9.0/postfix-local: error while loading shared libraries: libtokyocabinet.so.9: cannot open shared object file: No such file or directory )

output of shared dependencies;

ldd /usr/lib64/plesk-9.0/postfix-local
linux-vdso.so.1 => (0x00007fff1038b000)
libz.so.1 => /lib64/libz.so.1 (0x00007f718a318000)
libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f718a107000)
libsqlite3.so.0 => /usr/lib64/sw/sqlite37/libsqlite3.so.0 (0x00007f7189e70000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00007f7189b1f000)
libtokyocabinet.so.9 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f7189915000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f71896f9000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f71893f8000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7189175000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7188e1c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7188c0d000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f7188a09000)
/lib64/ld-linux-x86-64.so.2 (0x00007f718a539000)

looks like the update breaks postfix on several different distros so watch out.

for comparison here are the dependencies prior to apply the MU

ldd /usr/lib64/plesk-9.0/postfix-local
linux-vdso.so.1 => (0x00007fffa19fe000)
libsqlite3.so.0 => /usr/lib64/sw/sqlite37/libsqlite3.so.0 (0x00007f5b328e8000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00007f5b3258a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5b32231000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f5b3202d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5b31e10000)
libz.so.1 => /lib64/libz.so.1 (0x00007f5b31bfc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5b32b81000)

 

[burnleyvic]

centos 6 is also likely to suffer this dependency mess, but out centos 7 plesk 12 servers are ok.

 

[burnley]

Obviously a botched build. To me it looks like the latest /usr/lib64/plesk-9.0/postfix-local binary was built on a RHEL 7 system. Why would you do that when you *MUST* support RHEL 5 and 6 platforms? This build is broken for two reasons:
1. Wrong build platform
2. Wrong dependency. Why does it suddenly require libtokyocabinet.so?
Just fyi:
RHEL 5 provides /usr/lib64/libtokyocabinet.so.7
RHEL 6 provides /usr/lib64/libtokyocabinet.so.8
RHEL 7 provides /usr/lib64/libtokyocabinet.so.9
I'm afraid Parallels need to push #MU27 asap.

 

[IgorG]

You should use tokyocabinet packaged by Parallels but not from any other vendors. For CentOS5_x64 for example it can be found here - http://autoinstall.plesk.com/PSA_12.0.18/dist-rpm-CentOS-5-x86_64/contrib/

 

[burnley]

Igor, that makes sense. Here is my last response to the Parallels ticket:

On our CentOS 5 systems "rpm -qi tokyocabinet" says:

Name : tokyocabinet Relocations: (not relocatable)
Version : 1.4.9 Vendor: Fedora Project <http://bugzilla.redhat.com/bugzilla>
Release : 1.el5 Build Date: Wed 04 Mar 2009 13:06:43 AEDT
Install Date: Thu 23 Oct 2014 16:11:11 AEDT Build Host: xenbuilder2.fedora.redhat.com
Group : Development/Libraries Source RPM: tokyocabinet-1.4.9-1.el5.src.rpm
Size : 1041071 License: LGPLv2+
Signature : DSA/SHA1, Sun 08 Mar 2009 04:10:16 AEDT, Key ID 119cc036217521f6
Packager : Fedora Project <http://bugzilla.redhat.com/bugzilla>
URL : http://tokyocabinet.sourceforge.net/
Summary : A modern implementation of a DBM
Description :
Tokyo Cabinet is a library of routines for managing a database. It is the
successor of QDBM. Tokyo Cabinet runs very fast. For example, the time required
to store 1 million records is 1.5 seconds for a hash database and 2.2 seconds
for a B+ tree database. Moreover, the database size is very small and can be up
to 8EB. Furthermore, the scalability of Tokyo Cabinet is great.

This package has been pulled on our servers as dependency by php-dba-5.4.35-1.el5.remi so the toykocabinet package built by Parallels is obviously incompatible with our environment at the moment.
I'll have to look at what options we have to fix this incompatibility.

 

[IgorG]

Yes. As you can see - Packager : Fedora Project but not Parallels.

 

[burnley]

That's correct Igor, because we're trying to stick with packages from reputable source as much as possible, for as long as possible This is why we stopped using Atomic packages for quite some time and we're not going back, since Remi builds are superior in several respects. The existing tokyocabinet package was pulled as a dependency by php-dba-5.4.35-1.el5.remi package.
I have a temporary workaround involving a custom tokyocabinet package built from source and installed in /usr/local/tokyocabinet-1.4.48/. After adding the entry "/usr/local/tokyocabinet-1.4.48/lib" in /etc/ld.so.conf.d/tokyocabinet-1.4.48.conf followed by running ldconfig, now I get this ldd output:

[root@host05 ld.so.conf.d]# ldd /usr/lib64/plesk-9.0/postfix-local.stuffed
linux-vdso.so.1 => (0x00007fff62530000)
libz.so.1 => /lib64/libz.so.1 (0x00007f7948305000)
libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f79480f4000)
libsqlite3.so.0 => /usr/lib64/sw/sqlite37/libsqlite3.so.0 (0x00007f7947e5d000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00007f7947b0c000)
libtokyocabinet.so.9 => /usr/local/tokyocabinet-1.4.48/lib/libtokyocabinet.so.9 (0x00007f7947891000)
librt.so.1 => /lib64/librt.so.1 (0x00007f7947688000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f794746c000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f794716b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7946ee8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7946b8f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7946980000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f794677c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7948526000)

Looks ok this time, on Monday I'll test the new postfix-local binary with this new build. It's not pretty, I know, but at this point in time we're not going to sacrifice backwards compatibility on our existing CentOS 5 and 6 servers.
Ideally, if Parallels engineers can anticipate possible conflicts with existing libraries, they can at least look at doing static linking with some of the libraries. At the expense of bigger binaries, this should obviously offer better backwards compatibility with existing software installed on clients machines. If, of course, the license permits static linking.