Backup important data
There are three areas that should be backed up before any upgrade:
Moodle software (For example, everything in server/htdocs/moodle)
mv /var/www/html/moodle /var/www/html/moodlebkup
Moodle uploaded files (For example, server/moodledata)
#cd /var/
tar -cvf moodledata.tar moodledata
Moodle database (For example, your Postgres or MySQL database dump)
mysqldump -u root -p moodle > /root/data-moodle.sql
Put your site into maintenance mode
sudo -u apache /usr/bin/php /var/www/html/moodle/admin/cli/maintenance.php --enable
Install the new Moodle software
cd /var/www/html/
tar xvzf moodle-latest-3.8.tgz
Next, copy across your config.php, any custom plugins, and your .htaccess file if
you created one (check that custom plugins are the correct version for your new
Moodle first):
#cd /var/www/html/
cp moodlebkup/config.php moodle
cp -pr moodlebkup/theme/mytheme moodle/theme/mytheme (if exists)
cp -pr moodlebkup/mod/mymod moodle/mod/mymod (if exits)
Don't forget to make moodle/config.php (and the rest of the source code) readable
by your www server. For maximum security the files should not be writeable by your
server. This is especially important on a 'production' server open to the public
internet.
chown -R root:root /var/www/html/moodle (Linux debian - or even create a user
especially for moodle. Don't use the web server user, e.g. www-data/apache)
chmod -R 755 /var/www/html/moodle
If you use cron, take care that cron.php is executeable and uses the correct php
command:
chmod 740 /var/www/html/moodle/admin/cli/cron.php (some configurations need chmod
750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or
'#!/usr/local/bin/php5.3', no need to copy '<?php')
----------------
ONE Time if migration from version earlier then 3.2 to 3.2. Then DB enginee
conversion is required.
---------
MySQL storage engine conversion
cd /var/www/html/moodle/
/usr/bin/php admin/cli/mysql_engine.php --engine=InnoDB
Converting InnoDB tables to Barracuda
This is because tables using Antelope as the file format cannot handle more than 10
text columns. This file formats only supports compact and redundant row formats for
backward compatibility reasons. This may cause a problem on larger sites when
restoring a course, in which case the following error will be displayed:
Row size too large (>8126). Changing some columns to TEXT or BLOB or using
ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help.
Barracuda is the newest innoDB file format. In addition to supporting compact and
redundant row formats, Barracuda also supports compressed and dynamic row formats.
However, converting tables to Barracuda is only recommended, and not required,
since not all MySQL users are affected. (It may only be a problem for larger
sites.)
Tool for converting tables
A command line tool is included in Moodle for converting tables to Barracuda.
To view tables requiring conversion, use the list option:
$ php admin/cli/mysql_compressed_rows.php --list
Here is an example output:
[root@pho-moodle-01 moodle]# php admin/cli/mysql_compressed_rows.php --list
mdl_certificate Compact (needs fixing)
mdl_data Compact (needs fixing)
mdl_data_fields Compact (needs fixing)
mdl_enrol_paypal Compact (needs fixing)
mdl_lti Compact (needs fixing)
mdl_user Compact (needs fixing)
mdl_user_info_field Compact (needs fixing)
To proceed with the conversion, run the command using the fix option:
[root@pho-moodle-01 moodle]# php admin/cli/mysql_compressed_rows.php --fix
mdl_certificate ... Compressed
mdl_data ... Compressed
mdl_data_fields ... Compressed
mdl_enrol_paypal ... Compressed
mdl_lti ... Compressed
mdl_user ... Compressed
mdl_user_info_field ... Compressed
Converting to the new character set and collation
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
------
Upgrade moodle
sudo -u apache /usr/bin/php /var/www/html/moodle/admin/cli/upgrade.php (if error
occured databse cannot be read then use the GUI method)
OR From GUi
https://moodle.sngpl.com.pk/admin/index.php
Disable maintence mode
sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable
-----------------------
if necessary. However, for a simple upgrade, there should be no need to change
anything with cron.
CREATE USER 'root' IDENTIFIED BY 'lms';
GRANT USAGE ON *.* TO 'root'@localhost IDENTIFIED BY 'lms';
GRANT ALL privileges ON moodle.* TO 'root'@localhost;
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'root'@localhost;
--------------------------------------
Reset mariadb root password:
sudo systemctl stop mariadb
Start the database without loading the grant tables or enabling networking:
sudo mysqld_safe --skip-grant-tables --skip-networking &
Now you can connect to the database as the root user, which should not ask for a
password.
mysql -u root
You�ll immediately see a database shell prompt instead.
Now that you have root access, you can change the root password.
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('lms');
mv /var/www/html/moodle /var/www/html/moodlebkup
scp -P 1010 moodle/config.php 172.22.24.110:/var/www/html/moodle
scp -P 1010 -r /var/moodledata/ 172.22.24.110:/var/
cd /var/www/html/moodle/theme/
scp -P 1010 -r canvas/ klass/ shoelace/ theme_shoelace_moodle30_2015121901/
172.22.24.110:/var/www/html/moodle/theme
cd /var/www/html/moodle/mod
scp -P 1010 -r certificate/ 172.22.24.110:/var/www/html/moodle/mod
mysql -u root -p
CREATE DATABASE moodle;
mysql -u root -p moodle < data-dump.sql
sudo php /var/www/html/moodle/admin/purgecaches.php
Optional Optimization
I recently found on our Moodle server that students were timing out when trying to
self-enrol on a course.
To rectify this I edited /etc/php/7.2/apache2/php.ini and increased the
max_execution_time to 360.
To boost the enrolment process, one can change the frequency of the self enrolment
synchronise enrolments task (default every 10 minutes):
Site Administration > Server > Scheduled tasks > Edit task schedule: Self enrolment
synchronise enrolments task
Change the /10 into /1 to have this task run every minute ( change into * to run
the script every minute.)
