Merge Freephile's changes

[jamesmontalvo3]

Tracking plan to merge @freephile changes into this repo.

• [ ] [EZ] .gitignore hosts and nbproject
  • See #833
• [ ] [EZ] Semantic compound queries version changed from 1.1.0 to ~1.1
  • I generally prefer sticking with exact versions. Approximate versions have bitten us in the past.
  • It's not a big deal to submit a PR to roll a version number from 1.1.0 to 1.1.1 or whatever. It provides good traceability. But if composer decides to pull a newer version (which is supposed to not break anything but it happens) and something doesn't work right then we don't have any clear way to point to what caused the issue.
• [ ] ansible.cfg, forks = 1
  • does this make it so multiple servers won't be worked in parallel? I think this needs to be configurable.
  • If this doesn't do all nodes at once I believe it will break Elasticsearch full cluster restarts for major version upgrades. I believe we need to restart them all at once. Of course it'd be better to bring down one node at a time, upgrade it, move it to a separate cluster, and then bring up each node such that it gets added to the new cluster...then at the end make mediawiki point to the new cluster.
• [ ] defaults.yml m_http_always = true
  • stopping firewalld on some server(s) in site.yml for AWS unmanaged load balancer, modifying Apache config in apache-php/tasks/main.yml (why not directly modify config file?)
  • There are a couple times that you use lineinfile or blockinfile (and maybe others) to apply changes to httpd.conf (and perhaps other files). Instead why not just modify the the template for httpd.conf?
• [ ] Allowing access to ES plugins in site.yml
  • Updated docs in #897 and #895
  • does the method shown here work?
  • plus CORS settings in elasticsearch.yml, plus balancers in haproxy.cfg
• [x] [EZ] access Apache server info in httpd.conf

  • 889 moved several server status related items into [[Special:Serverstatus]]

• [ ] Short URLs in httpd.conf (or is this related to subdomains?), Modifying httpd.conf for aliases in configure-wiki/tasks/main.yml, .htaccess changes, symlink to core in mediawiki/tasks/main.yml, modify LocalSettings
  • Ref enterprisemediawiki branch subdomains. @freephile this needs your help. @jamesmontalvo3 stalled out ensuring both path and subdomain versions worked consistently.
• [x] [EZ] Rotate MariaDB.log in database/tasks/configure.yml an d roots .my.cnf
  • Incorporated in #889
• [ ] Removed SSL certs from load balancer...doesn't this break standard installs?
• [x] [EZ] Robots.txt
  • Incorporated in #889
• [ ] [EZ] Meza auth type default to anon-read
• [ ] [EZ] More skins
  • While this is an easy add...is it really necessary? While Wikipedia aims to satisfy everyone, I'd prefer to maintain consistent look. I think it'd be better for meza sysadmins to add more skins via MezaLocalExtensions (I'm actually not sure if that's possible currently, but it would be an easy add)
• [ ] [EZ] Use freephiles WikiBlender, allow setting domain vs path method for WikiBlender
  • Diff of jamesmontalvo3/master to freephile/multi-domain-merge-ready: https://github.com/jamesmontalvo3/WikiBlender/compare/master...b4bb51b58a53dbb884279e3bce382aed49308448
  • Assuming this doesn't break path (vs subdomain) WikiBlender, this would be an easy merge of into jamesmontalvo3/WikiBlender. Probably it should be moved to enterprisemediawiki/WikiBlender, though. I think we'd need to set the meza default to path since I don't think for IP addresses a subdomain will work...e.g. for Vagrant I don't think I can do demo.192.168.56.56
  • Ref enterprisemediawiki branches subdomains and landing. These roll WikiBlender into meza, rather than keeping it as a separate repo.
• [ ] Add --doshared to update.php. I don't think we want to do this. See my response on one of the pull requests that included this
  • Ref #846
• [ ] importExtensions.php (what does this do?)

Differences that don't need to be merged

• Freephile's elasticsearch.yml has other changes which conflict with supporting MW1.27 through 1.30. The current MW1.28 branch of emw/meza supports all.

[freephile]

 [EZ] .gitignore hosts and nbproject

DECLINE CHANGE This is mostly irrelevant. I could re-create this on an isolated commit to make it something easier to merge if desired.

[EZ] Semantic compound queries version changed from 1.1.0 to ~1.1

I generally prefer sticking with exact versions. Approximate versions have bitten us in the past. It's not a big deal to submit a PR to roll a version number from 1.1.0 to 1.1.1 or whatever. It provides good traceability. But if composer decides to pull a newer version (which is supposed to not break anything but it happens) and something doesn't work right then we don't have any clear way to point to what caused the issue.

