I just noticed something strange with suPHP when I went to install a new application. It isn’t giving the correct configuration that’s in /etc/php.ini and /home/user/etc/php.ini combined.
The phpinfo() through NodeWorx is correct, but if I do phpinfo() through a SiteWorx account it is not. For example, the only configuration setting in the /home/user/etc/php.ini file is for open_basedir.
They both show the correct PHP version. But some values that do not match either /etc/php.ini or /home/user/etc/php.ini that are showing in the phpinfo() for a SiteWorx account are:
allow_url_fopen = On
display_errors = STDOUT
expose_php = On
magic_quotes_gpc = On
max_execution_time = 30
memory_limit = 128M
safe_mode = On
… To name a few. I have no idea where these values are coming from because as I said, they are in neither /etc/php.ini or /home/user/etc/php.ini.
I commented out the line:
suPHP_ConfigPath /home/user1/etc
from the vhost_domain1.conf file.
Then under /etc/php.d/ I created user1.ini (by copying /home/user1/etc/php.ini to that file)
user1.ini needed to be owned by user1 with permissions of 600.
Then create the symlink in /home/user1/etc/php.ini to /etc/php.d/user1.ini (so user1 can edit his .ini file)
With the 600 permissions only user1.ini is read by user1 in phpinfo(). user1.ini will not be read by user2's vhost.
/etc/php.ini remains the master config file controlled by the administrator (instead of default php values) but since user1.ini comes in /etc/php.d/ it overrides /etc/php.ini with whatever directives therein.
I guess if you wanted to block certain directives from being modified (such as memory_limit) you can create a file /etc/php.d/zzz_admin_override.ini and place them in there. That will override any custom user .ini because they get parsed alphabetically (but the zzz's need to be lowercase). Or you can also just make the user1.ini files with an underscore like _user1.ini.
This doesn’t seem like the correct behavior? I’m still running without the suPHP option because I’m afraid to break sites running on my server, but do want to move to suPHP in the future. Hopefully this will get sorted before then.
Based on the research I’ve been doing all day it seems the option “suPHP_ConfigPath /home/user1/etc” says “Use this as the main config, if it’s not there, use the compiled in default path. If it is there, use it and then search /etc/php.d/”… based on the RedHat PHP setup. The compiled in default path is in the /etc/httpd/conf.d/suphp.conf file and it is /etc/.
So basically the PHP interpreter is only taking one of those paths. I tried adding a second path to the suPHP_ConfigPath line and it didn’t accept it. I tried adding a line above it pointing to /etc/ and it only utilizes the last option.
It only wants one main configuration file to load, “Loaded Configuration File” from phpinfo(). After it finds the first one, it searches “Scan this dir for additional .ini files” from phpinfo(), and lists them here: “additional .ini files parsed” in phpinfo() in alphabetical order.
Googling led me to find several sources saying that if custom php.ini files are used per user, it adds those on top of default PHP values, ignoring /etc/php.ini. Also, some workarounds that included copying the main /etc/php.ini file to each user directory… but that takes away from the admin’s default standards.
Creating the per-user .ini files in /etc/php.d/ with read/write-only permissions for each owner/user allows the admin to still utilize /etc/php.ini to set server-wide configuration and for each user to set his or her own custom settings on top of that, given they have the symlink in their home directory.
I find it strange that suPHP behaves this way… or atleast why you cannot specify a secondary configuration file as a server-wide standard, rather than relying on default PHP values.
Yeah, I have a web dev client that already had hosting and in their environment you just drop a php.ini file in the root directory and include things you want to override.
I just wanted to change the include path, so that’s the only thing I put in the php.ini in the user home directory.
This to me is the ideal setup, but at least your workaround still gets the job done, just not as convenient.
I would probably set this up differently today. It’s less work to create a custom php.ini with my own default values and copy it to each user’s home directory. Completely ignore /etc/php.ini. Any admin overrides can be put in a .ini file in /etc/php.d/.
I just wanted to use /etc/php.ini before in case I ever wanted to make a server-wide change in one of the values, I could just edit that single file… but I rarely do that.
Maybe Interworx can add something into Nodeworx that allows the admin to set defaults that update each user’s php.ini and allow users to change them in Siteworx? It’s still a complicated issue. If I decide to change the values in Nodeworx I wouldn’t always want them to change user values that I’m not trying to override… which is why I think /etc/php.ini should not be skipped.
Ideally I want to be able to make my own php.ini that overrides default php values. Each user should be able to override my custom php.ini. I should be able to create admin overrides in /etc/php.d/. This is the setup I have now, which I outlined in previous posts. But, I’m not sure how Interworx will implement the custom php.ini files in Nodeworx and Siteworx and if my solution will continue to work.