Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

SOLVED cPanel 66 Update MultiPHP INI Editor Changes

Discussion in 'EasyApache' started by linux4me2, Aug 29, 2017.

  1. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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?
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

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

    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 likes this.
  3. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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?
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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

    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:

    Code:
    # grep upload_max /opt/cpanel/ea-php56/root/etc/php.ini
    upload_max_filesize = 6M
    4. Downgrade and upgrade PHP 5.6:

    Code:
    yum downgrade ea-php56
    yum upgrade ea-php56
    5. Notice the custom value is retained:

    Code:
    # grep upload_max /opt/cpanel/ea-php56/root/etc/php.ini
    upload_max_filesize = 6M
    
    Thank you.
     
    linux4me2 likes this.
  5. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,156
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    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?
     
  6. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
  7. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,156
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  8. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,156
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    I only use the cPanel MultiPHP INI Editor. No CloudLinux, no custom code, no weird addons.
     
  9. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,156
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    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...

    Code:
    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?
     
  10. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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.
     
  11. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,156
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  12. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

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

    Code:
    /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 likes this.
  13. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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.
     
  14. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    I ended up retrieving the logs from a backup, and found out that the command to retrieve my settings from local.ini did fail:
    Code:
    [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.
     
    #14 linux4me2, Sep 1, 2017
    Last edited: Sep 1, 2017
  15. Wolfn

    Wolfn Registered

    Joined:
    Sep 4, 2017
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Uruguay
    cPanel Access Level:
    Root Administrator
    This is my output:

    Code:
    [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!
    
     
  16. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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:

    Code:
    /scripts/migrate_local_ini_to_php_ini --verbose --run
    Thank you.
     
    linux4me2 likes this.
  17. linux4me2

    linux4me2 Well-Known Member

    Joined:
    Aug 21, 2015
    Messages:
    167
    Likes Received:
    36
    Trophy Points:
    28
    Location:
    USA
    cPanel Access Level:
    Root Administrator
    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:
    Code:
    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 likes this.
  18. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,080
    Likes Received:
    1,364
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
    linux4me2 likes this.
Loading...

Share This Page