CentOS 7: Changes To Php.ini
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?
Cheers,
Niki
—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
6 thoughts on - CentOS 7: Changes To Php.ini
In the beginning I edited those values in php.ini. Got tired of having to remake the changes in php.ini, whenever php-updates were installed, so eventually began setting the needed values directly in the Owncloud-GUI.
Dates however are a different thing. I really always want to see and use ISO-dates and times regardless of it’s OC or whatever – so I edit the php.ini in that case.
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.
Just my $0.02
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
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
Valeri Galtsev wrote:
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
here:
like
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.
That’s a new one for me, thanks for the headsup!