DEPLOY.md: voller Deploy-Block für den internen Dienst + Stand nachgezogen

- Vollständiger kopierfertiger Deploy-Block für server-internal MIT npm ci:
  pull -> npm ci -> Lade-Test der nativen Module -> restart -> Selbsttest,
  als eine &&-Kette, die bei jedem Fehler VOR dem Neustart abbricht (alter
  Dienst läuft dann unberührt weiter). Bisher stand dort nur pull + restart
  ohne npm ci -- genau die Lücke, durch die Code und Pakete auseinanderliefen.
- Wächter: 18 -> 19 Punkte (Sicherungsprüfung dazugekommen).
- Zwei offene Punkte ergänzt: ausstehender Server-Neustart (Kernel/OpenSSL
  liegen bereit) und der ausstehende server-internal-Deploy.
- Veralteten Datenschutz-404-Eintrag abgehakt (heute live 401 verifiziert).

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-08-27 11:16:30 +02:00
co-authored by Claude Opus 5
parent 9bd9357185
commit 50ff8e0f4c
+46 -7
View File
@@ -52,13 +52,36 @@ Dienst mit unverändertem Code neu und wundert sich, warum nichts passiert.
`claudian` hat auf `/home/dogiintern/` **keinen Zugriff** (weder lesend noch
über den begrenzten sudo). Änderungen an `server-internal/` muss deshalb
Filipe selbst ausrollen:
Filipe selbst ausrollen.
**Der Standard-Fall** (nur Code geändert, keine neuen/geänderten Pakete):
```bash
sudo -u dogiintern git -C /home/dogiintern/dogfather-universe pull --ff-only origin main
sudo systemctl restart dogiintern.service
```
**Der volle Fall** (auch `package.json`/`package-lock.json` geändert — dann MUSS
`npm ci` mit, sonst laufen Code und Pakete auseinander). Ein Block, bricht bei
jedem Fehler ab, und startet den Dienst erst neu, wenn Pull, Installation und
ein Lade-Test der nativen Module (better-sqlite3) durch sind — schlägt etwas
fehl, läuft der alte Dienst unberührt weiter:
```bash
cd /home/dogiintern/dogfather-universe && \
sudo -u dogiintern git pull --ff-only origin main && \
sudo -u dogiintern npm --prefix server-internal ci && \
sudo -u dogiintern node -e "require('/home/dogiintern/dogfather-universe/server-internal/node_modules/better-sqlite3'); console.log('native Module laden: ok')" && \
sudo systemctl restart dogiintern.service && \
sleep 2 && echo "Dienst:" $(systemctl is-active dogiintern.service) && \
curl -s -o /dev/null -w "health nach Neustart: %{http_code}\n" https://postfach.dogfather-universe.com/health
```
Erwartete letzte Zeilen: `native Module laden: ok`, `Dienst: active`,
`health nach Neustart: 200`. Kommt stattdessen ein Abbruch VOR dem Neustart,
ist nichts passiert — der alte Dienst läuft weiter, und der Fehler (meist ein
fehlgeschlagener `npm ci`) lässt sich in Ruhe ansehen.
## Server-Code geändert? Dann ist ein Neustart PFLICHT
Statische Dateien sind nach dem Pull sofort live. Server-Code **nicht** —
@@ -155,7 +178,7 @@ Deploy-Schritt ist nicht nötig.
| Wann | Was | Skript |
|---|---|---|
| täglich 03:15 | Sicherung von Datenbank und Uploads | `server-internal/sicherung.sh` |
| alle 5 Minuten | Wächter über 18 Punkte | `server-internal/waechter.mjs` |
| alle 5 Minuten | Wächter über 19 Punkte (inkl. „läuft die Sicherung?") | `server-internal/waechter.mjs` |
**Sicherung.** Nutzt SQLites eigenen `.backup`-Befehl, keine Dateikopie —
die Datenbank ist 778 KB groß, ihr WAL 4,1 MB, eine Kopie der `.db`
@@ -239,6 +262,22 @@ Deploy vom Rechner aus überschrieben worden.
## Offene Punkte
- **Server-Neustart steht aus (seit 28.08.2026).** `unattended-upgrades` hat
Kernel (6.12.105) und OpenSSL (3.5.7) eingespielt, aber es läuft noch der alte
Kernel (6.12.100) und die Dienste haben die alte libssl im Speicher.
`/var/run/reboot-required` steht. Kein Notfall (die OpenSSL-CVEs betreffen
PKCS7/CMS/QUIC-Pfade, die hier kaum aktiv sind — Caddys QUIC läuft über Go),
aber der Neustart gehört auf eine ruhige Zeit gelegt, während Filipe erreichbar
ist (Netcup-Konsole griffbereit). Danach prüfen: laufen alle sechs Dienste?
- **Server-internal-Deploy ausstehend (28.08.2026):** In Gitea liegen fertige,
getestete Änderungen an `server-internal/`, die noch nicht live sind
(Anfragebremse für `/submit` + `/testimonials/submit`; `package-lock.json` auf
multer 2.2.0 / node-cron 4.6.0). Ausrollen mit dem **vollen** Deploy-Block oben
(der mit `npm ci`), weil sich die Paketstände geändert haben. Getestet:
multer 2.2.0 fängt den DoS-Fall sauber ab, node-cron 4.x akzeptiert den
bestehenden Aufruf, alle Selbsttests grün.
- ~~Hintergrundbilder liegen nur auf dem Server~~ — **erledigt, nachgeprüft am
26.08.2026.** Alle genannten Dateien (`bg-bewerben-modi.jpg`, `bg-links-seite.jpg`,
`bg-medien-casper.jpg`, `bg-supporter.jpg`, `bg-modis.jpg`) und der Ordner
@@ -273,11 +312,11 @@ Deploy vom Rechner aus überschrieben worden.
dotenv 16→17, better-sqlite3 11→13 (dort muss die ABI zur Node-Fassung
passen; ein Fehlgriff legt den internen Dienst still).
- **Datenschutz-Endpunkte warten auf einen Pull in `/home/dogiintern`.** Die
Oberfläche ist live, die drei Endpunkte
(`/webdesign/admin/datenschutz/{auskunft,vorschau,loeschen}`) antworten dort
noch mit 404. Der Pull scheitert vermutlich an der unverfolgten
`package-lock.json` — siehe den Abschnitt zu `npm ci` weiter oben.
- ~~Datenschutz-Endpunkte warten auf einen Pull~~ — **erledigt, live geprüft am
28.08.2026.** Alle drei (`/webdesign/admin/datenschutz/{auskunft,vorschau,
loeschen}`) antworten auf der echten Domain mit 401 (vorhanden und geschützt),
nicht mehr 404. Steht abgehakt hier, nicht gelöscht — wer prüft, will sehen,
dass geprüft wurde.
## Alternative Hosting-Optionen (nur als Notfall-Plan)