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 -
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';