SOLVED cPanel 66 Update MultiPHP INI Editor Changes

[linux4me2]

When the update from WHM 64 to 66 ran, several settings in the MultiPHP INI Editor, including allow_url_fopen, memory_limit, timezone, and upload_max_filesize, reverted to other settings.

I've got those issues resolved now, but according to the release notes for WHM 66, the MulitPHP INI Editor in WHM 66 saves changes to the php.ini file rather than the local.ini file. When there is an update of WHM or PHP that involves changes to the php.ini file, will my custom settings be lost and have to be reset each time?

 

[cPanelMichael]

Hello,

Here's a quote sent by one of our Technical Analysts from a recent support ticket where a similiar concern was brought up:

I do however believe I understand where there may be some additional confusion, and this relates to the 2 changes cPanel version 66 did make to topics related to what's been discussed in this ticket:

1) First change - WHM -> MultiPHP INI Editor now writes to /opt/cpanel/ea-phpXX/root/etc/php.ini instead of ../php.d/local.ini (since local.ini's existence essentially makes user's php.ini files useless under suPHP since local.ini overrides everything within it).

2) Second change - cPanel -> MultiPHP INI Editor now edits .htaccess, .user.ini, OR php.ini, depending on your handler. In cPanel v64, this interface would simultaneously edit php.ini, .htaccess, and .user.ini.
Due to the way local php.ini files work under suPHP (in that they *replace* system-wide php.ini), this file only containing a few directives means all other PHP options will be PHP defaults. This behavior was present in both 64 and 66. I've verified this by installing cPanel 64.0.36 to a test environment and testing further.

The difference between 64 and 66 however is that the local.ini has been transferred over to the system php.ini, leaving the incomplete php.ini files in user directories to result in all their un-speecified directives to be PHP Defaults. I'll agree that this may seem confusing, as the cPanel PHP INI Editor is in the context of making changes to specific directives, when in reality, submitting that form creates a php.ini file which ultimately sets most PHP settings to PHP defaults.

So, in summation, we have below the differences between cPanel 64 and 66:

v64: User's MultiPHP INI Editor in cPanel would write to php.ini, .user.ini, and .htaccess. Under suPHP, the php.ini would override the system-wide php.ini. The presence of a local.ini in /opt/cpanel/ea-phpXX/root/etc/php.d/ would override all the user's php.ini settings, but their customizations were re-implemented with the .user.ini file that was also present.

v66: User's MultiPHP INI Editor in cPanel writes to php.ini for suPHP, .htaccess if they're using DSO, and .user.ini if they're using CGI or PHP-FPM. Due to the lack of local.ini, any settings not specified in their local php.ini would be PHP defaults, leaving ONLY the user's customizations, and no server-wide configurations.

Custom PHP configuration values should remain preserved through future updates as long as you are using the "cPanel >> MultiPHP INI Editor" to make the changes.

Thank you.

 

[linux4me2]

If I understand correctly, with v66, the MultiPHP INI Editor saves changes to /opt/cpanel/ea-phpXX/root/etc/php.ini for suPHP, and to .user.ini in the user's home directory with PHP-FPM, though the latter currently doesn't work, and is the subject of an open internal case. What I don't get is where the custom settings for suPHP accounts are saved upon PHP updates. Isn't the /opt/cpanel/ea-phpXX/root/etc/php.ini overwritten with the new default php.ini each time PHP is updated?

 

[cPanelMichael]

Hello,

If suPHP is enabled as the PHP handler for an account, and that account uses "cPanel >> MultiPHP INI Editor" to make a PHP configuration change, then the following file is created (if "Home Directory" is selected):

/home/$username/php.ini

Isn't the /opt/cpanel/ea-phpXX/root/etc/php.ini overwritten with the new default php.ini each time PHP is updated?

No, this file is not overwritten as of cPanel version 66. EX:

1. Enable suPHP as the PHP handler for PHP 5.6.
2. Change "upload_max_filesize" in "WHM >> MultiPHP INI Editor" to "6M".
3. Notice it's populated in the php.ini file:

# grep upload_max /opt/cpanel/ea-php56/root/etc/php.ini
upload_max_filesize = 6M

4. Downgrade and upgrade PHP 5.6:

yum downgrade ea-php56
yum upgrade ea-php56

5. Notice the custom value is retained:

# grep upload_max /opt/cpanel/ea-php56/root/etc/php.ini
upload_max_filesize = 6M

Thank you.

 

[Kent Brockman]

Hello guys. In despite of all your explanation, I found today that a couple servers had its WHM's MultiPHP INI Editor settings reset to defaults. Both in servers using PHP-FPM or not, even on those configs using suphp as handler.
If the custom values should have been kept, then is this a bug?

 

