Experiments with Moodle multi-tenancy

Multi SitesWe should see native support for multi-tenancy in Moodle 2.3 which is due out in June and I’m keen to see how this will work. UPDATE 19/03: thanks to Gavin Henrick and Tim Hunt who pointed out that this feature was dropped from the Moodle 2.3 roadmap last month. I have removed a few references this release below.

A few months ago I came across this excellent post over on Dan Poltawski’s blog:  Multi-tenant Moodle without the 2.2 feature where he expands on the multi-tenancy Moodle setup they have at LUNS which scales to over 1,000 Moodle sites from a single codebase. I think this method will be hard to beat but we shall see with the release of 2.3.

I’ve been meaning to have a play with Dan’s setup for a while and never got round to it, but one our lovely Systems lads at Epic kindly had a go and we got this working, with some tweaks to the setup which we had to work out for ourselves. So if you’re interested, here’s what we did. Thanks ever so much to the brilliant Steve Avey for getting this working!

Apache setup

Each Moodle needs its own apache vHost entry for the domain name but the DocumentRoot is the same for both sites:

#

# Site 1

#

<VirtualHost *:80>

ServerAdmin [your Moodle Admin email address here]

DocumentRoot “D:/apache_root/multi_tenant_test” [your Moodle codebase location]

ServerName multisite1.domain.com [site domain name]

ErrorLog “logs/multisite1.domain.com-error.log”

CustomLog “logs/multisite1.domain.com-access.log” common

</VirtualHost>

#

# Site 2

#

<VirtualHost *:80>

ServerAdmin [your Moodle Admin email address here]

DocumentRoot “D:/apache_root/multi_tenant_test” [your Moodle codebase location]

ServerName multisite2.domain.com [site2 domain name]

ErrorLog “logs/multisite2.domain.com-error.log”

CustomLog “logs/multisite2.domain.com-access.log” common

</VirtualHost>

Moodle setup

Setup and install a default moodle on the first domain name as per a normal single site setup. You then need to change config.php to be:

<?php  // Moodle configuration file

$moodle_host = $_SERVER[‘HTTP_HOST’];

require_once(‘/etc/moodles/’.$moodle_host.’_config.php’);

You now need to create an /etc/moodles folder which will hold the individual config.php’s for each site. These need to be named in the ‘domainname_config.php’ format and must have some extra variables set to work, we had to add the following to each multi site config.php:

$CFG->dirroot   = ‘D:/apache_root/multi_tenant_test’;

require_once(“$CFG->dirroot/lib/setup.php”);

Using the above method we now have 1 moodle codebase using 2 separate databases & moodledata folders. Moodle 2.3, bring it on!

Facebook Twitter Linkedin

