search

virtualmin / virtualmin-gpl

Virtualmin web hosting control panel for Webmin
https://www.virtualmin.com
GNU General Public License v3.0
319 stars 99 forks source link

FPM port collision support breaks socket FPM config #96

Open timriker opened 5 years ago

timriker commented 5 years ago

Former config in apache:

$ grep sock /etc/php/7.0/fpm/pool.d/vm.conf /etc/apache2/sites-enabled/vm*conf
/etc/php/7.0/fpm/pool.d/vm.conf:listen = /var/php-fpm/php7.0-fpm-vm.sock
/etc/apache2/sites-enabled/vm.example.com.conf:          SetHandler "proxy:unix:/var/php-fpm/php7.0-fpm-vm.sock|fcgi://vm/"

How do I get back to using sockets instead of ports?

Note: using /etc/php//fpm/pool.d/.conf is painful. The username, the domain name, would each be better than some random domain-id number. ps auxw|grep fpm now shows just the domain-id and not the user or site name.

webmin-virtual-server 6.07.gpl on Ubuntu (still 16.04 in this case, most on 18.04)

every hour on the hour something is breaking the files in: /etc/php/7.0/fpm/pool.d/*.conf and setting them back to different port addresses, every hour. Every hour all the php sites break.

jcameron commented 5 years ago

We'll update the port fix code to not touch sockets in future .. although it shouldn't be running every hour, unless you have a cron job setup to run virtualmin check-config ?

Use of numeric IDs for the FPM configs is intentional - they are constant and don't change if the domain is renamed, so never need to be updated.

timriker commented 5 years ago

I see that they are constant. I get it. It's that they don't reflect how the users refer to them. These files are all consistant:

/etc/webmin/virtual-server/domains/146317553511227
/etc/webmin/virtual-server/everyone/146317553511227
/etc/php/7.0/fpm/pool.d/146317553511227.conf

however the tie to which virtual server account these are tied to is lost. I understand why the design choice was made, I just don't agree with it. I'd much rather have code that renames the file if the user account is ever renamed. All kinds of things would break if the user account is renamed, so this level of abstraction won't work anyway. Paths to the user's home directory are hardcoded all over the place. If renaming the user account is to be supported, there would have to be a function to walk through and edit all the references, rename files, move directories, etc. That function could just as easily rename these three files if needed.

timriker commented 5 years ago

I found it. Under:

Virtualmin -> Limits and Validation -> Validate Virtual Servers -> Scheduled Validation -> Validate on schedule -> Simple schedule

on the machine in question, Hourly was selected. On the others, it's set to "Disabled".

whereisaaron commented 5 years ago

Possibly this issue starts with an FPM version detection bug? I am still experiencing this problem with Virtualmin 6.07 and a single version of PHP-FPM install on Ubuntu 18.04.

I have just one version of PHP-FPM installed (7.2.3) but the configuration check detects/treats it as two versions:

The following PHP versions are available : 7.2.19 (/usr/bin/php-cgi7.2)
The following PHP-FPM versions are available on this system : 7.2 7.2.3

Then it seems to think the FPM ports are conflicting with themselves, and changes the numbers, breaking all the sites.

Fixing port clash for PHP-FPM version 7.2.3

Fixing port clash for PHP-FPM version 7.2.3

Restarting PHP-FPM server ..
.. done

Other users report this happens during updates also.

Should list_php_fpm_configs just be finding the one FPM version number if only one version is installed? https://github.com/virtualmin/virtualmin-gpl/blob/77b284ad00abf0dc01277a6344a9dd9ce94fe20b/php-lib.pl#L1697-L1701

Ref: https://www.virtualmin.com/node/66880 https://virtualmin.com/node/66706 https://www.virtualmin.com/comment/816508#comment-816508

MattWilcox commented 5 years ago

I have a server with 10 websites all down because of this, and no idea at all how to get them back up. Just ran the update, rebooted the server, now nothing is working in terms of serving websites... Port Clashes do seem to be the issue according to Re-Check Configuration, and I am seeing duplicate PHP versions in various places (7.2.19 listed twice, etc). Ubuntu 18.04.

whereisaaron commented 5 years ago

@MattWilcox yeah, you would think a bug that wreaks all websites on a server at once would be a thing 😕

To fix this you probably just need to go to all of your pool configurations and subtract one from update the pool port numbers. The sites are down because the port numbers in the Apache website configuration no longer match the port numbers of the FPM pool. You need to make them match again.

timriker commented 5 years ago

subtracting one from the pool members did NOT work for me. First, I was not using ports, I was using, and highly recommend using, named pipes instead of ports. Second, when I tried ports, it would bump them all up, so 8001-8010 became 8011-8020 and each time the schedule runs all the ports when up by the number of FPM pools. This includes FPM pools that are not configured in virtualmin. The key for me was disabling that scheduled server check, as that check is what breaks things.

whereisaaron commented 5 years ago

I’d be for named pipes owned by the website account too @timriker but my understanding was that virtualmin doesn’t support that option (and might keep reverting)?

jcameron commented 5 years ago

For people who are seeing this, try applying these patches :

https://github.com/virtualmin/virtualmin-gpl/commit/00243369f47fc09177e2d66102dfee2a713b9678#diff-d93c5e3420554c840d321dbc5e2fca0b

https://github.com/virtualmin/virtualmin-gpl/commit/de9c4e8ca01c32e0c577fe9e16c9a0c2e7e0736f#diff-d93c5e3420554c840d321dbc5e2fca0b

chris001 commented 5 years ago

For people who are seeing this, try applying these patches :

0024336#diff-d93c5e3420554c840d321dbc5e2fca0b

de9c4e8#diff-d93c5e3420554c840d321dbc5e2fca0b

I applied these 2 patches and this is the result - "Error - Perl execution failed Undefined subroutine &virtual_server::show_domain_name called at virtual-server-lib-funcs.pl line 10357. " ...even though the two patches' code was copied and pasted exactly into the source at the right lines: virtualmin patch for fpm ports error fails

chris001 commented 5 years ago

Update: My bad, used the wrong type of comment in perl source code. Code runs without crashing! Not sure if port problem is fixed, currently testing it.

chris001 commented 5 years ago

OK, tested as follows: Two websites on virtualmin were broken due to wrong FPM ports generated by virtualmin "Re-Check configuration" command. To "fix" these 2 websites, had to switch to FCGId mode, then back to FPM mode, as others shared. Then applied the 2 patches above, Manually run "System Settings" / "Re-check configuration" and "Validate virtual servers", The two PHP7.3-FPM based web sites, continued to run OK It appears the patches do prevent the breakage of FPM servers.

ayalon commented 5 years ago

@jcameron I tested the two patches, restarted webmin service and did the scenario as above. The patches did NOT fix the problem. After running Re-Check configuration the port ist still broken. I have php 7.2.3 and Ubuntu 18.04. It's not possible to use PHP FPM anymore.

ftrojahn commented 5 years ago

Well, I'm fighting this one for some time now, too. This is on a Debian 9 Stretch upgraded from 8, virtualmin 6.07 from repo. virtual-server-lib-funcs.pl is patched by the above mentioned two patches. Cannot take it into production using php-fpm 'cause of this, fearing it could come back on next virtualmin update.

Seeing here the following things, details below:

Possibly this issue starts with an FPM version detection bug? I am still experiencing this problem with Virtualmin 6.07 and a single version of PHP-FPM install on Ubuntu 18.04.

I get this:

The following PHP-FPM versions are available on this system : 7.0 7.0.33

Fixing port clash for PHP-FPM version 7.0.33

Restarting PHP-FPM server ..
.. done

Other users report this happens during updates also.

Should list_php_fpm_configs just be finding the one FPM version number if only one version is installed? https://github.com/virtualmin/virtualmin-gpl/blob/77b284ad00abf0dc01277a6344a9dd9ce94fe20b/php-lib.pl#L1697-L1701

Ref: https://www.virtualmin.com/node/66880 https://virtualmin.com/node/66706 https://www.virtualmin.com/comment/816508#comment-816508

While - due to the two above patches - the vhost's php-fpm ports are left alone, after each check-config run I see:

diff --git a/php/7.0/fpm/pool.d/www.conf b/php/7.0/fpm/pool.d/www.conf
index e4b28630..6e546464 100644
--- a/php/7.0/fpm/pool.d/www.conf
+++ b/php/7.0/fpm/pool.d/www.conf
@@ -33,7 +33,7 @@ group = www-data

-listen = 9019
+listen = 9020

Next run of virtualmin check-config: now I have listen = 9021 and so on. I have clearly no other services running on these ports. I have only 3 vhosts on php-fpm for test:

:~# netstat -plunt | egrep "(php|apache|:90)"
tcp6       0      0 :::80                   :::*                    LISTEN      14347/apache2       
tcp6       0      0 :::443                  :::*                    LISTEN      14347/apache2       
tcp6       0      0 :::9021                 :::*                    LISTEN      13770/php-fpm: mast 
tcp6       0      0 :::8000                 :::*                    LISTEN      13770/php-fpm: mast 
tcp6       0      0 :::8001                 :::*                    LISTEN      13770/php-fpm: mast 
tcp6       0      0 :::8002                 :::*                    LISTEN      13770/php-fpm: mast

OK, tested as follows: Two websites on virtualmin were broken due to wrong FPM ports generated by virtualmin "Re-Check configuration" command. To "fix" these 2 websites, had to switch to FCGId mode, then back to FPM mode, as others shared. Then applied the 2 patches above, Manually run "System Settings" / "Re-check configuration" and "Validate virtual servers", The two PHP7.3-FPM based web sites, continued to run OK It appears the patches do prevent the breakage of FPM servers.

So, yes, the patches are working here, too. But, port of standard php-fpm pool in www.conf is increasing for no reason.

What I'd really suggest:

timriker commented 5 years ago

@jcameron any update on this? I only have one version of php installed. All virtualmin sites and non-virtualmin sites are configured to use pipes, not ports. What is the recommended configuration for this? Currently I can't validate any servers without having virtualmin break all the php-fpm servers. Does anyone need the port based option? I'd recommend dropping support for that and converting all virtual hosts to pipe based. I'd also recommend the pipe name and fpm pool name be based on the "user" with user:ugroup ownership and not the numeric "id". If multiple virtual servers (ie: domains) have the same user entry, they can share the same fpm pool.

ayalon commented 5 years ago

I fixed it on Ubuntu like this: Check output of dpkg --list | grep fpm

ii  php-fpm                           1:7.2+60ubuntu1 
ii  php7.2-fpm                        7.2.19-0ubuntu0.18.04.2

One package is from ubuntu and one is from the repo of Ondřej Surý.

Just run: apt-get remove php-fpm

php7.2-fpm will remain. This this fixed the issue for me.

timriker commented 5 years ago

php-fpm is a virtual package. It depends on the latest fpm in your distro. When you do a do-release-upgrade having this package installed triggers the php/fpm upgrade. If it's not there, your php/fpm install will likely be left at the last version you had installed from the previous distro release and then will never be upgraded. This is a Bad Idea, as it leaves you running an outdated version of php/fpm and you won't get critical security patches installed. In short: leave the php-fpm installed unless you are absolutely certain you will never upgrade your distribution and you like having old, insecure, software installed.

ayalon commented 5 years ago

Compare this to options:

ftrojahn commented 5 years ago

One package is from ubuntu and one is from the repo of Ondřej Surý.

Just run: apt-get remove php-fpm

php7.2-fpm will remain. This this fixed the issue for me.

On Debian it is from standard repo, while hasn't really much in it - may be removing is a workaround, but not the cause:

:~# dpkg --list|grep fpm
ii  php-fpm                           1:7.0+49                           all          server-side, HTML-embedded scripting language (FPM-CGI binary) (default)
ii  php7.0-fpm                        7.0.33-0+deb9u5                    amd64   

:~# dpkg -L php-fpm
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/php-fpm
/usr/share/doc/php-fpm/changelog.gz
/usr/share/doc/php-fpm/copyright

# see output of:
:~# apt-cache show php-fpm
:~# apt-cache showpkg php-fpm

Even virtualmin-lamp-stack, virtualmin-lamp-stack-minimal, virtualmin-lemp-stack-minimal depend on it. So really should be no reason for this behaviour.

ayalon commented 5 years ago

It is! Because virtualmin detects two different php-fpm version and therefore changes the port. Eventhough there is only one version installed.

ayalon commented 5 years ago

See here: https://github.com/virtualmin/virtualmin-gpl/issues/103

ftrojahn commented 5 years ago

Ok, yes - removing php-fpm is a workaround, just tested - port in www.conf doesn't get incremented, then. That's why Jamie introduced this patch: 9abe167 so php-fpm gets ignored. Tested this, too, on debian 9 - with this patch the port doesn't get incremented. I just remove the other two patches to see how this works without.

ftrojahn commented 5 years ago

I confirm that on Debian 9 stretch with package webmin-virtual-server 6.07.gpl, using patch 9abe167, the php-fpm pool files do not get changed during 'virtualmin check-config' run.

Even used these two scripts from https://www.virtualmin.com/comment/814989#comment-814989 to change all vhosts to php-fpm and back, check-config in between, seems to work.

whereisaaron commented 5 years ago

HTTP/2 requires the Apache event MPM which in turn requires PHP-FPM. So changing to FCGI is not an option, nor a workaround.

Using port-based FPM pools doesn’t even seem like a good match for virtualmin. Pipe-based FPM pools make much more sense. The pipe can be secured to the website admin user account. And the whole port-contention, port-numbering, and associated security issues all go away.

fuerst commented 5 years ago

Confirming 9abe167 does fix the problem at Ubuntu 18.04.

It does not repair already messed up configurations though: You still need to fix wrong port numbers for php-fpm processes by changing a (all?) Virtual Server from FPM to FCGI and back again.

iliajie commented 5 years ago

Don't apply the patch, as Virtualmin 6.08 is released. Please upgrade.

timriker commented 5 years ago

Any idea when this will show up in the apt-get repo? ie: http://software.virtualmin.com/gpl/ubuntu/dists/virtualmin-universal/main/binary-amd64/?C=M;O=D

iliajie commented 5 years ago

I think, it will be ready within few days. We need to sort few other things out and do the release alongside with new Webmin and Authentic Theme.

MattWilcox commented 5 years ago

I've just done a fresh install of VirtualMin (6.08) on a fresh Ubuntu 18.04; and after running the post-installation config check guess what I see...

The following PHP versions are available : 7.2.19 (/usr/bin/php-cgi7.2), 7.2 (mod_php) The following PHP-FPM versions are available on this system : 7.2.3 (php7.2-fpm) PHP versions have changed to 7.2, 7.2 since last check. Regenerating any missing php.ini files

This isn't right, is it? Or am I mis-understanding?

MattWilcox commented 5 years ago

Aaaand... after using PHP-FPM so we can get HTTP2 support... PHP is not working on the server. Excellent.

Re-run config check... Says things changes, regenerating php.ini files...

Going to Webmin > Others > PHP Configuration shows only one php.ini file, and it's for etc/php/7.2/cgi/php.ini

Hit the settings cog top left of that PHP Configuration screen; /etc/php5/apache2/php.ini=Configuration for mod_php /etc/php5/cgi/php.ini=Configuration for scripts run via CGI /etc/php5/cli/php.ini=Configuration for command-line scripts

PHP5??

MattWilcox commented 5 years ago

Ok, an issue in mine... PHP was running as FPM, but Website Options had it set to run as FCGId despite the fact that I had previously edited VirtualMin > System Settings > Server Templates > Default Settings > PHP Options to "Default PHP Execution Mode: FPM". That seems to have been ignored. I'd also done the same for sub servers.

This whole PHP part of VirtualMin, on Ubuntu, seems like a complete mess of out-dated or broken stuff.

chris001 commented 5 years ago

To me, this PHP-FPM issue on Debian/Ubuntu, is a perfect reason why we should help @swelljoe to add a Travis-CI test script to this Virtualmin repo.

The test script would install Virtualmin and run tests, on each supported version of Ubuntu, Debian, CentOS, Fedora, Arch, etc. Making it 1000X easier to spot and fix any irregularity/glitch/bug/misbehaving code/regression. Such as this one where Virtualmin detects many PHP versions when only one version is installed. And where Virtualmin apparently creates php5 directories, when only php7.2 comes with Ubuntu 18.04.

timriker commented 5 years ago

Lately I run without mod_php and run apache in mpm event mode with fpm. Here's one box:

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
$ dpkg -l|awk '/(apache|php)/ {print $2"\t"$3}'
apache2 2.4.29-1ubuntu4.11
apache2-bin     2.4.29-1ubuntu4.11
apache2-data    2.4.29-1ubuntu4.11
apache2-utils   2.4.29-1ubuntu4.11
php-common      1:60ubuntu1
php-curl        1:7.2+60ubuntu1
php-fpm 1:7.2+60ubuntu1
php-gd  1:7.2+60ubuntu1
php-intl        1:7.2+60ubuntu1
php-mbstring    1:7.2+60ubuntu1
php-mysql       1:7.2+60ubuntu1
php-soap        1:7.2+60ubuntu1
php-xml 1:7.2+60ubuntu1
php-zip 1:7.2+60ubuntu1
php7.2-cli      7.2.19-0ubuntu0.18.04.2
php7.2-common   7.2.19-0ubuntu0.18.04.2
php7.2-curl     7.2.19-0ubuntu0.18.04.2
php7.2-fpm      7.2.19-0ubuntu0.18.04.2
php7.2-gd       7.2.19-0ubuntu0.18.04.2
php7.2-intl     7.2.19-0ubuntu0.18.04.2
php7.2-json     7.2.19-0ubuntu0.18.04.2
php7.2-mbstring 7.2.19-0ubuntu0.18.04.2
php7.2-mysql    7.2.19-0ubuntu0.18.04.2
php7.2-opcache  7.2.19-0ubuntu0.18.04.2
php7.2-readline 7.2.19-0ubuntu0.18.04.2
php7.2-soap     7.2.19-0ubuntu0.18.04.2
php7.2-xml      7.2.19-0ubuntu0.18.04.2
php7.2-zip      7.2.19-0ubuntu0.18.04.2
MattWilcox commented 5 years ago

I wish I knew enough to help, but I'm barely knowledgeable enough to provide semi-useful bug reports.

I too don't use the default PHP stack that VirtualMin ships with because it's totally inadequate; All modern websites should be running https and http2, which means we need MPM which means we need FPM. None of this old Apache stuff. Trying to use VirtualMin to switch between these things has never worked; you choose a radio option, apply it, and the reload just shows the old options as though you'd never done anything.

I'm having to manually use the command line to install various PHP bits and as follows:

apachectl stop a2enconf php7.2-fpm a2dismod php7.2 a2dismod mpm_prefork a2enmod mpm_event apachectl start

It's... a mess.

swelljoe commented 5 years ago

Is this not fixed for everyone in version 6.08 (rolled out last night)?

ftrojahn commented 5 years ago

Lately I run without mod_php and run apache in mpm event mode with fpm. Here's one box:

@timriker How do you handle the "php_admin_value engine Off" problem? For mpm_event, one has to disable php7.2 module since it depends on mpm_prefork. Just set up a new ubuntu 18.04 box with virtualmin (first time, usually using debian), php-fpm was detected correctly and switched on by default for new vhosts. But, transfering or restoring a virtual server, apache service does go down due to the "php_admin_value" line in apache config ... has to be removed manually.

chris001 commented 5 years ago

Is this not fixed for everyone in version 6.08 (rolled out last night)?

On Debian 8 Jessie, Virtualmin 6.08: Somehow the websites are causing browser security (invalid cert) errors, they're returning the wrong domain's letsencrypt SSL/TLS cert. Whether or not the update to 6.08 caused this, or not, is unknown.

Also, it's (still?) detecting the wrong PHP-FPM version numbers:

The following PHP versions are available : 5.6.40 (/usr/bin/php5), 7.3.10 (/usr/bin/php7.3)

The following PHP-FPM versions are available on this system : 5.6.33 (php5-fpm) 7.3.10 (php7.3-fpm)

The PHP-FPM 5.6.33 version is the only one that's wrong. When you check the version number on the command line by running php5-fpm -v, it shows 5.6.40...

timriker commented 5 years ago

I have removed the php_admin_value lines manually, multiple times.

swelljoe commented 5 years ago

php_admin_value is a separate issue. (And one that I thought had been fixed like years ago. I'll try to reproduce it.)

nicutor commented 5 years ago

Hello to everyone,

The following PHP versions are available : 5.6.40 (/usr/bin/php5), 7.3.10 (/usr/bin/php7.3)

The following PHP-FPM versions are available on this system : 5.6.33 (php5-fpm) 7.3.10 (php7.3-fpm)

The PHP-FPM 5.6.33 version is the only one that's wrong. When you check the version number on the command line by running php5-fpm -v, it shows 5.6.40...

The same on ubuntu 18.04 with virtualmin 6.08:

The following PHP versions are available : 7.2.19 (/usr/bin/php-cgi7.2), 7.3.10 (/usr/bin/php7.3), 7.3 (mod_php)
The following PHP-FPM versions are available on this system : 7.2.3 (php7.2-fpm) 7.3.10 (php7.3-fpm)

There is no 7.2.3 version. The correct one is 7.2.19.

nicutor commented 5 years ago

After I've installed all versions, it seems that only the Ubuntu OS default php version is affected by this bug. I've opened another bug which seems to be affected in the same way: https://github.com/virtualmin/virtualmin-gpl/issues/113

CentOS 7

The following PHP versions are available : 5.4.16 (/bin/php-cgi), 5.5.38 (/bin/php55-cgi), 5.6.40 (/bin/php56-cgi), 7.0.33 (/bin/php70-cgi), 7.1.32 (/bin/php71-cgi), 7.2.23 (/bin/php72-cgi), 7.3.10 (/bin/php73-cgi), 5.4 (mod_php)
The following PHP-FPM versions are available on this system : 5.4.16 (php-fpm) 5.5.38 (php55-php-fpm) 5.6.40 (php56-php-fpm) 7.0.33 (php70-php-fpm) 7.1.32 (php71-php-fpm) 7.2.23 (php72-php-fpm) 7.3.10 (php73-php-fpm)

# grep -r "listen =" /etc/opt/*/*/php-fpm.d /etc/php-fpm.d
/etc/opt/remi/php55/php-fpm.d/www.conf:listen = "127.0.0.1:9155"
/etc/opt/remi/php56/php-fpm.d/www.conf:listen = "127.0.0.1:9156"
/etc/opt/remi/php70/php-fpm.d/www.conf:listen = "127.0.0.1:9170"
/etc/opt/remi/php71/php-fpm.d/www.conf:listen = "127.0.0.1:9171"
/etc/opt/remi/php72/php-fpm.d/www.conf:listen = "127.0.0.1:9172"
/etc/opt/remi/php73/php-fpm.d/www.conf:listen = "127.0.0.1:9173"
/etc/opt/remi/php73/php-fpm.d/156633496324494.conf:listen = 8000
/etc/opt/remi/php74/php-fpm.d/www.conf:listen = "127.0.0.1:9174"
/etc/php-fpm.d/www.conf:listen = "127.0.0.1:9000"

