j3d1/toolshed
2
1
Fork 0
Code Issues 9 Pull requests 1 Projects Releases Packages Wiki Activity

stash

Browse source
This commit is contained in:
j3d1 2026-08-17 03:19:34 +02:00
parent 419893d93d
commit b51d3d05f4
3 changed files with 94 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

17
deploy/prod/README.md
View file

@ -51,8 +51,11 @@ toolshed:
in `user@yourtoolshed.tld`) — see [DNS](#3-dns) for how those two relate.
- `toolshed_handle_domain` — the **handle domain**, only needed when it's
different from `toolshed_domain`. Omit it when the two are the same (it
then defaults to `toolshed_domain`). Set so nginx/Django accept requests
for either domain, whichever ends up as the `Host` header.
then defaults to `toolshed_domain`). It doesn't affect nginx/Django at all
(they only ever accept `toolshed_domain` as the `Host` header) — it's used
solely to populate the `/local/domains` registration fixture (see
`toolshed_register_domains` in `playbook.yml`); publishing the SRV record is a
separate, manual DNS step either way.
- `toolshed_repo_url` — the git remote the playbook checks out and builds
from. Required, no default.
- `toolshed_version` — the branch, tag or commit to check out and build.
@ -94,10 +97,12 @@ There are two distinct domains at play here, and it's easy to conflate them:
`user@yourtoolshed.tld`. Toolshed usernames don't encode a server address
directly; the frontend resolves the handle domain to a server via an SRV
record, `_toolshed-server._tcp.<handle domain>.` (see
`frontend/src/store.js`, `lookupServer`). What's in `toolshed_handle_domain`
(see [Per-deployment configuration](#2-per-deployment-configuration)) only
makes nginx/Django accept it as a `Host` header — publishing the actual SRV
record is still a separate, manual DNS step, covered below.
`frontend/src/store.js`, `lookupServer`), which always points at the web
domain — nginx/Django never see the handle domain as a `Host` header.
`toolshed_handle_domain` (see [Per-deployment
configuration](#2-per-deployment-configuration)) only feeds the
`/local/domains` registration fixture; publishing the actual SRV record is
still a separate, manual DNS step, covered below.
The SRV lookup happens for every login, not just federation with other
servers, so **every** deployment needs it published for its own handle