Talk:Meza/Flow

Meza is optimized to manage a pure mediawiki farm. As a result, some changes have to be made to allow other web-apps to function on a meza managed server. The good news is that meza doesn't touch any folders that it doesn't need to, so non-meza web content in non-meza folders is safe from being modified by deployments. The only thing you have to do is update meza's apache config to configure access to the non-meza content. That said, here are my notes on how to alter the meza default apache configuration to enable other apps to function on a meza managed server:

Example: You want to host a non-meza app called "Foo" at https://www.MezaServer.com/Foo.

To accomplish this, changes need to be made to the following 2 meza managed files:

1. /opt/meza/src/roles/apache-php/templates/httpd.conf.j2
2. /opt/meza/src/roles/htdocs/templates/.htaccess.j2

Changes to httpd.conf.j2:

add the text shown at the bottom of the VirtualHost definition

# main handling via http
Listen 8080
<VirtualHost *:8080>

        ...existing stuff...

        # add the following "Alias" and "Directory" definition at the bottom of the webroot VirtualHost definition
        Alias /foo /opt/foo/
        <Directory /opt/foo/>
                AllowOverride All
                Options Indexes FollowSymLinks
                Require all granted
                Options All -Indexes
        </Directory>

</VirtualHost>

Changes to .htaccess.j2:

add a Rewrite Condition above the RewriteRule that alters the mediawiki path

# mod_rewrite
<IfModule mod_rewrite.c>

    ...existing stuff...

    # Taken from MediaWiki.org [[Extension:Simple Farm]]
    #
    # Redirect virtual wiki path to physical wiki path. There
    # can be no wiki accessible using this path.
    ...tbd... RewriteRule ^(?!mediawiki(?:/|$))[^/]+(?:/(.*))?$ mediawiki/$1

</IfModule>

An unfortunate limitation of using centos7 is that centos7 epel repos are limited to mariadb 5.5. Fortunately, mariadb.com has an upgrade tutorial [1] that I was finally able to get to work with a few additional steps. The upgrade procedure is as follows:

sudo systemctl stop mariadb
sudo yum install wget

wget https://downloads.mariadb.com/MariaDB/mariadb_repo_setup
chmod +x mariadb_repo_setup
sudo ./mariadb_repo_setup

sudo yum update

sudo systemctl start mariadb

sudo mysql_upgrade

Finally, visit Special:Version and confirm that mariadb is now 10.6.x

If mariadb won't start, then you might need to do the following:

sudo tail -n 50 /var/log/mariadb/mariadb.log

to see what the issues are and then maybe:

sudo mkdir /var/lib/mysql
sudo chown -R mysql:root /var/lib/mysql

sudo mkdir /var/run/mariadb
sudo chown -R mysql:root /var/run/mariadb

as needed.

---

[1] https://mariadb.com/resources/blog/installing-mariadb-10-on-centos-7-rhel-7/

As far as adding this to meza, I think it needs to be added to the /src/scripts/getmeza.sh for new installations and users seeking to upgrade existing systems can simply refer to this help topic.

😎

Meza configures SMW as:

enableSemantics( $wikiId );

whereas it should be (something like):

enableSemantics( domain );

fwiw, it only matters if you care about the semantic triplestore or the RDFa export.

what causes a wiki to be listed as an installation when visiting {server}/v=Admin?

Sometimes they show when there are jobs in the jobs queue, and sometime they show when there aren't any jobs... and mostly they don't show.

With MW 1.31 going end-of-life later this year (Sept 2021), what answer should enterprise users of Meza give to their management when asked if there are any significant software updates to be planned for later this year. Should Meza owners be planning to continue running Meza 31.x in 2022? .. indefinitely? ..or should we be preparing for an upgrade later this year?

I have a development server that is ready to start testing a 35.x deployment, but I am not aware of any specific branch of Meza that has been advertised as ready for user testing and feedback of a MW 1.35 version of Meza.

What is the status of the 35.x branch of Meza?

• Is it scheduled to become the next 'master' branch?
• Should Meza users be testing the 35.x branch and providing feedback? .. or is it not ready ready for user testing and feedback?

Thank you!

/Rich

I began 35.x work earlier this year, but other priorities have made it impossible to complete the work. It'll get done, but unfortunately without assistance or incentive I can't give a schedule.

That is totally understandable. Thanks for responding. We'd like to help (GRC-ATF). We'd like to fork whatever you say is the most current 35.x development and see if we can get some pull-requests your way. All we need to know is what branch you consider to the the right branch to fork. Please let us know. Thanks!

2021-08-28 UPDATE - I just ran a full deploy of the Meza 35.x branch from scratch on a new Centos7 VM in VBox. Except for the last task to verify Python3 in /src/roles/mediawiki/taksk/main.yml the entire install and deploy went without a hitch and I am now testing extensions in 35.x. I will fork this branch in github and try to contribute to it's development. Thanks for getting us this far!

Let us know how it goes for you.

Upgraded 31.8.4 to 31.9.0 and deployed without issue. Thanks!

admin must follow these instructions to install package "unzip" prior to running a deploy

During an initial deploy on a fresh new system meza failed during a composer update with the message that package "unzip" was needed.

sudo yum install unzip -y

problem solved

admin must follow these instruction to temporarily add swap space to system prior to running a deploy

During an initial deploy on a fresh new Centos7 AWS system we see the following error in the composer task:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar

So we check available swap memory per:

free -m

which produces something like:

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

..and note that there is no swap memory so per: https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors

we sudo up to root (sudo -s) and run:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/bin/chmod 0600 /var/swap.1
/sbin/swapon /var/swap.1

which temporarily creates swap space for composer to use.

I see the execution is sudo --- Is it possible to deploy this on a shared hosting environment with only SSH or Composer? If so, any tips would be greatly appreciated! Looks like a great project!