Watch
0
0
Fork
You've already forked hyperhive
0

hive-gateway: keep matrix discovery on the hive domain of a homeserver host without a hive

The hive-domain vhost renders where a hive or the homeserver runs. Its
matrix .well-known JSON and /matrix/ redirect are served wherever the
homeserver runs; the dashboard, swagger UI, agent routes and the
agents.conf include only where a hive runs, since they proxy to hive-c0re.

The gateway doc's vhost map says which rows exist without a hive, and the
trust-bundle text describes ca.pem by what it is rather than as retired.

Refs #4588
This commit is contained in:
atlas 2026-10-04 17:58:16 +02:00 • committed by mara
commit 3e1ac4e678
5 changed files with 91 additions and 51 deletions

View file

@ -49,8 +49,8 @@ identity a swarm service uses.
`hive-tls-resign.timer` once a day. It asks the store for a new leaf when
the current one is missing, past half the role's 720-hour lifetime, missing
a configured name, doesn't match the key beside it, or doesn't chain to the
store's root (`swarm-services-root.pem`). That last check is what replaces a
leaf the retired hive CA signed, on the first run that reaches the store.
store's root (`swarm-services-root.pem`). The first run that reaches the
store replaces a leaf that doesn't chain to that root, whoever signed it.
**The gateway doesn't wait for the store.** Nothing orders the gateway after
`hive-tls-resign.service`, so a hive holding a valid leaf starts its gateway
@ -65,8 +65,9 @@ self-signed root a consumer already holds in its trust bundle.
**A gateway host that runs no hive** (`deploy.hive-controller.enable` off,
such as a dedicated swarm-services or secret-store host) has no hive leaf, no
`hive-tls-resign.service`, no hive identity and no hive-domain vhost. Its
gateway serves the swarm-services leaf as its default certificate too. Where it
`hive-tls-resign.service`, no hive identity and no dashboard or agent routes;
its hive-domain vhost exists only to serve matrix discovery where the
homeserver runs there. Its gateway serves the swarm-services leaf as its default certificate too. Where it
fronts other swarm names it waits for `swarm-services-cert.service` at start.
Where the store's UI is its only swarm name it starts on a throwaway
self-signed certificate and switches to the services leaf once the store
@ -79,16 +80,16 @@ the file every consumer anchors on. It holds whichever of these exist:
- `swarm-services-root.pem`, the store's `pki` root, which the gateway leaf
and the swarm-services leaf both chain to.
- `ca.pem` and `ca-previous.pem`, the retired hive CA's public certificates,
so a leaf it signed keeps verifying until it's replaced. Removing them is a
deliberate later step.
- `ca.pem` and `ca-previous.pem`: a hive CA's public certificates. Nothing
issues under that CA; they stay in the bundle so a leaf it signed verifies
until `hive-tls-resign` replaces it. Removing them is a deliberate later
step.
- the swarm root, `<swarm.ca.stateDir>/root.pem`, on the host that generates
it.
No hive generates a CA or signs with a CA key. A
`<deploy.hive-controller.tls.stateDir>/ca-key.pem` an earlier generation left
stays on disk, unread: removing it comes with dropping `ca.pem` from the
bundle.
`<deploy.hive-controller.tls.stateDir>/ca-key.pem` stays on disk, unread:
removing it comes with dropping `ca.pem` from the bundle.
⚠️ **A consumer reads its trust when it starts.** An agent or service
container that last started before the store's root reached the bundle