By markc on

I've been testing multiple virtual hosts running off a single copy of Drupal to see what are the minimum changes needed to do so. The approach outlined here turns out to be quite simple, mainly because Drupal is so well written in the first place. With my approach, it comes down to essentially moving includes/conf.php to index.php and commenting out the reference to that include in bootstrap.inc, and, providing 4 soft links in the virtual host doc root along with the modified index.php and that's all, run two or 2000 instances of Drupal at different vhosts (or just URLs on the same vhost) and each one can have a separate database, or not. This has not been extensively tested, and certainly not on production servers, but I am excited that it looks to be so simple to do this as I have agonized laboured extensively to do this with other packages over the years (various php-nukes thru to phpBB). The basic layout looks like...

// around line 430 in includes/bootstrap.inc
//include_once "includes/$config.php";

/var/www/drupal-1.vhost.lan ls -l
total 4
lrwxrwxrwx  1 root root   18 Aug 22 13:17 includes -> ../drupal/includes/
-rw-r--r--  1 root root 1428 Aug 22 13:42 index.php
lrwxrwxrwx  1 root root   14 Aug 21 17:41 misc -> ../drupal/misc/
lrwxrwxrwx  1 root root   17 Aug 22 13:17 modules -> ../drupal/modules/
lrwxrwxrwx  1 root root   16 Aug 21 19:45 themes -> ../drupal/themes/

 cat index.php

$db_url    = "mysql://drupal:xxxxx@localhost/drupal";
$db_prefix = "";
$base_url  = (isset($_SERVER['HTTPS']) ? 'https://' : 'http://').
  $_SERVER['HTTP_HOST'].
  ($_SERVER['SERVER_PORT'] == '80' ? '' : ':'.$_SERVER['SERVER_PORT']).
  rtrim(dirname($_SERVER['SCRIPT_NAME']),'/');

// the normal index.php here...

The above is basically it. There were a few minor touchups I had to make in some files and I have not extensively tested all Drupal features as I've only been using Drupal for a few days and still getting used to how it works and reading the docs when I get time. I also am running PHP5 and applied various patches and tweaks myself so the borderline between some multihosting tweaks and various PHP5 tweaks is a little blurry. I'd be really interested to know if anyone else is interested in this kind of thing or has done something similar ?

Comments

torgeirb’s picture

torgeirb commented

You may want to have a look at the multisite configuration issue:

http://drupal.org/node/view/5942

afaik, this hasn't gone into HEAD yet.

markc’s picture

markc commented

Thanks for the heads up. I searched on "multihost" and missed the node you pointed out. However, I'm not that enthused about the multisite approach as it's very invasive and no where near as light weight as my proposal on this page. I specifically set about trying to achieve the ability to run 1000s of instances of Drupal with the absolute minimum of changes to the core code because if I have to maintain a separate codebase, to mainstream Drupal, then the changes had better be very simple. Compared to the mulitsite solution, I think I have achieved that.

For various site to have some uniqness I would simply mandate that their templates get centrally stored within the single codebase OR that the vhost in question maintains their own template/ dir instead of a link to the central codebase. The same for misc/. I would then look into creating a "local.php" override include file in the same vhost folder... if such a file exists then various links, logo images and parts of the system could be altered... perhaps, yet to be proven.

So far my approach is to comment out one single line in the current code and to add a few lines to the beginning of the index.php in each vhost document root along with 4 soft links to the single codebase. This very low impact solution now allows me to provide a complete Drupal administrative instance to every client for an ISP or vhosting company... or mum and dad and the kids... with a 1.5k file (index.php) and 4 extra links in each users webfolder. I can cope with manually commenting out one line in the main codebase if I have to manage upgrades.

My next task is to engage SQLite as the storage backend, instead of MySQL, and I'll be cookin' :-)

My specific goal is to get a PHP5-savvy multihosting CMS based on SQLite as the backend and I suspect many other hosting providers would also be very interested in such a solution. So far, after many years of trying, testing and hacking on various packages, Drupal is da bomb :-)

Steven’s picture

Steven commented

SQLite will result in some problems because it does not support the full spectrum of SQL commands. More specifically, upgrading is very hard (no ALTER TABLE support) and there are some holes in the support for DISTINCT and COUNT() queries.

markc’s picture

markc commented

