Files in directory /bin in any check-in
- fslsrv
- README.md
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:
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.
It’s more secure: each subsection of my site served by Fossil is fully isolated from the others.
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.