We are running several virtualhosts using moodle with the same codebase, and a slightly hacked config file. I think I posted it some time in the past, but I can't find the original with the explanation.

We run the virtual hosts all like foo.lms.eduforge.org and bar.lms.eduforge.org so the config file uses foo_ (and bar_) as table prefixes, and as the data directory.

Two things to bear in mind:
- you need to run your cron with extra params
- you'll have to split codebases if you want to upgrade them separately

Warning: big fat (complex?) config files follow:

- moodle's config.php

- our cron invocation

- our apache virtualhost/alias config


This is my config.php:

<?PHP // $Id: config-dist.php,v 1.54 2004/05/03 14:57:11 moodler Exp $

/// EDUFORGE MOODLE LMS SETUP --- YOUR ATTENTION PLEASE!!!!
///
/// This config file supports many moodle instances from one directory
/// and one config file.
///
/// We'll get the virtualhost prefix (foo in foo.lms.eduforge.org) and use that
/// to define:
/// - DB table prefix
/// - VAR directory: /home/lms/var/$prefix/
/// - Optional config override file: you can override any config value by creating
///  a config_$prefix.php file. Be cautious, however!

// Obtain and sanitize prefix
$eduforge_prefix = $_SERVER['HTTP_HOST'];
if (isset($_ENV['HTTP_HOST'])){ // this is to support cronjobs on a per-host basis
$eduforge_prefix = $_ENV['HTTP_HOST'];
}
$eduforge_prefix = explode('.', $eduforge_prefix);
$eduforge_prefix = $eduforge_prefix[0];
$eduforge_prefix = preg_replace("/\W/", "", $eduforge_prefix);

// if there wasn't a prefix redirect to eduforge
if($eduforge_prefix == 'lms' || $eduforge_prefix=='') { //
header("Location: http://eduforge.org/");
exit;
}

///////////////////////////////////////////////////////////////////////////
//                                                                      //
// Moodle configuration file                                            //
//                                                                      //
// This file should be renamed "config.php" in the top-level directory  //
//                                                                      //
///////////////////////////////////////////////////////////////////////////
//                                                                      //
// NOTICE OF COPYRIGHT                                                  //
//                                                                      //
// Moodle - Modular Object-Oriented Dynamic Learning Environment        //
//          http://moodle.org                                            //
//                                                                      //
// Copyright (C) 1999-2004  Martin Dougiamas  http://dougiamas.com      //
//                                                                      //
// This program is free software; you can redistribute it and/or modify  //
// it under the terms of the GNU General Public License as published by  //
// the Free Software Foundation; either version 2 of the License, or    //
// (at your option) any later version.                                  //
//                                                                      //
// This program is distributed in the hope that it will be useful,      //
// but WITHOUT ANY WARRANTY; without even the implied warranty of        //
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the        //
// GNU General Public License for more details:                          //
//                                                                      //
//          http://www.gnu.org/copyleft/gpl.html                        //
//                                                                      //
///////////////////////////////////////////////////////////////////////////
unset($CFG);  // Ignore this line

//=========================================================================
// 1. DATABASE SETUP
//=========================================================================
// First, you need to configure the database where all Moodle data      //
// will be stored.  This database must already have been created        //
// and a username/password created to access it.                        //
//                                                                      //
//  mysql      - the prefix is optional, but useful when installing    //
//                into databases that already contain tables.            //
//
//  postgres7  - the prefix is REQUIRED, regardless of whether the      //
//                database already contains tables.                      //
//                                                                      //
// A special case exists when using PostgreSQL databases via sockets.    //
// Define dbhost as follows, leaving dbname, dbuser, dbpass BLANK!:      //
//    $CFG->dbhost = " user='muser' password='mpass' dbname='mdata'";    //
//               




$CFG->dbtype    = 'postgres7';      // mysql or postgres7 (for now)
$CFG->dbhost    = 'XXXX';  // eg localhost or db.isp.com
$CFG->dbname    = 'XXXX';      // database name, eg moodle
$CFG->dbuser    = 'XXXX';    // your database username
$CFG->dbpass    = 'XXXX';    // your database password
$CFG->prefix    = $eduforge_prefix . '_';        // Prefix to use for all table names

