suPHP causing server 500 errors

Discussion in 'Installation/Configuration' started by djh-compnet, Jun 1, 2009.

  1. djh-compnet

    djh-compnet New Member

    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 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.
            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
            SSLEngine On
            SSLCertificateFile /etc/apache2/ssl/www/www.domain.crt
            SSLCertificateKeyFile /etc/apache2/ssl/www/www.domain.cert.key
    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:
    ;Path to logfile
    ;User Apache is running as
    ;Path all scripts have to be in
    ;Path to chroot() to before executing script
    ; Security options
    ;Check wheter script is within DOCUMENT_ROOT
    ;Send minor error messages to browser
    ;PATH environment variable
    ;Umask to set, specify in octal notation
    ; Minimum UID
    ; Minimum GID
    ;Handler for php-scripts
    ;Handler for CGI-scripts
    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.
  2. djh-compnet

    djh-compnet New Member

    This is a further relevant error in the log:
    [Mon Jun 01 21:43:40 2009] [error] [client] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "x-httpd-php" not found
    [Mon Jun 01 21:43:40 2009] [error] [client] Premature end of script headers: index.php
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    Your suphp configuration files seems to be overwritten or you installed suphp after you installed ispconfig. Please update your ispconfig installation and choose to reconfigure services during update.
  4. djh-compnet

    djh-compnet New Member

    I didn't realise that the ISPConfig version was already 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 and webmail under 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:
    Restarting web server: apache2[Tue Jun 02 13:45:14 2009] [warn] VirtualHost overlaps with VirtualHost, the first has precedence, perhaps you need a NameVirtualHost directive
     ... waiting .[Tue Jun 02 13:45:16 2009] [warn] VirtualHost overlaps with VirtualHost, 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 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.
    Last edited: Jun 2, 2009
  5. djh-compnet

    djh-compnet New Member

    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. :D
  6. Schnacki

    Schnacki New Member

    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
    in /etc/suphp/suphp.conf.

    Today I updated (via to and chose "reconfigure Services". This reset the /etc/suphp/suphp.conf to only enable
    (yes, twice). Suphp again only wrote
    [Wed Jun 24 19:52:57 2009] [error] [client] SecurityException in Application.cpp:440: Handler not found in configuration
    [Wed Jun 24 19:52:57 2009] [error] [client] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "x-httpd-php" not found
    [Wed Jun 24 19:52:57 2009] [error] [client] Premature end of script headers: index.php
    to the error-log.

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

    till Super Moderator Staff Member ISPConfig Developer

    The correct content is just one line:


    you got two lines after the update because you had the wrong second line "x-httpd-php=php:/usr/bin/php-cgi" in that file.
  8. Schnacki

    Schnacki New Member

    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:
    <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
    And here the one for the "https"-part:
    <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
    I'll just change the template so that both blocks look the same. I guess that's the way it should look, right?

Share This Page