Fossil Add-Ons

Files in bin/ of trunk

Files in directory /bin from the latest check-in of branch trunk

Helper Programs


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 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:

$ podman auto-update

Podman remembers the URI of the image so that it can check it for changes, then fetch a new version and rebuild the systemd units when necessary. This is about twice as fast as the way fslsrv does things normally. You need only pay the full cost when you’re changing something else, like the list of start_one calls at the end, as when adding 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. I keep it in /usr/local/bin, owned by my non-root user on that server to allow sync over SSH tunnels.

Notice that we did not prefix the above command with sudo. This is because fslsrv builds user units, not system units. It is able to do this by making use of Podman’s rootless-by-default nature, in particular its ability to map the root user inside the container (ID 0) to our non-root user out on the host.1

Because of this, you may have to say this on your system to get the containers to start up on boot and keep running after you log out of the system:

$ sudo loginctl enable-linger $USER

This is because some systemd-based Linuxes assume user services are needed only while that user is interactively logged in.

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.

  1. ^ This in turn is why the script adds the --nojail command to the fossil server instantiation: without it, Fossil would chroot itself inside our container, which is not only redundant, it would mean it couldn’t see the faux /dev tree Podman mapped into the container for us.