$CFG->dbpersist = true;        // Should database connections be reused?
                                // "false" is the most stable setting
                                // "true" can improve performance sometimes


//=========================================================================
// 2. WEB SITE LOCATION
//=========================================================================
// Now you need to tell Moodle where it is located. Specify the full
// web address to where moodle has been installed.  If your web site
// is accessible via multiple URLs then choose the most natural one
// that your students would use.  Do not include a trailing slash

$CFG->wwwroot  = 'http://' . $eduforge_prefix . '.lms.eduforge.org';


//=========================================================================
// 3. SERVER FILES LOCATION
//=========================================================================
// Next, specify the full OS directory path to this same location
// Make sure the upper/lower case is correct.  Some examples:
//
//    $CFG->dirroot = 'c:\FoxServ\www\moodle';    // Windows
//    $CFG->dirroot = '/var/www/html/moodle';    // Redhat Linux
//    $CFG->dirroot = '/home/example/www/moodle'; // Cpanel host

$CFG->dirroot  = '/home/lms/htdocs';


//=========================================================================
// 4. DATA FILES LOCATION
//=========================================================================
// Now you need a place where Moodle can save uploaded files.  This
// directory should be readable AND WRITEABLE by the web server user
// (usually 'nobody' or 'apache'), but it should not be accessible
// directly via the web.
//
// - On hosting systems you might need to make sure that your "group" has
//  no permissions at all, but that "others" have full permissions.
//
// - On Windows systems you might specify something like 'c:\moodledata'

$CFG->dataroot  = '/home/lms/var/' . $eduforge_prefix;


//=========================================================================
// 5. DATA FILES PERMISSIONS
//=========================================================================
// The following parameter sets the permissions of new directories
// created by Moodle within the data directory.  The format is in
// octal format (as used by the Unix utility chmod, for example).
// The default is usually OK, but you may want to change it to 0750
// if you are concerned about world-access to the files (you will need
// to make sure the web server process (eg Apache) can access the files.
// NOTE: the prefixed 0 is important, and don't use quotes.

$CFG->directorypermissions = 0777;


//=========================================================================
// 6. DIRECTORY LOCATION  (most people can just ignore this setting)
//=========================================================================
// A very few webhosts use /admin as a special URL for you to access a
// control panel or something.  Unfortunately this conflicts with the
// standard location for the Moodle admin pages.  You can fix this by
// renaming the admin directory in your installation, and putting that
// new name here.  eg "moodleadmin".  This will fix admin links in Moodle.

$CFG->admin = 'admin';


//=========================================================================
// 7. OTHER MISCELLANEOUS SETTINGS (ignore these for new installations)
//=========================================================================
//
// Prevent users from updating their profile images
//      $CFG->disableuserimages = true; 
//
// Prevent scheduled backups from operating (and hide the GUI for them)
// Useful for webhost operators who have alternate methods of backups
//      $CFG->disablescheduledbackups = true;
//
// Restrict certain usernames from doing things that may mess up a site
// This is especially useful for demonstration teacher accounts
//      $CFG->restrictusers = 'teacher,fred,jim';
//
// Turning this on will make Moodle filter more than usual, including
// forum subjects, activity names and so on (in ADDITION to the normal
// texts like forum postings, journals etc).  This is mostly only useful
// when using the multilang filter.  This feature may not be complete.
//      $CFG->filterall = true;
//
// Setting this to true will enable admins to edit any post at any time
//      $CFG->admineditalways = true;
//
// Setting this to true will force a non-guest login to see the user pages
// eg the teachers linked from course descriptions or site news
//      $CFG->forceloginforprofiles
//
// This setting will put Moodle in Unicode mode.  It's very new and
// most likely doesn't work yet.  THIS IS FOR DEVELOPERS ONLY, IT IS
// NOT RECOMMENDED FOR PRODUCTION SITES
//      $CFG->unicode = true;


