Meza/FAQ

External 443 traffic only meza config

I have a user on my enterprise network who is behind a firewall that only allows 443 traffic. He says that he can see the Meza Landing page but the individual wikis don't work. For diagnostic purposes, he opened up port 80 on his firewall and suddenly the he could access the wiki fine. But he can't run that way so I have been told I have to eliminate all outside dependencies on port 80. I know that meza defines lots of services that are unsecured on the loop-back (127.0.0.1) port on the "back-end" of the haproxy and I’m allowed to leave them be - just so long as the client doesn't need to access them directly.

• Question -- What minimum configuration changes are required to allow meza to work behind a firewall that only allows 443/https traffic?
  • Answer: When properly configured, a standard Meza installation should be fully accessible over HTTPS (port 443). The default SSL certificate is self-signed, so you may need to install your own certificate (e.g. from LetsEncrypt) depending on the requirements of your client. The certificate configuration is in /etc/haproxy/haproxy.cfg (or the template that creates it in the Meza deploy).

so are you saying that any port 80 dependencies I am experiencing are due to a failure to configure haproxy properly for my organization's certs?

I added my organization's cert chain to /opt/conf-meza/secret/monolith/ssl And that satisfied the browser front-end. Are you saying that I need to manually point /etc/haproxy/haproxy.cfg to /opt/conf-meza/secret/monolith/ssl?

I see three places where certs are mentioned in haproxy.cfg:

# Default SSL material locations
   ca-base /etc/ssl/certs
   crt-base /etc/ssl/private

and

frontend www-https
   bind *:443 ssl crt /etc/haproxy/certs/meza.pem

So if my certs are in /opt/conf-meza/secret/monolith/ssl do I update lines 14 and 15 in haproxy.cfg to be

ca-base /opt/conf-meza/secret/monolith/ssl
crt-base /opt/conf-meza/secret/monolith/ssl

?

(Force=yes) in "Ensure WikiBlender installed" Task

I made some changes to /opt/htdocs/WikiBlender/includes/Landing.php and now meza deploy can't complete the Ensure WikiBlender installed task with the default behavior of "force: no" in the task.

How can I command meza to overwrite any local modifications in /opt/htdocs/WikiBlender/includes/Landing.php upon meza deploy

To overwrite what is found in /opt/htdocs/WikiBlender you would want to ensure the task uses force: yes in the "Ensure WikiBlender installed" task at src/roles/mediawiki/tasks/main.yml. If you prefer to keep what's already existing, you can keep force: no, but be sure to add the (task) option to ignore errors as shown in the example below

- name: Ensure WikiBlender installed
  git:
    # use the multi-domain capable Blender (freephile fork)
    repo: https://github.com/freephile/WikiBlender.git
    dest: "{{ m_htdocs }}/WikiBlender"
    version: "multi-domain-merge-ready"
    # don't modify an existing checkout
    # assume deployer is playing with Blender source
    # force: no
  # ignoring errors is a task option, not a git option
  # ignore errors will allow the play to continue when the play does not do a checkout due to preexisting sources in the target.
  ignore_errors: yes

Where should I make the changes to /opt/htdocs/WikiBlender/includes/Landing.php so that they are included as part of the meza deploy results. (e.g. is there a template page for the landing.php file somewhere in /opt/meza/src/... ?)

WikiBlender is not currently part of meza. It's a separate code repo that is installed by meza. You can fork and/or submit patches to like Freephile/WikiBlender did

How to set the server timezone in Meza

Question 1 -- How to set the server timezone in Meza? Is there a timezone variable somewhere? secret.yml does not mention timezones.

• Answer: You can specify e.g. m_timezone:"America/New_York" in your /opt/conf-meza/public/public.yml file. Valid values for m_timezone can be found in column 3 "Zone name" of List_of_tz_database_time_zones. The value you specify will override the default.

SAML VS Policy Agent Authentication approaches

SAML is clearly the officially approved e-auth mechanism for meza. However, I am working with my organizations application security team on my meza site and they are telling me that they want me to use a "CA Policy Agent" installed on the Apache service that forces clients to have secure authenticated browser sessions from our enterprise identity provider (redirecting them as needed), and then to program the policy agent on the server to authorize client access to specific wikis based on specific session attributes controlled only by the identity provider. This means that I would NOT be using SAML auth in ANY wikis.. which generates some questions:

Question 1 -- Is there any reason why this can't work? -- Meaning, is there anything in the Ansible scripting for a meza deploy that will be guaranteed to either break or over-write the policy agent.

• Answer: --- Policy Agent Works well with Meza but is not yet included in meza as a configuration option. It requires some local modifications to meza that will need to be tracked and maintained apart from meza until we get Policy Agent support added. I will be adding a link to this FAQ with instructions on how to implement the CA Policy Agent with Meza. In the meantime, (User:revansx) if you need help.

Question 2 -- Does this impact the use model of the primary wiki feature of meza? if so how?

• Answer: ---

How do I change my domain name?

I installed meza on a system with one domain name (or IP address) and now I want to update the host name that meza resolves to. How do I do this?

• Answer: edit secret.yml (see Meza/Secret config). Update the value wiki_app_fqdn to your new domain name.

Questions about Primary Wikis

Question 1 -- if a wiki is made primary, can it be made made un-primary? what happens if it is deleted?

• Answer: If you deleted the primary wiki you'd lose the user table from the database that all other wikis rely upon. The same is true for the user_properties and interwiki tables, though losing those is less disastrous. Since all the other wikis had been relying upon that the primary wiki's user table, you could manually copy that table into the other wikis' databases. Or just copy it into one other wiki and define that wiki as primary.

Question 2 -- if every wiki is e-uthed (SAML or Policy Agent) such that login is account-creation is automatic based on third-party authentication and authorization, what is the advantage of having a primary wiki?

• Answer: Shared user settings across wikis (everything in preferences). Not having this is incredibly annoying if you have many wikis. Shared interwiki table so you can easily link between wikis without keeping interwiki tables synchronized. Keeps user ID numbers the same (so you're not user #1 on one wiki and user #5148 on another wiki) which makes it possible to merge wikis more easily if you ever want to do that.

favicon.ico location for meza launch page

Where can one place a 'favicon.ico' file that will be used by the blender start page at the domain root? I have been successful in getting it to work by placing it here: /opt/conf-meza/publis/wikis/favicon.ico. Not sure if this is the official location. Is placing a file (image) in /opt/conf-meza/publis/wikis/favicon.ico safe with respect to meza deploy commands?

• Answer: If you define a primary wiki it's favicon will be used for the landing page. Other than that there is no documented way of defining a favicon for the landing page. If you're using a single sign-on source it is recommended to define a primary wiki.

Add non-meza html pages to a meza environment

I have a RHEL7 system with meza 27.x installed (monolith) and my organization requires me to host a few non-wiki, non-sensitive static html pages in a folder on the server that is in a non-meza related directory. Where/How do I create such a folder in a way that will not interfere with normal meza operations?

• Answer: There is no way built into Meza to do this cleanly, yet. You can put the files in /opt/htdocs and I don't think Meza will remove them on meza deploy, but I'm not certain. You'll need to update /opt/htdocs/.htaccess to tell the webserver to allow access to the files, and that will be overwritten on each deploy
• Answer 2: Another approach is to make the required changes to /opt/meza/src/roles/apache-php/templates/httpd.conf.j2. This would be persistent upon subsequent deployments, but would be a variation from the official meza code base.

How can I find a list of all subpages to Meza here on mediawiki.org?

• Answer: Use the Special:PrefixIndex page to list subpages (and talk pages):
  • Subpages
  • Talk Pages

How do I get answers if they're not here?

Answer: First, try searching the Meza issues on GitHub. If you don't find what you're looking for there, join the Meza channel on element.io.