Moodle Administration 1. Authentication

Moodle Administration
Following tasks are associated with the moodle administration:
Managing accounts
Roles and permissions
Site appearance
Server settings
Site-wide reports
1. Authentication
Authentication is the process of allowing a user to login to a Moodle site based on their
username and password. Moodle provides a number of ways of managing authentication,
called authentication plugins.
Manual accounts - accounts created manually by an administrator
No login - suspend particular user account
Email-based self-registration - for enabling users to create their own accounts
CAS server (SSO) - account details are located on an external CAS server
External database - account details are located on an external database
FirstClass server - account details are located on an external FirstClass server
IMAP server - account details are located on an external IMAP server
LDAP server - account details are located on an external LDAP server
Moodle Network authentication - how different Moodle sites can connect and
authenticate users
NNTP server - account details are located on an external NNTP server
No authentication - for testing purposes only
PAM (Pluggable Authentication Modules) - account details come from the
operating system Moodle is running on, via PAM (can only be used Linux/Unix).
POP3 server - account details are located on an external POP3 server
RADIUS server - account details are located on an external RADIUS server
Shibboleth - account details are located on an external Shibboleth server
Web services authentication
Moodle Administration
2. Managing accounts
An administrator can perform various tasks relating to user accounts in Settings>Site
Administration>Users>Accounts. Following are the tasks that administrator can perform:
Browse list of users - search for, find and edit user accounts.
Bulk user actions - message, confirm, download or perform other actions on a large
group of users globally.
Add a new user - create one individual user account.
Upload users - bulk create new user accounts
User pictures - bulk upload profile pictures for users
User profile fields - create customised profile fields.
3. Enrolments
Enrolment, or 'enrollment', is the process of assigning users to roles (usually student) in a
course. Moodle provides a number of ways of managing course enrolment, called
enrolment plugins. Foolowing are the various ways supported by the moodle for
Manual enrolment - the administrator or course teacher adds users manually.
Self enrolment - a user can choose to enrol him/herself into a course.
Cohort sync - users are part of a Cohort which is added to the course.
Course meta link - users enrolled in other courses are given automatic access
Guest access - users can view course materials but not participate.
Category enrolments - users are enrolled in all courses in a category
External database - users are enrolled from a database such as Access, MySQL
Flat file -users are enrolled with a csv file.
IMS Enterprise - users are enrolled with this standard XML file format
LDAP enrolment - users are authenticated and then enrolled through LDAP
MNet remote enrolments - users are enrolled via a linked Moodle site
PayPal - users purchase enrolment with Paypal.
4. Roles and permissions
A role is a collection of permissions defined for the whole system that you can assign to
specific users in specific contexts. The combination of roles and context define a specific
user's ability to do something on any page. The most common examples are the roles of
student and teacher in the context of a course. Following is the list of items under the roles
and permsisions section:
Managing roles
Roles settings
Using roles
Standard roles
Creating custom roles
Training Programme under CAFT “Online Content Creation and Management in an eLearning Environment”
Moodle Administration
Override permissions
5. Security
Every web application software has security issues that are found from time to time,
usually involving some combination of input that the programmers did not anticipate. The
Moodle project takes security seriously, and is continuously improving Moodle to close
such holes as we find them. Following are some security recommendations/advice on how
best to keep your site secure and running:
 Update Moodle regularly on each release : Published security holes draw
crackers attention after release. The older the version, the more vulnerabilities
it is likely to contain.
 Register globals MUST be disabled : This will help prevent against possible
XSS problems in third-party scripts.
 Use strong passwords for admin and teachers : Choosing "difficult" passwords
is a basic security practice to protect against "brute force" cracking of accounts.
 Only give teacher accounts to trusted users. Avoid creating public sandboxes
with free teacher accounts on production servers. Teacher accounts have much
freer permissions and it is easier to create situations where data can be abused
or stolen.
 Separate your systems as much as possible : Another basic security technique is
to use different passwords on different systems, use different machines for
different services and so on. This will prevent damage being widespread even
if one account or one server is compromised.
6. Performance
Performance recommendations : Moodle can be made to perform very well, at small usage
levels or scaling up to many thousands of users. The factors involved in performance are
basically the same as for any PHP-based database-driven system. When trying to optimize
your server, try to focus on the factor which will make the most difference to the user. For
example, if you have relatively more users browsing than accessing the database, look to
improve the webserver performance.
7. Site Backup
A site backup allows a site administrator to save everything associated with a moodle site.
These backups can be restored to bring a site back to the point in time when the backup
was made. Performing regular backups are highly recommended to reduce the amount of
lost information in the event of a problem on the site and to speed the overall recovery
A Moodle system comprises three parts:
1. The data stored in the database (For example, a MySQL database)
2. The uploaded files (For example, site and course files uploaded via Moodle located
in moodledata)
Training Programme under CAFT “Online Content Creation and Management in an eLearning Environment”
Moodle Administration
3. The Moodle code (For example, everything in server/htdocs/moodle)
You can confirm where all these things are located in a Moodle installation by checking
the config.php file.
$CFG->dbname shows the database name
$CFG->prefix shows the the database table name prefix
$CFG->dataroot controls where the uploaded files are stored; and
$CFG->wwwroot points to where the code is stored.
Generally speaking, the database ("dbname and prefix") and the uploaded files (dataroot)
are the two most important to copy on a regular basis. These contain information that will
change most often.
The Moodle code (wwwroot) is less important as a frequent backup, since it will only
change when the the actual code is changed through upgrades, addins and code tweaks.
You can always get a copy of the standard Moodle code from
so you only have to backup the parts you added or changed yourself. Following are the
components that you need for creating a backup of your Moodle site :
The right way to back up your database depends on which database system you are
using. The instructions below are one way to back up a MySQL database. Another
option would be to use a tool like phpMyAdmin to manually make a backup. The
documentation for your database will give more options.
There are many ways to do such backups. Here is an outline of a little script you can
run on Unix to backup the database (it works well to have such a script run daily via a
cron task):
cd /my/backup/directory
mv moodle-database.sql.gz moodle-database-old.sql.gz
mysqldump -h -u myusername --password=mypassword -C -Q -e --create-options
mydatabasename > moodle-database.sql
gzip moodle-database.sql
Make sure that a database backup uses the correct character encoding. In most
databases, use UTF-8. When dumping the entire Moodle database, check for possible
character encoding issues. In some instances, backups created with mysqldump or
phpMyAdmin may not properly encode all of the data. This will result in non-readable
characters when the database is restored. One solution is to use MySQL Administrator
1.1 or another tool that will force a UTF-8 dump of the data. Following are the tools
for database backups :
o phpMyAdmin :phpMyAdmin is the tool of choice with most web hosting
o MySQLDumper :MySQLDumper is a backup script for MySQL databases,
written in PHP and Perl. MySQLDumper uses a proprietary technique to
Training Programme under CAFT “Online Content Creation and Management in an eLearning Environment”
Moodle Administration
avoid execution interruption when running PHP scripts (the max. execution
time is usually set to 30 seconds). MySQLDumper also cares for the
encoding problems mentioned above. It also works with compressed files
and allows setting up regular cron jobs for updating and updating to a
remote FTP site.
Uploaded files (moodledata)
Through the Moodle interface, users can upload or create files and folders. These are
located in a directory, often called "moodledata". Since they are just files and folders,
there are many different ways to backup or copy moodledata.
For example, using a file transfer program, copy the entire moodledata directory to a
different area, drive or computer. Example of file transfer programs include: FTP,
WinSP, wget, rsync. You might use a compression program to create compact files
(tar, zip. 7z, XZ, BZIP2, GZIP, and WIM are a few file formats) of the entire
directory. This can be done before or after file transfers. Typically not all moodledata
files change between regular/periodic backups. A new Administrator might want to
look into incremental or other efficient backups procedures. Depending upon the
operating environment there are many tools for backing up server files and ways of
backing up moodledata.
Moodle code
Backing up the Moodle code, will be similar to backing up moodledata. It is always a
good idea to have several backup copies of your Moodle code files. While you can
always download a fresh base copy of the Moodle code from, you might have customized that code. It is a good idea to
create a separate backup of your Moodle code before you customize the code. This
includes installing Contributed code, Themes and upgrading.
8. Site appearance
There are many ways to customise the appearance of your Moodle site so that it blends in
with, for example, your college site or your company's corporate brand. Following are the
sections that you can change for personalising the appearance of Moodle:
Front page - how best to display the entry page to your Moodle.
My Moodle - a personalised "dashboard" page for each user
Navigation - control how users find their way around Moodle
Course list - control who appears in the list of courses
Themes - change the "skin" of your Moodle for the whole site or just sections.
Header and footer - add information to the top and bottom areas of your Moodle.
9. Language
There are a number of language settings for administrators in Settings > Site
administration > Language > Language settings. By default, Moodle detects a user's
Training Programme under CAFT “Online Content Creation and Management in an eLearning Environment”
Moodle Administration
language from their browser setting. However, language auto-detection may be disabled so
that the default site language is used instead. One can sets the default language for a site.
This setting can be overridden by users using the language menu or the setting in their
personal profile. If a preferred language is set in your browser then this will override the
default site language (unless language auto-detection is disabled). You can enable
localised error messages for database connection problems by add the following line to
your config.php file:
10.Server settings
A Moodle administrator needs to set or track following while managing a Moodle site:
System paths
Session handling
Maintenance mode
Site registration
11.Site-wide reports
In addition to reports available at both site and course level, the following site-wide
reports are available for administrators:
Config changes report - Shows changes made by an administrator to the site
Course overview report
Question instances report - Reports where particular question types are used on the site
Training Programme under CAFT “Online Content Creation and Management in an eLearning Environment”