//=========================================================================
// ALL DONE!  To continue installation, visit your main page with a browser
//=========================================================================

// Allow file overrides for eduforge
if (file_exists("$CFG->dirroot/config_" . $eduforge_prefix . ".php"))  {      // Do not edit
include_once("$CFG->dirroot/config_" . $eduforge_prefix . ".php");
}

if (file_exists("$CFG->dirroot/lib/setup.php"))  {      // Do not edit
    include_once("$CFG->dirroot/lib/setup.php");
} else {
    if ($CFG->dirroot == dirname(__FILE__)) {
        echo "<p>Could not find this file: $CFG->dirroot/lib/setup.php</p>";
        echo "<p>Are you sure all your files have been uploaded?</p>";
    } else {
        echo "<p>Error detected in config.php</p>";
        echo "<p>Error in: \$CFG->dirroot = '$CFG->dirroot';</p>";
        echo "<p>Try this: \$CFG->dirroot = '".dirname(__FILE__)."';</p>";
    }
    die;
}
// MAKE SURE WHEN YOU EDIT THIS FILE THAT THERE ARE NO SPACES, BLANK LINES,
// RETURNS, OR ANYTHING ELSE AFTER THE TWO CHARACTERS ON THE NEXT LINE.
?>

And this is how I run cron (from /etc/cron.d/lms_eduforge) -- it guesses the virtualhosts (which are actually aliases on one vhost):
## Every five minutes, scan 050_lms_eduforge_org.conf, figure out what are the relevant virtualhosts, and run admin/cron.php for each.
## the log is saved in /home/lms/var/cron.log with good timestamps.
*/5 * * * *    www-data        ( echo [`date`] Running admin/cron.php for all LMS instances ; /usr/bin/nice /usr/bin/perl -ne 'm/^\s*ServerAlias (\w+.lms.eduforge.org)\W/i &&  print "$1\n"'  /etc/apache/conf.d/050_lms_eduforge_org.conf  | /usr/bin/xargs --verbose -l -iVHOST /bin/bash -c "cd /home/lms/htdocs/admin/; HTTP_HOST=VHOST /usr/bin/php /home/lms/htdocs/admin/cron.php" 2>&1 )  >> /home/lms/var/cron.log

And this is the vhost entry, which is included in apache's config

<VirtualHost *:80>
        ServerName lms.eduforge.org

        # Add one ServerAlias entry per hosted LMS
        # The server alias is expected to take the form of
        # $prefix.lms.eduforge.org
        # The config file /home/lms/htdocs/config.php
        # overrides values on a per-serveralias basis,
        # the overrides must be placed in /home/lms/htdocs/config_$prefix.php
        # martin@catalyst.net.nz
        ServerAlias nmit.lms.eduforge.org
        # SEPARATE CODEBASE FOR OP # ServerAlias op.lms.eduforge.org
        ServerAlias tpp.lms.eduforge.org
        ServerAlias ucol.lms.eduforge.org
        #NEWALIAS#

        ## After you have added the ServerAlias, create dir /home/lms/var/$prefix
        ## owned by www-data.www-data . After that, you should be able to
        ## hit http://$prefix.lms.eduforge.org/ and complete the process
        ##
        ## If you want a special template, go to /home/lms/htdoc/theme/ ,
        ## and clone/modify an existing theme. It's simple.
        ##
        ## Cronjobs for all instaces of Moodle from this file
        ## are handled by /etc/cron.d/lms_eduforge_org
        ## DO NOT RENAME THIS FILE OR CHANGE THE STYLE OF IT
        ## WITHOUT CHECKING THE CRONJOB
        ##
        ## martin@catalyst.net.nz

        DocumentRoot /home/lms/htdocs
        CustomLog /var/log/apache/lms_access.log full
        ErrorLog  /var/log/apache/lms_error.log

        DirectoryIndex index.php index.html index.htm

        # nail down the PHP settings Moodle wants
        php_value magic_quotes_gpc        1 
        php_value magic_quotes_runtime    0
        php_value file_uploads            1
        php_value session.auto_start      0
        php_value session.bug_compat_warn  0

        # Apache and PHP settings for Uploads
        LimitRequestBody 0
        php_value upload_max_filesize 8M
        php_value post_max_size      8M
