Helper Programs

fslsrv

This is the Fossil service rebuild script I run on my public web site server. (Likely the very site you’re reading this on.) It pulls the latest container image created by my Docker Hub image updater and uses it to rebuild the systemd services and the Podman containers backing them. If all that succeeds, it restarts the Fossil services, causing all of my repositories to be updated to the latest version of Fossil within seconds, even though each is served by a separate container.

The way it builds the systemd units, if the only thing that changed is the container image, you can update even faster with:

$ sudo podman auto-update

Podman remembers the URI of the image so it can check it for changes, then fetch a new version and rebuild the systemd units, if necessary. This is about twice as fast as the way fslsrv does things normally. You only have to pay that cost when you're changing something else, like the list of start_one calls at the end, such as to add a new repo.

As a bonus, this script copies the static fossil binary out of the first container it creates for later local use, replacing the first instance it finds in the PATH. Since the script has to be run as root, I keep it in /usr/local/bin so Fossil can find it when syncing over SSH, which works by running fossil test-http over the tunnel. Even if you don’t use ssh:// URIs with Fossil, having a copy of the binary out on the host side is considerably more convenient than issuing “podman exec NAME fossil” commands.

Prior to creating this, I had a script that would build Fossil from source on the remote server, then do a “make install” and finally restart all of the fossil server instances running directly on that host. This new scheme has a number of benefits over that:

1. The build step happens on my big development box, not on the cheap VPS host. Even with all the overhead in this process, it nets out faster.

2. It’s more secure: each subsection of my site served by Fossil is fully isolated from the others.

3. The disk space cost of the tools needed to manage all of this on the small VPS host net out about equal to the disk space needed to hold the Fossil source code, the repo clone, and the build products. On my development box, a few hundred megs of stuff isn’t a big deal, but it’s a significant fraction of the tiny slice of disk space I choose to rent from my hosting provider.

This script is meant to be forked. Adjust the variables at the top to suit your site’s configuration, and replace the canned set of start_one calls at the end to do something useful. The script maps each repository into your site’s root, named after the repository file’s basename; you might want to adjust this as well.

The script assumes each repository is stored in ~/museum/PROJECT/repo.fossil for the benefit of the container.

If your changes to the script are small enough, I suggest this workflow: clone this repository onto your host, open it up somewhere, and put its bin/ directory into your PATH. Make your changes, then commit those changes to a private branch. Now you can run from your private version, but merge new upstream changes in easily at need.