I keep getting 500 internal server error
The most common cause for this on our servers is that your file permissions are incorrect. For any other 500 internal server error problems you are welcome to submit a support ticket.
We switched our cpanel servers to phpsuexec on January 10, 2007. We have long used phpsuexec on our mail servers. It is known as a more secure management for PHP and also allows us to track and monitor client usage on shared servers so that PHP scripts are correctly identified by their true owner as opposed to "nobody" user.
There are pros and cons to phpsuexec and Suexec.
Suexec
According to Apache HTTP Server Version 1.3, Suexec: "provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server."
For detailed information about Suexec, go to: http://httpd.apache.org/docs/1.3/suexec.html
PhpSuexec
Php, without PhpSuexec, runs as an Apache Module, executes as the user/group of a web server, in this case "nobody". This causes real problems when php scripts are sending mail out as nobody@servername and we are unable to track abuse or hijack issues.
When PhpSuExec is enabled (running as CGI with suexec enabled) your Php scripts execute under your UID/GID level and not nobody/nobody. Files or directories that you require your Php scripts to write to no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else). That said, PhpSuExec is much more secure than Php running as a Apache module.
- The Downside to, or the impact of, using Phpsuexec:
Php Scripts:
Some scripts do not like the Phpsuexec CGI environment as it changes certain Php internal system variables causing them to fail.
.htaccess:
Manipulating some Php settings is not possible within .htaccess (use a local Php.ini instead)
Security:
Files / Directory permissions given a world read+write+execute 777 will not work, instead these files will need to be changed to 755
Php eAccelerator:
ZendOptimizer works, however other popular Accelerators such as eAccelerator won't.
URLs:
Variables in URL not encoded as regular variables that is variables inside the URL path, not expressed like view.Php?=view will not work.
PLEASE make the appropriate changes.
