Bringing up a TWiki Docker Instance

I am in the process of recovering a TWiki installation for a client. I have been given a tar archive containing the /data and /pub for the organizations internal TWiki data. I want to bring it up as a Docker instance with an NGINX reverse proxy exposing it to the outside world via HTTPS.

Approach One

Use an existing Docker TWiki.

I found a number of possible solution of various vintages.

• https://github.com/mharrend/docker-twiki
• https://hub.docker.com/r/opensciencegrid/docker-twiki-converter/

After some investigation I settled on -

• https://hub.docker.com/r/heradon/twiki

I got it working initially using HTTP on a PC running docker locally to understand how the pieces fitted together.

I then moved it across to a Linux server where I could front it with an NGINX revers proxy.

Here are the basic stages:

1. Get the Docker Container Running

This was achieved using a simple shell script as follows:

#!/bin/sh

docker run  -dt -p 8219:80 -v ./wiki/:/wiki -e URL_HOST=http://127.0.0.1:8219/ -e ADMIN_PW=Secret --name twiki --rm heradon/twiki

In this case the NGINX proxy is redirecting to http://127.0.0.1:8219 - thus the ports used above.

The local ./wiki directory contains pub and data directories from the old TWiki site each of which contain a CFP directory with the custom wiki data

Once I had the container running I could see the Main, TWiki and Sandbox default TWiki content.

2. Retrofit the CFP Data

The underlying TWiki Docker installation lives in /var/www/twiki. This folder conatains (among others) a 'pub' and 'data' folder which contain the default TWiki contents. As part of the Docker container initialization the run script moves twiki/data and twiki/pub to /data/data and /data/pub and then sym-links these back into /var/www/twiki.

This process collided with my initial Docker setup which mapped a local ./data to /data in the container - and this broke the internal container application setup as the run script directory re-work failed. As a result I mounted the client CFP data in ./wiki and once the container was up an running I copied it across to combine the custom site data with the generic TWiki data.

Once I had this worked out I was able to connect to the container and put the custom content in place:

$ docker exec -it twiki bash
% cd /data/pub
% cp -r /wiki/pub/CFP .
% cd /data/data
% cp -r /wiki/data/CFP .

And so the data was now in place:

root@5db33ad05760:/data# ls -l data
total 116
drwxrwxr-x 2 www-data www-data  4096 Jan 28 04:02 CFP
drwxrwxr-x 2 www-data www-data  4096 Jul 16  2018 Main
drwxrwxr-x 2 www-data www-data  4096 Jul 16  2018 Sandbox
drwxrwxr-x 2 www-data www-data 73728 Jul 16  2018 TWiki
drwxrwxr-x 2 www-data www-data  4096 Jul 16  2018 Trash
drwxrwxr-x 2 www-data www-data  4096 Jul 16  2018 _default
drwxrwxr-x 2 www-data www-data  4096 Jul 16  2018 _empty
-rwxrwxr-x 1 www-data www-data   337 Jan 28 04:06 log202601.txt
-rwxrwxr-x 1 www-data www-data  9024 Jul 16  2018 mime.types

However, this content is password protected and required a bit of work to get running.

3. Verify the NGINX proxy was forwarding the needed headers

I presumed this would be OK with my standard configuration as I am using the same approach with a number of Flask, FastAPI and React proxied sites.

4. Diagnosing the Authentication

I am setting an 'admin' password in the docker run command. However, the TWiki expects there to be a .htpasswd file in /var/www/twiki/data which also maps this.

It turns out the container (based on Debian) does not have htpasswd installed and so this had to be installed:

$ apt update
$ apt install apache2-utils

Once this was done I could create the .htpasswd file:

$ cd /var/wwww/twiki/data
$ htpasswd -c .htpasswd admin
...
$ chown www-data:www-data .htpasswd
% chmod 775 .htpasswd

I missed this initially as I am so used to working with NGINX which can cope with root ownership (for better or worse). I also needed to do this for the copies of the CFP directories so that Apache could access the data.:

% cd /data
% chown -R www-data:www-data data pub

The next issue turned out that the code uses an insecure HTTP protocol for the passwrd submission. I needed to do two things to fix this

i) Update the LocalSite.cfg File

In /var/www/twiki/lib/LocalSite.cfg I needed to make the following changes:

Update the Default URL to point to the HTTPS URL and not an HTTP localhost one

$TWiki::cfg{DefaultUrlHost} = 'https://cfp-wiki.performiq.com';

Add the following. In retrospect, I am not sure it is necessary but at some point I did this just in case:

$TWiki::cfg{ScriptUrl} = 'https://cfp-wiki.performiq.com/bin';

Now you may recall that htpasswd now uses MD5 hashing. But the TWiki isold andby default expects the old crypt protocol. And so I needed to change this:

$TWiki::cfg{Htpasswd}{Encoding} = 'crypt';

to:

$TWiki::cfg{Htpasswd}{Encoding} = 'md5';