[cPanelMichael]

If the custom values should have been kept, then is this a bug?

Could you verify the method used to enable the custom PHP values? For instance, was it only through the cPanel MultiPHP INI Editor, or were any other methods utilized?

Thank you.

 

[Kent Brockman]

I double checked now with 5 servers choosen randomly and found that some PHP settings were reset and others not. It appears to not be dependant on OS version as this happenned on both CentOS 6.9 and 7.3, but it is consistently happen with PHP 7.x. PHP 5.x has kept the values untouched.

Now I have to manually check and reconfigure almost 25 servers because of this fail. If you would add the feature to transfer PHP INI settings with transfer tool it could be done in a couple minutes. Hope you can work on this feature request: Transfer Tool to migrate PHP settings too

Do you know of a way to massively import PHP INI settings from one server to several others? Let me know asap please.

I'll have to switch from RELEASE to STABLE version in all the servers to avoid these bugs in the future.

 

[Kent Brockman]

Could you verify the method used to enable the custom PHP values? For instance, was it only through the cPanel MultiPHP INI Editor, or were any other methods utilized?

Thank you.

I only use the cPanel MultiPHP INI Editor. No CloudLinux, no custom code, no weird addons.

 

[Kent Brockman]

Of the Custom INI Settings I edit in the WHM UI, I customize some basic settings using the WHM INI settings form, and in the editor screen I use to preset a couple things like...

disable_functions = "proc_open,shell_exec,passthru,exec,ini_alter,system,leak,listen,chgrp,apache_setenv,define_syslog_variables,openlog,syslog,ftp_exec,posix_getpwnam,symlink"
log_errors_max_len = 0
date.timezone = "America/Argentina/Buenos_Aires"

And in the PHP 7.x settings these values were RANDOMLY reset to default in several servers.

If I fix these values all along the servers, should I expect this to not happen again as it was due to the migration from v64 to v66?

 

[linux4me2]

All my settings that were reset were set via WHM -> MultiPHP INI Editor as well. For me, it affected both PHP 5.6 and 7.0. I don't even have the feature enabled for cPanel -> MultiPHP INI Editor.

 

[Kent Brockman]

The most "irritating" issue is that "disable_functions" was reset in all PHP 7.x settings across al servers. That's pretty dangerous guys.

You guys (cPanel) should release an urgent update to v66 that send an email to all admins showing that their disable_functions variable in PHP x.y is empty and producing an eventual vulnerability. I do prefer an email because you cannot preset any function on this variable, cause some scenarios may need some functions unblocked and each admin knows what their users need.

In fact, checking for an empty disable_functions variable on all PHP versions, should be part of the maintanance done by upcp every day. Security Advisor should check this as well.

 

[cPanelMichael]

Hello,

The following command is ran as part of the update to cPanel version 66:

/scripts/migrate_local_ini_to_php_ini --run --verbose

Can you review the recent cPanel update logs in the /var/cpanel/updatelogs/ directory to see if there were any errors when that command was ran? If you see no errors, could you open a support ticket using the link in my signature so we can take a closer look to see why your PHP configuration settings were not automatically migrated?

Thank you.

 

[linux4me2]

This is interesting. I was going to take a look at the update log and see what happened in my case. I looked in /var/cpanel/updatelogs/ and it's empty. I got the email saying the upcp script did run on 8/31, and at the bottom, it says a copy of the log is available in /var/cpanel/updatelogs, but it's not there. I guess the logs are rotated every month and I just happened to look on the 1st after that happened? Are they archived anywhere?

I think at this point I have my php.ini's rebuilt and have things working again, but I'd still like to know what happened.

 

[linux4me2]

I ended up retrieving the logs from a backup, and found out that the command to retrieve my settings from local.ini did fail:

[2017-08-23 02:47:16 -0400]   Processing: Checking for deprecated PHP local.ini
[2017-08-23 02:47:16 -0400]    - Processing command `/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini --run --verbose`
[2017-08-23 02:47:16 -0400]      [12639]     Failed to migrate /opt/cpanel/ea-php56/root/etc/php.d/local.ini to /opt/cpanel/ea-php56/root/etc/php.ini. This will need done manually.
[2017-08-23 02:47:16 -0400]      [12639]     Failed to migrate /opt/cpanel/ea-php70/root/etc/php.d/local.ini to /opt/cpanel/ea-php70/root/etc/php.ini. This will need done manually.
[2017-08-23 02:47:16 -0400]      [12639] Processing ea-php56 …
[2017-08-23 02:47:16 -0400]      [12639]     Error: (XID 6nsc55) 1 error occurred:
[2017-08-23 02:47:16 -0400]      [12639]         Error #1: The PHP directive “extension” is not supported by this interface.
[2017-08-23 02:47:16 -0400]      [12639]  … done!
[2017-08-23 02:47:16 -0400]      [12639] Processing ea-php70 …
[2017-08-23 02:47:16 -0400]      [12639]     Error: (XID ummwnz) 1 error occurred:
[2017-08-23 02:47:16 -0400]      [12639]         Error #1: The PHP directive “extension” is not supported by this interface.
[2017-08-23 02:47:16 -0400]      [12639]  … done!