Thanks for the heads up on SQLite. Yes, it would be quite an invasive set of changes to make Drupal SQLite compatible. It would also take quite a bit of effort to get it to run under Oracle as well. The benefit of using SQLite for multiple users is too great to ignore so I will make the effort on my own working copy of Drupal when I get comfortable enough with the code. The main two benefits are that with a little bit of extra code it's possible to make it so that the SQLite backend can be automatically created and setup if it doesn't already exist in the user or vhosts webdir, and, that any onsite or offsite backups of the users or vhosts webdir automatically includes the database. Exporting that user or vhosts webdir to another Drupal+SQLite server is as simple as making an rsync (or zipfile) and transferring it. These two points could make using SQLite somewhat of a holy grail for hosting providers, on top of an effective multihosting scheme. No other SQL solution offers these two benefits as easily so SQLite has to become an option for me or otherwise I simply can't use Drupal in the longer term.

ti’s picture

ti commented

I like this. Thanks markc for giving a lighter weight alternative. If I may ask, which version of Drupal did you use? Drupal 4.4 or the CVS? Will you keep looking into this issue for newer versions too?

markc’s picture

markc commented

Glad you like it, please let me know if you try it out. My testing was done with CVS but it's so simple I would imagine it could work with any of the v4.* series. As far as maintainance goes, again, it's such a simple hack that I can imagine it will work for some time to come yet. I am personally going to start more extensive PHP5 hacks on my own copy of CVS HEAD which I'm imported into a local subversion server so I will probably not track Drupal directly in the future.

sepeck’s picture

sepeck commented

Any idea on if this would run on a Windows IIS server?

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

markc’s picture

markc commented

I understand there is an equivalent mechanism under windows for "aliases" as on linux. I don't know the exact details and a few minutes of googling did not provide me with a decent answer. I do suspect the same methodology will work under IIS though, worth a try if you can work out how to create aliases (shadow files?). Perhaps leave a note here if you have any success :-)

jsloan’s picture

jsloan commented

Here is a very good article concerning this issue: Windows Symbolic and Hard Links

Here is the M$ KB article: How to create and manipulate NTFS junction points

My first attempts to use this on my test servers failed... I'll try again later.

linulo’s picture

linulo commented

This hack seems to have become obsolete with Drupal 4.7.x (or even earlier, I don't know). Hosting multiple Drupal sites off the same codebase now is a built-in feature requiring no more than a directory within the sites-Directory and a settings file within that directory.

mike stewart’s picture

mike stewart commented

Would someone in the know, confirm if this is correct? (Obsolete Hack)

jbrauer’s picture

jbrauer commented

See the Handbook section on multi-site for the way to do this natively now.

------------------------------
Adding Understanding

--

jsloan’s picture

jsloan commented

For those of us who must work on Windows servers because of corporate policy the symbolic link was never an option. The multihosting features introduced in 4.6 was the solution. See this post on how I host mutiple directories under a single domain with clean URL's.

markc’s picture

markc commented

The same result as soft links can be achieved by using apaches Alias ability.

Alias                  /misc/          /path/to/drupal/misc/
Alias                  /themes/        /path/to/drupal/themes/
Alias                  /modules/       /path/to/drupal/modules/

For .4.7.2 I copy the settings.php file to /var/www/www.domain.com/.ht_drupal.php (the .ht* name denies direct viewing access, by default in Debians apache config anyway) and add/change these lines below in includes/bootstrap.inc. All I do is edit the .ht_drupal.php file and and add the very simple index.php example below and this gives me an ultra-lightweight multihosting system off a single codebase.

includes/bootstrap.inc

@@ -113,6 +111,9 @@
function conf_path() {
  static $conf = '';

  if ($conf) {
     return $conf;
   }

+  $conf = '/var/www/'.$_SERVER['HTTP_HOST'];
+  return $conf;

@@ -153,7 +154,8 @@
 function conf_init() {
   global $db_url, $db_prefix, $base_url, $base_path, $base_root, $conf;
   $conf = array();
-  require_once './'. conf_path() .'/settings.php';
+  require_once conf_path() .'/.ht_drupal.php';

/var/www/www.domain.com/index.php


define('INC', '/path/to/drupal/');
ini_set('include_path', INC);
chdir(INC);
require INC.'index.php';