Difference between revisions of "Finding and Selecting A Web Host"

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.3. Up-to-date documentation for the latest stable version is available here: Finding and Selecting A Web Host.

(Keeping Your Software Current)
(Keeping Your Software Current)
Line 79: Line 79:
Additionally, as noted below, Moodle is not the only product you may want to keep current,  and any time you are trying to keep multiple applications current you are bound to run into compatibility issues.
Additionally, as noted below, Moodle is not the only product you may want to keep current,  and any time you are trying to keep multiple applications current you are bound to run into compatibility issues.
===Keeping Your Software Compatible===
===Keeping Your Software Compatible===

Revision as of 23:10, 26 November 2008


These pages are meant to serve as an additional guide to help users work through variety of questions, issues, etc. as they choose the best way to provide Moodle as an LMS to their users. We hope that these pages will help to steer the user to helpful materials that may not be easily found by the docs search engine. This is an ambitious undertaking, so we would be very pleased for more authors to add to the content!


Planning a Moodle installation

If you are interested in installing and using a Moodle instance in your school, organization, or business, there are many things you must consider. Not only do you have to think about the technical aspects, you also should put some thought into how you would like to use the system, maintain the system, create the content, and support the users.

Depending on the scope and scale of your instance, and the technical expertise you can bring to the table, you may decide that you can host Moodle yourself or you may realize you could use some help! This page focuses on making decisions about how or where to host a Moodle site. Other pages will be developed to address the separate issue of retaining consultants apart from the question of hosting (though many of the concerns in addressing both are comparable.)

In addition to technical expertise, there are staffing issues to consider. A developer will help you write code to enhance or add new functionality. Many installations find that they do not need a developer, or they can hire development on an ad hoc basis. An LMS/Moodle administrator needs to have a good understanding of the system side of moodle. The more this person knows about databases and general web applications, the better. If you don't have an IT person to run the server and manage security, then the LMS/Moodle administrator may need to oversee these important duties. Content creators usually assist instructors with planning and creating course content. Large installations may need dedicated IT staff and database administrators. Consider the mix of people you have to support Moodle in your organization. You may find that you can cover all these bases with your current staff. If not, you may want to look at a Moodle Partner or a "full-service" host.

Who are you? Types of Moodle Instances

Before you choose a host, it would probably be helpful to have a firm understanding of who YOU are. What do you intend to accomplish with your Moodle instance?

Typical types of Moodle instances include schools, companies, agencies, churches, and a wide variety of non-profit organizations. A single individual may want to deliver just two or three courses. Some moodle instances serve as portfolios or special project spaces. Moodlers are very innovative!

Each of these types of Moodle users will have differing requirements and needs. Each may have different ideas about what kind of content they want to provide, who will be facilitating the "course work" (or if the course work will be automated), how they will enroll the users, and how strictly they want/need to enforce privacy for users.

These issues are of great importance when selecting a host. If you can identify exactly what you want to do and how you think it can be best accomplished, then you will likely recognize whether or not you can "do it yourself", if you need to look for full-service hosting, or if you can accomplish your goals with a consultant or ad hoc development.

The following are common types of users. Some people only use moodle to create and teach courses (albeit in quite a lot of different ways!) Some people take care of the Moodle "back end", which involves administrative functions. In some cases, the Moodle admin will take on responsibilities for "server admin" as well as assisting with training for teachers using moodle. In others, the "server admin" will work with other people to form a group that covers Moodle admin and classroom teacher perspectives. Trainers often have all the skills for the instructor as well as Moodle adminintrator. The are endless combinations of staffing and roles depending on your organization.

The following examples should be seen as a rough continuum with many variations possible. Take a look at the examples that seem to fit you best and we will attempt to describe the skillsets you will need and our best advice for the type of hosting you may find most practical:

The classroom teacher, instructor, professor, or course creator

This section describes the default role of "editing teacher" and sets out some considerations for evaluating your ability to manage a Moodle instance on your own.

