Submitted by iordachej on Fri, 10/23/2020 - 06:54 Pro Licensee
I transferred a domain from another server and I was not able to select FPM mode in Website Options because it was missing. I tracked the issue and found that get_php_fpm_config() in php-lib.pl was returning whatever php_fpm_version value was found in /etc/webmin/virtual-server/domains/1588694... , that was "7.1" in the original server, that was compared against the available FPM versions in the new system (7.4) and was failing. The conclusion was "fpm not supported for this domain".
One solution is to remove the line with php_fpm_version during a "Restore from backup" operation, or replace it with a version that exists on the new system.
Status:
Closed (fixed)
Virtualmin version:
6.12
Webmin version:
1.955
Comments
Hi,
Thanks for reporting it. We will take a look.
Submitted by JamieCameron on Sat, 10/31/2020 - 19:31 Comment #2
The most recent Virtualmin release should already include a fix for this issue of the PHP version changing on restore.
Submitted by IssueBot on Sat, 11/14/2020 - 18:42 Comment #3
Automatically closed - issue fixed for 2 weeks with no activity.
Submitted by martlam on Mon, 03/22/2021 - 18:08 Comment #4
Well, using Debian 10, I just hit this issue under the same scenario. Moving a site from one server to another. I am available to help diagnose.
System specs: Virtualmin 6.15 Webmin 1.973
The issue happens when PHP FPM version doesn't exist on the target server, which is found on the source (in a backed up file)?
Submitted by martlam on Tue, 03/23/2021 - 10:00 Comment #6
Here are results of diagnosis.
Sites are using 7.4 on one server and 7.3 on the destination server.
Sites that had FPM active on original server imported as expected to new server with FPM option already enabled.
In this case, FPM was not activated on the original server for the site in question. After importing the FPM option is not available to be selected for the site in question.
I had a look at the source code to determine how FPM was detected and created the missing files and directives manually.
In this instance, the apache .conf for the virtual server did not contain any 'proxy' directive such as the following.
So after adding this directive you have to determine a free port number. To find out free port number one must look in the FPM pool directory to see what is the last port used in the 8000 range and increment by 1. Create a copy of the FPM pool file with a unique name and assign the incremented port number.
Then finally restart Apache. The FPM option is now available for the virtual server.
Perhaps, a 'Enable FPM' button is needed that will do a few spot checks and create the necessary files and directives accordingly to resolve this use case.
Submitted by JamieCameron on Sun, 03/28/2021 - 12:38 Comment #7
martlam - was the trigger for this problem simply taking a backup from a system with PHP FPM 7.3, and restoring it on a system with 7.4 ?
Submitted by martlam on Sun, 03/28/2021 - 14:36 Comment #8
The trigger is that Virtualmin that a restored site will not be able to use FPM unless it detects proxy directives in apache.conf for the site, despite FPM being available to other sites using the same PHP version.
Whereas a new virtual server the FPM capability is determined by which PHP versions are installed on the local system and the one selected rather than the existence of a apache proxy directive.
I suppose that the logic used to determine PHP options when creating a new virtualmin site applied to a backup restoration would suffice to resolve this issue.
Submitted by JamieCameron on Sun, 03/28/2021 - 16:59 Comment #9
OK, I see the cause of this issue - it will be fixed in the 6.17 Virtualmin release.