MoodleDocs - Contribucions de l'usuari [ca]

Mobile Moodle FAQ

2010-06-29T15:42:28Z

Awyatt: /* Native Apps: */

{{Work in progress}}

== How can I use Moodle on mobile devices? ==

There are two ways to use Moodle on a mobile device, you can pay for or download a native app for your cellular device (currently the only native Moodle app is planned for release by [http://www.Moodletouch.com www.Moodletouch.com] in April 2010), or you can configure your Moodle site to be Mobile accessible by using one of the available plug-ins.

=== Native Apps: ===
* [http://www.moodletouch.com MoodleTouch] created by Ali OzGur (available April 2010)
* [http://mpage.hk/ mPage] created by Mass Media, HK (available May 24, 2010)

=== Web apps: ===
* [http://mle.sourceforge.com Mobile LE]
* [http://iphone.moodle.com.au iPhone4Moodle] (available 2010)
* Moodle for Mobiles: [http://www.mobilemoodle.org/momo18/ MoMo]

== Which platforms are supported? ==

=== iPhone ===
* [http://moodle.org/mod/forum/discuss.php?d=104599 Moodle Mobile for iPhone]
* [[Moodle_for_Mobiles#Creating_Mobile_Learning_Tutorials_for_iPhone.2FiPod_Touch|Creating Mobile Learning Tutorials for iPhone/iPod Touch]]

=== MLE ===
* [http://mle.sourceforge.net MLE-Moodle] - MLE-Moodle is a plugin for Moodle, which adds mLearning functionality to this open-source eLearning system.

=== Android ===
* [http://moodle.org/mod/forum/discuss.php?d=134778 Moodle on Android]

=== Twitter ===
* [http://moodle.org/mod/forum/discuss.php?d=104949 Twitter plug-in for Moodle]

== See also: ==

* [[Moodle for Mobiles]] is designed to work with mobile phones in Japan.
* Using Moodle [http://moodle.org/mod/forum/view.php?id=7798 Moodle for mobile forum]

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=31895 Moodle for Mobiles Quiz code released]
* [http://moodle.org/mod/forum/discuss.php?d=31895&parent=185847 Re: Customised Scripts -Moodle for Mobiles projects use of]
* [http://moodle.org/mod/forum/discuss.php?d=143973 Moodle for mobile browsers]
* [http://moodle.org/mod/forum/discuss.php?d=33033 Moodle for Mobiles Project]
* [http://moodle.org/mod/forum/discuss.php?d=141815 Comparisons and Advocacy > Mobile Moodle]

Miscellaneous
* [http://yuiblog.com/blog/2008/02/06/iphone-cacheability/ YUI blog post on how to optimise for the iPhone's cache]
* [http://www.mobilestudy.org/moodle/mobilequiz/ Moodle Mobile Quiz]
* [http://www.mobilemoodle.org/ Mobile Moodle (MOMO)]
* [http://moodle.org/mod/forum/discuss.php?d=123331 Emulators for mobile platforms]

[[Category:FAQ]]

Office add-in for Moodle

2010-05-16T00:55:57Z

Awyatt: /* Save file to Moodle */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

You may set up credentials for multiple Moodle instances.

[[Image:Add_another_instance2.gif|frame|center|Add another Moodle Instance]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

Remember that if you create a new version of the file by changing the name, extension, or location, you may need to relink the content in your Moodle course.

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate. The Courses block is included in the standard Moodle install.

===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-16T00:53:40Z

Awyatt: /* Requirements */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

You may set up credentials for multiple Moodle instances.

[[Image:Add_another_instance2.gif|frame|center|Add another Moodle Instance]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

Remember that if you change the name of the file or the extension, you may need to relink the content in your Moodle course.

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate. The Courses block is included in the standard Moodle install.

===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-16T00:48:51Z

Awyatt: /* Save file to Moodle */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

You may set up credentials for multiple Moodle instances.

[[Image:Add_another_instance2.gif|frame|center|Add another Moodle Instance]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

Remember that if you change the name of the file or the extension, you may need to relink the content in your Moodle course.

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate.
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-16T00:47:10Z

Awyatt: /* Creating a Moodle site link */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

You may set up credentials for multiple Moodle instances.

[[Image:Add_another_instance2.gif|frame|center|Add another Moodle Instance]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate.
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Fitxer:Add another instance2.gif

2010-05-16T00:43:41Z

Awyatt: Adding another instance of Moodle

Adding another instance of Moodle

Office add-in for Moodle

2010-05-16T00:37:39Z

Awyatt: /* Creating a Moodle site link */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

You may set up credentials for multiple Moodle instances.

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate.
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-16T00:36:39Z

Awyatt: /* Save file to Moodle */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

This add-in does not provide every file format that Office normally exports, but it does allow for the most common formats (Office 2003, Office 2007, open document format, portable document format, etc.) You cannot save in a format that generates multiple files and folders (complete or filtered webpage). Very large documents, such as presentations, may not export fully as .mht files (the text is likely to be there, but you may lose backgrounds or other media).

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate.
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-15T21:40:41Z

Awyatt: /* Requirements */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''For initial setup, My Courses block should be visible on course home pages and for it to be showing courses.''' After the first connection is successful, the My Courses block may be removed and the add-in will still operate.
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Office add-in for Moodle

2010-05-15T21:38:50Z

Awyatt: /* Limitations */

The Microsoft Office Add-in allows you to open and save Word, Excel and PowerPoint documents in Moodle. This Microsoft script will bypass the Moodle web interface completely, when saving or editing one of these file types. It does not change existing Moodle code.

:Note that such Add-ins are only compatible with Office on Windows, not the Mac OS X version.

==Creating a Moodle site link==
After installing the add in to Microsoft Office 2003 or 2007, the process works in the Office program and can be found in the File or "Office button".

:Some NOTs: Can not log in as an administrator but must be a teacher or a user that has rights to store files in a specific course. My course must be on and only courses can show on Front Page after login (checking on these two points, works when it is set this way). You can not have multiple logins for the same Moodle site when using Add-in from a computer. Just because you see a site, a course or a folder, does not mean you will be able to store a file there.

The first time, you will be asked to set up a Moodle site. Look for the "Add Moodle". Here you will supply the full URL to the Moodle site (for example <nowiki>http://MoodleSite.org/</nowiki>), the user name (for example: teacher) and the user password (For example: FunMood1ing!) for the Moodle site. This will create a link to the site and verify that the information is correct.
[[Image:MS Addin Setup MoodleSite 1.png|frame|center|Add a Moodle Site popup window]]

==Save file to Moodle==
After installing the Add-in, you will have some new options in your file menu or Office button.

[[Image:MS Addin Office New file icons.png|frame|center|The Add-in links in Word]]
In the "Save to Moodle" option window, you will see a list of the sites you have set up in Office via the add in.

Select the site and a list of courses that the user is enrolled in should appear.

[[Image:MS Addin Files and Folders1.png|frame|center| Selected the course]].

Choose the (or make a new) folder.

Edit the file name to be saved and change (if necessary) the file type.

Press save and the file will be saved in that folder in that Moodle site. You will be returned to your Office file in edit mode.

==Open file from Moodle==
After opening the Microsoft program, go to the file menu or Office button. Select "Open file from Moodle".

Select the Moodle site you wish to enter. You will be asked for your login name and password for the Moodle site.
[[Image:MS Addin Files and Folders open from.png|frame|center|Here we selected the site, course and are looking at available files]]

==Notes for site administrators==
The Microsoft Educational Labs have done this by calling Moodle web scripts. While not as stable as using web services designed specifically for this purpose (such as the ones in the upcoming Moodle 2.0), this approach does have the huge benefit that it works with any recent 1.x Moodle out of the box with no modifications to the Moodle site and its code.

==Requirements==
*Moodle 1.8-1.9, Microsoft Windows XP SP2 or higher, .NET Framework 2.0 or higher, Office 2003 or 2007.
*'''My Courses module to be visible on course home pages and for it to be showing courses.'''
===Limitations===
*Hasn't been tested with Moodle <1.8 or >=2.0
*Does not work with Live Services Plug-in for Moodle.
*Can not be admin or other role with category views (course level view essential)
*Students cannot use this add-in to access course or assignment files
*Does not work on Mac versions of MS Office
*Does not work with Office 2010

==See also==
*[http://moodle.org/mod/forum/discuss.php?d=147494 Announcement by Martin Dougiamas]
*[http://www.educationlabs.com/projects/officeaddinformoodle/Pages/default.aspx Download from MicroSoft Education Labs]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=147807 Office Add-in for Moodle] forum discussion

Guidelines for contributed code

2009-02-26T17:45:21Z

Awyatt: /* Share code with modules and plugins database */

This page describes the various ways to share and work collaboratively on contributed code.
#Submit code in Tracker under CONTRIB.
#Work with submitted code in cvs.moodle.org
#Share and distribute code with [http://moodle.org/mod/data/view.php?id=6009 Modules and Plugins] database
#Document features, install instructions in docs.moodle.org
#Talk and support code within forums at moodle.org
#Maintain and refine code with tracker.moodle.org

==The Frequently asked question==
'''Question:''' I have written a new block, activity, patch or theme to share with the Moodle community. What is the process for contributing the code?

'''Answer:''' First, thank you for your generosity and desire to share your work with the rest of the Moodle community. Code contributions are highly valued and Moodle wants to encourage creativity and generosity in keeping with its constructivist tradition and pedagogical approach. To support this, there are several tools will support your contribution by allowing the code to be more easily found, tested, used, maintained, documented, and evaluated by fellow Moodlers and developers. Learning to use the various tools common among Moodle developers will help you to efficiently and effectively develop, share and maintain the contributed code.

==How to submit code==
You have created some code that you would like to contribute to the Moodle community. The first step is to create a login in [[Tracker]]. You should create a new issue as a "non- core contributed module" project and a "New Feature" issue type. Here is a link to tracker with [http://tracker.moodle.org/secure/CreateIssue!default.jspa?pid=10033 those fields filled in].

Your issue will be a request that the code be evaluated and uploaded into CVS. Provide a clear description of what the code does and the functionality that it adds to Moodle. Attach the contributed code as a zip (or tar.gz) file to the tracker issue. At that point, the Contrib Coordinator will work directly with the code contributor to help evaluate the code, work on resolving any questions/issues found, etc.

*Contributors are encouraged to follow Moodle's coding guidelines [[Development:Coding]]).
*A list of current tracker [http://tracker.moodle.org/secure/BrowseProject.jspa contributed projects is here].

==How to work with code in CVS==
Once the code has been added to the CONTRIB section of Moodle's [[CVS (developer)| CVS]], the contributor will request CVS write access via http://moodle.org/cvs/ and thus be able to make changes to the contributed code.

Contributors are encouraged to maintain a branch for each major Moodle release (i.e. 1.8, 1.9, etc.). The HEAD branch should be used as the development branch. Once CVS write access is approved, the maintainer will be able to make whatever changes are needed to maintain the code.

That being said, contributors are encouraged to associate each change made to an issue in the tracker. This is accomplished automatically by beginning the CVS commit comment with the issue number. By doing so, the contributor helps to document the reason for the change in the code back to the issue requesting for a change. More information on working with CVS is available at: [[CVS (developer)]].

:''Tip:'' Eclipse is an example of an Integrated Development Environment (IDE) that integrates and facilitates many of the common CVS tasks involved in working with Moodle CVS. Instructions for setting up and using Eclipse are available at: [[Eclipse]]. Experienced developers are free to use the tools they are most comfortable/productive with.

==Share code with modules and plugins database==
Now you have a place for users to get your code, how will they know it exists? Moodle users can easily find information about contributed code in the Modules and Plugins database [http://moodle.org/mod/data/view.php?id=6009 http://moodle.org/mod/data/view.php?id=6009]. Many users will find this on the download.moodle.org page via the download links.

When you add an entry to this database, remember that it is searchable by any field. Every field is not required, but providing as much information as possible will help people who would like to find, read about, and then install your contribution. In particular, the name of the module and the description of its function are important. Screen shots are helpful (but please, not larger than 350px wide!). A direct link to the file in a standard archive format should be provided for download. Links to discussion (on moodle.org or other forum) and documentation (link to your page in the moodle docs or other location) should be included if possible.

If you host your code on a site other than moodle.org, please ensure that the download link goes directly to the file and that the file is in a standard archive format. This makes it easier for users to locate the file quickly, particularly if the website is written in a less familiar language.

Users may leave comments on your entry, so please check it periodically for questions and bug reports. If you include contact information or a link to a discussion, your users may be able to contact you more directly. The comments are not emailed automatically.

Entries added to this database must be released by a moderator before they are visible to all.

==How to provide documentation==
Having great code available to the community is wonderful. It is also important to educate users about how to use the code with documentation in [[Main Page|Moodle Docs]]. See [[MoodleDocs:Guidelines for contributors|guidelines for contributors]] for more help.

A documentation page for a contributed module should have some basic elements. A brief introduction of what the code does, a "Features" heading, perhaps a "Installation", "Tips and tricks" and "See also" headings, all with content of course. Sometimes a screenshot is worth 1000 words. In the "See also" put a link to the Modules and Plug database, with a note that this is the place to download versions, and the forum where questions can be answered at moodle.org.

Other information might include: Languages Supported, Known Issues, Supported Versions (for Moodle 1.8, 1.9), and maybe which are being actively supported. We suggest placing <code><nowiki>[[Category:Contributed code]]</nowiki></code> at the bottom of the page.

==Support code and get feedback with forums==
As users become familiar with the contributed code, discussions about the code are likely to emerge. We strongly urge you to place links to at least one forum at moodle.org in your Modules and Plugins entry as well as in MoodleDocs.

It is important to respond to users who have questions about how to use the code, suggestions for how to make it better, etc. If it looks like there is sufficient need for some contributed code to have its own forum, please create a request via the tracker in the MDL-SITE section. Moodle has included many contributed code projects and ideas into its core.

*[http://moodle.org/mod/forum/view.php?id=44 Contributed code forum] is a generic forum. Maybe create a thread "New Mousetrap module".
*[http://moodle.org/course/view.php?id=5 Using Moodle forums] The English speaking list of forums on many different subjects.
*[http://moodle.org/course/ A list of] other language forums and special areas in Moodle

==Maintain and refine code with Tracker==

In order to facilitate keeping track of feature requests, bugs, and other code issues, the contributor may request that a component be created in the CONTRIB section of the Moodle tracker. (This is the section where you initially made the request to have code included in CVS.moodle.org.)

The contributor can be added to the group of CONTRIB developers in the tracker to manage the issues assigned to them and better coordinate with other developers. Users of the contributed code can then add issues which can be assigned directly to the maintainer. The tracker helps to manage the work flow involved in fixing bugs, working through feature requests, and maintaining the code. When committing changes, maintainers are strongly encouraged to begin the commit comment with a tracker number.

We strongly encourage users to involve themselves in the process of creating a useful issue in tracker. For the developer and code contributor, describing the fix can help clarify the need for the code change. Further, it helps to establish good documentation about how the code developed. Others will be able to identify the issues addressed and understand why a particular decision was made.

==Summary==

It is hoped that following this procedure, will help guide contributors of code in the process of learning the tools and skills used by the Moodle developers. Learning to submit code by using the tracker, work the code with CVS, support the code by providing documentation, share code in Modules and Plugins, maintain the code by using the tracker, and evolve the code by using the Moodle.org forums will assist you in successfully contributing to the Moodle community and working with Moodle's developers.

Throughout this process, the CONTRIB Coordinator is here to encourage and support those contributing code to the Moodle community and fostering the development of tomorrow's Moodle developers.

Eventually, the community may wish for the code to become part of the Moodle core. By following the steps above, the developers will be able to evaluate the merit of the contributed code, understand how users have used the code, see the issues that have emerged and thus have more information to make an informed decision about whether or not to incorporate the contributed code into core.

==Most common recommendations for contributed code==

There are several small issues that the CONTRIB Coordinator will typically check for when reviewing the code prior to committing to the CVS server. These issues help to ensure consistency and quality of code. Any suggestions made by the CONTRIB Coordinator should be considered recommendations aimed to help folks new to the Moodle community collaborate in a way consistent with standard practices within the Moodle community. The suggestions are meant to help avoid potential issues and facilitate the acceptance of your code.

# Does the file structure conform to Moodle standards? - Generally speaking, each file should have an appropriate extension (i.e. php, html, css, txt, etc.). To avoid issues with case sensitivity, folders and files are normally lower case; however, there are exceptions to this. Another common recommendation is to place the lang folder within the block or module rather than asking the user to copy files into the main lang folder. Changes made in the get_string function for Moodle 1.9 and onward make it possible to do this which goes a long way in keeping things modular.
# Does the code work without any obvious errors - The CONTRIB Coordinator will try to install the block or module on a fresh Moodle installation and report back any errors. This testing is done with Debugging set to show All PHP notices and errors (not developer mode). The most common notices have to do with attempting to use a variable that has not been initialized or checked for existence.
# Does the code use the config_plugins table? - Contributed blocks and modules are encouraged to make use of the config_plugins table rather than the config table. Maintainers are encouraged to read the documentation provided for the get_config and set_config functions in the /lib/moodlelib.php file to help ensure that the footprint for the global $CFG variable does not become bloated.
# Does the code follow the [[Coding|Coding Guidelines]]? - The CONTRIB Coordinator will look at the code for general readability and point out any obvious deviations from the [[Coding|Coding Guidelines]]. While not all code needs to conform with each and every guideline, maintainers are encouraged to follow those guidelines as closely as possible.

==See also==

*[[Development:contrib]] CONTRIB is an area in the Moodle CVS
*[[Translation]] for information on the translation of contributed code
*[[Development:Overview]]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=99037 Best practices for code modification?] forum discussion

[[Category:Developer|Guidelines for contributors]]

Finding and Selecting A Web Host

2009-02-16T16:59:03Z

Awyatt: /* Hosts who provide full Moodle management services */

==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 [http://moodle.com/partners/list/ Moodle Partner] to provide management and maintenance services for your Moodle instance, your instructors, and your students/course participants.

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management/maintenance services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies may offer many of the same services that moodle partners offer. They may offer training and help desk services in addition to taking care of the all that goes into running a Moodle instance.

Either way, you need to be a careful consumer. Each of these companies is an individual concern, and a prospective client is ultimately responsible for understanding what service package they are purchasing. Do your research and articulate your needs and expectations very carefully!

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 of the software only, without additional management and maintenance services. These hosts do provide the software you need to run Moodle, but you are on your own after that!

===Hosting without Moodle management and maintenance services===

[[Hosting_without_service|Hosting without Moodle management and maintenance services]] is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

While full-service or managed hosting 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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:37:34Z

Awyatt: /* Do It Yourself */

==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 [http://moodle.com/partners/list/ Moodle Partner] to provide management and maintenance services for your Moodle instance, your instructors, and your students/course participants.

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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 of the software only, without additional management and maintenance services. These hosts do provide the software, but you are on your own after that!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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 Moodle management and maintenance services===

[[Hosting_without_service|Hosting without Moodle management and maintenance services]] is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

While full-service or managed hosting 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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:35:28Z

Awyatt: /* Planning a Moodle installation */

==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 [http://moodle.com/partners/list/ Moodle Partner] to provide management and maintenance services for your Moodle instance, your instructors, and your students/course participants.

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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 of the software only, without additional management and maintenance services. These hosts do provide the software, but you are on your own after that!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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 Moodle management and maintenance services===

[[Hosting_without_service|Hosting without Moodle management and maintenance services]] is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

While full-service or managed hosting 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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:32:46Z

Awyatt: /* Planning a Moodle installation */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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 of the software only, without additional management and maintenance services. These hosts do provide the software, but you are on your own after that!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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 Moodle management and maintenance services===

[[Hosting_without_service|Hosting without Moodle management and maintenance services]] is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

While full-service or managed hosting 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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:31:58Z

Awyatt: /* Hosting without service */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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 of the software only, without additional management and maintenance services. These hosts do provide the software, but you are on your own after that!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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 Moodle management and maintenance services===

[[Hosting_without_service|Hosting without Moodle management and maintenance services]] is perhaps the most common situation. Many people select this option when they have decided they do not want to be responsible for hardware or the basic software "stack" used to run a Moodle instance, but also do not want to pay the premium for someone else to provide administrative expertise in the management of Moodle. There are thousands of web hosts available, and each probably offers a slightly different set of service options.

While full-service or managed hosting 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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:29:24Z

Awyatt: /* Hosts who provide full Moodle management services */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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 of the software only, without additional management and maintenance services. These hosts do provide the software, but you are on your own after that!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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|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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-16T16:28:20Z

Awyatt: /* Full-service hosts */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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==

===Hosts who provide full Moodle management services===
Some hosts are 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.

[http://moodle.com/partners/requirements/| 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.

[http://moodle.com/partners/list/ 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.3F|Decision FAQ - What is a Moodle Partner]], provides no additional information at this time.

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!

You may find some hosts offering to install, manage, and maintain Moodle for your organization. Moodle hosts who are not partners are not affiliated with Moodle Pty Ltd. These companies offer many of the same services that moodle partners offer. 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|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.

If you have a reasonable level of confidence in hosting your own site this can be a very inexpensive solution.

===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 [[in_house_hosting|hosting your own Moodle instance.]] You could also consider commercial support for in-house hosting from any of the commercial support providers mentioned above.

=Choosing a Web Host=

==The User Experience==
===Your Compendium===
[[Web_Hosts|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 [http://spreadsheets.google.com/pub?key=pGlMhVRQ_zU-3m-jSjeQCGQ| 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 [http://moodle.org/mod/forum/discuss.php?d=53087#p459052| found here] and a list of discussions concerning quite a few other hosts, courtesy of [http://moodle.org/user/view.php?id=195424&course=5| Richard Enison (RLE)], appears in that collection [http://moodle.org/mod/forum/discuss.php?d=53087&parent=459052| 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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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 manner in which an issue is addressed in one version may change with the next (an example being 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-09T20:55:39Z

Awyatt: /* What Purpose Will Your Site Serve */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-09T20:36:27Z

Awyatt: /* Full-service hosts who '''are''' Moodle Partners */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-09T20:33:31Z

Awyatt: /* Full-service hosts who '''are''' Moodle Partners */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/ | Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Web Hosts

2009-02-09T20:06:08Z

Awyatt:

{{Work_in_progress}}
A host is service where a Moodle site is located and can be accessed. A web host refers to a service that allows a Moodle site to be reached via the internet. This page will focus upon commercial web hosting services. However larger organizations, such as a university or college can also be a web host. A [[Localhost]] (see [[Complete install packages]]) is a service run on a computer that can not be reached by anyone on the internet.

The intent here is to invite those who have experience with various web hosting firms to provide data on their experience so as to provide an easy comparison among web hosting firms.

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host Additional materials regarding pointers for selecting a web host are being developed here.]

Please feel free to add data or extend the matrix (but please respect the integrity of the material). In order to add comments and note the source you can footnote any table element as in this example (clicking on the black square takes you to the bottom of this page)
<center>
{|border="1" cellpadding="2" cellspacing="0"
!This
!That
|-
|[[#fn1|■]]
|
|-
|}
</center>

Feature Key appears below the matrix - please suggest additional features

{| border="1" cellpadding="2" cellspacing="0"
!Webhosts
!A
!B
!C
!D
!E
!F
!G
!H
! I
!J
!K
!L
!M
!N
!O
!P
!Q
!R
!S
!T
!U
!V
!W
!X
!Y
!Z
!II
!III
!IV
!VI
|-
|Siteground
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|BlueHost
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Dreamhost
|■
|■
|■
|■
|■
|■
|■
|■
|1
|■
|x
|x
|?
|■
|■
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Classroom Revolution
|
|
|■
|■
|
|
|
|
|1
|
|
|■
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|And Another
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|}

A. Customizable php.ini or .htaccess

B. Access to custom build of php

C. PHP version 5.x provided

D. MySQL version 5 provided

E. Shell access

F. SSH supported

G. Bulk Mail use restriction

H. SPAM restrictions in excess of security provided via Moodle

I. Language (1- only English, 2- English and Spanish, etc)?

J. Custom panel

K. Fantastico

L. Cpanel

M. Limited TLDs available

N. Domains available

O. Under US$100/yr

____

<span id="fn1">'''fn1.'''</span> A comment regarding the example matrix above, which I can also sign to indicate who made the entry. [[User:Marc Grober|Marc Grober]] 20:35, 6 November 2008 (CST)
----
[[Web Hosts]]

Finding and Selecting A Web Host

2009-02-06T15:30:53Z

Awyatt: /* Hosting without service */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-06T15:28:00Z

Awyatt: /* Full-service hosts */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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.

===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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-06T15:21:18Z

Awyatt: /* Full-service hosts who '''are not''' partners */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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|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.

===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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]
<s>Strikethrough</s>
[[Category:Installation]]

in house hosting

2009-02-05T21:26:33Z

Awyatt: New page: ===Linux Servers=== ===Windows Servers=== ===Mac Servers=== [https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

===Linux Servers===

===Windows Servers===

===Mac Servers===

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

Finding and Selecting A Web Host

2009-02-05T21:24:59Z

Awyatt: /* In-house hosting (or "do it yourself") */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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. 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|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.

===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 [[in_house_hosting|hosting your own Moodle instance.]]

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Hosting without service

2009-02-05T21:18:25Z

Awyatt:

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

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

Hosting for server admins

2009-02-05T21:17:25Z

Awyatt: /* Security */

Once upon a time the technical sophistication required to get a "server" up and running was such that this area was limited to those who already had the technical know-how or who were willing to put in the time and resources to become systems administrators. For good or ill, that is no loner the case. Now just about anyone can have a "server" up and running on almost any box that they find lying around, and while this may have increased access to a wide range of software, it has also increased some network perils.

Much of the initial development of the web was done with unix and the tools that were available with unix distributions. An open competitor, linux, shares many of the tools with unix and is very prevalent today. System administration on *nix systems has become simpler as vendors and developers have offered GUIs for system administration. OS X is an example of marrying a Unix OS to an advanced GUI.

The fly in the ointment, as it were, is MS-Windows. Windows, initially based on MS-DOS conventions, rules the desk top and has made major inroads into the server environment. Many use Windows as a server because they believe it easier to manage than other OS. As the number of users increased many wanted to use open software tools on this proprietary platform.

However, from the standpoint of being able to offer Moodle to a population, the critical factors are that your OS has to support the building/compiling of a web server, a SQL database and php5. As the systems administrator, it is your responsibility to manage the hardware, operating system and basic apps neccesary to support your
[[Hosting_for_moodle_admins_advanced|Advanced Moodle Admin]].

==Operating Systems==

System administrators have to be able to install and manage an operating system

==Networking==

==Applications==

==Security==

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

Hosting without service

2009-02-05T21:15:26Z

Awyatt: New page: 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#Softwa...

Finding and Selecting A Web Host

2009-02-05T21:14:39Z

Awyatt: /* Hosting without service */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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. 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|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.

===In-house hosting (or "do it yourself")===
Spin this off to another page?

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-05T21:12:54Z

Awyatt: /* The Server admin */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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. 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|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")===
Spin this off to another page?

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-05T21:11:12Z

Awyatt: /* The classroom teacher, instructor, professor, or course creator */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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. 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|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")===
Spin this off to another page?

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-02-05T21:07:52Z

Awyatt: /* The (limited) Moodle admin */

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

[[Hosting_for_moodle_teachers|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===

[[Hosting_for_moodle_admins|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, [[Hosting_for_moodle_admins_advanced|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 [[Hosting_for_server_admins|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====
[http://moodle.com/partners/requirements/| Moodle Partners] are companies that have been approved by Moodle Pty Ltd to advertise that they provide Moodle hosting. They do contribute 10% 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. Most of them do provide some level of development should it be needed by their clients.

[http://moodle.com/partners/list/ The list of Moodle Partners] shows that they can be found in many countries. Different Partners may focus on a variety of specialties.
A link to another document, [[Decision_FAQ#What_is_a_Moodle_Partner.3F|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. 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|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")===
Spin this off to another page?

=Choosing a Web Host=

==The User Experience==
[[Web_Hosts|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:

===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 [http://ic.eflclasses.org/tutorials/settingupmoodleonhostingwitholdcpanel.swf| 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 [[User:Eric Hagley|Eric Hagley]] indicates it is worth the wait as affords a step by step approach. If you have the new cpanel please use [http://ic.eflclasses.org/tutorials/settingupmoodleoncpanel.swf| 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|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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Usuari:A. T. Wyatt

2009-02-03T17:56:00Z

Awyatt:

I am a Moodle user. For several years, I was the major "go to" person for our faculty with respect to the course management system. I have since stepped back from that role, but I use Moodle myself as an instructor and am always interested in watching how it grows and develops.

I assist at moodle.org by moderating a few forums.

Interests:
--Themes
--Course formats
--Pedagogy
--Attendance module
--SCORM
--Mahara

Usuari:A. T. Wyatt

2009-02-03T17:55:30Z

Awyatt: New page: I am a Moodle user. For several years, I was the major "go to" person for our faculty with respect to the course management system. I have since stepped back from that role, but I use Mo...

I am a Moodle user. For several years, I was the major "go to" person for our faculty with respect to the course management system. I have since stepped back from that role, but I use Moodle myself as an instructor and am always interested in watching how it grows and develops.

I assist at moodle.org by moderating a few forums.

Interests:
Themes
Course formats
Pedagogy
Attendance module
SCORM
Mahara

experimental: gb tutoring

2009-01-25T12:56:50Z

Awyatt: /* Weighted mean */

=What is this all about=

==The Case for Cases==
In the various agonies of thrashing through our journey into the new and improved gradebook it became self-evident that we really needed quite a few tutorials that addressed a number of different ways of looking at gradebook and that to be most effective the tutorials needed to look at the gradebook the way we looked at grades, in a multitude of different ways and formulations.

Part and parcel of looking at things differently we thought it would be handy to perhaps identify sets of GB settings (much as Gary started to do with his first tutorial) so that eventually, someone who wanted to set up a gradebook like such and such would have a suchandsuch guide, while the teacher across the campus, who felt such and such was just so much could set up a grade book so and so....

And, the thought was that when others had an additional cases, having watched as we stumbled through these initial examples, they would empowered to likewise offer their illustrated examples so that the community could document how all this is supposed to work.

==Understanding Aggregation Methods==

In order to benefit from the case structure we proposed, you first must understand the aggregation methods available in the gradebook. There are a number from which you can choose (these supplied in the moodle gradebook helpfile associated with aggregation methods):

'''Mean of grades'''
The sum of all grades divided by the total number of grades.
A1 70/100, A2 20/80, A3 10/10, category max 100:
(0.7 + 0.25 + 1.0)/3 = 0.65 --> 65/100

'''Weighted mean'''
Each grade item can be given a weight, which is then used in the
arithmetic mean aggregation to influence the importance of each item in the overall mean.
A1 70/100 weight 10, A2 20/80 weight 5, A3 10/10 weight 3, category max 100:
(0.7*10 + 0.25*5 + 1.0*3)/18 = 0.625 --> 62.5/100

'''Simple weighted mean'''
The difference from Weighted mean is that weight is calculated as Maximum grade - Minimum
grade for each item. 100 point assignment has weight 100, 10 point assignment has weight 10.
A1 70/100, A2 20/80, A3 10/10, category max 100:
(0.7*100 + 0.25*80 + 1.0*10)/190 = 0.526 --> 52.6/100

'''Mean of grades (with extra credits)'''
Arithmetic mean with a twist. An old, now unsupported aggregation strategy provided here
only for backward compatibility with old activities.

'''Median of grades'''
The middle grade (or the mean of the two middle grades) when grades are arranged in order
of size. The advantage over the mean is that it is not affected by outliers (grades which
are uncommonly far from the mean).
A1 70/100, A2 20/80, A3 10/10, category max 100:
median(0.7 ; 0.25 ; 1.0) = 0.7 --> 70/100

'''Smallest grade'''
The result is the smallest grade after normalisation. It is usually used in combination
with Aggregate only non-empty grades.
A1 70/100, A2 20/80, A3 10/10, category max 100:
min(0.7 ; 0.25 ; 1.0) = 0.25 --> 25/100

'''Highest grade'''
The result is the highest grade after normalisation.
A1 70/100, A2 20/80, A3 10/10, category max 100:
max(0.7 ; 0.25 ; 1.0) = 1.0 --> 100/100

'''Mode of grades'''
The mode is the grade that occurs the most frequently. It is more often used for
non-numerical grades. The advantage over the mean is that it is not affected by outliers
(grades which are uncommonly far from the mean). However it loses its meaning once there
is more than one most frequently occurring grade (only one is kept), or when all the grades
are different from each other.
A1 70/100, A2 35/50, A3 20/80, A4 10/10, A5 7/10 category max 100:
mode(0.7 ; 0.7 ; 0.25 ; 1.0 ; 0.7) = 0.7 --> 70/100

'''Sum of grades'''
The sum of all grade values. Scale grades are ignored. This is the only type that does
not convert the grades to percentages internally (normalisation). The Maximum grade of
associated category item is calculated automatically as a sum of maximums from all
aggregated items.
A1 70/100, A2 20/80, A3 10/10:
70 + 20 + 10 = 100/190

Naturally, some of these aggregation methods will be more common than others. We will begin with the aggregation methods that we use ourselves, and hope that the community can come in and expand upon the rest in time.

==Case Divisions==

===Mean of grades===

===Weighted mean===
Case 1 - New Course (Weighted Mean of Grades)

[[Using "Weighted Mean of Grades" to weight categories containing assignments]]

===Simple weighted mean===

===Mean of grades (with extra credits)===

===Median of grades===

===Smallest grade===

===Highest grade===

===Mode of grades===

===Sum of grades===
Case 1 - Brand new course, no existing assignments or categories. Sum of points grading with a single category

[[experimental:_SOP_nocats | Sum of Points Case 1]]

Case 2 - This case begins with a course containing assignments, but no categories. It will illustrate the creation of categories, putting assignments in categories, and setting up the grade calculation to produce the total number of points earned for the course. We will also take a look at setting up an uncategorized section to allow for assignments that should not be included in the final point total.

[[experimental:_SOP_multicats | Sum of Points Case 2]]

Finding and Selecting A Web Host

2009-01-24T19:43:18Z

Awyatt: /* Full-service hosts who '''are not''' partners */

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

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

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

[[Hosting_for_moodle_admins|This section]] 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===

[[Hosting_for_moodle_admins_advanced|This section]] 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===

[[Hosting_for_server_admins|This section]] is 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.3F|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|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==
[[Web_Hosts|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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Finding and Selecting A Web Host

2009-01-24T19:42:52Z

Awyatt: /* Full-service hosts who '''are''' Moodle Partners */

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

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

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

[[Hosting_for_moodle_admins|This section]] 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===

[[Hosting_for_moodle_admins_advanced|This section]] 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===

[[Hosting_for_server_admins|This section]] is 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.3F|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|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==
[[Web_Hosts|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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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]]

[[Category:Installation]]

Hosting for moodle admins advanced

2009-01-07T15:06:16Z

Awyatt: New page: If you selected the "advanced moodle admin" role, then you are ready to work with code, server applications other than moodle, and moodle code itself. You should also be comfortable with...

If you selected the "advanced moodle admin" role, then you are ready to work with code, server applications other than moodle, and moodle code itself. You should also be comfortable with managing the moodle instance in all its respects--roles, courses, users, archive, backup, etc. (everything in the "limited moodle admin" role).

This role can encompass quite a lot. You might find yourself uploading large course files/archives directly to the moodledata folder, editing moodle code, adding a third-party module/plugin, or customizing a theme. More knowledgeable individuals will know how to install moodle from scratch, diagnose database problems, set up external authentication methods (LDAP is an example), and write scripts to build reports from the moodle database. However, we are not defining "advanced moodle admin" as a role where you are completely responsible for building and maintaining the server, configuring A-records, load balancing, etc.

Regardless of your skill level, advanced moodle admins will need access to the "back end" of moodle. You will need to be able to upload files and edit files. Full hosting providers may be reluctant to give this kind of access to a client. After all, if you wreck something, they would be called upon to fix it! If you are going with a no-service provider, then you certainly should have this kind of access.

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

Hosting for moodle admins

2009-01-07T14:52:58Z

Awyatt:

Administering Moodle, in the limited sense, has to do with everything you can do ''within'' the moodle interface to manage your instance. This generally includes setting up the default values for modules, course settings, gradebook options, quiz options, etc. It also includes managing roles, user accounts, and language settings.

The limited Moodle administrator does not manage email or authentication (other than ensuring that the right settings are entered into the appropriate places in the moodle administration forms), does not create the database or set up cron. He or she does not patch code or add 3rd-party modules and plugins to the instance.

Many people are confused about Moodle "flexibility". Moodle can be certainly be hacked by someone knowledgeable in php (or even someone who can follow directions well). Moodle can also be extended via the installation of additional modules. However, both of these activities are outside the scope of the limited Moodle administrator.

Our definition of the the "limited Moodle administrator" role assumes gui access only. Code alteration would require additional tools and shell or ftp access. With respect to modules, while the Moodle admin can ''manage'' installed modules to the extent that the module itself provides for control from inside the moodle GUI, the limited Moodle administrator can't add modules, filters or other extensions as the role as defined here does not include the additional access necessary.

Many hosting packages provide for the limited moodle administrator, even full service hosts or Moodle Partners. One or more persons from your institution will be given administrator rights, and those individuals will be responsible for managing the moodle instance. They will not be able to install additional software and may not even have FTP access to the server. Your Moodle instance will be either the standard packages available for download here at moodle.org or include some negotiated extras, such as selected 3rd-party modules and plugins and custom themes.

You will be responsible for notifying the host if there is a problem, whether the problem is related to the moodle instance itself (such as a database problem) or if it relates to security or spam. The host is not likely, for example, to periodically check every profile for spam entries if you have decided to use email authentication on your moodle instance.

You may not find the limited Moodle admin role to be satisfactory. After all, what if your instructors want more themes? What if you have a course archive or course materials that are too large to upload through the moodle interface? What if there is a small hack that you would like to apply or a 3rd party plugin you would like to install? All of these things require the ability to login directly to your server and upload or edit files. Once you reach this point, then I would invite you to take a look at the next section as you are moving into the "advanced moodle administrator" category.
https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced

[https://docs.moodle.org/en/experimental:Finding_and_Selecting_A_Web_Host back]

Hosting for moodle admins

2009-01-07T14:51:35Z

Awyatt:

Finding and Selecting A Web Host

2009-01-05T23:31:44Z

Awyatt: /* The Advanced Moodle admin */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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.

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

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] 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===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] 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===

[https://docs.moodle.org/en/Hosting_for_server_admins This section] is 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 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:31:08Z

Awyatt: /* The (limited) Moodle admin */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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.

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

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] 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===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

===The Server admin===

[https://docs.moodle.org/en/Hosting_for_server_admins This section] is 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 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:30:53Z

Awyatt: /* The classroom teacher, instructor, professor, or course creator */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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.

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

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] 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.

===The Advanced Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

===The Server admin===

[https://docs.moodle.org/en/Hosting_for_server_admins This section] is 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 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:06:50Z

Awyatt: /* [https://docs.moodle.org/en/Hosting_for_server_admins The Server admin (managing the server and stack software, but may be less or not involved in managing the moodle instance itself)] */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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 (limited) Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] 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.

===The Advanced Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

===The Server admin===

[https://docs.moodle.org/en/Hosting_for_server_admins This section] is 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 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:04:26Z

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

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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 (limited) Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] 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.

===The Advanced Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

===[https://docs.moodle.org/en/Hosting_for_server_admins 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:03:49Z

Awyatt: /* [https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced The Advanced Moodle admin (managing Moodle as well as getting into server side considerations, such as database management and php)] */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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===

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] describes the role of the Moodle admin. Not the server admin. This role is limited to managing Moodle itself.

===The Advanced Moodle admin===

[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced This section] is for those people who manage Moodle as well as getting into server side considerations, such as cron, email, database management and php.

===[https://docs.moodle.org/en/Hosting_for_server_admins 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:02:16Z

Awyatt: /* [https://docs.moodle.org/en/Hosting_for_moodle_admins The Moodle admin (limited to managing Moodle, but not other software packages on the server] */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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===

[https://docs.moodle.org/en/Hosting_for_moodle_admins This section] describes the role of the Moodle admin. Not the server admin. This role is limited to managing Moodle itself.

===[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced The Advanced Moodle admin (managing Moodle as well as getting into server side considerations, such as database management and php)]===

===[https://docs.moodle.org/en/Hosting_for_server_admins 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation

Finding and Selecting A Web Host

2009-01-05T23:01:03Z

Awyatt: /* Who are you? Types of Moodle Instances */

==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!

https://docs.moodle.org/en/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===

[https://docs.moodle.org/en/Hosting_for_moodle_teachers 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.

===[https://docs.moodle.org/en/Hosting_for_moodle_admins The Moodle admin (limited to managing Moodle, but not other software packages on the server]===

===[https://docs.moodle.org/en/Hosting_for_moodle_admins_advanced The Advanced Moodle admin (managing Moodle as well as getting into server side considerations, such as database management and php)]===

===[https://docs.moodle.org/en/Hosting_for_server_admins 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/

https://docs.moodle.org/en/Decision_FAQ#What_is_a_Moodle_Partner.3F

===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, https://docs.moodle.org/en/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==
[https://docs.moodle.org/en/Web_Hosts 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. 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===
[http://www.murphys-laws.com/murphy/murphy-true.html 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. This cron doc https://docs.moodle.org/en/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, https://docs.moodle.org/en/Email_settings and https://docs.moodle.org/en/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 [http://en.wikipedia.org/wiki/Uptime system uptime] and the implications thereby for the amount of time that a [http://en.wikipedia.org/wiki/High_availability 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 [http://en.wikipedia.org/wiki/Service_level_agreement a basic discussion of SLAs], a review of [http://www.nkarten.com/sla.html Naomi Karten's site], which is pitched at the vendor might prove helpful. There are [http://www.service-level-agreement.net/ commercial SLA kits as well].

By way of example, consider [https://confluence.delhi.edu/display/CIS/Moodlerooms+Service+Level+Agreement the SLA between Delhi SUNY and Moodlerooms] ([https://confluence.delhi.edu/pages/diffpages.action?pageId=82083866&originalId=82346012 and see this comparison]), an SLA in pdf format for [http://www.northumbrialearning.co.uk/documents/legal/moodle_hosting.pdf North Umbria Learning], and an SLA in MS Word format for [http://www.kwantlen.ca/__shared/assets/Moodle_Service_Level_Agreement4387.doc 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, [http://www.kentlaw.edu/perritt/courses/property/Hohfeld.htm 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=

https://docs.moodle.org/en/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 [http://books.google.com/books?id=lUG4_EIY0tAC&pg=PA54 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==
https://docs.moodle.org/en/Planning_your_installation