Mediawiki as This Website

Why MediaWiki

First, some background techical info. University of Rochester, CS Department has a shared website hosting service for all grad students and faculty member, powered by Apache 2 and supports PHP. The webroot itself appears to be mounted on an NFS drive. These factors majorly influenced my decision to use MediaWiki as the backend. Let's break down bit by bit.

I could have used a Static Site Generator (SSG) or even plain HTML, but decided against them since I would need a machine with the department network access to publish any changes. This limits my options to write content with, as it pretty much requires me to SSH into the university network AND have a good programmer's editor.

I would also like to write "knowledge snippets" on this website, and perhaps form a connected knowledge graph. This just screams "Wiki" to me -- thus I decide to choose a Wiki software, and start to prune my options by looking at technical constraints and my requirements. On top of this, I would need support of writing blogs (like this article), and the ability to create some more complex interactive pages.

The fact that there's only Apache/PHP with an NFS folder accessible means that there is no database available and no backends like Node. This rules out any wikis that require a SQL server, including BookStack, Wiki.JS, etc. For anything to work on the shared server of CS department, it has to run on PHP 7.3 and access nothing except for files on an NFS drive (more complications later). I would also not have access to the installation forever, so I would need the software to be rock solid. The best candidates under these requirements are: MediaWiki, DokuWiki, and PmWiki.

Now, if I say I chose MediaWiki because it's the first one I successfully set up, the story's going to be boring. Therefore, let's add some more reasoning.

If I am hosting just a Wiki on any machine that I own, I would use DokuWiki, period. It's small, has excellent default feature set, easy to maintain through the web interface, and doesn't require a database. I had good experience with it before. However, for this website it has two critical faults:

1. Unable to disable email support
2. Not enough info about making "special pages" via plugins, etc.

PmWiki is another choice, which I seriously considered using. Its main advantage are:

1. Extremely small size, measuring only 2.2MB over MediaWiki's >300MB
2. Immense customizability: just look at [1]

Yet there is one critical fault:

1. Everything requires machine access to manage, including passwords

And that leaves MediaWiki, our favorite behemoth of wiki software, unpacking to 300MB and running on SQLite. It's big and slow and complex, but it doesn't violate any hard requirements. It has a few bonus points:

1. Decent visual editor
2. Lots of features bundled
3. Widely used, so there are lots of resources online

Though it does have a few problems:

1. Visual editor can be very slow due to the shared-hosting nature of the website. Sometimes it is so slow that I suspect it crashes the server (thus I disable it)
2. Unlike DokuWiki, extensions are installed manually, requiring some machine access
3. The latest version that still supports PHP 7.3 is 1.38. This will be discontinued in June 2023. The last LTS, 1.35, will be discontinued in September.

Not ideal, but MediaWiki is good enough for my use case. Mostly I'd really like it to be smaller so I don't stress the server as much.

How to Setup

Setting up the wiki has a few major complications.

The shared webroot resides in an NFS mount, which is accessible to every machine on the CS department network, while the web server is a separate machine accessing the very same mount. The permission on the webroot isn't well configured either: each user gets a subfolder under webroot under <username>:www. Unfortunately, www is not the group Apache runs under.

For MediaWiki to work, the data directory must be writable by the Apache process, but I would like to avoid world-writable permission. In addition, by default the SQLite database is also created with permission 600 with owner apache:apache, which means I cannot actually read or back up the data by myself. Of course, I am just a regular user, with no permission to arbitrarily change ownership of files. To make things worse, directory SETUID/SETGID bits does not work under the particular NFS installation of this webroot, meaning that I cannot make all newly created files inherit owner, giving access to both Apache and me.

Well, not really -- NFSv4 actually supports ACL. It just requires some careful thought before installing MediaWiki, so every newly created file already inherits the correct permission.

For the following guide, I assume the current working directory is already at the webroot, and mediawiki is already extracted under mediawiki/. I assume the SQLite databases will be created under mediawiki/data/.

First, create the data directory as usual:

$ mkdir mediawiki/data

This directory now has ownership rdong3:www, nothing unusual. Next, I allow Apache to write to it:

$ setfacl -m 'u:apache:rwx' mediawiki/data

This is sufficient for MediaWiki to work. However, the database it create won't be accessible for me to perform backups, thus I need to add myself to the ACL list... but I don't have permission to do so. Therefore, I need to set default ACL rules on the data directory, so I can still access any new file, but nobody else can:

$ setfacl -dm 'u:rdong3:rwx' mediawiki/data
$ setfacl -dm 'g::---' mediawiki/data
$ setfacl -dm 'o::---' mediawiki/data

Yup, done. The only thing left is to set up MediaWiki as normal.

Final Remarks

I have the bad habit of fiddling with web hosting options. I can never say for sure that this MediaWiki installation will last forever, but currently it seems to be a good choice. I am probably satisfied enough to keep it a while longer.