This week I finally took the plunge and upgraded most of the servers I work with from PHP 7.1 to PHP 7.2. (Some of them still can't be brought forward due to dependencies that use mcrypt.) I ran into a few snags with the upgrade to 7.2 and thought I'd document them here. This may be useful if you:

• Run CentOS 6 (6.9 in my case),
• Want to install PHP 7.2,
• Need pthreads support in PHP, and
• Prefer to compile PHP from source

Executive summary

In order to build PHP 7.2 with pthreads on CentOS 6, you must upgrade to autoconf 2.64, which can't presently be done through the yum package manager. You'll also have to first build PHP 7.2 without pthreads, then use this "bootstrap" copy to prepare the pthreads extension before compiling PHP a second time.

autoconf 2.64

Start by installing autoconf 2.64. The latest version available through yum is 2.63, which isn't sufficient to build PHP's configure script.

It's critical that you supply the --prefix=/usr option when configuring autoconf. The default installation prefix for the generic autoconf distribution is /usr/local, but CentOS 6 keeps it in /usr. If you forget to set the correct prefix, you're going to wind up with two different versions of autoconf installed, and who wants that?

curl -Lo autoconf-2.64.tar.gz ftp://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.64.tar.gz
tar xfz autoconf-2.64.tar.gz
cd autoconf-2.64
./configure --prefix=/usr
make && make install

Make sure the correct version has been properly installed. autoconf --version should show:

autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
[..snip..]

Bootstrap PHP 7.2

Compiling PHP 7.2 with pthreads presents a bit of a Catch-22: in order to build the pthreads extension, you need to have the 7.2 version of PHP (more accurately, a version with ZEND_MODULE_API_NO >= 20170718) and its libraries already installed. To work around this scenario, it's necessary to compile and install a minimal version of the PHP 7.2 CLI first, then use this "bootstrap" version to prepare pthreads.

Start by obtaining the latest PHP 7.2 source distribution and doing a minimal build. The only option you need to pass to configure this time around is --enable-maintainer-zts, to turn on thread safety. Don't worry about other modules (mysqli, PDO, etc.) as you're not going to be keeping this version of PHP installed for long. If you also run PHP as an Apache module, disregard that for now and just build the CLI version.

curl -Lo php-7.2.1.tar.gz http://us3.php.net/get/php-7.2.1.tar.gz/from/this/mirror
tar xfz php-7.2.1.tar.gz
cd php-7.2.1
./configure --enable-maintainer-zts
make
make install

Verify that a thread-safe version of PHP 7.2 has been installed. The output of php -v should indicate a 7.2 version number and the ( ZTS ) signature.

PHP 7.2.1 (cli) (built: Jan 8 2018 17:14:36) ( ZTS )
[..snip..]

Prepare pthreads

Obtain and prepare the pthreads extension. Note there's a dot . as the final argument to git clone. If you don't use git, you can manually download a .zip file of the pthreads source.

cd ext      #this should put you in the php-7.2.1/ext directory
mkdir pthreads && cd pthreads
git clone https://github.com/krakjoe/pthreads.git .
phpize && ./configure && make install

If you receive error output that includes the following,

php_pthreads.c:38:3: error: #error "pthreads requires PHP 7.2, ZTS in versions 7.0 and 7.1 is broken"

...this means that your bootstrap PHP 7.2 didn't install properly, and you have an older PHP command line binary on your system. You should repeat the bootstrapping step above.

Build your final PHP 7.2

Now it's time to build PHP 7.2 for real. Return to the main PHP source tree, clean up the artifacts from the bootstrap build, and generate a new configure script. ...

In an age where SSL/TLS certificates are free via Let's Encrypt, if you're running a Postfix mail server, you should make sure it's capable of speaking TLS.

Here's the output from postconf -n | grep tls on my machine, which lists all of the TLS options in main.cf that I've changed from their defaults:

smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_ciphers = medium
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtpd_tls_CAfile = /etc/pki/tls/cert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/letsencrypt/live/my.example.com/fullchain.pem
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/ssl/dh_512.pem
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, CAMELLIA, DES, IDEA, RC4, MD5, \
    PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, ECDHE-RSA-RC4-SHA, \
    KRB5-DES, CBC3-SHA, DHE-RSA-SEED-SHA, SEED-SHA
smtpd_tls_key_file = /etc/letsencrypt/live/my.example.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, CAMELLIA, EXPORT, DES, IDEA, RC4, MD5, \
    PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, ECDHE-RSA-RC4-SHA, \
    KRB5-DES, CBC3-SHA, DHE-RSA-SEED-SHA, SEED-SHA
smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

The two CAfile entries point to cert.pem from the CentOS ca-certificates package; this will probably need to point somewhere else on other distros.

The dh1024_param_file and dh512_param_file are generated like this:

mkdir -p /etc/postfix/ssl
openssl gendh -out /etc/postfix/ssl/dh_512.pem -2 512
openssl gendh -out /etc/postfix/ssl/dh_2048.pem -2 2048

As noted in TLS Forward Secrecy in the Postfix SMTP Server, the smtpd_tls_dh1024_param_file directive is a bit of a misnomer. This file can be generated with a prime >1024 bits, and 2048 bits or higher is suggested.

The above configuration works fine with all the major providers like Gmail, Microutlook Hotchangeffice365, Yahoo, etc. In cases where TLS negotiation fails, the SMTP transaction will fall back to plain unencrypted text, and your server will still send and receive messages. Depending on which servers your MTA talks to, you might need to allow TLSv1 (by removing !TLSv1 from the mandatory_protocols settings), and/or be more permissive in which ciphers you'll accept.