vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs/setup: the granting unit runs on the host now

Browse source 
The bootstrap block still described a one-shot unit "inside the store's
container". That stopped being true when the unit moved, and a merged
change that leaves the docs asserting the old topology is worse than one
that never moved it.

Also retires the "only run once, didn't go all the way through" note. It
has run twice against a live store now and failed both times — but for
its own reasons, not the grants': it could not reach the store from where
it ran, so neither attempt exercised a single one of them. The grants are
still derived from `-output-policy` rather than proven, and the warning
now says that directly instead of implying a partial test.
This commit is contained in:
atlas 2026-09-10 21:22:57 +02:00 • committed by mara
commit bf54436937
1 changed files with 11 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

19
docs/getting-started/setup.md
View file

@ -103,16 +103,17 @@ bao token create -policy=swarm-bootstrap -ttl=24h -orphan -display-name=swarm-bo
``` ```
Put the token's value at `services.hyperhive.deploy.bao.bootstrapTokenFile` Put the token's value at `services.hyperhive.deploy.bao.bootstrapTokenFile`
(all-local names that path for you), then rebuild. A one-shot unit inside the (all-local names that path for you), then rebuild. A one-shot unit **on the
store's container reads it, writes the `swarm-controller` policy, enables the host** reads it, writes the `swarm-controller` policy, enables the cert auth
cert auth method, and creates the `swarm-controller` role that attaches the two. method, and creates the `swarm-controller` role that attaches the two. It runs
there because every API listener demands a client certificate, and the host is
the side that has one.
⚠️ **This has only run once, and it didn't go all the way through.** The ⚠️ **The grants above are derived, not proven.** They come from
first real provision against a live store returned 403, so `-output-policy`, not from a swarm that came up on them. The unit has run twice
treat the block above as derived, then only partly tested — not proven: the against a live store and failed both times for reasons of its own — it could
grants still come from `-output-policy`, not from a swarm that came up on them. not reach the store from where it then ran — so neither run exercised these
What that 403 does _not_ tell you is whether the login or the write was grants at all.
refused — `bao read auth/cert/certs/swarm-controller` separates the two.
**Delete the file only once `bao read auth/cert/certs/swarm-controller` returns **Delete the file only once `bao read auth/cert/certs/swarm-controller` returns
the role.** The unit skips when the token is absent, so a host that has finished the role.** The unit skips when the token is absent, so a host that has finished