Include php.ini in default install for phpsuexec users
Travis - June 23, 2005 - 01:06
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Phpsuexec is a patch for Apache that does what the name implies; it allows the webserver to execute scripts using the permissions of individual users. Many ISPs have switched to phpsuexec as a security policy, but doing so breaks the ability to set php environment variables in .htaccess. To set up the php environment in a phpsuexec-enabled server, one must create a php.ini file and fill it with the appropriate content.
Thus, I think it would a good idea to include a pre-filled php.ini file with the default drupal package. If the user's apache hasn't been phpsuexec patched, the php.ini file won't actually do anything, so no harm.
Drupaler kbahey posted the following example php.ini file in http://drupal.org/node/14339 .
; This php.ini files is required when using PHPSuExec.
;
register_globals = 0
track_vars = 1
short_open_tag = 1
magic_quotes_gpc = 0
magic_quotes_runtime = 0
magic_quotes_sybase = 0
arg_separator.output = "&"
session.cache_expire = 200000
session.gc_maxlifetime = 200000
session.cookie_lifetime = 604800
session.auto_start = 0
session.save_handler = user
session.cache_limiter = none
allow_call_time_pass_reference = OnThoughts?
-t-
#1
Actually, I think this is a feature request. My bad.
#2
As a user of an ISP that runs phpsuexec on three of it's four servers (the fourth is under change now), I second that this is a really important file for usability of drupal. There are many ISPs running phpsuexec, and many more everyday, and most users of such ISPs don't know about it. So having to make these changes manually is just another bump in the road that makes drupal look bad. Even though drupal is not at fault, the types of users on such shared hosting providers, don't know or understand that.
#3
Most of those values can be defined at runtime, as it is in fact, in settings.php
See the .htaccess file supplied with Drupal. There are just a few...
#4
Just came across this problem (my host changed to PHPSuExec) and it took me a while to figure it out. I was getting Internal Server Errors and I couldn't figure out why... my host had warned that trying to set this variables outside of a php.ini would give me those errors, but I was still getting them after cleaning up .htaccess and settings.php and couldn't figure it out.
Turns out a simple php.ini file got rid of all the errors and brought the site back on-line. So I vote that it should be included with a default instalation (unless that brings problems to other users).
#5
I'm using this php.ini which included all the php settings I found in .htaccess (the first 3) and settings.php (the rest of them):
magic_quotes_gpc = 0
register_globals = 0
session.auto_start = 0
arg_separator.output = "&"
magic_quotes_runtime = 0
magic_quotes_sybase = 0
session.cache_expire = 200000
session.cache_limiter = "none"
session.cookie_lifetime = 2000000
session.gc_maxlifetime = 200000
session.save_handler = "user"
session.use_only_cookies = 1
session.use_trans_sid = 0
url_rewriter.tags = ""
Do I need these ones from the original php.ini provided by that other guy??
track_vars = 1short_open_tag = 1
magic_quotes_runtime = 0
magic_quotes_sybase = 0
session.cache_limiter = none
allow_call_time_pass_reference = On
#6
It'd be good to get some core developer feedback on this and maybe get into d6...
Bevan/
#7
Please don't use cnr to attempt to get a core dev to look at an issue.
How about bringing the topic up on the development list?
#8
@markus_petrux,
I don't think you understand the problem. Those runtime settings DON'T WORK in .htaccess files on a phpsuexec-configured server.
They must be defined in php.ini for them to have any effect on a phpsuexec-configured server.
@bdragon
Sorry about that -- I thought that's what 'code needs review' is for. What is CNR for? Is the dev list the only place where things like these are discussed?
#9
CNR is for when a patch file in unified diff format has been attached to the issue, and is ready for people to apply it to their test sites and post feedback on.
I suggested posting on the dev list because this issue seems like the kind of issue that is discussed on the dev list.
#10
Cool. Thanks for that.
One more question; What's the difference between 'Ready to be committed', and CNR?
Do you think it would be useful to have another status that caters for problems that have some sort of solution (but are not yet CNR), but also distinguishes them from unsolved issues. i.e. something between 'active' and CNR? ('needs more info' doesn't really apply to that situation).
If you also think that would be a good idea, I might create an issue on d.o webmasters...
#11
AFAIK phpsuexec hasn't gone away and this is still an issue. Consider this a *bump*.
#12
I believe more and more shared hosts are using phpsuexec. Another bump.