php.ini (user.ini) in php-fpm and subdirectories

opt2bout

• June 10, 2017 12:46

I have found a couple of threads on internal case issues and reports regarding php.ini (or .user.ini and .htaccess) to override default PHP settings per domain. I have even opened up a case, and closed it thinking the issue was resolved. With an fpm enabled account, the php.ini overrides only apply to that directory. Subdirectories below are requiring that we copy the .user.ini to each directory where we have an application below the root public_html. Is this the way its supposed to work? If so, are there any alternatives to fpm for performance that work where we can just set a single php configuration file at the root and have it apply to all sub-directories?

• 

  Anoop P Alias

  • June 11, 2017 08:37

  The .user.ini is a per directory ini file and affects on the directory the file resides. If you need to change php.ini settings on a global scale edit multiPHP ini editor in WHM or if you wish to do this on a per domain basis, you can edit the php-fpm pool file that cPanel creates for the domain which will then affect all directories.

  0
• 

  opt2bout

  • June 12, 2017 21:23

  So the only way to change php.ini setting using php-fpm is to have the system administrator modify the /opt/cpanel/ea-php70/root/etc/php-fpm.d/[[domain]].conf file and restart fpm? So shouldn't the settings in the user's cPanel be disabled?

  0
• 

  cPanelMichael

  • June 13, 2017 16:51

  Hello, It looks to relate to the internal case referenced on the following thread: .user.ini files not recursive Let us know if the workaround referenced on that thread helps. Thank you.

  0
• 

  opt2bout

  • July 03, 2017 16:47

  Was building a new server and got delayed in testing this. Yes, this change fixed the issue. We can now have one .user.ini in the public_html directory and all sub-directories are applied. Ideally this would work if we chose to place the .user.ini file in the home directory as well.

  0
• 

  bgarrant

  • April 05, 2018 15:06

  Was building a new server and got delayed in testing this. Yes, this change fixed the issue. We can now have one .user.ini in the public_html directory and all sub-directories are applied. Ideally this would work if we chose to place the .user.ini file in the home directory as well.

  
  Did you try a .user.ini in the home directory (/home/user)? It does seem to work recursively. Just wondering if it is OK to do it this way as all the docs I see say to have the .user.ini in the public_html folder. Also, how can I make it so my clients can't modify the .user.ini file? I am trying to use this to just add an open_basedir restriction.

  0
• 

  cPanelMichael

  • April 05, 2018 15:09

  Did you try a .user.ini in the home directory (/home/user)? It does seem to work recursively. Just wondering if it is OK to do it this way as all the docs I see say to have the .user.ini in the public_html folder. Also, how can I make it so my clients can't modify the .user.ini file? I am trying to use this to just add an open_basedir restriction.

  
  Hello, We recommend using the INI Editor in cPanel to make these types of changes as this ensures the proper entries/files are automatically populated in the event the handler changes in the future. There's not currently a supported method to prevent user modifications to individual PHP configuration files with suPHP, aside from the workarounds referenced in this post: How to configure SuPHP to use only the MultiPHP INI file, not user inis, and open_basedir? Thank you.

  0

Please sign in to leave a comment.