Moodle 2 Administration

There are a number of different environments in which you can set up Moodle. The three main criteria that should dictate the choice of the correct setup are:

In addition to these three key criteria that usually influence the decision about the underlying infrastructure, there are other factors that will have an impact on your decision, such as in-house expertise, compatibility with other systems, personal preference, and existing resources.

We will cover the three most popular operating systems for hosting Moodle Linux, Windows, and Mac OS. For other setups such as on a memory stick, in a virtualized environment, or a larger multiserver cluster, please consult your local Moodle Partner (www.moodle.com). Some hosting companies offer quick one-click installations (often via the Fantastico installer, which usually doesn't contain the latest version). While the resulting Moodle system is sufficient for experimental sites, it is certainly unsuitable for production environments.

There are a number of hardware and software requirements that must be installed before we can start installing Moodle.

Go to download.moodle.org to download Moodle. As you can see, there are quite a number of distributions to choose from.

There are four types of builds available on Moodle's download site:

Each version is made available in the two compressed formats: TGZ (use the tar command to uncompress) and ZIP (requires unzip). You can either download them by clicking on the respective link or, if you have (secure) shell access, retrieve the file directly by using the wget command (The file name is kept in sync with the current version number, which increases every 6 months; for example, moodle-latest-22, moodle-latest-24, and so on):

wget http://download.moodle.org/stable21/moodle-latest-21.zip

Once you have moved the file to the location where you want to install it on your web server (dirroot), extract the file using the unzip command (or tar xvfz if you downloaded the TGZ version). In a hosted environment, you might have to use the uncompressing method provided by the web administration interface (cPanel, Plesk, or any bespoke system).

unzip moodle-latest-21.zip
tar xvfz moodle-latest-21.tgz

If you place the entire folder in your web server documents directory, the site will be located at www.yourwebserver.com/moodle. To access your site from www.yourwebserver.com, copy the contents directly into the main web server's documents directory.

Once this has been successfully done, you have to create the database that Moodle uses to store its data.

Moodle requires a database where it can store its information. While it is possible to share an existing database, it is highly recommended to create a separate database for Moodle. This can either be done via a web interface, as provided by hosted servers, or via the Unix command line.

Using a hosted server

Most hosting providers provide a dedicated web interface to carry out basic database operations. Alternatively, you can use phpMyAdmin, an open source software that allows you to manage MySQL databases over the Web. It is part of most Linux distributions and also part of many control panels, such as cPanel or Plesk. (phpMyAdmin is often configured not to allow new databases to be created. If this is the case, you have to create the database from the database manager in your control panel.)

Once you have started phpMyAdmin, go to the Databases section and create a new database using the UTF collation. You don't need to create any tables; Moodle will be populating the database during the installation process.

While you can use the existing account of a database user, it is good practice to create a dedicated user for the Moodle database. This step is carried out in the Privileges section.

Note

Do not use the MySQL root account for your Moodle database!

phpMyAdmin allows you to perform both steps creating a database and adding a new user in a single action as shown in the following screenshot. We will create a user book and also check the Create database with same name and grant all privileges option.

mysqladmin -u root -p reload

order deny,allow
deny from all

The installer script performs two main actions populating the database and creating the configuration file config.php. The Moodle installer is initiated by entering the URL of wwwroot (the location where you copied Moodle) into your web browser; Moodle will recognize that it hasn't been installed yet and start the process automatically.

The Moodle installer has to set a session cookie. If your browser has been configured to trigger a warning, make sure you accept that cookie.

The first screen lets you choose the language to be used during installation. This is not the locale used for Moodle, only the language for the installation.

The following screen displays the expected values for the Web address of the site (wwwroot), the Moodle directory (dirroot)and the Data directory (dataroot). You might have to modify the data directory entry if the location of your moodledata differs.

If dataroot cannot be located or does not have the correct permissions, an error message with details will be displayed. The same applies if dataroot is accessible directly via the Web and hence is not secure.

In the following screenshot, you have to select which database you wish to use. On my system, only the standard MySQL driver is installed. To use other database systems such as PostgreSQL, Oracle, or MS SQL Server, a driver has to be installed first.

This interface is using the configuration details that have been previously established. This would look slightly different if you have chosen a different database driver to the native MySQL.

Once you see the following screen, you will know the Moodle configuration file config.php has been successfully created. If the creation of the configuration file fails (usually because of incorrect permissions) the installer will display the content of the configuration file. You will have to copy, the text from the screen and paste it to config.php in your dirroot.

Before Moodle can proceed with the installation, you have to agree to the GPL license agreement. You can find the full license text at docs.moodle.org/en/License.

Once you have accepted the license agreement, the Moodle installer checks to see if certain components are installed. Not all modules are compulsory see the Moodle prerequisites section in this chapter and notices on screen. The installer also verifies the key PHP settings. If any of the tests are not passed, it is important that you go back to the Software requirements section to resolve any problems and restart the installation process after the issues have been fixed. Otherwise, some features may not work or the installer will not continue, depending on the importance of the module.

Once this screen has been confirmed, the Moodle installer will create all tables in the database. This process might take a few minutes.

Once the table creation and population have been concluded, you will see the screen to set up the administrator account. The default username is admin, which should be changed for security reasons. The self-explanatory fields you have to fill in are New password, First name, Surname, Email address, City/town and Select a country. All other fields are explained in great detail in Chapter 5, User Management.

The last screen of the installation script asks you to enter some front page settings, namely, the Full site name, Short name for site and Front page description. These front page settings can be modified later (see Chapter 7, Moodle Look and Feel). Additionally, the installer allows you to turn on Self registration. Leave this disabled for now, until you have covered Chapter 5,

Once this information has been entered and the screen has been confirmed, you are ready to start using Moodle. However, it is recommended to finalize the installation and setting up the execution of the Moodle maintenance script.

To make sure that Moodle is running without problems, go to Notifications in the Site administration menu in the Settings block.

In my installation, there are two issues a PHP setting has a value that is not recommended (I have to change this in the php.ini file) and the so-called cron maintenance script has not run for 24 hours. We will solve that mystery after we have registered our site. Other messages might appear in the Notifications area and you should resolve them in due course.

You might also want to check out http://<yoursite>/admin/health.php, which provides a mini health center that points out any additional issues. For each identified problem, a description, its severity level, and a solution are displayed.

Moodle provides some statistics about its usage on www.moodle.org/stats. To be included in these figures, you have to register your Moodle site. Registration (below the Notification link) with moodle.org (MOOCH) is optional and free, and you decide what information will be made public. Even if you opt out of providing any usage patterns for your site, it is still highly recommended to register, as you will get occasional notices from moodle.org. For example advanced security alerts.

After entering the details, you will have to confirm the submission and enter a reCAPTCHA (a slightly distorted image showing text). You also have the ability to unregister your site at any time.

The settings for the registration screen are as follows:

Moodle has to perform a number of background tasks on a regular basis. The script that performs these tasks is known as a cron script and is executed by the so-called cron process. An entire page has been dedicated to this in the Moodle documentation; you can find it at docs.moodle.org/en/Cron. It is important that you set up the cron process. Otherwise, any timed Moodle features, such as scheduled backups, sending forum notifications, statistics processing, and so on, will not work.

The script cron.php is located in the admin directory and can be triggered manually through a web browser (unless your security settings have been changed). Once executed, the output from the script (http://yoursite/admin/cron.php) is shown on screen and you have to navigate back to your Moodle system manually.

Most control panels allow you to set up scheduled tasks via a cron job management tool. Bear in mind that this is not part of Moodle but a part of your hosting package. The following screenshot is from the widely-used Plesk system, which executes the script every 5 minutes:

There are a number of ways to call the cron script. wget q O /dev/null http://<yoursite>/admin/cron.php is the most popular option in a Linux environment (see Command in the preceding screenshot). However, if this does not suit your setup, check out docs.moodle.org/en/Cron for alternatives.

The interface shown earlier creates an entry in the crontab, a file located in the /etc directory that contains all system-wide cron entries. This file can also be edited manually using crontab -e, but be careful to get the syntax right!

This concludes the installation process for Moodle in a LAMP environment. If you have come across any problems that have not been covered in these instructions, or if your setup differs from the one described, go to docs.moodle.org/en/Installing_Moodle, where more installation details are provided and exceptions are covered in greater detail.

The high-level process for updating a Moodle system is as follows:

If you are updating from a previous version of Moodle, the process is the same. However, double-check the Upgrading document at docs.moodle.org/en/Upgrading for any version-specific issues.

For example, if your current Moodle system is still on version 1.8 and you wish to update to version 2.1, you will first have to update to the latest version of 1.9 before updating to the latest version of 2.1. However, you can update from 2.1 straight to 2.1.5.

Creating a backup

Before you install a new update, it is highly recommended that you create a backup of your Moodle system. While most updates will run smoothly, the backup will be required if you have to revert the system to the pre-update version. There are three parts that have to be backed up:

• Database: There are two ways you can create a so called database dump from a MySQL database, either via command line or via Moodle's optional database interface.

  The simplest syntax for the command line tool is:

mysqldump -u <user> -p <database>>backup.sql

• To restore the database you need to use the mysql command line tool as follows:

mysql -u <user> -p <database><backup.sql

• The interface for the database tool is accessed via Server | phpMyAdmin. This is an optional module and has to be installed separately (it is the MySQL Admin add-on see Chapter 14, Installing Third-party Add-ons for more details).

  Click on the Export link on the front page, select the database to export, and click on Go, as shown in the following screenshot. The output of the command will be displayed on screen:

• Data directory: This is the moodledata directory. Create a copy of this elsewhere on the server (using cp R) or create an archive using the tar command (tar cvf moodledata).

• Moodle: This is the Moodle software itself. Create a copy of the directory elsewhere on the server. While only some parts of this backup are required (config.php, added themes, modified language packs, and so on), it is good practice to create a backup of the entire software. Finally, rename your Moodle system from moodle to say, moodle.old (mv moodle moodle.old).

Note

For more information on backups, check out Chapter 13,

Running the update script

Once you go to the location of your Moodle site and login in as administrator, the system will recognize that a new version is available and kick off the installer automatically.

The first screen displays the build of the new version (here, 2.0.1+) and asks you to confirm that you wish to go ahead with the upgrade.

Next, a screen is displayed that provides a link to the release notes and performs the same server check as the one described during the installation.

Moodle plugins, whether core or third-party, sometimes cause problems when upgrading Moodle. The installer lists all components and states whether they are Standard, Non-Standard, Extension, or Incompatible. The Status column highlights any actions required or problems found. You will need to resolve any issues that have arisen. See Chapter 14, Installing Third-party Add-ons, for more details.

Once this screen has been confirmed, the actual installation starts, during which new database fields are created and data is modified if and when necessary. Any new system settings that have been added to Moodle are shown and can be changed straightaway. For example, in the following screenshot, a new Path to dot parameter has been added to the System paths section.

Once the upgrade process has been completed, make sure you check the Notifications page as earlier. Also, don't forget to turn off the Maintenance mode!

As you would expect, Moodle updates can also be run using the already-discussed CLI. Once you have backed up your data and updated to the latest version, all you need to do is run the following script:

sudo u www-root /usr/bin/php admin/cli/upgrade.php --non-interactive

Updating Moodle via CLI is even more powerful when combined with the CVS or GIT checkout of the Moodle source code. That is what we will look at next.

An alternative approach exists to keep a current version up-to-date. It uses open source versioning systems which are supported by Moodle, namely, CVS and GIT. All checked-in Moodle code is made available via this method, which allows you to update only the modules that have actually changed.

The repository cvs.moodle.org is a read-only version of git.moodle.org. First, we are going to describe the basics of how to set up CVS. CVS has to be installed on your Moodle server. The first time you use CVS, you have to download the full version of Moodle, as follows:

cvs -z3 -d:pserver:anonymous@cvs.moodle.org:/cvsroot/moodle co d <directory> -r <version>Moodle

<directory> is the location where your Moodle system is installed and<version> specifies the version you wish to install, for example, MOODLE_21_WEEKLY or MOODLE_20_STABLE.

Once this has been successful, go to your Moodle site and you will be guided through the same update process as discussed earlier. If this fails, check that the user and group permissions are set correctly and adjust them accordingly (chown R <user>:<group> moodle).

For further updates you should use the following command, which remembers your previous settings, such as the chosen mirror site:

cvs update -dP

For further options of how to use CVS from the command line and in operating systems other than Unix, check out docs.moodle.org/en/CVS_for_Administrators.

Setting up GIT is a cumbersome process, which is beyond the scope of this book. You can find details at docs.moodle.org/en/Git. However, once set up, GIT is a very streamlined system to use, particularly in conjunction with the CLI we discussed earlier.

The following is a sample script which gets the latest version of the source code, puts Moodle in maintenance mode, merges the old code with the new, runs the upgrade script, and disables the maintenance mode.

git fetch
sudo -u www-root /usr/bin/php admin/cli/maintenance.php --enable
git merge origin/cvshead
sudo -u www-root/usr/bin/php admin/cli/upgrade.php
sudo -u www-root/usr/bin/php admin/cli/maintenance.php --disable

If you have changed any core code, potential conflicts might arise and will have to be resolved (CVS and GIT will prompt you to do so).

You might also come across some conflicting advice on whether to use CVS or GIT for production sites or not. The advantages are that your system is always up-to-date and that the updates are carried out automatically. The disadvantages are that the update process might require intervention to resolve any conflicts or it might fail, especially when a lot of third-party add-ons have been employed.