Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@hebergement-serveurs.fr and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Looking at the log I only have this
[error] [client xxx.xxx.xxx.xxx] Premature end of script headers: php
I ran into the same problem on my test machine but haven’t yet had the time to work on that. I’d like suEXEC working with PHP5 as a CGI but considering the paranoia around the suexec binary I can’t really tell what the problem is. If anyone has an idea I’d be greatfull for the time saver.
The /var/log/httpd/suexec* log files will shed light. suexec just does a series of checks before it execs a script. The usual culprits of suexec not working are:
your script is owned by some other user than suexecusergroup says.
the directory in which your script lives in owned by someone other than suexecusergroup
the perms on your script and/or directory are too lenient (711 for each is fine).
The list goes on, and the options are better prioritized here:
Well pascal, that is the best thing to do I can think of at the moment. (You should be able to put the binary in the skel directory, and run some script to update the binary in everyone’s directories. Doing things this way is no different then having the individual users use their own cgi scripts, which just happen to be the php5 binary in this case. The other option is to modify the suEXEC binary to skip the requirement to have target UID/GID match script UID/GID.
What command are you trying to run from the browser here Pascal? php itself? Or are you trying to run a script that uses PHP #!/usr/bin/php style?
The php binary itself doesn’t need to be in the webspace, just as /usr/bin/perl doesn’t for perl based CGI scripts. There must be something else going on here.
Well, the other option is to modify mod_php’s source code, adding “5” to everything. So you could load “mod_php5” instead of “mod_php”. If it checks for a modified content type as well, they may work along side each other. The problem here is you need to modify the code on EVERY release of PHP. Well… with a context-sensitive patch…
We are not (yet) releasing RPMs as php5 is not officially part of the iworx RPM set so you’ll have to build the RPMs yourself. This HOWTO is meant to help you out getting a php5 / mysql 4.1 box running.
Install rpmbuild if needed
yum install rpm-build
Build the MySQL server for your platform. This needs to be done first so we can link php5 against it.
This will give you php 5 + mysql 4.1 with php as a module and as a cgi.
THIS HAS ONLY BEEN TESTED ON CENTOS 4.1 AND CENTOS COMES WITH MYSQL 4.1 SO I USED THE DEFAULT MYSQL 4.1 FOR CENTOS (I.E. SKIP THE FIRST FEW STEPS UP TO THE PHP BUILD.
THIS IS STILL DEEMED EXPERIMENTAL AND WE CAN’T DIRECTLY SUPPORT IT AS WE WOULD OTHER IWORX PROVIDED RPMS.
Yep, you’d have to build from source and change the SPEC file to build the cli instead of the cgi Dave. And yes, you’ll still need the --with <distro> string.