blob: 4a5a0e18b2d4e0396487de5ab96d06563919f437 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
# Architecture
Intended to be deployed on OpenBSD with all processes running with minimal privileges.
- LAN
- shop.samanthony.xyz
- Basic web server, e.g. httpd(8)
- Serves static HTML files
- Serves scripts (js/wasm) including htmx.js
- api.shop.samanthony.xyz
- `buthd` API server
- Serves htmx fragments
- Proxy between client HTTP and backend 9P servers
- Handles login forms: client↔authfs
- Handles cart and checkout endpoints: client↔shopfs
- authfs
- `buthauthfs` 9P file server daemon
- Persistent user database
- Stores password hashes
- Manages client sessions
- shopfs
- `buthshopfs` 9P file server daemon
- Inventory
- User shopping carts
- Checkout
- relayd(8)
- TLS proxy/gateway
- WAN
- Client web browser
- HTML renderer, js/wasm interpreter
- Generates and stores session cookies
The LAN could be either a single OpenBSD host, several vmd(8) VMs, or several machines in a VPN, e.g. Tailscale.
An administrator can manage the site by mounting the `fs` daemons in a terminal's namespace with userspace plan9 utils.
![[arch.png]]
## Notes
Should `buthd` be monolithic, or should there be one http/9p gateway per 9p file server, multiplexed by relayd? should the htmx fragment serving/template rendering be broken out into its own process?
Nice to minimize number of http servers (just httpd and buthd). Less sysadmin: relayd, permissions, init scripts.
|