1

I have a vps, running directadmin with apache 2 and php 5. It all worked fine, until today, since i discovered that PHP scripts are executed under apache:apache, and not under file's owner uid. This screwed up the entire system, but the main problem is that I can't figure out WHY would suphp stop working suddenly??

Some info:

root # php -v
PHP 5.2.17 (cli) (built: Aug 17 2011 21:02:28)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

httpd.conf

User apache
Group apache
...
<Directory "/var/www/html">
    Options -Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
   <IfModule mod_suphp.c>
        suPHP_Engine On
        suPHP_UserGroup webapps webapps
    SetEnv PHP_INI_SCAN_DIR
   </IfModule>
</Directory>


<VirtualHost 192.168.56.55:80 >
        ...
    SuexecUserGroup robert robert
        ...
        <Directory /home/robert/domains/testing.com/public_html>
        Options +Includes -Indexes

        php_admin_flag engine ON
    </Directory>
</VirtualHost>

extra/httpd-php-handlers.conf

<FilesMatch "\.(inc|php|php3|php4|php5|php6|phtml|phps)$">
AddHandler application/x-httpd-php .inc .php .php3 .php4 .php5 .phtml
AddHandler application/x-httpd-php-source .phps
</FilesMatch>

Whenever I run phpinfo() inside /var/www/html, or home/robert/domains/testing.com/public_html (with the file owner robert:robert), the result is the same: User/Group apache(48)/48

How can i solve this?

  • and suphp log is empty :(
2

suPHP is likely not installed.

Since you are using conditional load statements, suPHP may have been removed on an Apache upgrade.

I don't work on DirectAdmin boxes any longer, but I know they used to be problematic with overwriting custom configurations.

  1. Confirm that suPHP is indeed installed in Apache. Use:

    httpd -l

to list built-in apache modules. Or look for a Load statement in your configuration. A quick ways to test is to comment the conditional load statements and then try to restart Apache.

  1. Assure that suPHP is enabled on the domain and that the user/group specs are correct in the httpd configuration. (What you posted looks good.)

  2. Once suPHP is enabled, you can likely just chown the directory to the correct user.

| improve this answer | |
  • httpd -l shows mod_suexec.c. It was all working fine until yesterday. – develroot Jan 5 '12 at 10:15
0

Honestly, (from an admin's standpoint) suphp is a bad idea and dangerous. Doubly so on a shared system. That being said... are you sure suphp is being loaded? You have a nicely formated statement that would completely be ignored if the module failed to load or was missing.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.