12 Replies to “Experiments with Moodle multi-tenancy”

  1. Thanks Tim, I appreciate the notification. I gather it was discussed at the developer meeting in Feb, that’ll teach me to miss them! And thanks Dan too, I’ll check both those out 🙂

  2. Many years ago I worked at a place that ran Moodle like this (from a single codebase) for 100s of sites- problems were that all users had to have the same plug-in set, code changes, be upgraded at the same time. There were complaints about that. Of course Salesforce runs like this for most customers, but I think that many people see Moodle as an app that can be customized via plug-in choices and Educational institutions particularly are often concerned about managing the time/date of their upgrades.

    With modern code management via a SCM (git/svn, etc.) and code taking only a tiny amount of space on most sites, the benefits of a single codebase seem to weigh about as much as the drawbacks, IMO.

  3. Hi Michael,

    Some really valid points you raise there. I believe that LUNS and ULCC run this sort of multi-tenant model at large scale and it certainly places constraints on users in terms of upgrade times and customisation opportunities. But the fact they have hundreds or even thousands of users would imply that while multi-tenanting certainly offers less freedom, the value for money that the MT model can offer is pretty compelling. I’ve also heard customers of MT providers complain about the lack of freedom they have, however they like the expert support and the value they get and so are happy to stay.

    For those who place higher value on freedom, they’ll always need to get their own installation.

    I suspect the MT services are predominantly used by small and medium sized orgs of say under 5K users. Was that your experience with your previous employer?

    Great point about SCM. I’ve been spending some time working with Flavours too, and I think between SCM, Flavours and Multi-tenanting there are some really interesting options for running multi-site environments. I am hoping for some interesting discussions at next month’s UK Moot on this area, a number of sessions on MT and Flavours (including mine!) were approved so it’s clearly a popular topic.

  4. Hi Mark,

    This Apache/config.php solution achieves mapping multiple domains (e.g. tennant1.myhost.com, tennant2.myhost.com etc.) to the same Apache Document Root containing the same Moodle codebase, and for each Moodle to retain its own config.php defining its own database and moodledata directory. However, it doesn’t address key MT requirements we’re typically asked about.

    A common requirement is the need for courseware to be shared across all tennants, yet for each tennant to appear to be self-contained and not be able to access any other tennant’s data. Another common requirement is for a central/head office to be able to report out on all tennant’s data in a single report and to manage each tennant centrally.

    To meet these requirements, all tennants need to be using the same database (not separate databases, as in this solution) and that single database needs to be data-segregated such that each tennant appears self-contained to all other tennants. This can’t be achieved with Apache and Moodle config alone; code changes to the Moodle codebase are required.

  5. Hi Mike,
    Thanks for replying, very good points. Alex Buchner from Synergy did a MT presentation at MoodleMoot last week which explored this, he pointed to a range of use cases such as whether a MT setup requires central user admin and reporting, content sharing and others, and the impact this has on the MT architecture that then gets implemented. All the PPTs will be up on Slideshare within the next few weeks so I’ll post it up here when it’s online, it was a really useful primer of questions to ask when considering a MT solution.
    Cheers,
    Mark

    1. Hi Mark and others,

      I’m wondering a couple of things about the single code-base / multi-config approach that I do not see anyone discussing:

      1) The cron function is essential for many moodle functions, and it would seem that each “site” instance would need to have a separate cron job run using that instance’s own config.php settings.. How has this been handled, especially considering that running the cron from CLI is not affected by, or concerned with, or triggered by the various host names used to trigger different instances — so it would seem that the CLI cron approach would not be able to make use of PHP host id statements to handle all the instances?

      2) Why did you find that the extra dirroot and setup,php statements (mentioned in your post) were necessary?

      3) In the Buchner white paper, there are a number of “cons” listed for this “distributed” (singel codebase) approach, that seem to imply a lot of admin / mgt settings are somehow shared (like user mgt). But, if separate DBs and dataroots are setup for each instance, wouldn’t virtually all admin/plugin settings and user data/settings be independent (aside from the existence of things like physical plugin /theme files that of course would be shared/visible to by all as part of the common codebase)?

      Thanks in advance for any insights on these points.

      Doug R

  6. So… I don’t mean to resurrect an old thread… but is this now a dead feature that will never come to light?

    It would be nice if it was a native feature in new moodle versions.

  7. A suite of plugins called IOMAD allows for multi-tenant Moodle systems. It adds to the site administration block a new series of select ions for adding companies, departments, and sub-departments, licenses with configurable seat counts and expiry dates, and has a nice user interface to create, add, delete, edit and run reports on each company’s users. Sounds perfect, hey? It is, essentially.

    So, what’s the catch? IOMAD has been around now since 2013. Three years and it is still pretty buggy.

    I hope they will allow me to assist them in debugging their plugins, for they represent something VERY needed by the Moodle communities. In the meantime, my company has achieved a “faux” multi-tenant solution which employs multiple enrollment methods, roles, groups, and custom, role-specific front page blocks on 1 set of courses. The multiple enrollment methods only require a customized version of the enrollment methods list page and what we call an “orientation” page for the student to be specifically directed to the enrollment page and see only the area of the list they need to for their organization.

    We’ve had to perform various hacks here and there to our theme, so our customer admins cannot see students from other organizations. A few are especially ugly. But the LMS works smoothly without error or hindrance. That’s enough for us.

Leave a Reply

Your email address will not be published. Required fields are marked *