I totally missed the "failed" message and the part about needing to make the changes manually. I clearly need to read these update logs more carefully.

I suspect the error regarding the PHP directive "extension" is why Imagick didn't get carried over, either.

 

[Wolfn]

Hello,

The following command is ran as part of the update to cPanel version 66:

/scripts/migrate_local_ini_to_php_ini --run --verbose

Can you review the recent cPanel update logs in the /var/cpanel/updatelogs/ directory to see if there were any errors when that command was ran? If you see no errors, could you open a support ticket using the link in my signature so we can take a closer look to see why your PHP configuration settings were not automatically migrated?

Thank you.

This is my output:

[2017-09-04 02:37:40 -0400]   Processing: Checking for deprecated PHP local.ini
[2017-09-04 02:37:40 -0400]    - Processing command `/usr/local/cpanel/scripts/migrate_local_ini_to_php_ini --run --verbose`
[2017-09-04 02:37:40 -0400]      [17216]        Failed to migrate /opt/cpanel/ea-php56/root/etc/php.d/local.ini to /opt/cpanel/ea-php56/root/etc/php.ini. This will need done manually.
[2017-09-04 02:37:40 -0400]      [17216]        Failed to migrate /opt/cpanel/ea-php70/root/etc/php.d/local.ini to /opt/cpanel/ea-php70/root/etc/php.ini. This will need done manually.
[2017-09-04 02:37:40 -0400]      [17216] Processing ea-php54 …
[2017-09-04 02:37:40 -0400]      [17216]        No local.ini.
[2017-09-04 02:37:40 -0400]      [17216]  … done!
[2017-09-04 02:37:40 -0400]      [17216] Processing ea-php55 …
[2017-09-04 02:37:40 -0400]      [17216]        No local.ini.
[2017-09-04 02:37:40 -0400]      [17216]  … done!
[2017-09-04 02:37:40 -0400]      [17216] Processing ea-php56 …
[2017-09-04 02:37:40 -0400]      [17216]        Error: (XID vuembm) 1 error occurred:
[2017-09-04 02:37:40 -0400]      [17216]                Error #1: The PHP directive “extension” is not supported by this interface.
[2017-09-04 02:37:40 -0400]      [17216]  … done!
[2017-09-04 02:37:40 -0400]      [17216] Processing ea-php70 …
[2017-09-04 02:37:40 -0400]      [17216]        Error: (XID pagmrb) 1 error occurred:
[2017-09-04 02:37:40 -0400]      [17216]                Error #1: The PHP directive “extension” is not supported by this interface.
[2017-09-04 02:37:40 -0400]      [17216]  … done!
[2017-09-04 02:37:40 -0400]      [17216] Processing ea-php71 …
[2017-09-04 02:37:40 -0400]      [17216]        No local.ini.
[2017-09-04 02:37:40 -0400]      [17216]  … done!

 

[cPanelMichael]

The PHP directive “extension” is not supported by this interface.

Internal case CPANEL-15652 is open to ensure the migrate_local_ini_to_php_ini fails succeeds if an "extension" directive is present in the local.ini file. I'll monitor this case and update this thread once the resolution is published. In the meantime, the workaround is to create individual .ini files in the /opt/cpanel/ea-php$$/root/etc/php.d/php.d/ directory for any affected PHP versions that use custom "extension=" lines in the local.ini file, remove the extension directive(s) from the local.ini file(s), and then run the migration script again:

/scripts/migrate_local_ini_to_php_ini --verbose --run

Thank you.

 

[linux4me2]

In our case, it was Imagick that was the extension lost with the v. 66 update, and since we want it available to all accounts, I just added the line:

extension=imagick.so

in Editor Mode of the MultiPHP INI editor to both versions of PHP we're running, then turned PHP-FPM off and back on for the sites we have running PHP-FPM so the change would take effect for them as well as the non-PHP-FPM sites.

 

[cPanelMichael]

Hello,

To update, the case is published in cPanel 66.0.19:

Fixed case CPANEL-15652: Manually migrate extension directives from local.ini.

Thank you.