Compare commits
3 commits
c76bbf2791
...
59295318f8
| Author | SHA1 | Date | |
|---|---|---|---|
| 59295318f8 | |||
| f332559b59 | |||
| bbcc9cd998 |
1 changed files with 0 additions and 65 deletions
|
|
@ -1,65 +0,0 @@
|
||||||
# nsecbunkerd migration & DB-maintenance runbook
|
|
||||||
|
|
||||||
Operational notes for applying schema migrations and ACL/pairing maintenance on
|
|
||||||
deployed, **LNbits-connected** nsecbunkerd instances.
|
|
||||||
|
|
||||||
## ⚠️ Never full-wipe `nsecbunker.db` on an LNbits-connected instance
|
|
||||||
|
|
||||||
The nsecbunkerd ↔ LNbits pairing is **split across both systems**:
|
|
||||||
|
|
||||||
- **Bunker** (`nsecbunker.db`): per-account `KeyUser` binding (keyed by LNbits's
|
|
||||||
stable client pubkey) + redeemed `Token` + a shared `Policy`.
|
|
||||||
- **LNbits** (`accounts.signer_config`, `RemoteBunkerSigner`):
|
|
||||||
`{token, client_nsec, policy_id}`.
|
|
||||||
|
|
||||||
`RemoteBunkerSigner.sign_event()` signs **directly with the stored `client_nsec`**
|
|
||||||
— it does NOT re-connect/re-redeem, and there is **no auto-repair** on restart or
|
|
||||||
sign-failure. `provision()` runs only at new-account creation and mints a NEW
|
|
||||||
npub (which changes the user's nostr identity).
|
|
||||||
|
|
||||||
**Consequence of a full `nsecbunker.db` wipe:** the `KeyUser` bindings are
|
|
||||||
deleted → every LNbits account's stored config dangles → all signing fails, and
|
|
||||||
the only standard "repair" (`provision()`) changes identities. **Do not do it.**
|
|
||||||
|
|
||||||
### Correct way to strip the #24 materialized photocopies
|
|
||||||
|
|
||||||
Post-#27, token grants are evaluated live via the ACL step-4 `Token → Policy →
|
|
||||||
PolicyRule` join, so the old materialized `SigningCondition` rows are redundant
|
|
||||||
— and, written with `expiresAt = NULL`, they would keep granting past a token's
|
|
||||||
expiry (silently re-opening #24 for already-paired clients). Strip them with a
|
|
||||||
**targeted delete** that preserves the pairing:
|
|
||||||
|
|
||||||
```sql
|
|
||||||
-- Verify first.
|
|
||||||
SELECT COUNT(*) FROM Token WHERE redeemedAt IS NOT NULL; -- bindings to preserve
|
|
||||||
SELECT COUNT(*) FROM SigningCondition; -- photocopies to strip
|
|
||||||
|
|
||||||
-- Keeps KeyUser + Token + Policy intact. Live-token clients keep working
|
|
||||||
-- untouched; only the stale photocopies are removed.
|
|
||||||
DELETE FROM SigningCondition;
|
|
||||||
```
|
|
||||||
|
|
||||||
Run against each instance's `nsecbunker.db`. If an instance was already
|
|
||||||
full-wiped, recover by restoring the pre-wipe `nsecbunker.db` backup, then run
|
|
||||||
the targeted delete.
|
|
||||||
|
|
||||||
> Manual-override grants (`add_signing_condition`, web-approval) also live in
|
|
||||||
> `SigningCondition`. On an LNbits-only bunker there typically are none, so a
|
|
||||||
> blanket `DELETE FROM SigningCondition` is safe. If an instance uses manual
|
|
||||||
> overrides, delete only the policy-derived rows you intend to strip.
|
|
||||||
|
|
||||||
## Keys are never in the DB
|
|
||||||
|
|
||||||
Key material lives in `nsecbunker.json` (`keys`), never in `nsecbunker.db`. A DB
|
|
||||||
wipe loses ACL/pairing state, never keys. LNbits holds the bunker **admin nsec**
|
|
||||||
(`LNBITS_NSEC_BUNKER_ADMIN_NSEC`) and is the sole admin client.
|
|
||||||
|
|
||||||
## Schema migrations
|
|
||||||
|
|
||||||
Migrations are applied by the deploy's `prisma migrate deploy`, **not** by the
|
|
||||||
daemon on boot — the in-`start.js` `npm run prisma:migrate` step is a no-op
|
|
||||||
(tracked in #31). After adding a migration, make sure the deploy applies it.
|
|
||||||
|
|
||||||
Prisma on NixOS needs the engine env pinned to `prisma-engines_6` (the bare
|
|
||||||
`prisma-engines` attr is now 7.x with no `libquery_engine.node`; devShell fix
|
|
||||||
tracked in #30). The deploy's `package.nix` already pins `_6`.
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue