Default PHP change - CentOS 7
Anybody else running CentOS 7 with their default PHP version set to 8.0 noticing that some mysterious task is resetting the default PHP version to 8.1?
This has happened on more than one occasion. The file /etc/cpanel/ea4/php.conf gets changed from
default: ea-php80
to
default: ea-php81
Seems to be happening on all of our CentOS 7 servers that have PHP 8.0 as the default. Our AlmaLinux 8 servers do not appear to be affected, nor does one server that still has PHP 7.3 as the default seem to be affected.
I'm not seeing anything in the logs to indicate that a cron task was executed that would have changed this, but I've got a lot of servers to go through.
It's a very annoying issue.
-
I'm not almost certain that this is tied to the EA4 update. Because all of the changes to [font="courier new">/etc/cpanel/ea4/php.conf happened around the time I pushed the latest update yesterday. There was no EA4 update for AlmaLinux 8. Not sure why the server set with PHP 7.3 as default was not affected. 0 -
Hey hey! I created a CentOS 7 box and set the default PHP version to 8.0 through WHM >> MutliPHP Manager. I confirmed this was in place in the file: [root@host /]# cat /etc/cpanel/ea4/php.conf --- default: ea-php80 ea-php73: suphp ea-php74: suphp ea-php80: suphp ea-php81: suphp
Since it's a new machine, there should be some updates available, so I ran the update from WHM >> EasyApache 4. I didn't see a change there after the provision. I then forced a general "yum update" and didn't see a change. I then did a "/scripts/upcp --force" and still didn't see a change. If you can come up with a way where I can reproduce this I'd be happy to try it!0 -
Indeed - today, I updated all of the PHP pear packages: [font="courier new">ea-php81-pear-1.10.13-1.1.1.cpanel.noarch ea-php80-pear-1.10.13-1.1.1.cpanel.noarch ea-php74-pear-1.10.13-1.1.1.cpanel.noarch ea-php72-pear-1.10.13-1.1.1.cpanel.noarch ea-php73-pear-1.10.13-1.1.1.cpanel.noarch ea-php71-pear-1.10.13-1.1.1.cpanel.noarch ea-php56-pear-1.10.13-1.1.1.cpanel.noarch ea-php70-pear-1.10.13-1.1.1.cpanel.noarch And the default PHP version has been updated from PHP 8.0 to PHP 8.1 0 -
I can duplicate this by setting the default PHP version to PHP 8.0: [font="courier new">/usr/local/cpanel/bin/whmapi1 php_set_system_default_version version="ea-php80" And verifying that [font="courier new">/etc/cpanel/ea4/php.conf is set accordingly: # cat /etc/cpanel/ea4/php.conf --- default: ea-php80 ea-php73: suphp ea-php74: suphp ea-php80: suphp ea-php81: suphp
And then forcing a reinstall of any of these recent ea pear packages ... although, I suspect any ea package will trigger this. [font="courier new">yum reinstall ea-php80-pear-1.10.13-1.1.1.cpanel.noarch And then checking the default settings:# cat /etc/cpanel/ea4/php.conf --- default: ea-php81 ea-php73: suphp ea-php74: suphp ea-php80: suphp ea-php81: suphp
There is also a key in the [font="courier new">/var/cpanel/cpanel.config file - [font="courier new">php_system_default_version that I assume plays a role in this as well, but it too is set to [font="courier new">ea-php80 prior to reinstalling this ea package. This is telling me one of two things: Either all EA packages are assuming that the latest version of PHP installed, in this case PHP 8.1, is supposed to be the default version and redoing that. Or... [font="courier new">/usr/local/cpanel/bin/whmapi1 php_set_system_default_version version="ea-php80" isn't setting all of the proper configuration files that register the "default" PHP version and when an EA package is installed the system is confused as to what to set the default PHP version to.0 -
Alright - let me try this and I'll report back! 0 -
I'm still not able to reproduce this scenario on my end. Could you create a ticket with our team so we can see this on the affected machine? 0 -
Ticket #94538737 has been created regarding this issue. Although I don't know from what IP addresses you will be accessing the server from, so I was not able to punch a hole in the firewall for that. I thought the ticket system used to tell you what IP addresses cPanel staff would be accessing the server from so that we could allow access from those IPs. If it still does, then I must've missed that part when filling out the server access part. Found it! - How to Authenticate your Server for cPanel Technical Support | cPanel & WHM Documentation 0 -
It would be odd if that didn't show up, but we do have a list here: Grant cPanel Support Access | cPanel & WHM Documentation 0 -
Yea, I found the list after I submitted the ticket. I granted these IPs access on the server. I won't say that the ticket system didn't present these IPs when I went through the process - I just didn't see them if it did. But I could have been staring right at it and not seen it too. 0 -
Hello Sir,
I encountered the same problem as you. Can you tell me how to fix this error?
0 -
It would be best to create a ticket if you're experiencing this issue still.
0
Please sign in to leave a comment.
Comments
11 comments