Multi Tenancy in Moodle

Moodle Multi-Tenancy
A Synergy Learning White Paper
April 2012
Prepared by Alex Bchner
Disclaimer
Every effort has been made in the preparation of this white paper to ensure the
accuracy of the information presented. However, the information contained in
this white paper is without warranty, either express or implied. Synergy
Learning cannot be held liable for any damages caused of alleged to be caused
directly or indirectly by this guide.
April 2012
Unless stated otherwise, this document is distributed under the

Creative Commons Attribution-NonCommercial-ShareAlike CC
BY-NC-SA License.
2012 Synergy Learning

Page 2
www.synergy-learning.com

Table of Contents
Disclaimer .............................................................................................................. 2
Table of Contents ................................................................................................... 3
Introduction........................................................................................................... 4
Multi-tenancy overview ......................................................................................... 5
Multi-tenancy requirements .................................................................................. 8
The multi-tenancy solution that is NOT coming to Moodle ................................... 16
Monolithic Approach ........................................................................................... 19
Distributed Approach........................................................................................... 23
Federated Approach ............................................................................................ 25
Summary ............................................................................................................. 28
Appendix I Checklist .......................................................................................... 30
Appendix II References...................................................................................... 32
About Synergy Learning ....................................................................................... 33


Page 3

Introduction

This Synergy Learning white paper discusses different approaches and models of
how to design and implement a multi-tenancy in Moodle. If any of the following
scenarios are of interest, then this document is for you:
An authority representing hundreds or thousands of schools in a region

or country who wish to provide each school with a separate Moodle
system, but need to manage the systems centrally.
A private training organisation with a number of customers, each needing

their own walled area and theme.
A global organisation that has regional entities requiring their own

learning space.

The white paper is structured as follows:
1. A brief overview of multi-tenancy in Moodle
2. Requirements of multi-tenancy in Moodle
3. Four approaches to multi-tenancy in Moodle
a. The multi-tenancy that is NOT coming to Moodle
b. Monolithic approach
c. Distributed approach
d. Federated approach

4. Summary
5. Checklist of multi-tenancy in Moodle
6. References

Page 4

Multi-tenancy overview
Multi-tenancy in Moodle has been discussed for more than 5 years. Forum
discussions on moodle.org have been posted as early as December 2007 and the
topic has come up frequently ever since.

At some stage it was proposed that multi-tenancy would be implemented as site-
wide groups, but this never materialised. Instead, cohorts have been introduced
in Moodle 2, but they dont cater for multi-tenancy.

Multi-tenancy has been on the roadmap for version 2.2 and 2.3, but
unfortunately Moodle HQ put the proposed solution on ice in February 2012
more on that later.

Since then, a lot of organisations educational or commercial are still looking
for a suitable solution for multi-tenancy. But, what exactly is multi-tenancy?

According to Wikipedia multi-tenancy refers to a principle in software
architecture where a single instance of the software runs on a server, serving
multiple client organizations (tenants). [] With a multitenant architecture,
a software application is designed to virtually partition its data and configuration,
and each client organization works with a customized virtual application
instance.

In a Moodle context this means that separate entities or instances (tenants)
managed within a centrally managed setup.

Page 5
Tenant
1
Tenant

Tenant
2
Central
Tenant
5
Tenant
3
Tenant
4

So, who needs multi-tenancy in Moodle? Well, any organisation that has to
manage more than a single Moodle site. We have listed a few use cases in the
introduction.

Other web-based systems that are used in educational setups facilitate similar
concepts, for instance

Mahara supports the concepts of institutions
Wordpress and Drupal provide the so called multisites
Alfresco explicitly offers a multi-tenancy extensions


Page 6

Terminology used in this white paper:

Term
Description
Central site
One main or master site
Local site
Multiple client or tenant sites
Master administrator
The person in charge of the central site and

hence the overall system
Tenant administrator
The person managing the local site
Moodle instance
Depending on the infrastructure in place and

the set up to be implemented, each tenant
might be a separate site, a space in an existing
Moodle system or some other logical or
physical entity.

Note: Multi-tenancy does not deal with content sharing. Other facilities (mainly
Moodle Networking via MNet and the recently introduced Moodle Community
Hubs) have been designed to cater for this.

Before we look at different implementation approaches, let us first deal with the
plethora of requirements that exist for multi-tenancy in Moodle.

Page 7

Multi-tenancy requirements
There are a number of requirements when it comes to multi-tenancy, which have
been listed in the diagram below:

There are 3 main areas where decisions have to be made whether management
should take place at the central instance or at the local instances:

User and course management
Admin and code management (settings, modules and code)
Miscellaneous management (themes, reporting and backups)

User and course management
There are a number of critical questions that have to answered in the context of
user and course management:

Storage of user information
Must each tenant administrator be able to manage its own users?
If authentication information is stored in a directory (e.g., LDAP, MS-AD or an

external database) how is tenant-related data represented, if at all?

Page 8
User details
Do user names have to be unique across tenants?
Can identical user name be used in different tenants?
Should there be a quota on the number of users per tenant?
What tenant does a guest user belong to, if any?

Course Management
Will courses be managed centrally, locally or both?
Should users from multiple tenants be able to enrol in the same course?
Can a user enrol into courses in multiple tenants?

Tenant Privacy / Walled Gardens
Is it acceptable that users from one tenant can see users from other tenants?
Is it acceptable that courses from one tenant can be seen in another tenant?
Can users from one tenant communicate (send messages) to users form another
tenant?

Depending on the answers to the above questions, a potentially very different
multi-tenancy set up has to be constructed.

Admin and code management
These are further critical decisions that have to be taken before a decision can be
made about the most suitable multi-tenancy setup:

Settings
Moodle is equipped with a plethora of administrator settings. For each top-level
menu item, it should be decided whether the administration will be dealt with
centrally, managed locally, or inherited:

Page 9
Centrally managed administration items can only be set by the super-

administrator. This is often recommended for security and performance
settings, system parameters as well as network values.

One mechanism that comes in useful is to force admin settings in Moodle
as each parameter in the Site administration menu can be configured via
config.php1. If a value has been set via this method, it is effectively hard-
coded and cannot be changed via the Moodle interface; not even by the
administrator.

For example, you might want to make sure that an administrator does not,
even by accident, turn on HTTPS for logins. Activating this would lock
everybody out of the site if no SSL certificate is installed. To do this, enter
the following line in config.php.

$CFG->loginhttps=false;

How do you know what a parameter is called? Go to the respective setting
in Moodle (in this case, Security | HTTP security) and you will see the
name of the parameter underneath the label.

If the value is specified in config.php, Moodle will display Defined in
config.php besides the parameter, which indicates that the setting cannot
be changed by the user. Invalid values are also shown for these hard-
coded settings. In the following screenshot, the Debug messages value is
incorrect while the Display debug messages value is correct:
1 Taken from Moodle 2 Administration, Packt Publishing.

Page 10
Locally managed administration items can only be set by the tenant

administrator. The border cases are none (all items are managed
centrally, i.e. there is de facto no local administrator) and all (every
setting is managed locally). The reality is usually somewhere in between.
Typical requirements for local administration are around users, courses
and often grades.

It is usually possible to implement these requirements via permissions
using roles and capabilities. Most installations create a new role for the
local administrator and apply it in the System context. More details on
how to manage permissions can be found in the roles and capabilities
chapter of Moodle 2 Administration from Packt Publishing.

Inherited administration items describe the approach where values are

set centrally, but can be modified at local level.

A useful tool that can be utilised is the so-called flavours add-on. A
flavour is a set of Moodle site settings, plugins, string customisations and
language packs (docs.moodle.org/dev/Moodle_flavours). Its key objective
is to package, distribute, and deploy the same settings and add-ons to
multiple Moodle sites. The latest version of the plugin can be downloaded
from plugins section on moodle.org. Once installed, you can select the
settings to be packaged up in a flavour:

Page 11

Module & Code management
One of the many advantages of Moodle is its modularity and the ability to modify
its source code. Any deviation from the core standard system, whether via third-
party plugins or through code changes, increases the amount of maintenance
work when it comes to updating and patching the system. When dealing with
multiple installations, this can potentially become an extremely onerous task. It
is therefore critical to decide up-front what level of modifications will be applied
to the system(s):

Modules (third party plugins)
Will all tenants have the same plugins or will some require extra one?
Will local plugins be managed centrally or by the local administrator?

Code modifications (patches as well as new functionality):
Will code be modified at all?
If yes, will the modifications propagated to all tenants or only some?
Is there a chance of code changes at tenant-level?

Page 12
Miscellaneous management

There are a number of miscellaneous issues that can have an impact on the type
of multi-tenancy configuration, namely themes, reporting and backups.

Branding
More often than not, tenants require their own branding. A faculty might want its
own colour scheme to be in line with the printed prospectus; companies that
have subscribed to training offerings on a commercial site whish to have their
own corporate identity applied; and each school might require its logo on the site
of a region-wide installation.

What is often critical is whether the branding has to be present before users
login or if a generic login page is acceptable and the branding changes after
authentication has been successful. This can be by-passed by a separate login
page that contains the branding of the respective tenant.

A closely related issue to branding is the front-page. In some cases it is
acceptable that there is a shared front-page across tenants. In other cases it is
compulsory that each tenant has its own, dedicated front-page. There exist some
workarounds with modified myMoodle pages, but this approach is only suitable
certain circumstances.

Reporting
Reporting is often critical in learning setups and Moodles reporting tools are not
its strong point. This is emphasised further in a multi-tenancy set up. Typical
requirements include, but are not limited to:
Reporting across tenants
Drill-downs down to tenant and course level
Complete separation of tenants with regards to reporting due to data

protection regulations

Page 13
A great tool for reporting is the Configurable Reports add-on, which can be
downloaded from the plugin section on moodle.org. It allows the creation of a
wide range of flexible and interactive reports using a generator or native SQL. It
further supports charts and export to common formats, such as CSV and MS-
Excel.

To cater for certain multi-tenant setups, Synergy Learning has extended the
module with a powerful drill-down functionality. In the screenshot above, the
drill-down has already taken place from the region North-West Europe (tenant)
to United Kingdom (sub-tenant). It is possible to further drill-down to institutes
(sub-sub-tenants), in this case Glasgow and London.

Backups
A solid backup and restore strategy is essential in any Moodle setup. The
complexity increases when dealing with multiple tenants. Issues to consider are
Will tenants be responsible for their own backups or will there be a

central approach?
Can tenants restore courses or can this only be done centrally?
How will system backups (databases and moodledata) being managed?
Where and how will tenant backups stored and archived?

Page 14
Other
There are likely to be other requirements that are unique to your organisation.
For instance, a unique site policy might be required for each tenant or different
customised language packs. If this is the case, your list of needs will have to be
extended accordingly.

Now that we have covered the majority of requirements for multi-tenancy in
Moodle, let us look at four different approaches of how to implement it.

Page 15

The multi-tenancy solution that is NOT coming to Moodle
It might come across cynical to describe an approach that will not be
implemented, but we have decided to include it in this paper as it gives some
interesting insights into multi-tenancy, its complexity, its diversity, and the fact
that there is no one-size-fits-all method.

In August 2011 multi-tenancy was added to the Moodle roadmap. An initial
specification was developed (docs.moodle.org/dev/Multitenant_support) and a
tracker item was created (MDL-28946).

The proposed solution introduced a new Tenant context to the context
hierarchy that is already forming the basis of permissions granted in Moodle
systems.


Page 16

The underlying idea is that each tenant has its own categories and courses, its
own front page, and also its own users. The approach has a number of
advantages:

Relatively simple to implement
Consistent with existing concepts
Ability to manage multiple tenants centrally

However, the solution also comes with a number of drawbacks:

Same plugins for all tenants
No separate authentication for each tenant
Administration settings can not be delegated to tenant level
Only basic user management at tenant level (e.g. no batch upload)
User cannot belong to more than one tenant
No backups at tenant level
Problems with context-agnostic concepts, such as blogs and tags
No MNet support
And many more

Page 17

To cut a long discussion (on MDL-28946) short, it was decided by Moodle HQ in
March 2012 to cancel the project. Below are a number of posts from the
comments section of the tracker item that demonstrate the evolution of the
thread:

August 11:
Technically it should be possible to implement this in 2.2dev

reaching experimental status in Moodle 2.2.

January 12:
This is obviously much longer and more complex than originally

envisaged.

February 12: Unfortunately, during 2011 it became apparent that:
it addressed less than 90% of what people wanted wrt

multi-site hosting,
it was a complex issue and had the potential to create

regressions all over Moodle
the estimate was revised by Petr to be a lot longer [(months

instead of years, ready for Moodle 2.5)]

It's unfortunate, but I think the responsible thing for me to protect
Moodle is to cancel that approach.

So, what went wrong? The multitude of requirements of multi-tenancy simply
couldnt be catered for with a single one-size-fits-all approach.

We have already seen the wide spread of different and potentially incompatible
requirements. Now that multi-tenancy has been, at least for now, abandoned by
Moodle, let us deal with three approaches that cater for different sets of
requirements and needs.

Page 18

Monolithic Approach
The simplest form of multi-tenancy has been labelled monolithic, that is a simple
Moodle instance in which a category represents a tenant. Using sub-categories
and sub-sub-categories also sub-tenants and sub-sub-tenants can be supported.

We have the ability to create a dedicated theme for each category. However, this
will not be seen until a user has logged in. A new role category administrator or
similar can be created and the appropriate permissions can be granted
accordingly, for instance the ability to add sub-categories and courses.

Below is an example of such an implementation. The Goethe Institut is
Germanys cultural institution operational worldwide. It promotes the study of
German abroad and encourages international cultural exchange. The
organisation has a total of over 200 institutes (tenants) that are organised in
more than 100 countries, which themselves are represented in 17 regions. The
interface has been modified to simplify the management of new tenants and new
roles have been created for regional, country, and institute managers.


Page 19

One main criticism of the monolithic approach is that plugins can only be
configured site-wide and not at a tenant, that is category, level. This has been
tackled to a degree in Moodle 2.3 with the introduction of the addinstance
capability for each module. Effectively, the capability provides a vehicle to allow
administrators to control which activities can be added to which courses, similar
to the already existing mechanism for filters. However, the capability only caters
for activities, but not for other plugins, such as authentication, enrolment,
plagiarism, and so on. Also, it can only be applied at course level and not at
category level.

Page 20

An alternative approach to monolithic multi-tenancy has been implemented by
Totara. Totara is a powerful Moodle distribution targeted at corporate and
public sector organisations.

Totara supports the concept of organisations. Within a Totara instance, multiple
organisations (tenants) can be created, which themselves can represent any
internal organisations structure. Below is an example to demonstrate this:

Organisations, among other information such as position, can then be assigned to
users, either manually or in batch.


Page 21
Learning programs (sets of Moodle courses) can then be run for all staff of an
organisation (tenant) and powerful, interactive reports can be created at every
level of the organisation hierarchy.

A similar approach has been implemented in an alternative Moodle distribution
called ELIS. ELIS has the concept of organisational clusters, where each cluster
represents a tenant. A cluster is effectively a site-wide group that can be
associated with courses.

To summarise the monolithic approach, here is its pro-cons table:
Central user management
Tenant privacy
Central course management
Local administration settings
Site-wide reporting
Local modules
Central course backups
Local source code changes

Page 22

Distributed Approach
The principal idea of the distributed approach to multi-tenancy is to have a
single code base, but multiple, separate, stand-alone Moodle instances. All
systems have to be identical and no local modifications are possible.

The solution requires two main steps:

1. Web server configuration
These are crude instructions for Apache servers. Other web servers will have
similar facilities.

For each Moodle instance, a separate vhost file is required where the parameters
ServerName, ErrorLog and CustomLog point to the individual instances, but the
DocumentRoot variable has to be identical in all vhost files. This ensures that the
same code base (CFG->dirroot) is used.

2. Moodle setup (config.php)
There is one main config.php file that is called no matter which instance is
opened in a web browser. This acts as the launch pad for all other instances that
are represented by individual config.php files. These local config.php files have to
be stored in a separate location and have to follow a strict naming convention (in
our example <name of domain>_config.php). The installation of these as well as
its maintenance is usually implemented via scripts to ensure the consistency of
the set up.

In order to make this work, the main config.php file has to be modified as follows,
assuming your local config.php files are stored in /etc/local_moodle:


Page 23
<?php
// Moodle configuration file
$moodle_host = $_SERVER['HTTP_HOST'];
require_once(/etc/local_moodle/.$moodle_host._config.php);

In each local config.php file, the $CFG->dirroot has to be set to the same value
that has been specified in DocumentRoot in the vhost file above.

Local config files can then be customized further to cater for any idiosyncrasies
on particular tenant. For instance, you might want to freeze certain
administration parameters that must not be modified by the tenant
administrator.

The distributed approach has been implemented in Synergy Learnings training
setup where, in the Moodle Administrator course, each participant has its own
instance. This regularly requires the installation of 20+ systems when multiple
sessions are taking place simultaneously. This has been supplemented with reset
scripts to clear the sites after course completion.

One large implementation of a distributed system that follows the above
approach is at Cumbria and Lancashire Education Online in the UK. It comprises
of almost 1,000 Moodle instances, where each tenant represents a school in the
region. Each school has its own administrator, its own theme and its own
administrations settings to manage users, courses and grades.
To summarise the distributed approach, here is its pro-cons table:
Single codebase
Tenant privacy
Local modules
Separate theme
Site-wide reporting

Page 24

Federated Approach

The main drawback of the monolithic and distributed approaches is that all
tenants have to run an identical system. While this is acceptable or wanted in
many scenarios, it is a showstopper in others. To tackle this shortcoming, lets
have a look at the federated approach to multi-tenancy.

The principal idea of this method is to provide tenants with their own modifiable
and configurable Moodle instance, but with a built-in mechanism to guarantee
consistency of the source code across systems. To achieve this, we make use of
the code management system GIT and the Moodle command line interface (CLI),
which was introduced in version 2. The picture below visualises the workflow of
the approach (in case you wondered, the strange looking creature in the image is
the github logo):

The central repository is your own github. It regularly synchronises with the
main github of Moodle. That way, your master system is up-to-date. You then
have the ability to link in modules from other githubs (usually third-party
plugins) or your own code repository.

Page 25
The local repositories pull their latest version from central and have also the
ability to link in modules from other githubs or their own code repository. That
way, each tenant has full flexibility, but there is still a degree of control of the
main code base.

There are a number of permutations of the above workflow. For instance, the
local instance can pull code directly from the main Moodle github, or code could
be pushed from central to local (via rsync), if only additional modules have to be
installed at the tenants sites, and so on.

The entire workflow would obviously be fully scripted to minimise the amount of
maintenance work. Below is a skeleton of a script that makes use of GIT and CLI.
In a real-world setup additional steps would have to be added, for instance to
allow for rollbacks in case of failure.

1
git fetch
/usr/bin/php admin/cli/maintenance.php --enable
git merge origin/cvshead
/usr/bin/php admin/cli/upgrade.php --non-interactive
/usr/bin/php admin/cli/maintenance.php --disable

1. Get latest version from Moodles github (has to be set up prior to first run)
2. Put Moodle in maintenance mode
3. Merge latest version with current version
4. Run update script without user input
5. Disable maintenance mode


Page 26
One system where the above approach has been implemented is the Foyle Cloud
Moodle Network. The current set up includes 7 schools aiming at 25 schools in
the coming years. However, the infrastructure can scale to hundreds or even
thousands of instances, if required. The diagram below illustrates the Foyle
Cloud Moodle network setup and the main user type responsibilities. It further
makes use of the Moodle Networking functionality and also integrates the open-
source e-portfolio tool Mahara:

To summarise the federated approach, here is its pro-cons table:
Local modules
Local source code changes
Tenant privacy
Site-wide reporting
Separate theme

Page 27

Summary
We have covered multi-tenancy and a number of alternative approaches how it
can be implemented in Moodle environments. These were monolithic,
distributed and federated as well as a concept by Moodle HQ that has never been
implemented. We have also provided some examples to demonstrate the
feasibility of each method.

What has hopefully come across is that there is no one-size-fits-all solution. The
decision of the most suitable method depends entirely on the requirements of
the application to be put in place.

There are other options to consider, which have not been dealt with:

Cohorts
There has been some on-going discussion about extending the concept of
cohorts to facilitate multi-tenancy.

IMS-LTI
The standard allows Moodle to be an LTI consumer, but also to be a LTI
provider. This approach opens up some interesting avenues that are yet
to be explored in a multi-tenancy context.
Web services
A lot of organisations have developed its own management system that
controls Moodle remotely. This is certainly a feasible approach in a multi-
tenancy environment, if the management system is able to cater for the
requirements and provides a programmable interface.

Page 28
We have mainly focussed on technical aspects. Other facets that have not been
dealt with, but are critical in the decision-making, are more of operational
nature: How are the tenant sites being supported? Will there be central support
staff or will there be local support staff. Like local administrators, how about the
training requirements of these? This can be a logistical challenge that should not
be under-estimated.

A further issue that has been left out intentionally is that of data protection as
this depends heavily on local idiosyncrasies and legal structures. It might be the
case that the storage of tenants data has to be separate or that reporting across
tenants is not compliant with regulations.

Another challenge that will only be applicable in some scenarios is the existence
of stand-alone Moodle sites, which have to be migrated (tenant import) to a
multi-tenancy set up. A technical process has to be put in place to guarantee the
import of data and potential conflicts in terms of functionality have to be catered
for. Equally, if a tenant wishes to leave the federation (tenant export), what are
the technical implications?

While a lot of all this might look very technical, daunting and labour-intensive, it
will be a relatively pain-free exercise if a solid plan is followed alongside a
professional and experienced partner.

Page 29

Appendix I Checklist
Below is a checklist that forms a solid starting point for planning a multi-tenant
set up. This list is by no means complete, but should give you some indication
what approach is most suitable for your requirements. The three described
approaches and, for completeness, Moodles planned implementation, have been
Distribution
Federated
Moodle planned
Monolithic
mapped against the requirement criteria listed.
User Management
Must each tenant administrator be able to manage its own users?
Do user names have to be unique across tenants?
Can identical user name be used in different tenants?
Should there be a quota on the number of users per tenant?
N1
N2
N2
N1
Are guest supported in tenant mode?
Is course management supported centrally, locally or both?
B3
Should users from multiple tenants be able to enrol in the same
I3
L45
L45
?5
Course Management
course?
Can a user enrol into courses in multiple tenants?
Tenant Privacy
Is it acceptable that users from one tenant can see users from other
tenants?
Is it possible that courses from one tenant can be seen in another
tenant?
Can users from one tenant communicate (send messages) to users
form another tenant?
Administration settings
Are administration settings set centrally, locally or can they be
inherited?

Page 30
Monolithic
Distribution
Federated
Moodle planned
Modules
Can tenants have their own plugins?
N6
N6
N6
Will local plugins be managed centrally or by the local
Theme per tenant
Tenant theme at login
Reporting across tenants
Drill-downs
Y7
Tenant backups
Miscellaneous
Sub-tenants
Tenant import / export
Networking (MNet) supported
administrator?
Code Base
Can tenants make source code modifications locally?
Branding
Reporting
Backups

? Undecided or unknown
1 Has to be implemented as a system setting
2 Has to be implemented as an authentication plugin
3 Via roles and roles overrides
4 Individual values can be frozen via config.php
5 Inheritance via flavours
6 Modules in 2.3 via new addinstance capability
7 Custom development of Configurable Reports plugin

Page 31
Appendix II References
Below is a list of references that has been utilised while authoring this white
paper:
http://docs.moodle.org/22/en/Cohorts
http://docs.moodle.org/22/en/Git_for_Administrators
http://docs.moodle.org/dev/Moodle_flavours
http://docs.moodle.org/dev/Multitenant_support
http://docs.moodle.org/dev/Module_security_improvements
http://docs.moodle.org/dev/Web_services_Roadmap
http://tracker.moodle.org/browse/MDL-28946
http://blog.danpoltawski.co.uk/archives/2011-10-multi-tenant-moodle-without-the-2-2-
feature.html
http://www.moodlenews.com/2011/what-is-multi-tenancy/
http://www.open-thoughts.com/2012/03/experiments-with-moodle-multi-tenancy/

For all aspects on user and course management, roles and
permissions, themes, backups, and reporting, please refer
to the Moodle 2 Administration book by Packt
Publishing.
http://www.packtpub.com/moodle-2-administration-configuring-
securing-customizing-extending/book
We would like to thank Gavin Henrick for some fruitful discussions on earlier
drafts of this white paper.

Page 32
About Synergy Learning

Established in 1997 Synergy Learning is an educational technology services company
working with organisations across all vertical sectors. We provide services that embrace
Open Source technologies such as Moodle, Totara and Mahara. Headquartered in Belfast,
UK, with satellite offices in Manchester, Lancaster, Fife and Heidelberg, Germany,
Synergy Learning is a leading authorised Moodle, Totara and Mahara Partner, with a
global client base that includes Dell, BP, Ryanair, British Airways, British Council, SNCF
Macmillan Cancer Support, PricewaterhouseCoopers, Atos S.A., Goethe Institut, and
Roehampton University. The following is a summary of skills present in the company:

Moodle Hosting
Synergy Learning operates a server farm hosting over 500 Moodle installations.
Installations range from small usage packages to dedicated VLE servers and load
balanced fault-tolerant clusters. The secure environment has been optimised for Moodle
usage and provides full nightly backup facilities. The company also provides an
installation and health-check service for sites hosted internally by clients.

Moodle Training
Synergy Learning initially started as an e-learning company 10 years ago and has a very
strong educational and pedagogical focus that is complemented by its technical skill set.
The company offers a range of standard Moodle courses that are delivered on a regular
basis.

Moodle Support
Synergy Learning is assisting a number of educational and commercial customers with
support contracts covering course creation subjects as well as administration issues.
The Synergy Learning Moodle help desk operates through a ticket system by email and
phone.

Page 33
Moodle Development
Synergy Learning has the technical skill and experience to customise Moodle through
code and to develop new modules using its underlying PHP programming language. A
large number of development projects have been completed providing new
functionality, modifications to standard platform features or integration with external
systems. Synergy Learning actively contributes to Moodle core.

Moodle Themes
Synergy Learning is highly skilled in creating Moodle and Totara themes (skins)
according to an organisations visual identity guidelines with the aim of increasing the
overall usability and impression of the site for specific target audiences.

Moodle Integration
A number of projects have been carried out where Moodle was integrated with existing
systems. These ranged from standard student management systems and commercial
systems to bespoke applications.

Moodle Course Creation

Synergy Learning has an in-house design team, which specializes in the development of
learning resources that are tailored for Moodle usage.

Contact Synergy Learning

Telephone: +44 (0) 28 9042 2000
Email: info@synergy-learning.com
Blog: www.synergy-learning.com/blog
Twitter: www.twitter.com/synergylearning
Facebook www.facebook.com/synergylearning

Page 34

Multi Tenancy in Moodle

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Multi Tenancy in Moodle

Încărcat de

Drepturi de autor:

Formate disponibile

Moodle Multi-Tenancy

A Synergy Learning White Paper

Unless stated otherwise, this document is distributed under the

2012 Synergy Learning

2012 Synergy Learning

An authority representing hundreds or thousands of schools in a region

A private training organisation with a number of customers, each needing

A global organisation that has regional entities requiring their own

2012 Synergy Learning

2012 Synergy Learning

Mahara supports the concepts of institutions

Wordpress and Drupal provide the so called multisites

Alfresco explicitly offers a multi-tenancy extensions

2012 Synergy Learning

One main or master site

Multiple client or tenant sites

The person in charge of the central site and

The person managing the local site

Depending on the infrastructure in place and

2012 Synergy Learning

User and course management

Admin and code management (settings, modules and code)

Miscellaneous management (themes, reporting and backups)

Must each tenant administrator be able to manage its own users?

If authentication information is stored in a directory (e.g., LDAP, MS-AD or an

2012 Synergy Learning

Do user names have to be unique across tenants?

Can identical user name be used in different tenants?

Should there be a quota on the number of users per tenant?

What tenant does a guest user belong to, if any?

Will courses be managed centrally, locally or both?

Can a user enrol into courses in multiple tenants?

2012 Synergy Learning

Centrally managed administration items can only be set by the super-

1 Taken from Moodle 2 Administration, Packt Publishing.

2012 Synergy Learning

Locally managed administration items can only be set by the tenant

Inherited administration items describe the approach where values are

2012 Synergy Learning

Will local plugins be managed centrally or by the local administrator?

Will code be modified at all?

If yes, will the modifications propagated to all tenants or only some?

Is there a chance of code changes at tenant-level?

2012 Synergy Learning

Reporting across tenants

Drill-downs down to tenant and course level

Complete separation of tenants with regards to reporting due to data

2012 Synergy Learning

Will tenants be responsible for their own backups or will there be a

Can tenants restore courses or can this only be done centrally?

How will system backups (databases and moodledata) being managed?

Where and how will tenant backups stored and archived?

2012 Synergy Learning

2012 Synergy Learning

2012 Synergy Learning

Relatively simple to implement

Consistent with existing concepts

Ability to manage multiple tenants centrally

Same plugins for all tenants

No separate authentication for each tenant

Administration settings can not be delegated to tenant level

Only basic user management at tenant level (e.g. no batch upload)

User cannot belong to more than one tenant

No backups at tenant level