The Moodle admin (limited to managing Moodle, but not other software packages on the server

The Advanced Moodle admin (managing Moodle as well as getting into server side considerations, such as database management and php)

The Server admin (managing the server and stack software, but may be less or not involved in managing the moodle instance itself)

Types of Hosts

Full-service hosts who are Moodle Partners

Moodle Partners are companies that have been vetted by and approved by Moodle Pty Ltd to provide and advertise that they provide Moodle hosting. They do contribute 10% back to the moodle trust to support Moodle development. Most Moodle Partners deliver high quality service and have very comprehensive knowledge of Moodle and how it works. They usually provide support, training, and other services (such as content building) if needed by their clients. Most of them do provide some level of development should it be needed by their clients.

Moodle Partners can be found in many countries, and different partners specialize in different areas. You can read more about them at http://moodle.com/partners/list/


Full-service hosts who are not partners

If you google "moodle hosting" you will find Moodle Partners and a large number of sites offering Moodle hosting that are not full-service hosts. Be very careful. Many sites that advertise Moodle hosting are really offering you hosting without service. They provide the software, but you are on your own after that!

Full service Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. Some of them do participate in the forums and give a lot of assistance to the Moodle community. They are companies that offer many of the same services that moodle partners offer. Some will serve fewer clients, and some will serve many clients. They will sometimes offer training and help desk services in addition to taking care of the server-side of a moodle instance.

Hosting without service

Hosting without service is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware but also do not want to pay the premium for someone else to provide administrative expertise in the management of your Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

Your use of a web host will likely be made most enjoyable if your web host offers current mysql and php with the requisite extensions and access to php.ini. MAYBE YOU SHOULD PUT SOME EXAMPLES OF EXTENSIONS HERE?? You will likely want shell access, ssh support with sftp, access to phpmyadmin.

WHAT ABOUT NEEDING .htaccess files, register globals off and all that??

You may find yourself with issues regarding e-mail, as that is an area where web hosts can often be sensitive (both as to spam and as to bulk mail, which are not necessarily synonomous.)

These web hosts may also offer automated installers. Some of these are installers are wonderful options, some may create more trouble than if you installed manually. PROBABLY NEED EXAMPLE OR MORE INFO HERE--FANTASTICO, CPANEL, ETC.

In-house hosting (or "do it yourself")

Choosing a Web Host

The User Experience

A matrix has been created so that users can provide information on various web hosting options here.

Please feel free to add to the matrix, but respect the footnoting conventions and the table structure please.

Why Use A Web Host

General areas of concern are:

Keeping Your Software Current

Software such as Moodle is not static; it changes all the time. Indeed Moodle software changes sometimes daily. Software may be altered to fix security issues or to make improvements. Sometimes a fix in one respect causes a bug in another.

Additionally, as noted below, Moodle is not the only product you may want to keep current, and any time you are trying to keep multiple applications current you are bound to run into compatibility issues.

Keeping Your Software Compatible

Moodle is not "just" Moodle. The Moodle experience relies on a set of software applications, including a web server (often but not necessarily Apache), PHP, and a database engine (often but not necessarily mySQL), as well as the Moodle code itself.

Each of the elements involved is regularly updated and this will result in compatibility issues. A fix to one application may cause a problem in another.


Murphy's Law offers no exceptions; it is an absolute, and without knowing who you are, where you come from or what you do, your Moodle will some day fail. Get over it ;=} The good news is that the odds of multiple failures are in your favor, so if you are well prepared, this eventuality can be viewed with same equanimity as that stubbed toe.....

The Moodler must remember that while Moodle itself can do some backups, Moodle backups are very intensive and are only a small facet of an effective backup program, which must address the variety of data that is encompassed by a Moodle web site.

We'll discuss various backup types and issues below, but first let's talk about the underlying issue; who is doing what?

Some web hosts provide "snap shots", some provide site wide backups. Some offer shell access and tell you to roll your own, while some web hosts honestly couldn't care less.... You must remember that it is very unlikely that your web host acknowledges any responsibility for maintaining your data. Unfortunately, typically each of your data types may require a different kind of backup and you either need to learn how to do effective backups of your site on your own, or you will have to negotiate what amounts to bare metal backup with your Web Host (and you will need to identify an appropriate window, because you want your backups to be rather more current than your web host might find sensible....)

If you have shell access the good news is that there are quite a few scripts out there you can use to help yourself build an effective backup regimen.

There are critical points with respect to backing up your data that need to be addressed. They range from the global, such as addressing the location for the backups and managing remote backups (rsync can be helpful in this respect) and actually handling and recycling of the files themselves (when do you back up, what do you backup when you do backup, and how long do you keep a specific file) to the narrow (for example the db should be locked during backup.) While we have broken up this discussion because different types of data need to be treated in different ways, one could script one's system to address backups for all the different types of data.

Another option that we should mention in passing is that one can also look at replication of data, either to a simple store or to a failover unit. Be aware that mysql replication requires access to mysql commands that some web hosts do not provide. Chances are that if you are looking at replication you are having multiple private systems hosted by a vendor or are running your own installation and have looked at fail-over, clusters and replication in depth.

Lastly, please remember that if you are paying a web host for bandwidth used, remote backup could become a source of significant expense

Note: AT present there is one Backup page in the docs, and it might be helpful at some time to break that up so that separate docs address different aspects of backup with one page addressing scripting options. In any event link to backup page needs to be added


By data we mean the contents of the moodledata directory. This data may in fact be excluded in your Moodle backups, but may present some of your most important material such a media that was sited in Site Files.


Your GUI is what is most often neglected when addressing backups. More often than not much of what you think of as your GUI will be reflected in any customizations to your theme, with pertinent data located in your Moodle code installation (/moodle/theme - see below) and possibly moodledata (a possible site for images used.)


Whatever database you are using, it is critical that you dump and store your db regularly, especially because it can be so simple to restore a site if you have a recent db dump. This can be accomplished manually via a GUI as with phpmyadmin or mysql admin or via command line if the user has access and the requisite skills. It can also be automated via commercial or open scripting (as in HandyBackup or automysqlbackup).


Not only your Moodle configuration (additional modules, hacks and twiddles), but complementary software that you have integrated (like Mahara, etc) should be backed up.

You might ask why you should back up your Moodle code when you can just download it from Moodle and reinstall. There are a couple of issues here. First, the version of Moodle you download today is going to be different than the same version of Moodle you download tomorrow. This is confusing but that is how things lie. It is possible that a new install will result in problems on a restore and if you are facing down some failure you DO NOT want to then also have to try and figure out why what was working yesterday isn't working today. All things being constant is the hallmark of restore, and you don;t want to deal with any changes you are not aware of.

The second issue is your potential customization, whether that amounts to hacks to php code or just to the installation of additional modules. If speed is of interest (and when doing a restore after failure the most oft heard words are "how soon" ) you don't want to have to recreate your Moodle application, you want to be able to restore.

And a third issue related to the previous point is theme customization. Themes are stored in /moodle/theme.


Most often we talk about security in the context of potential threats to your data. Of course, what can cause some consternation here is that different folks think of data in different ways. There is the data Moodle places in the mysql database. There is the data that Moodle places in the moodledata file structure, and there is the Moodle code itself. You may want to consider protecting all of these types of data from unauthorized reading, writing and execution. Think of this as a two dimensional matrix. Now add a third dimension that includes various ways one might be able to access any cell in the existing table, including coding flaws, external configuration problems and internal Moodle configuration issues

Code Flaws

Code exploits are addressed regularly through patches.

Need links to the various fora, etc for security reporting and info)


