docs: what a site needs that no page answered
Four gaps a second site hits and cannot resolve by reading. **Restoring on Windows** was one sentence - "the standard mysql < dump.sql" - with no ordering. Restoring a database under running code that expects a different schema turns a restore into a second incident, so the steps are now ordered and each says why. It also says what `.env` costs if it is lost, which is the part nobody discovers until they are already rebuilding: the dump does not contain it, and without the JWT secrets every issued token dies, so every collector and every GE-Enforce client on the fleet needs a new key. **Rolling back** had a paragraph saying downgrades are refused and a backup is the way back, but not the procedure. Rollback is restoring a matched pair, code and the schema it expects, in that order - and the doc now separates it from the case it gets confused with: a migration that failed mid-update has already been rolled back by the installer, and fixing forward is the only move. **Sizing, acquisition and support** were absent from the install guide entirely. A reader could not learn how big a server to ask for, where the .exe comes from, or where to raise a problem. The sizing is small and the reasons are stated, so a site does not over-provision a VM for a load that is a few dozen users. **Credentials** were described in three documents from three ends, so three answers existed for where a key lives. One table, both ends - server and PC - plus the two rules behind it: what a shop-floor PC holds is scoped to exactly what it does, and a credential is delivered rather than typed, because a value entered per machine is a value that is wrong on some machine.
This commit is contained in:
@@ -68,6 +68,25 @@ takes everything over HTTPS, because those PCs have no share.
|
||||
credentials at all, because a screensaver and a wall display have nowhere to
|
||||
keep one. They are read-only and carry nothing a floor visitor should not see.
|
||||
|
||||
## Where the credentials live
|
||||
|
||||
Three documents each named a different place, which is what happens when a
|
||||
credential is described from whichever end the author was working on. Both ends
|
||||
are here.
|
||||
|
||||
| Credential | On the server | On the PC | Rotate by |
|
||||
|---|---|---|---|
|
||||
| Collector key | A managed token scoped to `collector.ingest` only. `COLLECTOR_API_KEY` in `.env` also works and is simpler for a pilot, but cannot be revoked per fleet. | `HKLM:\SOFTWARE\GE\ShopDB` value `CollectorKey` | Replacing the token file the fleet reads from, so every PC picks it up on its next cycle. Never put it in the manifest - manifests sync broadly. |
|
||||
| GE-Enforce fetch token | A managed service token scoped to the GE-Enforce fetch scope | `HKLM:\SOFTWARE\GE\ShopDB` value `ApiToken` | Same path as the collector key |
|
||||
| Server URL | n/a | `HKLM:\SOFTWARE\GE\ShopDB` value `BaseUrl` | Setting it once at install; nothing should overwrite a bay's own value |
|
||||
| Application secrets | `.env`: `SECRET_KEY`, `JWT_SECRET_KEY`, `DATABASE_URL`, integration tokens | n/a | See [BACKUP-RESTORE](BACKUP-RESTORE.md) - losing these invalidates every issued token |
|
||||
|
||||
Two rules behind that table. A shop-floor PC is not a trusted place, so what it
|
||||
holds is scoped to exactly what it does: a collector key that leaks buys the
|
||||
reader the ability to file a PC report, not to read the asset register. And a
|
||||
credential is delivered, never typed - a value that has to be entered per machine
|
||||
is a value that is wrong on some machine.
|
||||
|
||||
## What owns what
|
||||
|
||||
The question that decides most arguments: **who is allowed to change this?**
|
||||
|
||||
Reference in New Issue
Block a user