Introduction

On this page I will explain in general what solutions are provided for the different requirements

Please read previous Requirements page: http://drupal.org/node/80472

Safe mode

Enabling Safe Mode imposes several restrictions on PHP scripts. These restrictions are mostly concerned with file access, access to environment variables and controlling the execution of external processes.
There are problems which may be encountered when this mechanism is turned on, notably when attempting to work with files owned by different users and files which have been created at runtime by the script (which will be owned by the owner of the web server process).

In Plesk (and most other virtual hosts system) each vhost gets its own owner (FTP user) that is set when files are uploaded to the server. As we want a single code base located in a central place, the owner of the files within that central place will be different then the owner of the files in the vhost's location.

In order to work around these issues, a relaxed form of the file permission checking is also provided by Safe Mode. Using the php.ini directive safe_mode_gid, it is possible to relax the user ID check to a group ID check.
That is, if the script has the same group ID as the file on which a file operation was requested, the operation will succeed. If the script owners and the web server are members of the same group, and all hosted files are owned by this group, the file operations will succeed regardless of user ID.

Thus, we will create a group "drupal" that will cover all drupal related files across vhosts and enable the safe_mode_gid. By doing so we will still have a more secure system then when we would disable the safe mode.

Information taken from here: http://www.acunetix.com/websitesecurity/php-security-5.htm

Open Basedir

Open Basedir limits the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off.

When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.

In Plesk (and most other virtual hosts system) each vhost gets its own open_basedir restriction that restricts the opening of files to the httpdocs directory and the /tmp directory. As we want a single code base located in a central place, that location will not be accepted trough this restriction.

Thus, we will alter the open basedir restriction so that it includes the single code base location. But as we want other applications to be installed within the same vhost, we will add the location only for directories using drupal. 

Plesk integration

The plesk control panel works great as long as you keep the directory structure and security as it is provided by plesk. Therefore we need to merge the single code base and each vhost within the provided structure.

The single code base will be installed as a normal vhost but limiting web access to the domain. As such a backup of the single code base can be scheduled and FTP can be enabled to upload new modules and themes. 
Each vhost will have his own local "sites" directory and will create its database trough the plesk interface.

Managed application

As the single code base resides as a single vhost, we can upgrade the code, add modules and themes into one location. To make upgrading easier we need to make sure that each vhost that uses drupal, references one single point independent of the drupal version.

We will make subdirectories per drupal version in the single code base location and have one single reference that we can switch when going to a new version. 
Thus their will be a symbolic link called "drupal" pointing towards a drupal version "drupal-4.7.3" and each vhost that uses drupal will have symbolic links pointing towards the "drupal" symbolic link. When we change version, we only need to change the "drupal" symbolic link once and all vhosts will be adjusted accordingly.

eAccelerator

The eAccelerator speeds up the execution of the php script by precompiling them and putting them into memory. The disadvantage is that you need to have the memory and the more you have the more php files can be kept for fast execution.
Therefore we need to limit the number of php files on the server.

By using the single code base, every vhosts uses the same files and thus memory usage can be limited and all php scripts run faster. 

more on eAccelerator can be found here: http://eaccelerator.net

Each individual vhost requirements

as noted above in the "Plesk Integration" part, each vhost gets his own "sites" directory that enables them to add their own modules and themes. Also as natively available by drupal, the multisites mechanism will work for the same reason.
Using symbolic links and this "sites" directory will give the user the feeling that it is a full drupal install on their system.

The local "sites" directory will allow the flexibility required 

Navigation

As the book seems to order the sub pages by date, I list here the order of further reading: