.user.ini files not recursive
I am using CentOS 6.9, cPanel 64.0 (build 21), PHP 7 with PHP-FPM with some sites and I am having difficulty getting .user.ini files to work recursively. The problem is described and solved here (although not for cPanel):
stackoverflow.com/questions/27226055/does-the-user-ini-file-work-for-subdirectories
Essentially the problem is that cPanel adds a slash to the end of the PHP-FPM proxy address as below:
Looking at the phpinfo for a site with this setting shows that the $_SERVER['SCRIPT_FILENAME"> variable ends up being prepended with a // similar to:
This then has the effect of .user.ini files not being read by sub-directories and can only be rectified by placing another .user.ini in the sub-directory itself, which is obviously not ideal as I want the settings in my webroot .user.ini to be effective across all sub-directories, similar to how php_value settings work in a .htaccess file. By taking the slash away from the end of the SetHandler line within the httpd.conf file directly and restarting Apache the problem is temporarily solved. However, because of how cPanel works the next rebuild of the httpd.conf file will add the trailing slash again. Although cPanel allows specific virtualhost settings by adding files to the /etc/apache2/conf.d/userdata directory, the include of these settings happens in the httpd.conf file before the SetHandler line is added, meaning we cannot customise this line. Is there another way to fix this at a global level within my cPanel install?
SetHandler proxy:unix:/opt/cpanel/ea-php70/root/usr/var/run/php-fpm/5109b0c98599403f47e6e1f35c4510ebc9d8bcfb.sock|fcgi://domain.tld/Looking at the phpinfo for a site with this setting shows that the $_SERVER['SCRIPT_FILENAME"> variable ends up being prepended with a // similar to:
$_SERVER['SCRIPT_FILENAME"> //home/account/app/public_html/info.phpThis then has the effect of .user.ini files not being read by sub-directories and can only be rectified by placing another .user.ini in the sub-directory itself, which is obviously not ideal as I want the settings in my webroot .user.ini to be effective across all sub-directories, similar to how php_value settings work in a .htaccess file. By taking the slash away from the end of the SetHandler line within the httpd.conf file directly and restarting Apache the problem is temporarily solved. However, because of how cPanel works the next rebuild of the httpd.conf file will add the trailing slash again. Although cPanel allows specific virtualhost settings by adding files to the /etc/apache2/conf.d/userdata directory, the include of these settings happens in the httpd.conf file before the SetHandler line is added, meaning we cannot customise this line. Is there another way to fix this at a global level within my cPanel install?
-
Hello, Internal case EA-6167 is open to address an issue where PHP-FPM in combination with .user.ini files acts non-recursively in the public_html directory due to trailing slash in proxy_fcgi_module configuration. I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can create custom Apache Virtual Host templates as a temporary workaround. EX: cp -a /var/cpanel/templates/apache2_4/vhost.default /var/cpanel/templates/apache2_4/vhost.local cp -a /var/cpanel/templates/apache2_4/ssl_vhost.default /var/cpanel/templates/apache2_4/ssl_vhost.local
Once you create the local template files, you can modify the .local files to modify the PHP-FPM entry from:[%- IF vhost.php_fpm %] SetHandler proxy:unix:[% vhost.php_fpm_socket %]|fcgi://[% wildcard_safe(vhost.servername) %]/
To:[%- IF vhost.php_fpm %] SetHandler proxy:unix:[% vhost.php_fpm_socket %]|fcgi://[% wildcard_safe(vhost.servername) %]
Then, rebuild the Apache configuration file:/scripts/rebuildhttpdconf
Thank you.0 -
Great temporary solution - that's worked a treat. Hopefully, a later cPanel release will fix this issue and then presumably we should revert to the vhost.default and ssl_vhost.default files in case we miss any future updates to these files? 0 -
Great temporary solution - that's worked a treat. Hopefully, a later cPanel release will fix this issue and then presumably we should revert to the vhost.default and ssl_vhost.default files in case we miss any future updates to these files?
You could simply remove the .local files that you created to remove the customization once a resolution is published. Thanks!0 -
Any progress on fixing this? (Internal case EA-6167) 0 -
Any progress on fixing this? (Internal case EA-6167)
The default configuration in release 66 (Current) applies these changes automatically--so no need for .local versions when 66 goes to Release. I'm running Current and have removed my .local versions of my apache config.0 -
What WHM version will this be included in?
EasyApache 4 updates are independent of cPanel updates. You should be able to use the "yum update" command to update the EA4 RPMs on your system. Thank you.0
Please sign in to leave a comment.
Comments
8 comments