Premature end of script headers (suphp problem)

AL-Kateb

Active Member
Feb 27, 2010
28
0
51
Hello everybody,
today i decided to test suphp on my testing VPS and i recompiled apache and php based onthe "php security profile"

i attached the profile so you can look at it.

I'm always getting 500 internal server error with any php file i try to execute

i searched this before posting of course but what i found was not the cause of the problem.

i used suphp before for a while and it worked fine on this VPS so I'm surprised why it's not working now

the perms and the ownership are fine
there are no .htaccess in the webroot nor anywhere in the user's home dir so it would not be cos of invalid value in .htaccess

i tailed the error_log and i found this error "Premature end of script headers"

and when i read in suphp website i figured php might still be handled by the cli version of php? so i configured suphp.conf to set the handler like this:

Code:
application/x-httpd-php="php:/usr/bin/php5-cgi"
;application/x-httpd-php4="php:/usr/php4/bin/php"
application/x-httpd-php5="php:/usr/bin/php5-cgi"
why there is supposed to be a handler for php4? is it supposed to be handled anyway? i commented out that line but maybe i should not right? well anyway it's not relevant to the problem.

then i restarted apache and tried again but the same error

in suphp log file there is nothing but [info] no errors and no warnings

without changing anything in the profile i set php handler to cgi and it worked fine and yes it worked as the user not as nobody but since I'm using suphp am not i supposed to set the handler to suphp?

i noticed another error in the error_log which is:
Code:
SoftException in Application.cpp:574: Could not execute script
I'm not sure how to fix this problem

i am still suspecting the php handler could be the problem! is there a binary for suphp that i need to place in the suphp.conf instead of /usr/bin/php or /usr/bin/php5-cgi?

or what exactly is the problem?

and a related question is
if i enabled "safe php cgi" to prevent users from overriding php.ini's settings will suphp_configpath still be effictive? or that will disable it as well?

thanks in advance
 

Attachments

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
For the handler, you want to keep the original paths rather than changing it. suPHP is not going to work with the handlers that were set. The right handlers should be the following:

Code:
[handlers]
;Handler for php-scripts
application/x-httpd-php="php:/usr/bin/php"
application/x-httpd-php4="php:/usr/php4/bin/php"
application/x-httpd-php5="php:/usr/bin/php"
If you aren't talking about the handlers, then whatever was modified, I'd change it back. I can provide an unmodified /opt/suphp/etc/suphp.conf file if needed (if no backup was made before editing it).

Can you provide your entire suphp.conf contents? I want to ensure nothing else was changed.

Next, do you have any includes in /usr/local/apache/conf/includes location? An include could cause suphp to not work for all accounts depending on the include type. Also, you did not edit /usr/local/apache/conf/php.conf correct?

Finally, in reference to safe php cgi, do you mean safe_mode?
 

AL-Kateb

Active Member
Feb 27, 2010
28
0
51
i changed the handlers because it was not working but now i changed them back and it's not working.

i attached my suphp config file and i changed allow_writable_* to true so scripts with wide permissions do not cause troubles for now

and about the includes there is nothing there with data except for the errordocument.conf but nothing for the accounts

and i will attach my virtual host container maybe there is something wrong there?

Code:
<VirtualHost xx.xx.xx.xx:80>
    ServerName myuser.com
    ServerAlias www.myuser.com
    DocumentRoot /home/myuser/public_html
    ServerAdmin [email protected]
    UseCanonicalName Off
    CustomLog /usr/local/apache/domlogs/myuser.com combined
    CustomLog /usr/local/apache/domlogs/myuser.com-bytes_log "%{%s}t %I .\n%{%s$
    ## User myuser # Needed for Cpanel::ApacheConf
    UserDir disabled
    UserDir enabled myuser
    <IfModule mod_suphp.c>
        suPHP_UserGroup myuser myuser
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup myuser myuser
    </IfModule>
    ScriptAlias /cgi-bin/ /home/myuser/public_html/cgi-bin/


    # To customize this VirtualHost use an include file at the following locati$
    # Include "/usr/local/apache/conf/userdata/std/2/myuser/myuser.com/*.conf"

</VirtualHost>
and btw this might be useful to know but i created a file and executed from shelll
PHP:
#!/usr/bin/php
<?php
echo "Hello world\n";
?>
and it worked as expected

so the error has something to do with apache something with headers! i can't figure out what that is

Also, you did not edit /usr/local/apache/conf/php.conf correct?
i did not edit that file but still here it is maybe there is something wrong previously (i removed comment so the post does not take too much space)

Code:
Action application/x-httpd-php5 /cgi-sys/php5
AddType application/x-httpd-php5 .php5 .php4 .php .php3 .php2 .phtml
Finally, in reference to safe php cgi, do you mean safe_mode?
no but in the easyapache there is that option which is described as "to prevent users from overriding the main php.ini settings" something like that

so what could cause this problem?

and is this error "premature end of the script headers" and SoftException in Application.cpp:574: Could not execute script relative to the problem?
 

Attachments

Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
When I look at your suphp.conf file, I see several changes from the default. The most glaring being this one:

Code:
chroot=/home
Please comment that out again so it looks like this:

Code:
;chroot=/home
The other ones changed were these:

Code:
allow_file_group_writeable=true
allow_file_others_writeable=true
allow_directory_group_writeable=true
allow_directory_others_writeable=true
errors_to_browser=true
They are false by default. I doubt they are the issue. The chroot one would definitely be.
 

AL-Kateb

Active Member
Feb 27, 2010
28
0
51
Please comment that out again so it looks like this:
That indeed was the problem thanks a lot for helping me with this, i know my reply came late but i did not have time to test and i thought that i should anyway come to say that this was the problem in case somebody came across the same problem would know what was the cause.

thanks