This is an overview of the directory structure used by a meza server. This does not include every single file, but attempts to list out directories and files used by the meza application.
Info required: which files exist on which server types? Currently this is mostly focused on monolithic installations, where the controller and all applications (MariaDB, Elasticsearch, MediaWiki, etc) are on the same server.
There are several terms in this document which may be described in the [Glossary](Glossary.md).
The five major directories are:
/opt/meza: The meza application. Only modified when developing for or upgrading meza version
/opt/conf-meza: meza configuration. Modified by sysadmins when making configuration changes.
/opt/data-meza: storage of meza information. Modified anytime wiki users do anything on the site.
/opt/.deploy-meza: Files deployed by the meza application. Sysadmins don't need to touch this. Instead, modify
/opt/htdocs: The webserver root. Deployed just like
Meza application directory. This should never change except if you upgrade meza (or you're doing development for the meza application itself). This only exists on the controller.
ansible.cfg: Ansible config file. Ref: http://docs.ansible.com/ansible/intro_configuration.html
defaults.yml: base config vars, able to be overridden in /opt/conf-meza/public/public.yml
i18n: mostly unused attempts to internationalize meza
MezaCoreExtensions.yml: extensions installed on all meza servers
ifcfg-enp0s8: CentOS7 VirtualBox Host-Only network interface template
README.md: Ref Issue #712: Flatten config/core/ to just config/
CONTRIBUTING.md: Directions on how to contribute to meza
.eslintignore: Config file for CodeClimate analysis
.eslintrc: Config file for CodeClimate analysis
ISSUE_TEMPLATE.md: Template text for new GitHub issues
PULL_REQUEST_TEMPLATE.md: Template text for new GitHub pull requests
.gitignore: Ref: https://git-scm.com/docs/gitignore
LICENSE: license info for meza
commands.gif: GIF for main README showing usage of meza command
pigeon.txt: ASCII art of pigeon declaring successful install; Ref Issue #676: reincorporate into deploy
- (files used for help when using meza command, e.g.
- (files used for help when using meza command, e.g.
- (various files explaining various aspects of meza)
README.md: meza's main README
- (Ansible playbooks. Ref: http://docs.ansible.com/ansible/playbooks.html)
- (Ansible roles. Ref: http://docs.ansible.com/ansible/playbooks_roles.html)
- Run on hosts:
create-vm.sh: Create a Vbox VM; remove when
vagrant upmature? Or keep for RedHat
- Setup dev VMs:
dev-networking.sh: Setup host-only network on Vbox VM; Remove after Vagrant? Keep for RedHat setup?
- Run on controller:
getmeza.sh: (Used to install
- Run on controller:
meza.py: (Entry point for
ssl-selftest.sh: Ref Issue #714: Move to tests/integration/ and use in automated testing
unifyUserTables.php: Ref Issue #672: determine if still functional
- Run on hosts:
deploys: Scripts run on controllers which run several commands to test various functions
setup-alt-source-backup.yml: Ansible playbook run on controller to setup a test case. creates a fake non-meza source to import from.
docker: Scripts run on a Docker host
backup-to-remote.setup.sh: generates 2 meza Docker containers
import-from-alt-remote.setup.sh: generates 2 meza Docker containers
import-from-remote.setup.sh: generates 2 meza Docker containers
init-container.sh: generates a generic container
init-controller.sh: uses init-container to generate a controller container
init-minion.sh: uses init-container to generate a minion container
run-tests.sh: Entrypoint script to setup which tests to run. first argument for this script is which test type to run.
image-check.sh: finds image URL via JS API, the checks is present on server
server-check.sh: several basic tests to verify a meza installation is functioning
wiki-check.sh: checks wiki API, Parsoid, Elasticsearch for a wiki
git-setup.sh: shim to handle git checkout funnies in Travis
.travis.yml: Config file for Travis CI automated testing
Vagrantfile: Create VMs with Vagrant. Ref: https://www.vagrantup.com/docs/vagrantfile/
 These are shell scripts used to create users. Ref Issue #713: Consolidate.
Location of configuration setup for meza. This is split into
public config. Secret config is intended for sensitive info like passwords. It also houses your
hosts file which declares which servers have which components installed (e.g. Parsoid is installed on
hosts file may or may not be considered sensitive, but it resides in
secret nonetheless. Some non-sensitive items may be more convenient to put in
secret. These include things like
enable_wiki_emails, which you may only want set to
true on your production setup and no others. Since the
hosts file resides in
secret those environment-specific settings may be better to keep in
Additionally, the user
meza-ansible is used by meza to perform most actions. Some other actions are performed by the
alt-meza-ansible user. However, we don't create these users in
/home due to possible conflicts with other user systems. Ref #727.
MezaLocalExtensions.yml: Use to define extra extensions for your meza installation
public.yml: MAIN CONFIGURATION VARIABLES FILE!
- (Any .php files here will be loaded at the end of LocalSettings.php)
- (Any .php files here will be loaded at the beginning of LocalSettings.php)
demo: this "demo" is known as the wiki ID
.phpfiles here loaded at end of LocalSettings.php for this wiki only)
.phpfiles here loaded at beginning of LocalSettings.php for this wiki only)
- (more wikis with same format as above)
secret.yml: This is the main secret config file. Encrypted by vault password.
hosts: AKA "Inventory file", listing server roles. See [Glossary](Glossary.md) for more info
meza.crt: SSL certificate for this environment. Encrypted by vault password
meza.key: Private key for this environment. Encrypted by vault password
- (more environments if you so choose)
id_rsa: secret key file on controller only. KEEP SAFE!
id_rsa.pub: public key file. This needs to be put on any minion servers.
.vault-pass-monolith.txt: vault password file for monolith environment. See /opt/conf-meza above. On controller only
.vault-pass-<env>.txt: (vault password file for other environments)
alt-meza-ansible: alternate user for some operations to avoid conflicts
Data storage for meza. This is basically any information generated by using meza, including MariaDB (MySQL) database info, files uploaded by users, logs from meza commands (logs from Apache, HAProxy, system logs, etc are kept in their standard CentOS/RHEL locations), temp files, and backups from running
meza backup command.
backups: backups directory populated from running
meza backup <environment>
monolith: backups for the "monolith" environment
20170523123216_wiki.sql: database backup from specified timestamp
uploads/: backup of uploads directory
production: backups for the "production" environment
- (wikis in production)
elasticsearch: files associated with Elasticsearch data
jobs_20170525_cron.log: log from automated job runner
parsoid-restart.log: log from nightly parsoid restarts
search-index.demo.1495583788.log: log from this wiki's search index rebuilding
smw-rebuilddata-out.demo.1495583793.log: log from this wiki's SMW rebuildData.php
mariadb: many files and directories associated with MariaDB data
mysql-bin.000001: Ref Issue #613: mysql-bin files are not cleaned up by meza currently
tmp: temp files which can be deleted. Ref Issue #497: need to keep this directory clean
demo: location where Demo Wiki's uploads/images are kept
- (more wikis uploads/ directories)
uploads-gluster: used instead of
uploadsif multiple app-servers used. File system distributed between app-servers.
This directory is a hidden directory (e.g. starts with a period) because it really shouldn't be modified directly. When the
meza deploy command is run this directory is set based upon the config set in
config.php: PHP config variable file written based off defaults, secret and public config
config.sh: Bash config variable file written based off defaults, secret and public config
Extensions.php: Extensions to load, written based off core and local extensions
elastic-build-index.sh: Rebuild Elasticsearch index for a wiki. Deployed by
elastic-rebuild-all.sh: Wrapper for
elastic-build-index.sh. Deployed by
smw-rebuild-all.sh: Rebuild SMW data for all wikis. Deployed by
public: A copy of /opt/conf-meza/public, but present on all app-servers, as opposed to
/opt/conf-mezawhich is only present on the controller
MezaLocalExtensions.yml: present but not used within .deploy-meza (controller only)
postLocalSettings.d: gives app servers access to these files
preLocalSettings.d: gives app servers access to these files
public.yml: present but not used within .deploy-meza (controller only)
demo: gives app servers access to these logos and wiki specific PHP
runAllJobs.php: Used in cron jobs to run jobs
This directory is similar to
/opt/.deploy-meza in that it is a deployed directory: It is put in place on app servers by the meza application. In fact, it was considered to be placed at
/opt/.deploy-meza/htdocs but due to its larger significance as the web root it seemed like it should have its own directory.
index.php: entrypoint for landing page
mediawiki: mediawiki application. many items not shown below
extensions/: where extensions are installed (by the meza application; sysadmins do not need to touch this)
LocalSettings.php: Settings file generated based on your config
LocalSettings.php.17294.2017-05-22@18:59:46~: Ref Issue #710: backups of LocalSettings.php not required
LocalSettings.php.22591.2017-05-23@00:36:42~: (see above)
LocalSettings.php.31311.2017-05-23@19:03:29~: (see above)
ServerPerformance: logging and performance graphs
index.php: server performance
space.php: disk space usage
WikiBlender: landing page repo. Perhaps should be rolled into meza
demo: directory that symlinks to deployed config, to make logo/favicon web accessible
config: symlink to
/opt/.deploy-meza/public/wikis/demo(Ref Issue #709: Security implications)
- (more wikis)