Ubuntu 18.04

The following PHP versions are available : 5.6.40 (/usr/bin/php5.6), 7.0.33 (/usr/bin/php7.0), 7.1.32 (/usr/bin/php7.1), 7.2.23 (/usr/bin/php-cgi7.2), 7.3.10 (/usr/bin/php7.3), 7.0 (mod_php)
The following PHP-FPM versions are available on this system : 5.6.40 (php5.6-fpm) 7.0.33 (php7.0-fpm) 7.1.32 (php7.1-fpm) 7.2.3 (php7.2-fpm) 7.3.10 (php7.3-fpm)

/etc/php/5.6/fpm/pool.d/www.conf:listen = "/run/php/php5.6-fpm.sock"
/etc/php/7.0/fpm/pool.d/www.conf:listen = "/run/php/php7.0-fpm.sock"
/etc/php/7.1/fpm/pool.d/www.conf:listen = "/run/php/php7.1-fpm.sock"
/etc/php/7.2/fpm/pool.d/www.conf:listen = "/run/php/php7.2-fpm.sock"
/etc/php/7.3/fpm/pool.d/156605852127932.conf:listen = 8000
/etc/php/7.3/fpm/pool.d/www.conf:listen = "/run/php/php7.3-fpm.sock"
/etc/php/7.4/fpm/pool.d/www.conf:listen = "/run/php/php7.4-fpm.sock"
whereisaaron commented 5 years ago

