On our main server, we run most of our clients' sites. These are small sites with not too much traffic, and being "extended business cards", they don't need too many resources. So, we host them on one server.
Now there's two options on how to run PHP: as an apache module, or as a FastCGI application. Which one did we choose, and why?
We use Plesk to administer our clients, so we can specify this option per domain and even subdomain, but we keep it on one setting: FastCGI. Now one might ask: Where is the difference performance-wise?
A site of the Plesk-docs wraps it up fairly well: While the apache module performs best, the FastCGI application has one major advantage: The PHP scripts are not run as the same user (apache) for every client, but on behalf of the client's dedicated system user. If our number one concern was performance, and we had only one client on the server, we'd definitely go for the apache module, but we do not want to risk making all clients' files editable by another client's dubiously downloaded Drupal module. Really not.
FastCGI and the PHP session path issue
When you run PHP as a FastCGI application, the server runs as the dedicated system user you've assigned to the webspace. The default session directory, /var/lib/php/session, is only writeable by apache, though. Thus, it is not usable in FastCGI mode and some systems can't handle sessions and logins without it.
You could solve the problem by changing this folder's group to psacln, a group containing all users apache can run with, but let's think further: We chose FastCGI for a reason. If every website should run as their own user, why should they be able to read another site's session files? Let's create a dedicated session directory for every webspace.
A dedicated session directory
For every webspace you run PHP as a CGI application with, create a php_sess directory in the private directory of its main domain, then chmod 700 it (Do all of this as the webspace's dedicated user, or you will have to chown it as well).
Now go to every domain and subdomain of that webspace, and change its session.save_path to /var/www/vhosts/themaindomain.com/private/php_sess
Voilà, you have working sessions again.
As always, if you have questions, suggestions or a better approach, please comment. I appreciate it.
