suPHP causing server 500 errors

First of all thank you to the developers for this brilliant control panel.

The suPHP module version 0.6.3, default Debian one not compiled version, Apache 2.2.9, PHP 5.2.6-1, and ISPConfig 3.0.1.2 are installed on Debian Lenny.

This is a custom virtual host with SSL and the port 80 one is virtually the same without the SSL directives.

Code:

<VirtualHost 123.12.123.12:443>
        ServerName domainname.com
        ServerAlias www.domainname.com
        ServerAdmin [email protected]
        DocumentRoot /var/www/domain/public_html

        SuexecUserGroup www-data www-data
        <Directory /var/www/domain/public_html>
        Options FollowSymLinks
        AllowOverride Indexes AuthConfig Limit FileInfo
        Order allow,deny
        Allow from all

        suPHP_Engine on
        #suPHP_UserGroup www-data www-data
        AddHandler x-httpd-php .php .php3 .php4 .php5
        suPHP_AddHandler x-httpd-php
        </Directory>

        SSLEngine On
        SSLCertificateFile /etc/apache2/ssl/www/www.domain.crt
        SSLCertificateKeyFile /etc/apache2/ssl/www/www.domain.cert.key
</VirtualHost>

If you are wondering whether it is the custom vhost that could be causing it, well, the same 500 server error happens with sites enabled with the ISPConfig control panel with suPHP enabled.

This is the suphp.conf:

Code:

[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=www-data

;Path all scripts have to be in
docroot=/var/www

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=true
allow_file_others_writeable=false
allow_directory_group_writeable=true
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0077

; Minimum UID
min_uid=100

; Minimum GID
min_gid=100


[handlers]
;Handler for php-scripts
x-httpd-suphp=php:"/usr/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Basically what I need is a good solution to securely run PHP for MODx or Joomla with either suPHP or fast-cgi without having to chmod directories to 777 which surely is a security risk. The files and directories in public_html are owned by a apache user with uid/gid 1***/1*** and are also writable by the custom ftp user. I have scoured the forums for users that have had similar issues and tried various things to no avail. I would appreciate any help as this is now the only sticking point with my installation.

 

This is a further relevant error in the log:

Code:

[Mon Jun 01 21:43:40 2009] [error] [client 12.34.123.12] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "x-httpd-php" not found
[Mon Jun 01 21:43:40 2009] [error] [client 12.34.123.12] Premature end of script headers: index.php

 

I didn't realise that the ISPConfig version was already 3.0.1.13 so I decided to reinstall ISPConfig instead and now websites work with suexec, CGI, fastCGI and suPHP as long as the owners of the published files/folders in the web root have the correct GID/UID (e.g. web1 client1).

However, what is the best strategy to create virtual hosts outside of ISPConfig on the same server and avoiding 500 server errors when using suexec, CGI, fastCGI or suPHP? What I mean is how to create a user or under what user to chown files and folders so that errors are avoided.

Also now when I use the vhosts from my previous configuration which were working for the control panel accessible with https://cp.domainname.com and webmail under https://web.domainname.com and *:8080 also accessible in clear text. Now once ISPConfig created default vhosts during install and I copy the custom vhost to /etc/apache2/sites-available and and symlink it to /etc/apache2/sites-enabled and restart Apache the following warning occur:

Code:

Restarting web server: apache2[Tue Jun 02 13:45:14 2009] [warn] VirtualHost 123.12.123.12:443 overlaps with VirtualHost 123.12.123.12:443, the first has precedence, perhaps you need a NameVirtualHost directive
 ... waiting .[Tue Jun 02 13:45:16 2009] [warn] VirtualHost 123.12.123.12:443 overlaps with VirtualHost 123.12.123.12:443, the first has precedence, perhaps you need a NameVirtualHost directive

When I change the virtual host with hostname cp.* to _default_:443 then the webmail virtual host resolves with both cp.* and webmail.* and the control panel is inaccessible under https://cp.domainname.com. In my previous configuration I only had ispconfig.vhost and some custom vhosts symlinked to sites-enabled and an ispconfig.conf file in that folder. Now there is a also default and default-ssl in sites-available. Should I delete them or is there a better or cleaner way of doing it so that the custom virtual hosts work again?

Staying with customisation, where is the best place to put the customised main.tpl.htm, header_logo.png, favicon.ico without having to copy them back each time ISPConfig is updated? One way I have done it is keeping a copy in the same folder with a .bak extension but isn't there a better way? Also some hints on how to customise default error messages in customer websites without obviously having to do it manually each time. Any other useful customisations that will maintain the branding and make the hosting panel look more professionally set up would also be useful.

 

Deleting default and default-ssl within /etc/apache2/sites-available and 000-default from ../sites-enabled does indeed help stop the problem along with setting the IP address in the control panel through System > Server Config > tick Network Configuration > IP address (in my case same IP as cp.* and web.* virtual hosts in DNS). Now the virtual hosts resolve properly with the webmail and control panel working on separate subdomains with ssl.

 

Same problem but other "solution"

I had the same problem discussed in this thread right after fresh install (following the tutorial für Lenny). I could only fix it by setting

Code:

x-httpd-suphp=php:/usr/bin/php-cgi
x-httpd-php=php:/usr/bin/php-cgi

in /etc/suphp/suphp.conf.

Today I updated (via ispconfig_update.sh) to 3.0.1.3 and chose "reconfigure Services". This reset the /etc/suphp/suphp.conf to only enable

Code:

x-httpd-suphp=php:/usr/bin/php-cgi
x-httpd-suphp=php:/usr/bin/php-cgi

(yes, twice). Suphp again only wrote

Code:

[Wed Jun 24 19:52:57 2009] [error] [client 79.229.47.80] SecurityException in Application.cpp:440: Handler not found in configuration
[Wed Jun 24 19:52:57 2009] [error] [client 79.229.47.80] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "x-httpd-php" not found
[Wed Jun 24 19:52:57 2009] [error] [client 79.229.47.80] Premature end of script headers: index.php

to the error-log.

What is the correct content for the /etc/suphp/suphp.conf?

 

Ok, I found out what happened:
I wanted to use suPHP in an ssl-enabled vhost. I found out, that the "http"-part of the vhost is configured correctly, but the "https"-part not. Fortunately enough the source of this difference was easy to find.

In /usr/local/ispconfig/server/conf/vhost.conf.master there are two different blocks.

Here is the one for the "http"-part:

Code:

<tmpl_if name='php' op='==' value='suphp'>
    # suphp enabled
    <Directory {tmpl_var name='web_document_root'}>
        suPHP_Engine on
        # suPHP_UserGroup <tmpl_var name='system_user'> <tmpl_var name='system_group'>
        AddHandler x-httpd-suphp .php .php3 .php4 .php5
        suPHP_AddHandler x-httpd-suphp
    </Directory>
</tmpl_if>

And here the one for the "https"-part:

Code:

<tmpl_if name='php' op='==' value='suphp'>
    # suphp enabled
    suPHP_Engine on
    # suPHP_UserGroup <tmpl_var name='system_user'> <tmpl_var name='system_group'>
    AddHandler x-httpd-php .php .php3 .php4 .php5
    suPHP_AddHandler x-httpd-php
</tmpl_if>

I'll just change the template so that both blocks look the same. I guess that's the way it should look, right?