docs: zeus keeps time from the router, and why the obvious setup did not

zeus was 142 seconds behind mulan and had no time daemon at all. That
matters more than it looks: the database computes TTL expiries as
absolute times, so a clock that disagrees with the machines writing to it
shifts every retention deadline by the difference.

chrony now runs under runit and takes its time from 192.168.2.1 - the
server DHCP already advertises. dhcpcd's hook writes the lease's NTP
servers into the config, with NTP_CONF pointing at chrony.conf; left
alone the hook picks /etc/ntp.conf, which nothing here reads, so the
DHCP-supplied server went into a file no daemon looked at.

Two attempts that were wrong, both only visible in the log:

Naming the router by hand as well as taking it from DHCP logged "Could
not add source 192.168.2.1" on every start - chrony already had it.

Keeping pool.ntp.org as a fallback meant chrony synced to a stratum-2
pool server in preference to the router at stratum 3, so the machine was
not using the source it was asked to use. The pool is gone; if the router
is down the clock free-runs, which is honest rather than quietly taking
somebody else's time.

Verified: reference ID C0A80201, zeus and mulan report the same second, a
clean restart with no errors, and the enable is a symlink under
/etc/runit/runsvdir/default so it survives a reboot. The container takes
the host clock, so nothing is configured inside it.

deploy/zeus/README.md

@@ -50,3 +50,30 @@ is the smaller step. Neither is done yet.
 The database was stopped first. A live copy of a WAL-backed store can be torn,
 and recovery reported `TrivialSuccess: 27288 docs in 93 collections` with zero
 WAL entries to replay - which is what a clean copy looks like.
+
+## Time
+
+zeus was 142 seconds behind mulan. That matters here because the database
+computes TTL expiries as absolute times, so a clock that disagrees with the
+machines writing to it shifts every retention deadline by the difference.
+
+chrony is installed and enabled under runit, taking its time from the router at
+192.168.2.1 - the same server DHCP advertises. dhcpcd's `50-ntp.conf` hook writes
+the lease's NTP servers into the config, and `/etc/dhcpcd.conf` sets
+`NTP_CONF=/etc/chrony.conf` so it writes them where chrony will read them; by
+default the hook picks `/etc/ntp.conf`, which nothing here reads.
+
+Two things learned while setting it up, both visible only in the log:
+
+- Naming the router in `chrony.conf` by hand *and* letting DHCP write it in
+  produced `Could not add source 192.168.2.1` on every start. DHCP supplies it,
+  so the manual line is gone.
+- With `pool pool.ntp.org` also configured, chrony synced to a stratum-2 pool
+  server in preference to the router at stratum 3. The pool is gone: the router
+  is the source. If it is down the clock free-runs, which is the honest outcome
+  on a LAN rather than quietly taking somebody else's time.
+
+    chronyc tracking     # Reference ID should be C0A80201 (192.168.2.1)
+    chronyc sources      # ^* marks the selected source
+
+The container takes the host's clock, so nothing is configured inside it.