-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of James Hogarth Sent: den 21 september 2017 15:51 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 7: changes to php.ini

When you have different applications with different needs it's best to either use mod_php specific directives within that virtualhost such as

here:

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud- defaults.inc

Or honestly better still to not use mod_php and instead switch to php-fpm with separate application pools which each have their own php settings

like

this nginx based setup:

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud- conf-nginx.conf

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-el7- php-fpm.conf

Would that be true even for really small installs. Like running one server with one, maybe two services relying on php? It feels rather over the top.

I use Apache and php because most good howto's out there are based on those assumptions.

-- //Sorin

Valeri Galtsev wrote:

On Thu, September 21, 2017 4:04 am, Nicolas Kovacs wrote:

...

Hi,

I'm hosting a few web apps like OwnCloud, Wordpress and Dolibarr on CentOS 7 that require a handful of changes to php.ini. I have to define some custom values for post_max_size, upload_max_filesize, etc.

I don't know if I'm supposed to edit /etc/php.ini directly or if changes should be put in a configuration file stub in /etc/php.d. For example, I followed the recommendations of a fellow CentOS user and defined date.timezone by edit /etc/php.d/date.ini like this.

[Date] ; Defines the default timezone used by the date functions ; http://php.net/date.timezone date.timezone = Europe/Paris

Am I supposed to do something similar for other PHP variables?

I for one do all changes I need (like timezone, memory, upload size, etc) in /etc/php.ini or its equivalent (on FreeBSD it will be /usr/local/etc/php.ini). Package managers are smart to not overwrite (or delete when package is uninstalled) configuration files. I'm sure config files in php.d are read after /etc/php.ini so they have "final word" on what some variable will be. Making habit to put things there is good in respect you will check/edit in place that will be overriding other places like /etc/php.ini. As I am one sysadmin in the team, I prefer slight convenience (or indulge my laziness) of doing it /etc/php.ini. So, it basically can be just your own habit.

Y'all should note the existence of yum-posttransaction-actions, which allows you to create scripts to be automagically run after a yum update. I, specifically, use it to keep apcupsd from either screaming and screaming, as happens with an extension, by just using sed -i to change /etc/apcupsd/appcontrol (which is *not* a configuration file, and so is overwritten) so that SHUTDOWN=/bin/false, rather than /sbin/shutdown

mark