With 6.07 I get the same php_admin_value problem all the time that @timriker and @ftrojahn report. I remove them from templates on new virtualman servers and manually remove them when virtuamin adds them or they are brought across by a transfer.

@swelljoe as far as know this is not fixed. If you uninstall mod_php, cleanse the templates, and make php-fpm the default, run check-config (then spend a bonus hour fixing all your broken FPM sites) then brand new sites don't get this problem, so that is fixed for that case. But it does not remove them for sites have ever had the entries added for some reason.

chris001 commented 4 years ago

PHP-FPM websites hosted on Virtualmin are still down, they're incorrectly serving the wrong certificate (certificate of the main website) instead of the corresponding correct cert, therefore, the browser absolutely refuses to go any further, no advanced exceptions are allowed.

  1. Would it be possible to get a grep/awk/sed command line, working on both DEB and RPM distros, that detects this PHP-FPM websites down (serving wrong cert) condition?
  2. What's a grep/awk/sed command line that takes the output of the above command, and fixes the sites down due to serving the wrong cert?
jcameron commented 4 years ago

@chris001 any SSL cert issue would be unrelated to PHP or FPM - the cert is served by Apache even before PHP scripts are run.

abclution commented 4 years ago

I'm not exactly sure this is a related problem, but Virtualmin is not finding all my php-fpm versions I have installed, more specifically the 7.4 version.

I noticed this issue while I was running Stretch (not 100% sure..), but I recently upgraded to Buster and this is definitely present. I've installed/reinstalled/purged to no progress. Not sure if this is intended or a bug.

From check config. php 7.4 cgi is found but not php7.4 fpm

The following PHP versions are available : 5.6.40 (/usr/bin/php-cgi5.6), 7.0.33 (/usr/bin/php-cgi7.0), 7.1.33 (/usr/bin/php7.1), 7.2.28 (/usr/bin/php-cgi7.2), 7.3.15 (/usr/bin/php-cgi7.3), 7.4.3 (/usr/bin/php-cgi)

The following PHP-FPM versions are available on this system : 5.6.40 (php5.6-fpm) 7.0.33 (php7.0-fpm) 7.1.33 (php7.1-fpm) 7.2.28 (php7.2-fpm) 7.3.11 (php7.3-fpm)

iliajie commented 4 years ago

PHP 7.4 support is coming in Virtualmin 6.09 that is going to be released in few days. Meanwhile, you can manually tweak it to make it work.

timriker commented 4 years ago

@rostovtsev, this issue is about the fpm port mapping, which I'm not sure is fixed in all cases still. @abclution's issue is not directly related to the port mapping.

iliajie commented 4 years ago

this issue is about the fpm port mapping, which I'm not sure is fixed in all cases still.

