[GUIDE] upgrading PHP to 8.3.36 on CentOS 7 / CWP (System PHP + PHP)

PHP 8.3.36 on CentOS 7 / CWP – Manual upgrade

I upgraded System PHP 8.1.17 and PHP-FPM 8.3.15 to PHP 8.3.36 on CentOS 7.9 with CWP.

Both CWP PHP builders failed, so I compiled PHP manually.

The main problems were library detection (`bz2`, `curl`, `pcre2`) and compatibility with CentOS 7's OpenSSL 1.0.2k.

This is what worked on my server.

1. Download PHP and apply the OpenSSL patch

Code: [Select]

mkdir -p /root/php83-build
cd /root/php83-build

curl -fLO https://www.php.net/distributions/php-8.3.36.tar.gz
tar -xzf php-8.3.36.tar.gz

curl -fL
https://raw.githubusercontent.com/centminmod/centminmod/fe2932ee6577e3548b812ab6d32888e870a605c6/patches/php/php82-openssl102-xp_ssl-asn1.patch
-o openssl102.patch

cd php-8.3.36
patch -p1 < ../openssl102.patch

cd ..
cp -a php-8.3.36 php-8.3.36-system

The patch comes from Centmin Mod and fixes compilation against OpenSSL 1.0.2 in `ext/openssl/xp_ssl.c`.

2. Set PKG_CONFIG_PATH

CWP had installed PCRE2 under `/usr/local/lib`, but pkg-config was not finding it correctly.

Code: [Select]

export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:/usr/local/lib64/pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}"

Without this, configure was also reporting misleading BZip2 and cURL linking errors.

3. Compile PHP-FPM 8.3.36

My PHP-FPM 8.3 installation was located at `/opt/alt/php-fpm83/usr`.

I reused the existing PHP-FPM configuration options instead of creating a completely different build.

Code: [Select]

cd /root/php83-build/php-8.3.36

FPM_OPTS=$(/opt/alt/php-fpm83/usr/bin/php-config --configure-options | sed 's/ PKG_CONFIG_PATH=[^ ]*//g')

eval "./configure $FPM_OPTS"

make -j2

After successful compilation:

Code: [Select]

make install

systemctl restart php-fpm83

systemctl is-active php-fpm83

/opt/alt/php-fpm83/usr/bin/php -v

PHP-FPM was running PHP 8.3.36.

4. Compile System PHP 8.3.36

System PHP is a separate installation. Upgrading PHP-FPM does not update `/usr/local/bin/php`.

My System PHP prefix was `/usr/local`, with configuration files under `/usr/local/php`.

I used the second patched source directory and the configuration options from the existing System PHP installation.

Code: [Select]

cd /root/php83-build/php-8.3.36-system

SYS_OPTS=$(/usr/local/bin/php-config --configure-options | sed 's/ PKG_CONFIG_PATH=[^ ]*//g')

eval "./configure $SYS_OPTS"

make -j2

Once compilation completed:

Code: [Select]

make install

/usr/local/bin/php -v
/usr/local/bin/php-cgi -v
/usr/local/bin/lsphp -v

All three reported PHP 8.3.36.

If using persistent LSAPI/CGI workers, recycle those processes through the relevant web server.

5. PHP extensions

After the System PHP upgrade, Imagick, Sodium and OPcache were missing from its PHP 8.3 extension directory.

Both of my PHP 8.3.36 installations had compatible non-thread-safe extension ABIs, so I reused the working modules from PHP-FPM.

Code: [Select]

SRC=$(/opt/alt/php-fpm83/usr/bin/php-config --extension-dir)
DST=$(/usr/local/bin/php-config --extension-dir)

for ext in imagick sodium opcache; do
    cp -p "$SRC/$ext.so" "$DST/"
done

I also added OPcache to `/usr/local/php/php.d/zz-opcache.ini`:

Code: [Select]

zend_extension=opcache.so
opcache.enable=1

Do not copy extensions between incompatible PHP builds. If the PHP API or build options differ, compile the extensions separately.

6. Final checks

Code: [Select]

/usr/local/bin/php -v
/usr/local/bin/php -m

/opt/alt/php-fpm83/usr/bin/php -v
/opt/alt/php-fpm83/usr/bin/php -m
/opt/alt/php-fpm83/usr/sbin/php-fpm -t

systemctl status php-fpm83

On my server:

- System PHP: 8.3.36
- PHP-FPM: 8.3.36
- PHP-FPM service: active
- Imagick, Sodium and OPcache: loaded
- Redis and APCu on PHP-FPM: loaded

No missing libraries or PHP extension-loading warnings.

Notes

This was done on CentOS 7.9 with GCC 4.8.5 and OpenSSL 1.0.2k. Other installations may need different configure options or dependencies.

The CWP GUI reported successful rebuilds even when compilation had failed. Check the actual binaries and build logs.

This procedure does not update CWP's internal PHP 7.1 runtime. It also does not address the unsupported CentOS 7 operating system or its OpenSSL security issues.

Manual installation may conflict with future CWP PHP rebuilds. Have a recovery method available before replacing production binaries.

Patch credit: Centmin Mod.

https://github.com/centminmod/centminmod/blob/fe2932ee6577e3548b812ab6d32888e870a605c6/patches/php/php82-openssl102-xp_ssl-asn1.patch

This fixes the PHP bug, but CentOS 7 has plenty of other security holes that allow remote execution.