Administration via command line: Difference between revisions
Helen Foster (talk | contribs) (Tool for converting innodb tables to Barracuda) |
|||
Line 193: | Line 193: | ||
==Tool for converting innodb tables to Barracuda== | ==Tool for converting innodb tables to Barracuda== | ||
Some users upgrading to 2.8 are getting the following MySQL error during the course restoration procedure: | |||
' | Row size too large (>8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. | ||
This is due MySQL default type (Antelope) cannot handle more than 10 text columns. We strongly recommemd you change the default type to Barracuda. | |||
We've created a tool specially to help users on this database type conversion. Please use the command below to do the change on your database. | |||
php admin/cli/mysql_compressed_rows.php | |||
[[fr:Administration en ligne de commande]] | [[fr:Administration en ligne de commande]] |
Revision as of 07:39, 9 February 2015
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 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
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 via command line
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/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 the 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 at the 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 of your Moodle system), 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
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
Since Moodle 2.7
Scheduled tasks are automatically run by the cron script above, 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.
Update user pictures via command line
http://moodle.org/pluginfile.php/143/mod_forum/attachment/926929/updatepics.php
Tested for 2.3.1+
Place this file in /admin/cli/updatepics.php
How to use: Run with "dir" option to specify which directory contains the files.
.../admin/cli/updatepics.php --dir=PATH_TO_DIR
- File names must be identical to usernames
Manage MOD's,Blocks via command line
Here are two scripts to help you manage your plugins.
http://tracker.moodle.org/browse/MDL-35736
How to use "manage_blocks.php": place in /admin/cli
hide: ../admin/cli/manage_blocks.php --name=tag_youtube --hide
show: ../admin/cli/manage_blocks.php --name=tag_youtube --show
delete: ../admin/cli/manage_blocks.php --name=tag_youtube --delete
protect: ../admin/cli/manage_blocks.php --name=tag_youtube --protect
unprotect: ../admin/cli/manage_blocks.php --name=tag_youtube --unprotect
(obviously - replace "tag_youtube" with the blockthat you want to remove...)
How to use "manage_mods.php":
hide: ../admin/cli/manage_blocks.php --name=game --hide
show: ../admin/cli/manage_blocks.php --name=game --show
delete: ../admin/cli/manage_blocks.php --name=game --delete
- Important!
this script does not delete the relevant folder in /moodle/mod or /moodle/blocks
you have to delete it yourself !
Update language pack via CLI
http://tracker.moodle.org/browse/MDL-35735
Place attached file in /admin/cli and simply run it, without any command-line arguments :)
ReSort course list via CLI
http://tracker.moodle.org/browse/MDL-36237
Place attached file in /admin/cli and simply run it, without any command-line arguments :)
I import courses every night from an external system, and run this script afterwards
Purge caches via CLI
You can purge caches using this script:
php admin/cli/purge_caches.php
Tool for converting innodb tables to Barracuda
Some users upgrading to 2.8 are getting the following MySQL error during the course restoration procedure:
Row size too large (>8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help.
This is due MySQL default type (Antelope) cannot handle more than 10 text columns. We strongly recommemd you change the default type to Barracuda.
We've created a tool specially to help users on this database type conversion. Please use the command below to do the change on your database.
php admin/cli/mysql_compressed_rows.php