If systemd detects that the system clock is not correct, it sets it to a
"known good" time based on the release date of its version. Since this
can still be weeks or months in the past, it will use the timestamp of
the `/usr/lib/clock-epoch` file, if it exists, as the reference time.
To get our system clock closer to the correct time earlier in the boot
process, we update the `clock-epoch` file's timestamp during build.
This will cause the clock to be set to approximately the build time of
the root filesystem image. Presumably, the rootfs image is built
relatively frequently, so the time should be a lot closer to correct
than the systemd release date.
Docker and Jenkins need more storage than is available in the *tmpfs*
filesystem mounted at `/var`. We can use NBD to provide additional
storage volumes for these paths.
The `nbd@.service` systemd unit, which is included in the *nbd* package
but not actually installed by it, starts an NBD client, using the
configuration in `/etc/nbdtab` for the specified block device. To avoid
hard-coding the NBD server name here, the file included in the rootfs
image is actually a template. This template is rendered at boot time,
using the same server name specified on the kernel command line for the
rootfs device. Obviously, this implies that the same server has to host
both the rootfs image and the persistent storage, but that is not likely
to be a problem for this project.
To allow multiple devices to use the same rootfs image but separate
persistent storage devices, the `nbdtab` template can include a
placeholder for the device's serial number. This only works for
Raspberry Pi devices, of course, but the concept could be extended to
other device types by adding more placeholders for other
machine-specific properties (e.g. DMI UUID, etc.)
Since `/var/lib/jenkins` is the home directory for the *jenkins* user,
and thus the location of its `~/.ssh/authorized_keys` file, we have to
make sure the *fetch-sshkeys@jenkins.service* unit does not start until
the persistent storage volume is mounted. We also need a service unit
that ensures the permissions of the mount point are correct,
particularly for the first boot when the filesystem is initially
created.
Similarly, we have to ensure that the Docker daemon does not start until
`/var/lib/docker` is mounted. Adding a `RequiresMountsFor=` property to
the *docker.service* unit generates the necessary dependencies to
accomplish this.
Dustin