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 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.
- ^
This in turn is why the script adds the
--nojail
command to thefossil 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.