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 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 webmaster@domainname.com
            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.
     
  2. djh-compnet

    djh-compnet New Member

    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
    
     
  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 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.
     
    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
    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?
     
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    The correct content is just one line:

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

    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:
    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?
     

Share This Page