DECLINE CHANGE I agree, and can't find any reference to why I might have changed the version match notation for Semantic Compound Queries. However, I notice this change is present in 5aec77f046337a8b3667d61da65c01a30b2d513c Also, the INSTALL directions at https://www.mediawiki.org/wiki/Extension:Semantic_Compound_Queries say to list ~1.1 in composer.json (extension author is Yaron Koren)

ansible.cfg, forks = 1

does this make it so multiple servers won't be worked in parallel? I think this needs to be configurable. Agree that this should be configurable, if used at all. Basically, this is a documentation issue. "Meza needs at least 2GB Memory ... etc." If trying to run meza on a very limited platform, you might try forks=1 in your ansible.cfg to limit execution to a single thread.

DECLINE CHANGE

defaults.yml m_http_always = true

checks for unmanaged load balancer, modifying Apache config in apache-php/tasks/main.yml

This commit adds a configuration option to force HTTPS always ON in your Meza instance, when using an external load balancer. Commit 19db20f8dd4a17df42351a5ea073024ba8eb5b55

Allowing access to ES plugins in site.yml

Updated docs in #897 and #895 does the method shown here work? plus CORS settings in elasticsearch.yml, plus balancers in haproxy.cfg

DECLINE CHANGE I believe the update in the docs is sufficient.

access Apache server info in httpd.conf

889 moved several server status related items into [[Special:Serverstatus]]

DECLINE CHANGE Great job on the extension! Perfect

Short URLs in httpd.conf (or is this related to subdomains?), Modifying httpd.conf for aliases in configure-wiki/tasks/main.yml, .htaccess changes, symlink to core in mediawiki/tasks/main.yml, modify LocalSettings

NEEDS WORK Commit 6d8a918016c231b02249ec6b2bb948a0bf93cadc Short URLs are an implementation of the Short URLs in MediaWiki so we get page URLs like http://example.org/wiki/Page_title It does conflict with traditional Meza setups that use the $wikiId (folder) for $wgScriptPath. Introduces $wgArticlePath as "/wiki/$1"

[EZ] Rotate MariaDB.log in database/tasks/configure.yml an d roots .my.cnf

DECLINE CHANGE (already committed)

Removed SSL certs from load balancer...doesn't this break standard installs?

NEEDS WORK Yes, it does. It's supposed to be used with the CertBot role that I have in development. The CertBot role should provide the SSL cert for the standard install.

[EZ] Robots.txt

DECLINE CHANGE (already committed)

[EZ] Meza auth type default to anon-read

Proposed because anonymous edit is a nightmare on a public wiki. (You will get SPAM instantly)

[EZ] More skins

For default installs, I believe it makes sense to incorporate a few of the 'standard' skins that would be available in the tarball: Vector (the default skin), MonoBook, Modern and Cologne Blue. I still would like to implement MezaLocalSkins.yml, where perhaps we list some of the most popular skins

[EZ] Use freephiles WikiBlender, allow setting domain vs path method for WikiBlender

Yup, we should do this.

Add --doshared to update.php. I don't think we want to do this. See my response on one of the pull requests that included this

DECLINE CHANGE Agreed. It's a bad idea to add this option. In fact, another commit reverts the change. There is an unresolved bug in MediaWiki (that update.php skips shared tables without --doshared; and breaks if you do specify it: See https://phabricator.wikimedia.org/T158154). Due to the bug, this option creates more problems if actually used. NEEDS WORK UPSTREAM

importExtensions.php (what does this do?)

It compares extensions defined in a local Meza (both in core and MezaLocalExtensions.yml) as compared to what is found in a site API (aka the "live" site you want to convert). It lists any extensions found on the live site that aren't already in your "staging/test" site controlled by Meza. It's like the extension that Cindy just worked up: https://www.mediawiki.org/wiki/Extension:VersionCompare DECLINE CHANGE (use Cindy's extension if desired)

[jamesmontalvo3]

I'll address all of the above hopefully tonight. Too much for me to read right now...but can you confirm that I should close #833 and #871?

[jamesmontalvo3]

I closed them because I'm pretty sure that's what you meant. Will reopen if I'm wrong.

[freephile]

@jamesmontalvo3 You can close this issue. I re-synchronized my master to match yours. I created new branches for each individual change that possibly merits inclusion in master. I will create separate (new) pull requests for each.