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';
Of course, after any of the changes you will need to restart Apache to get the changes to take effect.
The data/CPN/WebPreferences.tx file contains a block which controls document access:
* Users or groups who __are not__ / __are__ allowed to __view__ / __change__ / __rename__ topics in the %WEB% web: (See %TWIKIWEB%.TWikiAccessControl)
* Set DENYWEBVIEW =
* Set ALLOWWEBVIEW = *
* Set DENYWEBCHANGE = Main.TWikiGuest
* Set ALLOWWEBCHANGE = Main.Study754Group, admin
* Set DENYWEBRENAME = Main.TWikiGuest, admin
* Set ALLOWWEBRENAME = Main.Study754Group, admin
To allow access you can either use '= *' to open it up completeley of add ', admin' to allow admin to access the content.
Despite doing this the authentication still failed. The final requirement was to get Apache to honour the HTTPS headers by adding the following to /etc/apache2/sites-enabeled/twiki.conf:
SetEnvIf X-Forwarded-Proto "https" HTTPS=on
As soon as I added this and restated Apache theauthentication started to succeed.
OK now that I have that working I am going to re-enble BasicAuth on the site to protect the information.
Approach Two
Using docker compose with a customize Docker image.