I use DokuWiki as a personal wiki: a private blog, somewhere to jot down ideas and plan out projects. I’m currently running Dokuwiki on my Windows laptop from DokuWikiStick but wanted something more permanent. I’ve started self-hosting some applications on an old HP desktop computer and want to expand this setup. DokuWiki is a good candidate for moving onto my server. However, hosting the wiki on that could cause a chicken-and-egg situtation if the server is down and I need access to the information. I wouldn’t be able to access the wiki if the server goes down, and if the wiki contained information on how to fix the server I’m out of luck. Some people host these types of services on a Raspberry Pi and I wanted to host the wiki there but I wasn’t sure which model to get. There were only 1GB RAM models in the UK and I wasn’t sure if that would be enough. (I now know that’s enough memory, so I’ll get a Pi over the holidays and migrate over)

For now, I opted to use a cloud service to host the data would be easiest. I already had the prout.tech domain and keeping with the subdomain theme, wiki.prout.tech seemed a good fit.

There were a lot of options for how and where to host it. The easiest option would have been a Bitnami DokuWiki image. This could have been hosted on AWS EC2 and would have been very simple to manage, just plug-and-play. However, I’m planning to run other applications which will ingest the wiki’s data, that would have been tricky to setup with a managed image.

I decided to run the wiki off a Digital Ocean Droplet for $4 /month. This was the cheapest I could find. 0.5GB RAM / 10GB disk (less than a low-end rpi) I was worried that the specs would be too low but it seems to be handling the workload fine.

DokuWiki has a standard, albeit dated recommended structure. It’s written in PHP and the standard installation serves requests using Apache. I have no knowledge of PHP or Apache so I followed a guide written by Grant Winney. This was a good starting point. He pointed out a good resource for setting up a Ubuntu server and linked the recommended Ubuntu installation guide for DokuWiki. Part of his guide focuses on setting up HTTPS. My wiki will be publically available so I want lock the wiki behind authentication. I’ll be logging into the wiki from public wifi so HTTPS was a must. However, when configurating the certbot I got into a mess with Apache. I hadn’t used Apache before so I wasn’t too sure what I was doing. Rather than learn Apache I decided to switch the webserver to either NGINX or Caddy. I’ve used Caddy to reverse proxy between frontend and backend containers so I chose to use that.

DokuWiki’s Caddy installation guide is a bit thin on details so I’ll document the steps I took here and explain the logic behind the setup in another post.

Installation steps:

Install php (8.1 for this install, any 7.x/8.x should work), php-fpm, php-xml and Caddy. I installed the packages with apt, nothing special required.
Install DokuWiki

cd /var/www
sudo wget https://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz
sudo tar xvf dokuwiki-stable.tgz
sudo mv dokuwiki-*/ dokuwiki

Create a Caddyfile somewhere

https://wiki.prout.tech { (1)
        encode gzip zstd
        root * /var/www/dokuwiki (2)

        #Remember to comment the below forbidden block out when you're installing, and uncomment it when done. (3)
        @forbidden path /data/* /conf/* /bin/* /inc/* /install.php
        handle @forbidden {
                respond * 403
        }
        #End of the forbidden block

        try_files {path} {path}/index.html

        route {
                handle_path /_media/* {
                        rewrite * /lib/exe/fetch.php?media={path}&{query}
                }
                handle_path /_detail/* {
                        rewrite * /lib/exe/detail.php?media={path}&{query}
                }
                handle /_export/* {
                        @export path_regexp export ^/_export/([^/]+)/(.*)
                        rewrite @export /doku.php?do=export_{re.export.1}&{query}&id={re.export.2}
                }
                handle / {
                        rewrite * /doku.php?{query}
                }
                try_files {path} /doku.php?id={path}&{query}
        }

        file_server
        php_fastcgi 127.0.0.1:9000
}

(1) must match domain name for HTTPS to work (2) must point to where DokuWiki is installed (3) when installing comment this out otherwise unable to access /install.php to configure the wiki

Inside /etc/php/8.1/fpm/pool.d/www.conf, change the configuration to accept FastCGI requests from localhost:9000. It’s a simple change, comment out the line listen = /run/php/8.1-fpm.sock and add listen = 9000. Just stating the port implies localhost. This matches where Caddy will dispatch the requests (php_fastcgi 127.0.0.1:9000 in the Caddyfile)
At this point the domain’s A Record was still propagating. Normally you would get around this by using the server’s IP but Caddy expected to be accessed from the domain (1) so couldn’t verify the domain. It automatically upgrades requests to HTTPS, so this was causing SSL errors. Resolved by waiting until the record had propagated.
Change the owner of the wiki’s folder /var/www/dokuwiki to be the same as the Caddy service’s.
Start up php-fpm and Caddy.

Your wiki should now be accessible at your domain.

Part II

A follow up post will be published shortly breaking the Caddyfile down line-by-line and explaining the path a request takes.

Part II#

Part II