@@ -6,12 +6,19 @@ The FastAPI process that owns Albok's buildings-and-wings store (`vh/albok`,
- **URL:** `http://albok.nh3.internal:8392` (= `http://10.100.50.40:8392` ). Container port 8390.
⚠ Host port **8392 ** , because **8390 on nh3-docker is the althing post office ** .
- **Image:** `gitea.phasefinal.com/pfi/albok-service:0.1.1 ` @ `sha256:33e4e98a …` (pinned in
`compose.yaml` ), built from vh/albok `e349d50 ` (tag albok-service/v0.1.1 ; albok core 0.1.1). 0.1.0 ( `0b37431` ) ran 2026-10-02 1754– .
- **Image:** `gitea.phasefinal.com/pfi/albok-service:0.1.2 ` @ `sha256:6f91a33f …` (pinned in
`compose.yaml` ), built 2026-10-03 0250 from vh/albok `544ecfd ` (tag albok-service/v0.1.2 ; albok core 0.1.2) .
⚠ Built from albok-dev's LOCAL commit before the operator pushed it (main was 29 ahead of origin). After the
push, check that origin's tag `albok-service/v0.1.2` is still `544ecfd` . Image labels carry the full SHA.
History: 0.1.0 (`0b37431` ) 2026-10-02 1754– `e349d50` ) 1805 to 2026-10-03 0251.
- **Health:** `GET /health` (no auth) → `"status": "ok"` on 0.1.1. (0.1.0 always said `degraded` : its
canary reports `alive` and the check expected `ok` ; fixed in 0.1.1.) The Docker healthcheck checks HTTP 200.
- **0.1.1 also accepts numeric `default_gid` / `gid` in the config**, which would make the mounted
`/etc/group` unnecessary. The current name-based config stays valid, so it is left as is.
- **Why 0.1.2:** 0.1.1 leaked a Chroma client (and its sqlite fds) on every health probe. After 9 h it held 1018 of
1024 fds, 478 of them deleted canary files, and `/health` and `/search` answered 500. 0.1.2 closes the client.
Verified 0251: 30 `/health` calls left the fd count at 59, with 0 deleted. The same count had caught the leak on
0.1.1. 0.1.2 also stamps `X-Albok-Service: <version>` on every response.
## Pieces and where they live
@@ -25,8 +32,8 @@ The FastAPI process that owns Albok's buildings-and-wings store (`vh/albok`,
**Identities (fixed numeric ids, created by `playbooks/albok-service-host.yaml`): ** user and group
`albok` 1500:1500 (the image's user), read groups `albok-read` **1510 ** (building `fleet` ) and
`albok-personal` **1511 ** (building `personal` ). Reserve 1512+ for restricted wings ( agent-feedback,
vault) and add each to the host, `conf/group` and `group_add` .
`albok-personal` **1511 ** (building `personal` ). * * `albok-feedback` 1512** = restricted wing `personal/ agent-feedback` (2026-10-03, default-deny: no viewer is
in it). Reserve 1513+ for the vault wing and any later restricted wing; add each to the host, `conf/group` and `group_add` .
**Why the group file and `group_add`: ** the service resolves group NAMES with `grp.getgrnam()`
inside the container and `chgrp` s wing dirs as uid 1500. Without the names in the container's
@@ -36,6 +43,11 @@ Verified: wings came up `drwxr-s--- albok:albok-read` / `albok:albok-personal`,
**Secrets (vault): ** `albok/litellm-key` , a LiteLLM key scoped to `qwen3-embedding` only (alias
`albok-service` ; verified 200 on embeddings, 403 on any other model); `albok/bootstrap-admin-token` ,
the first-start admin token (also at `/srv/albok/private/bootstrap-admin-token` , 0600).
**Nemi (albok's tagger, runs on nh3-dev): ** `albok/token-nemi` , a service token minted 0255 with read+write on
`fleet/memory` , `fleet/stash` and `personal/agent-feedback` ; it sees exactly those three wings (`personal/notes` hidden).
The previous token (`01M40979…` , without agent-feedback) is still live until albok-dev revokes it.
`albok/litellm-key-nemi` , alias `albok-nemi` , scoped to `gen-small` , `summarizer` and `qwen3-embedding` . Verified 200 on
all three and 403 on another model.
**Backups: ** nh3-docker is VM 100 on nh3-pve, in the nightly 21:00 vzdump (snapshot mode → pbs-ana),
so `/srv/albok` is covered whole-VM. No file-level restic job for it.
