Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FPM port collision support breaks socket FPM config #96

Open
timriker opened this issue Aug 6, 2019 · 44 comments
Open

FPM port collision support breaks socket FPM config #96

timriker opened this issue Aug 6, 2019 · 44 comments

Comments

@timriker
Copy link

@timriker timriker commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jcameron jcameron commented Aug 11, 2019

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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Aug 12, 2019

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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Aug 12, 2019

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

This comment has been minimized.

Copy link

@whereisaaron whereisaaron commented Aug 31, 2019

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?

virtualmin-gpl/php-lib.pl

Lines 1697 to 1701 in 77b284a

# list_php_fpm_configs()
# Returns hash refs with details of the system's php-fpm configurations. Assumes
# use of standard packages.
sub list_php_fpm_configs
{

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

@MattWilcox

This comment has been minimized.

Copy link

@MattWilcox MattWilcox commented Sep 5, 2019

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

This comment has been minimized.

Copy link

@whereisaaron whereisaaron commented Sep 6, 2019

@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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Sep 6, 2019

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

This comment has been minimized.

Copy link

@whereisaaron whereisaaron commented Sep 7, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jcameron jcameron commented Sep 8, 2019

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

0024336#diff-d93c5e3420554c840d321dbc5e2fca0b

de9c4e8#diff-d93c5e3420554c840d321dbc5e2fca0b

@chris001

This comment has been minimized.

Copy link

@chris001 chris001 commented Sep 25, 2019

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

This comment has been minimized.

Copy link

@chris001 chris001 commented Sep 25, 2019

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

This comment has been minimized.

Copy link

@chris001 chris001 commented Sep 25, 2019

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

This comment has been minimized.

Copy link

@ayalon ayalon commented Sep 27, 2019

@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

This comment has been minimized.

Copy link

@ftrojahn ftrojahn commented Oct 15, 2019

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:

  • the Debian-origin php versions are reported twice

  • after using the above mentioned two patches, domain-specific ports are left as they are, but the system php-fpm "www.conf" increments the port at every run of check-config, at least not preventing apache from running, here.

  • port clash detection must be wrong, too

  • I really don't understand why a tool called "check-config" does not only check. But, it changes config, eg. running thru all dozens of websites, eventually removing the set php version in all apache configs for another, if it is missing for some reason. Check-config changing ports, may be crashing all sites. Without etckeeper, I have no chance to know what's really on. Even worse - the wrong config (without the 2 patches) may be left unnoticed, hitting you next time apache2 is reloaded/restarted, e.g. in the morning on logrotate.

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?

virtualmin-gpl/php-lib.pl

Lines 1697 to 1701 in 77b284a

# list_php_fpm_configs()
# Returns hash refs with details of the system's php-fpm configurations. Assumes
# use of standard packages.
sub list_php_fpm_configs
{

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:

  • fully revert all changes according to "php-fpm port clash", If really needed, do it right again from scratch

  • split the "check-config" into "check-config" and "fix-config", so I can have a look what's may be wrong, without touching anything. The web gui "Re-check config" could surely do both one after another, or just check and then have a button "fix config"?

@timriker

This comment has been minimized.

Copy link
Author

@timriker timriker commented Oct 15, 2019

@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

This comment has been minimized.

Copy link

@ayalon ayalon commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@ayalon ayalon commented Oct 15, 2019

Compare this to options:

  • Since Jun 29 2019 this bug was introduced by virtualmin. All my virtualhosts went offline on this day.
  • This bug is not fixed eventhough it is super critical and a lot of people are affected
  • There is no workaround and patch available
  • whenever the server configuration is validated via cron at midnight, all virtualhost are broken.
    versus
  • Uninstall the package and use php-fpm instead of php-fcgi
  • Hope that someday someone will care..
@ftrojahn

This comment has been minimized.

Copy link

@ftrojahn ftrojahn commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@ayalon ayalon commented Oct 15, 2019

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

@ayalon

This comment has been minimized.

Copy link

@ayalon ayalon commented Oct 15, 2019

See here: #103

@ftrojahn

This comment has been minimized.

Copy link

@ftrojahn ftrojahn commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@ftrojahn ftrojahn commented Oct 16, 2019

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

This comment has been minimized.

Copy link

@whereisaaron whereisaaron commented Oct 17, 2019

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

This comment has been minimized.

Copy link

@fuerst fuerst commented Oct 17, 2019

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.

@rostovtsev

This comment has been minimized.

Copy link
Collaborator

@rostovtsev rostovtsev commented Oct 17, 2019

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

@timriker

This comment has been minimized.

Copy link
Author

@timriker timriker commented Oct 17, 2019

@rostovtsev

This comment has been minimized.

Copy link
Collaborator

@rostovtsev rostovtsev commented Oct 17, 2019

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

This comment has been minimized.

Copy link

@MattWilcox MattWilcox commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@MattWilcox MattWilcox commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@MattWilcox MattWilcox commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 18, 2019

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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@MattWilcox MattWilcox commented Oct 18, 2019

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

This comment has been minimized.

Copy link
Collaborator

@swelljoe swelljoe commented Oct 18, 2019

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

@ftrojahn

This comment has been minimized.

Copy link

@ftrojahn ftrojahn commented Oct 19, 2019

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

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 19, 2019

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

This comment has been minimized.

Copy link
Author

@timriker timriker commented Oct 19, 2019

I have removed the php_admin_value lines manually, multiple times.

@swelljoe

This comment has been minimized.

Copy link
Collaborator

@swelljoe swelljoe commented Oct 19, 2019

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

This comment has been minimized.

Copy link

@nicutor nicutor commented Oct 19, 2019

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

This comment has been minimized.

Copy link

@nicutor nicutor commented Oct 20, 2019

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: #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

This comment has been minimized.

Copy link

@whereisaaron whereisaaron commented Oct 20, 2019

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

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 31, 2019

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

This comment has been minimized.

Copy link
Collaborator

@jcameron jcameron commented Nov 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.