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