Florian Wilde
bf1e52cf73
Zwei Wege in den Betrieb, beide so weit gefahren, wie es hier moeglich war. deploy/install.sh richtet Debian 13 in neun Schritten ein: PostgreSQL 17 hoert nur am Unix-Socket, der Dienstnutzer hat kein Login, die Geheimnisse entstehen im Zielsystem und liegen 0600 bei root. Die Umgebungsdatei wird nie ueberschrieben -- auch nicht beim Aktualisieren, sonst enden alle Sitzungen und die verschluesselten Bind-Passwoerter waeren unlesbar. deploy/proxmox/laufzettel.sh legt den Container an und ruft install.sh darin auf. Der pct-Teil ist ungetestet, weil kein PVE-Host zur Verfuegung stand; die Gegenprobe steht als Pruefliste in docs/betrieb/proxmox.md, das Folge-Issue ist #024. Die Abnahme gegen alle 61 Kriterien hat drei Zusagen ohne Deckung gefunden, alle behoben: der Healthcheck des Webdienstes konnte nie bestehen (busybox loest localhost nach ::1 auf, Next lauscht nur auf IPv4), die CI-Pipeline konnte in keinem Job gruen werden (kein LDAP-Dienst, kein gestarteter Server, kein shellcheck), und der README nannte fuer die Entwicklungsdatenbank den falschen Port. Closes #19
36 lines
1.3 KiB
Markdown
36 lines
1.3 KiB
Markdown
# #025 Healthcheck gibt die rohe Datenbankfehlermeldung heraus
|
||
|
||
**Status:** offen
|
||
**Im Tracker:** –
|
||
**Meilenstein:** v0.2.0
|
||
**Labels:** phase-2, backend
|
||
**Geschätzt:** 1 h **Tatsächlich:** –
|
||
|
||
## Ziel
|
||
|
||
`src/app/api/gesundheit/route.ts` antwortet im Fehlerfall mit
|
||
|
||
```json
|
||
{ "status": "fehler", "meldung": "<fehler.message>" }
|
||
```
|
||
|
||
Der Pfad ist absichtlich ohne Anmeldung erreichbar — er steht in der Allowlist des Proxys, und
|
||
`tests/sicherheitsrichtlinie.test.ts` hält das fest. Eine Fehlermeldung von Prisma oder `pg` nennt
|
||
typischerweise Host, Port, Benutzername und Datenbanknamen. Das ist für einen öffentlich erreichbaren
|
||
Endpunkt zu viel: er soll sagen, **ob** es geht, nicht warum nicht.
|
||
|
||
Aufgefallen beim Abnahme-Review zu [#019](019-betrieb-release.md).
|
||
|
||
## Aufgaben
|
||
|
||
- [ ] Nach außen nur `{ "status": "fehler" }` mit Status 503
|
||
- [ ] Die Begründung serverseitig protokollieren, damit sie beim Suchen nicht fehlt
|
||
- [ ] Prüfen, ob `docs/betrieb/` irgendwo die Meldung als Diagnosehilfe nennt — dann auf das Log
|
||
verweisen
|
||
|
||
## Akzeptanzkriterien
|
||
|
||
- [ ] Test: bei nicht erreichbarer Datenbank enthält die Antwort weder Host noch Port noch
|
||
Benutzernamen
|
||
- [ ] Test: der Statuscode bleibt 503, damit Docker und der Reverse Proxy weiter richtig entscheiden
|