Canfield Research Group

I found myself needing to host a number of Drupal sites, all low volume, and having just one system available. Drupal can be configured in the following major ways (there are many others, but these are the common ones):

1. Dedicated : One site per system (or virtualized system). This is the bets way to isolate Drupal sites but has a number of performance and resource needs not the least is keeping every system updated and tuned.
2. VHOST : Multiple sites per system using Apache virtual named hosts (or IP). Less secure than the above but shares a single OS while keeping each Drupal instance somewhat isolated. If you grant PHP access to your users it is trivial for them to access the other sites. This method is less resource intensive than the first but more so than using Drupals multi-host configuration.

1. Multi-Host : Multiple sites shared under a single Drupal code base. This is the most efficient method since any PHP code caching, file caching, etc. is shared among all sites. This configuration usually uses Apache virtual named hosting as well. I always use per-site dedicated database whenever possible, it makes it much easier to customize and migrate the site,

This table summarizes the pros and cons (simplified) as compare dot each other. The PHP Eval column indicates if you should enable PHP evaluation in Drupal nodes. blocks, etc. Note that with an unmodified Drupal the only effective way to do that is to without the admin account. If PHP Eval is enabled then it is trivial for users to access configuration settings, including databases, of other users or even access and modify code. All a bit dangerous to a shared environment.

I had 7 low usage sites, demos and experimental, that needed to be configured. Of these 3 were sites that were under active development and could possible have modules or even core patches applied, I called these my Demo sites. The Demo sites are pretty much under my immediate staff’s control who in this case are trusted. So I choose VHOST, it allows separate code base.

The other 4 systems were for users to get acquainted with Drupal before a roll out. Let’s call these user systems. These sites were all the same code base (with different modules enabled) so the Multi-Host configuration works very well. I created an admin user on each system and the created an applicable user for content authoring granting them RW to most elements. Selecting the permissions and such is tedious, but once done can be automated with a custom profile.

So now I have 7 systems all running pretty well in a single OS. But there are some problems with this configuration:

• I have to remember admin passwords for 7 systems or use the same admin for all. Both are poor solutions to me.

• The user systems cannot have an admin account making it harder to configure elements that would be useful, such as input filters, module activation,and other settings.

A solution to the above required some minor hacks to the Drupal core and the use of an Apache proxy server.