The most typical issue in this area is placing the moodledata directory in the web root.

Moodle set-up

This includes such matters as enrollment, internal role configuration, etc.

Perhaps the most widely discussed problem here has been the matter of profile spam that can be produced when admins allow open e-mail enrollment. There are arguments as to whether this is a security issue or not (and sometimes it seems that the same folks are on both sides of the issue at times) but what it means from a practical standpoint is that you can have a Moodle targeted at your elementary school which contains enough pornography to make Bosche blush.

Sophisticated authentication relying on Moodle Networking, LDAP etc. will require some administrative skill sets pertinent to the scheme employed. One should also be acquainted with the underlying nature of access control including the difference between authentication and authorization. See, e.g. http://en.wikipedia.org/wiki/Access_control

More more prosaic but as important are matters of security policy and enunciation of protocols addressing access rights to data (in the U. S. consider HIPAA, FERPA, IDEA, etc.)

Criteria for Selecting Web Hosts

What Purpose Will Your Site Serve

Production, Experimentation, etc Classroom support or Asynchronous Remote Gradebook and critical classroom data Number of concurrent users

Will You Be Running a 5 Nines Site

What is all this you hear about "five nines". This is a way to discuss system uptime and the implications thereby for the amount of time that a system is down and not available.

While five nines is not that difficult to achieve, it becomes obvious quickly that without redundancy bringing down any part of a system for maintenance quickly knocks one out of the park.

