As part of my learning more about web hosting, I have a VPS that hosts a testing area for this site and I also host a couple of virtual hosts for other people. One of the side effects of the standard server setup that I have been using is that in WordPress, whenever I want to upgrade or install anything, I have to type in my FTP password to give WordPress the privileges to modify files. This doesn’t happen on the hosted server that I currently use for the live site.

I know what the cause of this password requirement is; because the files and directories that make up wordpress are not owned by the the same user that the web server (apache) runs as, the web server has no authority to make changes in those directories. The files are owned by my user ($username) on the system, but apache runs as www-data.

Obviously, the simplest way of sorting this out is just to change the owner of the files to be the same as the apache user, but this is not good practice. It means that the contents of the files can be read and written-to by apache, but it also means that the files can be read-from and written-to by any apache process. This means that any user’s scripts on the system will have access to any other user’s web files through apache. Not too much of a problem if there’s only one user or virtual host, but with more than one, it’s not a great idea.

The other option then is to run php scripts as the user who owns them. Not quite as simple as changing the file owner, but then I’m not the first person to have come to this. There are a number of modules that will alter the owner of the php process based on the owner of the script file, I’ve gone for suPHP.

As it turns out after an hour or so of searching, the process is pretty straight forward, everything is included as part of Ubuntu’s packages. In fact it took less time to implement than it did to research…

Install suphp libraries:

  • sudo apt-get install libapache2-mod-suphp

which will also install suphp-common.

Deactivate the current php module in apache:

  • sudo a2dismod php5

mod_suphp replaces mod_php, and passes the php scripts from apache to the installed php-cgi and back, so having both activated means suPHP won’t do what you expect. mod_suphp should be enabled in in apache by apt, but if it’s not, just enable it with a2enmod suphp.

Then restart apache:

  • sudo /etc/init.d/apache2 restart

The settings for suPHP are in /etc/suphp/suphp.conf, and if there are any problems, the logfile is /var/log/suphp/suphp.log.

Troubleshooting

As soon as I activated suPHP and restarted apache, the first thing that happened was a wordpress installation went offline, and gave nothing but “Internal Server Error 500” messages. It turns out, that suPHP is supposed to do that; the problem was just that I’d been messing about with file and folder permissions.

In particular, you’ll see this error for one of two main reasons:

  • The file/folder permissions are too permissive.

Files must be 644 or lower and folders 755 or lower, or suPHP will refuse to parse the script. This is sensible, it stops users from overexposing their files unintentionally. So suPHP won’t run your php scripts if you allow write permission to group or all.

  • The file is owned by the apache user.

If the whole point of using suPHP is to separate apache user based on file user, setting files owned by www-data is a step backwards, so by default, the script owner must have a uid higher than 100 for suPHP to accept it. This will mean that www-data owned files in the default host may stop working, so you might need to adjust min_gid in /etc/suphp/suphp.conf from 100 to 33. Obviously this shouldn’t be a problem if you only have virtual hosts.

So, if like me, you’ve been playing with the owner and permissions to try and get WordPress to update happily with mod_php, you’ll need to reset them before mod_suPHP will show your site.

Troubleshooting Update

Adding suPHP on my home development server also managed to kill off phpmyadmin. This is installed by apt on ubuntu, and lives in the /usr/share directory under the ownership of root. suPHP wont run it because of owner, but also, the suphp.conf file containes a specific exeption for files in /usr/share, so it wont run any php scripts in there anyway.

To get around this I reactivated mod_php (a2enmod php5) and restricted it to only parse php files from /usr/share by having only the following in /etc/apache2/mods-available/php5.conf:

<code class="block"><IfModule mod_php5.c>
    <Directory /usr/share/>
	<FilesMatch "\.ph(p3?|tml)$">
            SetHandler application/x-httpd-php
	</FilesMatch>
	<FilesMatch "\.phps$">
            SetHandler application/x-httpd-php-source
	</FilesMatch>
    </Directory>
</IfModule></code>

This means the phpmyadmin will now run, with one small problem. Browsing to the folder address (server_name/phpmyadmin/) does not work, I just get offered a download of index.php, but browsing to server_name/phpmyadmin/index.php works just fine. I have no idea why that is though!

Sources:

www.chrisabernethy.com/why-wordpress-asks-connection-info/ library.linode.com/web-applications/control-panels/ispconfig/ubuntu-10.04-lucid www.debiantutorials.com/installing-suphp/ www.rickogden.com/2010/01/suphp-userdir-on-ubuntu/ update: serverfault.com/questions/211935/running-phpmyadmin-and-suphp