Have you experienced this issue with Virtualmin 6.08?

timriker commented 4 years ago

On my current 6.08 box, FPM is not detected correctly. I'm running on Ubuntu 18.04 LTS with mod_php disabled, and php-fpm installed. suexec is also disabled.

webmin wanted libapache2-mod-fcgid installed. php config was working without that, but fpm was not detected. mod_fcgid is not needed as fpm has it's own startup service.

Line from a working config:

<FilesMatch ".+\.ph(ar|p|tml)$">
   SetHandler "proxy:unix:/run/php/php7.2-fpm.sock|fcgi://localhost"
</FilesMatch>

Installing libapache2-mod-fcgid and enabling now shows FPM. virtualmin breaks server configuration by adding:

<FilesMatch \.php$>
SetHandler proxy:fcgi://localhost:8000
</FilesMatch>

When an existing socket SetHander is present, a new port based one should not be added. So, yes. 6.08.gpl is still broken.

What I expect:

After re-enabling FPM, which breaks the sockets setup, I manually edit the files back to working status, running a validate does NOT break it again. If that's the bar for closing this ticket, then I guess we can leave it closed. Not the friendliest of setups, but at least a validate does not break things.

chris001 commented 4 years ago

Agreed with @timriker this FPM support should be made more friendly and secure; by default use sockets with relevant username as owner and secure permissions, and no breakage or constant remap when passing thru validation or disabled/enabled.