Webstack - PHP84 Protection

Created by: Lester Caine, Last modification: 7 May 2026

With openSUSE having switched to php8.5, there is a need to provide a copy of php8.4.20. The files for these have been duplicated to /opt/php84 so that needs copying to the server. Then since the default location of the php.ini file used is hard coded into the executables, switching to the matching php.ini needs a little help, and environment variables can be set to override the default.

/opt/php84/bin/php
/opt/php84/bin/php-cgi
/opt/php84/bin/php-config
/opt/php84/bin/phpize
/opt/php84/sbin/php-fpm
/opt/php84/extensions/  -> the .so files

In order to run 'php84' we can select the correct ini files. The base php.ini and the extensions ini files both need overriding.

Environment=PHPRC=/etc/webstack/php84
Environment=PHP_INI_SCAN_DIR=/etc/webstack/php84/conf.d

Checking the servers we need to pull latest configuration from desktop - git pull
and then the copy can be tested using. But first we need to create the tmp file that the php8.4 copy will use.

md /srv/tmp/php84 
PHP_INI_SCAN_DIR = /etc/webstack/php84/conf.d PHPRC=/etc/webstack/php84 /opt/php84/bin/php --ini

link the new php84-fpm.service - sudo ln -s /etc/webstack/systemd/php84-fpm.service /etc/systemd/system/php84-fpm.service
load new php84-fpm.service into systemd - sudo systemctl deamon-reload
And if everything else is in place it can be started by - sudo systemctl start php84-fpm

Then the vhosts files can be updated to switch the copy of php-fpm being used, in this case to php84-php, but since we are relying on git to provide the actual files, this needs to be actioned on the desktop machine and then after committing to git it can be pushed to both servers.

sed -i 's|php-fpm.sock|php84-fpm.sock|g' /etc/webstack/nginx/vhosts.d/*.conf

Then on both servers nginx can be checked and restarted
nginx -t systemctl restart nginx Checking that on srv9 first and confirming https://rdm1.uk:8443/phpinfo.php shows php using the right ini sources before repeating on srv10.

While a little 'after the horse has bolted', preventing SUSE from over writing the PHP8.4 release of PHP should have been blocked. The SUSE does not properly handle this as it did between php7 and php8 is somewhat irritating and certainly being able to actually select between php84 and php85 is the object here. While sorting out the mess on srv10 I locked things on desktop and srv9, and removed the lock once I was happy that php84 was protected.

zypper addlock "php8*"
zypper removelock "php8*"