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

Finding and Selecting A Web Host: Difference between revisions

From MoodleDocs
No edit summary
Line 90: Line 90:
Please feel free to add to the matrix,  but respect the footnoting conventions and the table structure please.
Please feel free to add to the matrix,  but respect the footnoting conventions and the table structure please.


A Moodle partner is the preferred option when choosing a web host but if you decide to choose a hosting company that has cpanel then [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf this tutorial] will guide you through the process of choosing a host and setting up moodle via the old cpanel. If you have the new cpanel please use this link this tutorial will guide you.  
A Moodle partner is the preferred option when choosing a web host but if you decide to choose a hosting company that has cpanel then [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf this tutorial] will guide you through the process of 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 it is worth the wait as it is a step by step process shown. If you have the new cpanel please [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf use this link] this tutorial will guide you. Again, it is a large file so let it load!


==Why Use A Web Host==
==Why Use A Web Host==

Revision as of 00:07, 28 January 2009

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!

Decision FAQ

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.

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.

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

Decision FAQ - What is a Moodle Partner

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 a current version php with the requisite extensions and access to php.ini. See Installing Moodle - Software with respect to php and mysql requirements.

You will likely want shell access, via ssh that will allow you to manage files from the command. This eases making changes to htaccess files, php.ini and conf files. You should of course determine if your web host allows access to various Apache, php or mysql configuration files, as some web hosts either preclude such access or provide only limited GUI tools for this purpose.

You will want sftp so that you can move files to and from the server without having to rely on php to accomplish this.

You will also want to confirm that you have access to phpmyadmin or mysqladmin so as to be able to easily manage your mysql databases although, if you have access to your mysql host, you can manage via command line. ssh support with sftp, access to phpmyadmin.

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

Some web hosts may also offer automated installers. Some of these installers are wonderful options, some may create more trouble than if you installed manually. The Moodle forums are fully of discussions of issues with various installers at specific hosts. Fantastico is a common example, while some web hosts like DreamHost have custom scripts. Many hosts now offer GUI "panels, such as Cpanel, which provide GUI tools to manage mail, databases, application installs etc. We encourage users to supplement this documentation with information about installers and panels at various hosts by editing the web host matrix referenced below.

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.

A Moodle partner is the preferred option when choosing a web host but if you decide to choose a hosting company that has cpanel then this tutorial will guide you through the process of 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 it is worth the wait as it is a step by step process shown. If you have the new cpanel please use this link this tutorial will guide you. Again, it is a large file so let it load!

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

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