Finding and Selecting A Web Host

Purpose

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!

A similar effort can be found in the Decision FAQ and if you have suggestions for integration, linking, etc. please feel free to post suggestions via the "page comments" tab above.

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

The Hosting for moodle teachers page describes the default role of "editing teacher" and sets out some considerations for evaluating your ability to manage a Moodle instance on your own.

If you decide that this category describes you best, you will likely be interested in full service hosting or full service hosting with a moodle partner. If you have an in-house IT department, you may be able to negotiate an agreement with them to provide the hosting and assume responsibility for the administrative tasks related to running a Moodle instance. Depending on your situation and the level of support you need, outsourcing might be the more attractive option.

The (limited) Moodle admin

The hosting for moodle admins page describes the role of the Moodle admin. Not the server admin. This role is limited to managing Moodle, but not other software packages on the server.

If you decide that this category describes you best, you will likely be interested in full service hosting or full service hosting with a moodle partner. If you have an in-house IT department, you may be able to arrange for them to provide the hosting and you assume responsibility for the administrative tasks related to running a Moodle instance.

The Advanced Moodle admin

As you by now expected, the hosting for moodle advanced admins page is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

If you decide that this category describes you best, you will likely be interested in hosting without service.

The Server admin

There is also a page addressing hosting for server admins, for people who have the necessary skills and knowledge to manage the server and stack software. If you fit into this category, you may be less or not involved in managing the moodle instance. Some individuals will be able to run the server as well as manage the moodle instance in its entirety.

Types of Hosts

Full-service hosts

A full-service host is a host who is ready to support Moodle as a software package as well as providing and maintaining the server it runs on. They may provide training, content building, and development services as well. Service packages will likely include moodle upgrades, installation of approved third-party blocks/modules/question types, database maintenance, phone or email support, and backups.

There are two types of full-service hosts for the purposes of this discussion: Moodle Partners and hosts who are not Moodle Partners.

Full-service hosts who are Moodle Partners

Moodle Partners are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle services, including hosting. They are permitted to use the "Moodle" trademark for commercial purposes and they contribute 10% of their Moodle related revenue back to the Moodle Trust to support Moodle development. Moodle Partners are expected to have comprehensive knowledge of Moodle and to deliver high quality service. In addition to hosting they typically provide support and training as well as such other services (such as content building) as may be needed by their clients. Many of them do provide some level of development should it be needed by their clients.

The list of Moodle Partners shows that they can be found in many countries. Different Partners may focus on a variety of specialities. A link to another document, Decision FAQ - What is a Moodle Partner, provides no additional information at this time.

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. These companies offer many of the same services that moodle partners offer. Some will serve fewer clients, and some will serve many clients. They may offer training and help desk services in addition to taking care of the all that goes into running 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.

While full-service packages may include upgrades, installation of approved third-party blocks/modules/question types, database maintenance, phone or email support, and backups, no-frills hosting will assume that you are willing to manage all these aspects of running a moodle instance.

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

If you have the necessary background and interest, you (or your IT team) can set up your own server and run one or more Moodle instances to support your institution, business, or project. You may choose to deploy Moodle on a variety of different operating systems (Mac, Linux, Windows) and with several different database options (MySQL, Postgres, MSSQL). While this page is not intended to provide assistance in accomplishing this goal, it does attempt to describe the sort of knowledge base you or your team will require for successfully hosting your own Moodle instance.

Choosing a Web Host

The User Experience

Your Compendium

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. There is some exploration of using Google Docs to address user feedback on Web Hosts. While a Google Doc may eventually be embedded in the Web Host doc, an experimental version can be seen here.

'NB:' If the wiki structure for the matrix is too much of a hassle, please just use the + tab from the "page comment" tab (you must be logged in to docs to see this, and that is still a separate log in....) to add your comments and someone will transfer them to the matrix.

Discussion in the Forums

While the forums should not be viewed as authoritative as circumstances change over time, they have been a focal point for quite a bit of discussion of various web hosts over time.

A collection of posts largely focusing on GoDaddy can be found here and a list of discussions concerning quite a few other hosts, courtesy of Richard Enison (RLE), appears in that collection at this address.

Why Use A Web Host

General areas of concern are:

General Management and Installation Assistance

Many web hosts offer GUIs that provide shortcuts to install and manage web applications. Some typical "panel" options are Fantastico and cpanel, while an example of a management application that many webhosts make available is phpmyadmin (for managing mysql databases.)

CPanel

If you decide to choose a hosting company that has cpanel then this tutorial may provide some guidance in choosing a host and setting up moodle via the old cpanel. It is a VERY large file (that runs for about 12 minutes) and you will have to wait for it to load but Eric Hagley indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use this link for an updated tutorial.

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.

As noted elsewhere, some web hosts provide utilities for web application management. For a discussion of updating software using such utilities (Cpanel for example) see the section on General Management and Installation Assistance above.

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. Moreover, the maner in which an issue is addressed in one version may change with the next (an example ebing the use of php.ini files, which were required in every directory in php 4.x, a practice unnecessary in php 5.)

In addition to the four primary Moodle components (again, web server, database engine, PHP and Moodle code) you may wish to install a variety of additional software to use with Moodle (Moodle offers many modules to provide for the integration of external applications). The addition of an external application to your overall system increases complexity because as the various applications develop the modules integrating them may fail.

Module installation might be handled by a firm offering dedicated Moodle services, but will not be typically addressed by a vanilla web-host, which leaves the install of aspell, dragmath, asciimathml, etc. all to you.

One of the most intelligent questions that may be heard in a Moodle class is whether a course developed in Moodle A will work in Moodle B. The best answer is, "Maybe".

Backups

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 may some day fail. 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.....

Keeping very good records of your hacks, your additions, and the settings you have used for moodle as well as all the other software that it takes to support a moodle instance provides invaluable information. A backup regime, including course backups, software backups, and database backups is also important.

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, without a specific agreement otherwise, it is 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

Data

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.

GUI

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.)

Databases

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).

Software

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.

Security

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)

Configuration

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.)

Integration

After an initial basic Moodle installation there are quite a few tasks that need to be addressed to integrate the Moodle with all the bells and whistles you are expecting to use.

Cron

One of the most important post-install tasks is to invoke cron.php via the system cron daemon (or Task Scheduler...) Among other tasks, such as backup, cron triggers mail. Cron explains a good deal but there may be issues when trying to use smtp (some of these have been fixed in Moodle 1.9.3) to alternative ports.

Mail

While typically Moodle will use PHP's mail routines, in some cases you may have to configure mail manually and some issues may require manual database edits. See, Email settings and Email setup gmail as examples of possible manual configuration.

Max File Upload

The maximum size of file uploads for Moodle can be controlled via the Moodle GUI but are also constrained via Apache and PHP, and to adjust these you may need to be able to edit .htaccess and/or php.ini. Here are some examples of the discussin of such matters: http://moodle.org/mod/forum/discuss.php?d=98064&parent=433245 and http://moodle.org/mod/forum/discuss.php?d=103190&parent=456650

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

Issues of scale can be very important. A relatively small number of concurrent users can generate enough email through forum postings to get you in trouble with your host. Email volume, storage space for users and courses, number of accounts,

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

SLAs

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.

Remedies

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

Installation FAQ

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

Planning your installation Strikethrough