Files
Laufzettel/docs/issues/025-gesundheit-fehlermeldung.md
T
Florian Wilde bf1e52cf73
Prüfung / pruefung (push) Canceled after 0s
Prüfung / pruefung (pull_request) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s
Prüfung / e2e (pull_request) Canceled after 0s
feat(betrieb): native Installation, Proxmox-Einzeiler und Abnahme
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
2026-09-26 15:53:01 +02:00

1.3 KiB
Raw Blame History

#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

{ "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.

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