Meza/Commands

New Enhanced Documentation

See the Full Command Reference including previously undocumented commands.

Help

If you run the meza command all by itself (or with the short -h or long option --help for help), it will display general or context-sensitive help.

Visual Overview of Deploy

For a visual graph of the site.yml playbook, or any other Meza/Ansible playbook see the Ansible Playbook Grapher

Pass-through

Meza is written in Python, and is a logic wrapper to Ansible underneath. Meza ultimately passes through command-line options and arguments to Ansible's ansible-playbook command. You can see this when you issue a meza command, as the first thing it outputs is the underlying ansible command being executed. For example:

sudo meza deploy <environment> --list-tags (where <environment> is your environment name, which is likely monolith or vagrant)

Shows this:

sudo -u meza-ansible ansible-playbook /opt/meza/src/playbooks/site.yml -i /opt/conf-meza/secret/monolith/hosts --vault-password-file /opt/conf-meza/users/meza-ansible/.vault-pass-monolith.txt --extra-vars '{"env": "monolith"}' --list-tags

So, if there are ansible-playbook options that you wish to use, you can do so. Particularly useful for getting to know Meza are the --list-tags, and --list-tasks options to ansible-playbook. These options cause Ansible to go into a 'dry-run' mode for the playbook, telling you more about it without executing any actions.

Meanwhile, the --tags and --skip-tags options control Ansible's selection of what specific tasks to run, according to the tags associated with tasks in the playbook. These come in handly when you want to target a specific aspect of your deployment.

Tasks

There is a lot of detail in the list-tasks output.

In the task list, you can see tags that are associated at the task level. Again, this command will not execute a deploy. It will show you the tasks that would be run.

sudo meza deploy monolith --list-tasks

As we saw earlier, at the very start of output, it shows you the underlying Ansible command which is invoked by Meza:

sudo -u meza-ansible ansible-playbook /opt/meza/src/playbooks/site.yml -i /opt/conf-meza/secret/monolith/hosts --vault-password-file /opt/conf-meza/users/meza-ansible/.vault-pass-monolith.txt --extra-vars '{"env": "monolith"}' --list-tasks

Using Tags and Skipping Tags

To be written. In our next update, we'll show you how to use and skip tags. You can even combine listing and skipping.

sudo meza deploy monolith --list-tasks --skip-tags cron Will show you all the tasks that would be executed if you skipped the cron tasks.

After making configuration changes to a meza wiki server, it will be common to run deploy with options such as this example:

sudo meza deploy monolith --tags mediawiki,parsoid (one or both) and/or --skip-tags latest,update.php,verify-wiki,smw-data,search-index (one or more)

Tags we recommend typically specifying:

mediawiki specifies all mediawiki setup steps, including config changes

parsoid is rarely necessary to specify, but it comes after mediawiki so if you're repeatedly running things starting at mediawiki it can be handy to run to the end by also specifying parsoid

Tags that are often a good idea to skip:

latest gets the latest versions of software, including git-fetch of mediawiki core and extensions. This can take a long time (but may be necessary to include if you add an extension).
- TO-DO: There are also ways to specify just git extensions or just composer extensions, or just meza core extensions versus local config extensions.
update.php updates the MediaWiki database. This is not required if you're not changing MediaWiki version or extensions that make database changes. This takes a long time on large/plentiful wikis.
verify-wiki basically makes sure a bunch of stuff is present for each wiki, but it does not do specific config for each wiki. So if you make a wiki config change you still can skip this.
smw-data rebuilds SMW data. This takes ~24 hours on large wikis. This won't run unless a new wiki is created/imported, but you can still specify to skip it just to be sure.
search-index rebuilds the Elasticsearch data. This takes several hours on large wikis.
mediawiki-core git clone core Mediawiki, verifies ownership of directory structure in Mediawiki core

MediaWiki Maintenance

Meza is wiki farm enabled by default. This mean that the LocalSettings.php file is conditioned to look for a wiki id in every request. There's a variable $mezaWikiEnvVarName='WIKI'; that is used to control the collaboration between the web server, command-line scripts, and file-system based identifiers. So, always pass a value for this SHELL variable for any command-line scripts:

WIKI=demo php /opt/htdocs/mediawiki/maintenance/update.php --quick

Note: this example is just that. It's an example of how to run MediaWiki php scripts in the maintenance directory. Normally you wouldn't need to run update.php outside of Meza because you can use the Ansible 'tag' update.phpas described in the section "Using Tags" ie. meza deploy <env> --tags update.php Without any tags specified, all deploys will run update.php if necessary.

Also note: In LocalSettings.php (and other PHP code generated by Meza), the wiki identifier variable name is $wikiId. In CLI scripts and the shell environment, the variable default name is WIKI. In YAML files or Ansible commands, the variable name is wiki_id. Why are there three different names for the same thing? This difference no doubt causes some confusion, while respecting traditional naming conventions in PHP, BASH and YAML. Convention could be ignored to use a consistent variable name e.g. WIKI_ID or SITE_ID throughout.

Undocumented Commands

There are undocumented commands (see https://github.com/enterprisemediawiki/meza/issues/825) such as meza maint rebuild <env>

and sudo meza maint run_jobs [-- <wiki_ID>] operates on all wikis unless you nominate a specific wiki, separated by a double hyphen and a space to pass the argument through. This command only works for monolith setups. details