Note: This documentation is for Moodle 2.7. For up-to-date documentation see Administration via command line.

Administration via command line: Difference between revisions

From MoodleDocs
m (removing 2.0 template)
(→‎Converting InnoDB tables to Barracuda: copying changes from 28 docs)
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
If you have shell access to your web server, you may find various CLI (command line interface) scripts useful during Moodle administration. All command line tools are located in <code>admin/cli/*</code> directory. To avoid problems with access control, you should run them as the owner of the web server process. It is especially important for CLI installation and upgrade as they create new files in moodledata directory and the web server has to have write access to them. In Linux distributions, the user that runs the web server is usually apache or wwrun or httpd or something similar. As a root, you will probably want to execute Moodle CLI scripts like this:
{{Installing Moodle}}
==Running CLI scripts==
If you have shell access to your web server, you may find various CLI (command line interface) scripts useful during Moodle administration. Core admin CLI tools are located in the <code>admin/cli/*</code> folder. Other plugins provide their CLI functionality via scripts in their own cli folder. For example, the enrol_db sync script is located in <code>enrol/db/cli/</code>.
 
To avoid problems with access control, you should run them as the owner of the web server process. It is especially important for CLI installation and upgrade as they create new files in moodledata directory and the web server has to have write access to them. In Linux distributions, the user that runs the web server is usually apache or wwrun or httpd or something similar. As a root, you will probably want to execute Moodle CLI scripts like this:


     $ cd /path/to/your/moodle/dir
     $ cd /path/to/your/moodle/dir
Line 8: Line 12:
     $ sudo -u apache /usr/bin/php admin/cli/install.php --help
     $ sudo -u apache /usr/bin/php admin/cli/install.php --help


== Upgrading ==


== Installation via command line ==
Moodle can be upgraded from the command line. As with the installation script, there is either interactive or non-interactive mode of the upgrade. The script itself does not put the site into the maintenance mode, you have to do it on your own. Also, the script does not backup any data (if you read this page, you probably have some own scripts to backup your moodledata and the database, right?)


Since version 2.0, Moodle can be installed from the command line. There are two modes of installation. In interactive mode, the install script asks you for all data needed to properly set up new Moodle site. In non-interactive mode, you must provide all required data as the script parameters and then the new site is installed silently. The parameters can be passed in the interactive mode, too. The provided values are then used as the default values during the interactive session.
    $ sudo -u apache /usr/bin/php admin/cli/upgrade.php
 
Upgrading via command line is a very comfortable way of Moodle upgrade if you use Git checkout of the Moodle source code (see [[Git for Administrators]]). See the following procedure how to upgrade your site within several seconds to the most recent version while preserving your eventual local customizations tracked in git repository:
 
    $ cd /var/www/sites/moodle/htdocs/
    $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
    $ git pull
    $ sudo -u apache /usr/bin/php admin/cli/upgrade.php
    $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable
 
== Installation ==
 
There are two modes of installing Moodle from the command line. In interactive mode, the install script asks you for all data needed to properly set up new Moodle site. In non-interactive mode, you must provide all required data as the script parameters and then the new site is installed silently. The parameters can be passed in the interactive mode, too. The provided values are then used as the default values during the interactive session.


     $ sudo -u apache /usr/bin/php admin/cli/install.php --lang=cs
     $ sudo -u apache /usr/bin/php admin/cli/install.php --lang=cs
Line 21: Line 38:
     $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
     $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable


To turn the maintenance mode off, just execute the same script with --disable parameter.
To turn maintenance mode off, just execute the same script with --disable parameter.


== Offline mode ==
== Offline mode ==
Line 31: Line 48:


You can prepare a nice formatted HTML page to inform your users about the server being down and keep in the moodledata directory under a name like <code>climaintenance.off</code> and rename it to the <code>climaintenance.html</code> if needed.
You can prepare a nice formatted HTML page to inform your users about the server being down and keep in the moodledata directory under a name like <code>climaintenance.off</code> and rename it to the <code>climaintenance.html</code> if needed.
== Upgrading via command line ==
Moodle can be upgraded from the command line. As with the installation script, there is either interactive or non-interactive mode of the upgrade. The script itself does not put the site into the maintenance mode, you have to do it on your own. Also, the script does not backup any data (if you read this page, you probably have some own scripts to backup your moodledata and the database, right?)
    $ sudo -u apache /usr/bin/php admin/cli/upgrade.php --non-interactive
Upgrading via command line is a very comfortable way of Moodle upgrade if you use [[CVS]] or [[Git|git]] checkout of the Moodle source code. See the following procedure how to upgrade your site within several seconds to the most recent version while preserving your eventual local customizations tracked in git repository:
    $ cd /var/www/sites/moodle/htdocs/
    $ git fetch
    $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
    $ git merge origin/cvshead
    $ sudo -u apache /usr/bin/php admin/cli/upgrade.php
    $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable
===Issues with Upgrading via Command Line===
if your config.php contains information about several moodle instances (distinct moodle websites and databases sharing the same codebase), then this script will silently fail
The solution is to temporarily eliminate from config.php all but the one instance you want to upgrade
If this is a problem for the other instances (production sites), then modify the cli script to point to a copy of config.php  (which will be the one edited to contain only one moodle instance at a time)


== Custom site defaults ==
== Custom site defaults ==
Line 65: Line 59:
</code>
</code>


These defaults are used during install, upgrade and are also displayed as defaults at the Site administration pages.
These defaults are used during install, upgrade and are also displayed as defaults on Site administration pages.


== Reset user password ==
== Reset user password ==


If you happen to forget your admin password (or you want to set a password for any other user of your Moodle system), you can use reset_password.php script. The script sets the correctly salted password for the given user.
If you happen to forget your admin password (or you want to set a password for any other user on the site), you can use reset_password.php script. The script sets the correctly salted password for the given user.


     $ sudo -u apache /usr/bin/php admin/cli/reset_password.php
     $ sudo -u apache /usr/bin/php admin/cli/reset_password.php
Line 78: Line 72:


     $ sudo -u apache /usr/bin/php admin/cli/mysql_engine.php --engine=InnoDB
     $ sudo -u apache /usr/bin/php admin/cli/mysql_engine.php --engine=InnoDB
==Converting InnoDB tables to Barracuda==
Sites using MySQL with database tables using Antelope as the file format are recommended to convert the tables to the Barracuda file format.
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:
mdl_data                            Compact    (needs fixing)
mdl_data_fields                    Compact    (needs fixing)
mdl_enrol_paypal                    Compact    (needs fixing)
To proceed with the conversion, run the command using the fix option:
$ php admin/cli/mysql_compressed_rows.php --fix
Successful table conversion will be reported in the output, for example:
mdl_data                  ... Compressed
mdl_data_fields            ... Compressed
mdl_enrol_paypal          ... Compressed
Please note that the commands must be executed on your moodle directory. Once tables are fixed, the warning message will no longer be displayed.
For further information on InnoDB file formats see the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_antelope MySQL InnoDB glossary - Antelope] and the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_barracuda MySQL InnoDB glossary - Barracuda].


== Running cron via command line ==
== Running cron via command line ==
Line 83: Line 117:
In versions 1.x, you could execute admin/cron.php either from command line or via the web. Since Moodle 2.0, only admin/cli/cron.php script can be run via command line.
In versions 1.x, you could execute admin/cron.php either from command line or via the web. Since Moodle 2.0, only admin/cli/cron.php script can be run via command line.


[[Category:Installation]]
== Scheduled tasks ==
 
Scheduled tasks are automatically run by the cron script, but the specific tasks which run on each cron iteration are determined by the scheduled tasks configuration. It is possible to override the scheduled tasks configuration and run a single scheduled task immediately using the admin/tool/task/cli/schedule_task.php script.
 
This script accepts the following arguments:
 
--list - list all the known scheduled tasks. The tasks are listed by the class name used to run the task. This class name is required as the argument to the next option in order to run a specific task immediately.
 
--execute=<task> - Runs a single scheduled task immediately - regardless of scheduling settings. This will even run disabled tasks. Tasks will still use locking to prevent concurrent execution of the same task - even on clusters. The format of the <task> argument must be the same as returned by the --list option above.
 
'''Note:''' You must escape the "\" with an extra \ when using the --execute command. Take the following for example:
 
<pre>php schedule_task.php --list</pre>
 
will return something like:
 
<pre>
== List of scheduled tasks (http://yourserver.com/moodle) ==
\enrol_imsenterprise\task\cron_task                10 * * * * *      ASAP
\logstore_legacy\task\cleanup_task                * 5 * * * *      ASAP
\logstore_standard\task\cleanup_task              * 4 * * * *      Wednesday, November 12, 2014, 4:35 AM
\mod_forum\task\cron_task                          * * * * * *      ASAP
\core\task\automated_backup_task                  50 * * * * *      ASAP
 
...
</pre>
 
To run the first task in that list, you would execute
 
<pre>php schedule_task.php --execute=\\enrol_imsenterprise\\task\\cron_task</pre>
 
==Database transfer==
 
A command line script for [[Database transfer]] may be found in ''admin/tool/dbtransfer/cli/migrate.php''.
 
==Purge caches==
 
You can purge caches using this script:
 
  php admin/cli/purge_caches.php
 
==Fix course / module sequences==
 
In rare cases (such as after upgrading from a very old version of Moodle), the course / section / module sequence data can be out of sync. This can cause various problems for affected courses, such as sections not appearing, backups failing, pages not displaying etc. There is a specific check to check for errors caused by this problem, and to fix the data in the database if they are found. To run this script please use the command below:
 
  php admin/cli/fix_course_sequence.php -c=* --fix
 
This will check every course in Moodle and report which ones had errors and were fixed.
 
==See also==
 
* MDL-35736 - Manage plugins via command line
* MDL-36237 - Resort course list via CLI
 


[[fr:Administration en ligne de commande]]
[[fr:Administration en ligne de commande]]
[[de:Administration über Kommandozeile]]
[[ja:コマンドライン経由の管理]]
[[es:Administración por línea de comando]]

Latest revision as of 06:30, 1 July 2015

Running CLI scripts

If you have shell access to your web server, you may find various CLI (command line interface) scripts useful during Moodle administration. Core admin CLI tools are located in the admin/cli/* folder. Other plugins provide their CLI functionality via scripts in their own cli folder. For example, the enrol_db sync script is located in enrol/db/cli/.

To avoid problems with access control, you should run them as the owner of the web server process. It is especially important for CLI installation and upgrade as they create new files in moodledata directory and the web server has to have write access to them. In Linux distributions, the user that runs the web server is usually apache or wwrun or httpd or something similar. As a root, you will probably want to execute Moodle CLI scripts like this:

   $ cd /path/to/your/moodle/dir
   $ sudo -u apache /usr/bin/php admin/cli/somescript.php --params

Most of the scripts accept common --help (or -h) parameter to display the full usage information, for example:

   $ sudo -u apache /usr/bin/php admin/cli/install.php --help

Upgrading

Moodle can be upgraded from the command line. As with the installation script, there is either interactive or non-interactive mode of the upgrade. The script itself does not put the site into the maintenance mode, you have to do it on your own. Also, the script does not backup any data (if you read this page, you probably have some own scripts to backup your moodledata and the database, right?)

   $ sudo -u apache /usr/bin/php admin/cli/upgrade.php

Upgrading via command line is a very comfortable way of Moodle upgrade if you use Git checkout of the Moodle source code (see Git for Administrators). See the following procedure how to upgrade your site within several seconds to the most recent version while preserving your eventual local customizations tracked in git repository:

   $ cd /var/www/sites/moodle/htdocs/
   $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
   $ git pull
   $ sudo -u apache /usr/bin/php admin/cli/upgrade.php
   $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable

Installation

There are two modes of installing Moodle from the command line. In interactive mode, the install script asks you for all data needed to properly set up new Moodle site. In non-interactive mode, you must provide all required data as the script parameters and then the new site is installed silently. The parameters can be passed in the interactive mode, too. The provided values are then used as the default values during the interactive session.

   $ sudo -u apache /usr/bin/php admin/cli/install.php --lang=cs

Maintenance mode

To switch your site into the maintenance mode via CLI, you can use

   $ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable

To turn maintenance mode off, just execute the same script with --disable parameter.

Offline mode

In some situations, you may want to switch your Moodle site into offline mode so that it is not accessible via the web but you can not stop the web server completely (typically because there are other web pages and applications running there). If a file called climaintenance.html exists in the root folder of moodledata directory, Moodle will automatically display the contents of that file instead of any other page.

   $ cd /var/www/sites/moodle/moodledata/
   $ echo '<h1>Sorry, maintenance in progress</h1>' > climaintenance.html

You can prepare a nice formatted HTML page to inform your users about the server being down and keep in the moodledata directory under a name like climaintenance.off and rename it to the climaintenance.html if needed.

Custom site defaults

During the install and upgrade via CLI, Moodle sets the administration variables to the default values. You can use different defaults. See MDL-17850 for details. Shortly, all you need to do is to add a file local/defaults.php into your Moodle installation. The format of the file is like

<?php $defaults['pluginname']['settingname'] = 'settingvalue'; // for plugins $defaults['moodle']['settingname'] = 'settingvalue'; // for core settings

These defaults are used during install, upgrade and are also displayed as defaults on Site administration pages.

Reset user password

If you happen to forget your admin password (or you want to set a password for any other user on the site), you can use reset_password.php script. The script sets the correctly salted password for the given user.

   $ sudo -u apache /usr/bin/php admin/cli/reset_password.php

MySQL storage engine conversion

If you run your Moodle site with MySQL database backend and use the default MyISAM as the storage engine for your tables, you may want to convert them to use some more reliable engine like InnoDB (actually, you should want to switch to PostgreSQL ;-) anyway).

   $ sudo -u apache /usr/bin/php admin/cli/mysql_engine.php --engine=InnoDB

Converting InnoDB tables to Barracuda

Sites using MySQL with database tables using Antelope as the file format are recommended to convert the tables to the Barracuda file format.

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:

mdl_data                            Compact     (needs fixing) 
mdl_data_fields                     Compact     (needs fixing)
mdl_enrol_paypal                    Compact     (needs fixing)

To proceed with the conversion, run the command using the fix option:

$ php admin/cli/mysql_compressed_rows.php --fix

Successful table conversion will be reported in the output, for example:

mdl_data                   ... Compressed
mdl_data_fields            ... Compressed
mdl_enrol_paypal           ... Compressed

Please note that the commands must be executed on your moodle directory. Once tables are fixed, the warning message will no longer be displayed.

For further information on InnoDB file formats see the MySQL InnoDB glossary - Antelope and the MySQL InnoDB glossary - Barracuda.

Running cron via command line

In versions 1.x, you could execute admin/cron.php either from command line or via the web. Since Moodle 2.0, only admin/cli/cron.php script can be run via command line.

Scheduled tasks

Scheduled tasks are automatically run by the cron script, but the specific tasks which run on each cron iteration are determined by the scheduled tasks configuration. It is possible to override the scheduled tasks configuration and run a single scheduled task immediately using the admin/tool/task/cli/schedule_task.php script.

This script accepts the following arguments:

--list - list all the known scheduled tasks. The tasks are listed by the class name used to run the task. This class name is required as the argument to the next option in order to run a specific task immediately.
--execute=<task> - Runs a single scheduled task immediately - regardless of scheduling settings. This will even run disabled tasks. Tasks will still use locking to prevent concurrent execution of the same task - even on clusters. The format of the <task> argument must be the same as returned by the --list option above.

Note: You must escape the "\" with an extra \ when using the --execute command. Take the following for example:

php schedule_task.php --list

will return something like:

== List of scheduled tasks (http://yourserver.com/moodle) ==
\enrol_imsenterprise\task\cron_task                10 * * * * *      ASAP
\logstore_legacy\task\cleanup_task                 * 5 * * * *       ASAP
\logstore_standard\task\cleanup_task               * 4 * * * *       Wednesday, November 12, 2014, 4:35 AM
\mod_forum\task\cron_task                          * * * * * *       ASAP
\core\task\automated_backup_task                   50 * * * * *      ASAP

...

To run the first task in that list, you would execute

php schedule_task.php --execute=\\enrol_imsenterprise\\task\\cron_task

Database transfer

A command line script for Database transfer may be found in admin/tool/dbtransfer/cli/migrate.php.

Purge caches

You can purge caches using this script:

 php admin/cli/purge_caches.php

Fix course / module sequences

In rare cases (such as after upgrading from a very old version of Moodle), the course / section / module sequence data can be out of sync. This can cause various problems for affected courses, such as sections not appearing, backups failing, pages not displaying etc. There is a specific check to check for errors caused by this problem, and to fix the data in the database if they are found. To run this script please use the command below:

 php admin/cli/fix_course_sequence.php -c=* --fix

This will check every course in Moodle and report which ones had errors and were fixed.

See also