Downtime can grossly be divided into planned and unplanned outages. You may determine that since you only serve people in one time zone who had beeter be in bed between 2 and 4 in the morning, that you can live with 2 hours of planned downtime a night. On the other hand, you may feel that from 7:00 a.m. to 10 p.m. Monday through Friday no outage is acceptable.

Are you Prepared to Serve as a SYSADMIN?

How are you planning to staff your project (see above??) Do you have buy in from your IT dept? Is everyone involved familiar with the realistic demands of a Moodle install (crank the FTEs!)

Is Your Web Host Willing to Negotiate for the Services You require


What is an SLA? An SLA is a Service Level Agreement. While wikipedia provides a basic discussion of SLAs, a review of Naomi Karten's site, which is pitched at the vendor might prove helpful. There are commercial SLA kits as well.

By way of example, consider the SLA between Delhi SUNY and Moodlerooms (and see this comparison), an SLA in pdf format for North Umbria Learning, and an SLA in MS Word format for Kwantlen, Canada.


Well, having considered an SLA hard and fast, the question is whether your SLA sets out specific remedies for those occasions when your vendor doesn't provide the services agreed upon, and if not, what recourse you may have.

To put this another way, you have no rights if you have no remedies. Depending on the relative bargaining power of the parties remedies could run from monetary damages to a term extension. In many cases your potential vendor may refuse to agree to any specific remedies. Consider the vendor who "guarantees" band width and when asked what the client receives when the bandwidth drops below the guaranteed service level, the vendor states that they will work to resolve the issue; there is no remedy and the guarantee is mere puffing.

Negotiating for remedies is an excellent way to explore the amount of faith the vendor puts in his own stock. Most often you will be told that the vendor can't provide any remedy as remedies could put them out of business. Chances are that this vendor does not have redundancy or experience necessary to provide mission critical service.

Notes to selves: Here is the real meat and potatoes, which we can put here or actually put on additional pages (my prefs) SO a link to range of service, types of support, security, e-mail, mysql support, panels.... perhaps as well, pages on SLAs generally, boilerplate and guarantees, punchlists Perhaps specific sections, with brief descriptors and links to more detailed pages.

Planning an Installation


Alphabet Salad - RFPs, RFQs, RFTs, SS, etc

Preparing a Project Proposal

Believe us, you don't want to be in this position: http://asdtech.wik.is/ASD_Tests_Moodle_Waters

  • Make sure you research all questions that arise and keep accurate notes.
  • Consider publishing all the development and research material among your team
  • Secure and use a team, prefereably at some point including all "stake-holders" (before that term refers to person looking to drive said stakes through your heart)
  • Avoid impropriety, as well as the appearance of impropriety.

Developing Specs

This is often a troublesome area as it simply makes sense to discuss specs with prospective vendors. Unfortunately, this is also the path to the slippery slope!

Do It Yourself