First of all: Why a current php version should be unsecure? Also it is not a upgrade, it is a new installation, the current servers will not update to another php version - this has nothing to do with security, even it is more secure to use a up to date version.
I’m sorry, but this is not true: current systems will not be automatically updated, if the system runs php 7.3, it will stay on php 7.3 until you would manualy upgrade the packages. Currently we work on a implementation for this using the v-scripts.
You can’t take hestia as example for a auto upgrade, because this was a mistake from our side: We haven’t set the php version for apache+nginx packages, so it just installed “the current package” - in that way ppa sent out php 7.4.
I just check the php fpm installation now, it’s possible, that the last few changes on the installer has made some mistakes in nginx + php fpm installation.
I can confirm, that the current installer for nginx + php fpm stopped working, I currently check why this happened and will push a fix as soon as possible.
It will update. I had this problem already. See: update-alternatives --config php
By default, option 0 is selected - automatic upgrade. That is, if you use the php package, it will always match the latest php version from the ppa:ondrej/php repository.
Yesterday it was php 7.3 version, and today it is 7.4
Just checked on one of my systems (multiphp), basicly i can confirm this situation, because the package “php” is also installed (currently don’t know why, because it should be php-fpm only). But it looks only php cgi is php7.4, the current web stacks havent changed. can you confirm this? Or did also php fpm udpated himself?
The release branch has been fixed now, I’ve reverted the changes we did for apache2+nginx - they has caused the issues with php fpm installations. We need to take a deep look into the issues with different php cli versions and auto upgrades on sury repo - but what I can say for now: Current webstack’s php version will not be changed or updated - a update of php cli is possible, basicly you would need to change the default version for “php”-command.
We need to rework the installer for the different php versions, but due to the holidays, we do not have enough devs here.
Can you please recheck the installation and let me know, if all works properly?
I understand, that different php-cli versions can cause issues, also for example with magento 2. But it should not upgrade the pfp-fpm instances, because they were installed with the php version itself (for example php7.3-fpm and not with php-fpm).
As I already wrote: we will do a deep analyze what exactly happened with the php-fpm installations due to the reverted commit and also we try to find a solution for the upgrade issues.
I try to install with fpm_v=“5.6” (I need this version for old site) in hestia installation script and again got the first message error. Can not get it work. Php 7.4 was also installed by the installation script.
Again try install with multi-php option and got apache2 installed but php-fpm was only selected to install.
For point 1: I think it has installed the php-cli version itself, but the php fpm package would have been setup properly. Please check this with a phpinfo();. You can change the cli version with the following command: update-alternatives --set php /usr/bin/php5.6
For the second point this is quiet easy: If you choose multiphp on nginx+apache2 configuration, it will be solved using php fpm and provide you for every php version a own apache2 template. Just check under edit web -> apache2 template. You also can copy the default one and adjust them if needed.
It is intresting that in 5.6 case, php 7.4 was not installed in the system, but while Hestia installation one of php modules (php-imap) was installed without specifying the 5.6 version. This led to the installation of a module for current (as ppa:ondrej/php repo) php 7.4 and not for 5.6.
After that, Hestia was not able to configure php-fpm correctly.
.