</VirtualHost>

Anybody have success running the Moodle Chat Daemon under this type of multiple installations?  Everything else in my duplicated Moodle installations works fine, but I'm trying to figure out what to do to mod/chat/chatd.php as it loads a dummy config file.  Any thoughts?

Hello,
I am wondering if there is a way to have the same SCORM content, or other resource, available for multiple Moodle instances with no need of duplication.
This could be helpful not only for hard disk space economy but for content update purposes (if I want to install a new version of SCORM material I would prefer to do it once).
Thanks in advance, and excuse me if the answer is obvious (I am a moodle newcomer).

We run multiple instances on both a (single) Moodle 1.7 and 2.1 codebase. We call these instances by separate hostnames. The only thing we need to change in the code is create a switch-statement on the hostname in the root config.php file, and put everything that is instance-dependant (such as $CFG->dbname and $CFG->dataroot which are basically the only two values that need to change) within a host-case. In this way each instance has their own database and datadirectory, so this provides a real clean way of separating instances and minimal code-changes.

To prepare for this hostname-switch-construction you need to move all the hostname dependant code within the switch statement:

...
switch ($_SERVER['HTTP_HOST']) {
    case 'instance1.yourdomain.com':
        $CFG->dbname = '...';
        $CFG->dataroot = '...';
        // and what else you want to configure here
        // ...
        break;
    case 'instance2.yourdomain.com':
        $CFG->dbname = '...';
        $CFG->dataroot = '...';
        // and what else you want to configure here
        // ...
        break;
    case 'some.completelyother.org':
        $CFG->dbname = '...';
        $CFG->dataroot = '...';
        // and what else you want to configure here
        // ...
        break;
    default:
        die('domain not configured in config.php');
}
...

The above example is for live environments, for (local) development you probably use a different config file.

Creating a new (live) instance (at least in Moodle 2.1) comes down to this (assuming you have a (sub)domain configured):

- make a new case for this (sub)domain
- create a database (with the same host and username as the other instance-databases) and new datadirectory and configure these in the new case

Upon calling this new (sub)domain (remember: the database and datadirectory are still completely empty) this database and datadirectory will be (seem to be) populated automagically. Installation of new instance: done!

Anyone got any ideas on why I can log into one instance of Moodle, but the other one says I don't have cookies enabled on my browser?  I'm using different subdomains 2 sites.

WARNING:

Running multiple instances of Moodle from a single copy of code sounds neat, but depending on your situation, it may cause more problems than it solves.  You should be aware of the implications of sharing the same copy of code, such as:

• all instances will need to be upgraded at the same time: Upgrading (especially from one major version to another) can be a very long process.
  • Dumping the new code onto the server, and hitting the upgrade button can take quite a while.  Once you dump in the new code, sites may not work properly until they are upgraded.  Are you sure you want to upgrade 50 sites at the same time?
  • Even before you dump the new node onto the server, upgrading requires investigation work, making sure that the upgrade won't break anything.  This may take a lot of time.  If you share one copy of the code, that means that you'll have to do this investigative work on all of your sites before any of them can be upgraded.
  • Upgrading also means that you need to make sure that all the plugins that you use are compatible with the new version, and that Moodle's behaviour hasn't changed in ways that break the way you are using it.  If, say, you have one site that uses a certain plugin that isn't compatible with the new version, but none of your other sites use that plugin, are you willing to hold off on upgrading the other sites until that one plugin is upgraded?  Or can you tell that one site: "tough luck, you'll have to do without the plugin"?
• using a single copy of the code means, well, the code is the same.  If site1 needs a plugin, but site2 doesn't want (or breaks, or will be too slow) the plugin, what do you do?

You probably do not want to use a single copy of code if:

• you are providing commercial support
• have more than a handful of sites
• your sites have very different needs
• your sites are intended to be available long-term