The secret config directory, located at
/opt/conf-meza/secret, holds information about multiple Meza environments. Within each environment sub-directory is contained the following info:
hostsfile, AKA "Inventory" file (not encrypted)
- SSL certs (encrypted)
The secret config file, located at
/opt/conf-meza/secret/<your environment name>/secret.yml, is used to hold sensitive information like passwords.
What's in this file that users want to change?Edit
wiki_app_fqdn: This is the fully qualified domain name for your server. If you're using Vagrant, it's just the virtual machine's IP address (probably
192.168.56.56). For enterprisemediawiki.org this value is
- Add SAML info per Meza/Setup SAML authentication
Editing the encrypted
The secret.yml file is encrypted automatically by Meza because it stores passwords and other sensitive information. This allows the file to be stored in version control systems with greater security. It makes it more difficult to use, however, because you must use special commands to edit the file. To do so, perform the steps below. It is well understood that this is an incredibly cumbersome process and it needs to be simplified.
- First, set a variable called
meza_envto your desired Meza environment. This is likely
vagrantbut could be anything if you explicitly setup an environment. For example, paste the following into your terminal if your environment is
- Then run the following
ansible-vault editcommand which will de-crypt the
secret.ymlfile and automatically begin editing it:
sudo ansible-vault edit "/opt/conf-meza/secret/$meza_env/secret.yml" --vault-password-file "/opt/conf-meza/users/meza-ansible/.vault-pass-$meza_env.txt"
- Edit the file using the Vi editor.
- Save the file by typing
sudo meza deploy <environment>to apply your configuration changes to your server
The hosts file determines where all the parts of your Meza installation go. On a standard "monolithic" installation everything is installed on
localhost. See the next section below. A more interesting setup may distribute parts of the install across many servers. See the second section below.
A standard "monolith" hosts fileEdit
# Ansible inventory (AKA "hosts") file # # http://docs.ansible.com/ansible/intro_inventory.html # Tell Ansible to use a local connection for localhost localhost ansible_connection=local [load-balancers] localhost [app-servers] localhost [memcached-servers] localhost [db-master] localhost # Note: db-slaves needs to be in the form: # 188.8.131.52 mysql_server_id=2 # ids must be unique and greater than 1 [db-slaves] [parsoid-servers] localhost [elastic-servers] localhost [backup-servers] localhost [logging-servers] localhost
A multi-server hosts fileEdit
This hosts file defines a more complicated setup. It does not use Meza's load balancer, but relies on an external one. It has two app servers (running PHP and MediaWiki) that are also functioning as Memcached servers and the location that backups are dumped. It has one database master and one database replica (slave). Two separate servers are running Parsoid, and two are running Elasticsearch. Additionally, it is setup to pull backups from example.com.
# Ansible inventory (AKA "hosts") file # # http://docs.ansible.com/ansible/intro_inventory.html # Tell Ansible to use a local connection for localhost localhost ansible_connection=local [load-balancers] [load-balancers-unmanaged] 255.1.255.140 255.1.255.141 255.1.255.142 [app-servers] 184.108.40.206 220.127.116.11 [memcached-servers] 18.104.22.168 22.214.171.124 [db-master] 126.96.36.199 # Note: db-slaves needs to be in the form: # 188.8.131.52 mysql_server_id=2 # ids must be unique and greater than 1 [db-slaves] 184.108.40.206 mysql_server_id=2 [parsoid-servers] 220.127.116.11 18.104.22.168 [elastic-servers] 22.214.171.124 126.96.36.199 [backup-servers] 188.8.131.52 184.108.40.206 [logging-servers] # Sourcing from example.com [db-src] example.com alt_remote_user=src-meza-ansible [backup-src] example.com alt_remote_user=src-meza-ansible [exclude-all] example.com