From e6e7ab033e6d06f5e9cb21cd5b340ee6c9a947c7 Mon Sep 17 00:00:00 2001 From: Dogfather Date: Wed, 26 Aug 2026 23:48:21 +0200 Subject: [PATCH] DEPLOY.md: die heutigen Werkzeuge und der Stand der offenen Punkte Nach einem Tag mit vielen Aenderungen beschrieb die Anleitung weder, was neu automatisch laeuft, noch stimmte ihre Liste offener Punkte. NEU AUFGENOMMEN - Zwei Zahlen beim Webdesign-Deploy: CACHE_NAME in sw.js UND die Nummer in der Registrierungsadresse. Mit Begruendung, warum eine allein nicht reicht -- Cloudflare ersetzt das "no-cache" des Servers durch vier Stunden, gemessen am 26.08.2026. - Was per Cron laeuft: Sicherung (taeglich 03:15) und Waechter (alle fuenf Minuten), samt Probeschalter und der Grenze, die bleibt. - Die Verwaltung als eigene App, und warum ihr Manifest in der Ausnahmeliste der Zugangswand stehen muss. OFFENE PUNKTE NACHGEPRUEFT STATT ABGESCHRIEBEN Der Eintrag "Hintergrundbilder liegen nur auf dem Server" stimmt nicht mehr: Alle genannten Dateien und der Avatar-Ordner sind versioniert, "git status --untracked-files=all -- assets/" meldet auf dem Server null. Als erledigt gekennzeichnet, nicht geloescht -- eine Liste, in der Erledigtes ungekennzeichnet steht, wird beim naechsten Mal gar nicht mehr gelesen. Der CORS-Punkt war schaerfer formuliert als die Lage: Die Antwort enthaelt KEIN Access-Control-Allow-Credentials, und die Verwaltung weist sich ueber "Authorization: Bearer" aus statt ueber ein Cookie. Ein Browser schickt bei einer fremden Seite also weder Cookies noch das Token mit; erreichbar sind nur die ohnehin oeffentlichen Endpunkte. Sauberer waere eine feste Herkunftsliste -- das ist Haertung, keine Reparatur, und gehoert als eigener Vorgang mit Live-Test angefasst. Ergaenzt: express 5 ist vorbereitet aber bewusst nicht umgestellt, und die Datenschutz-Endpunkte warten auf einen Pull in /home/dogiintern. Co-Authored-By: Claude Opus 5 --- DEPLOY.md | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 109 insertions(+), 8 deletions(-) diff --git a/DEPLOY.md b/DEPLOY.md index 0aee7f64..92d7d52a 100644 --- a/DEPLOY.md +++ b/DEPLOY.md @@ -121,6 +121,76 @@ ssh dogfather-server "rm -f /home/dogiweb/dogfather-universe/server/package-lock ssh dogfather-server "cd /home/dogiweb/dogfather-universe && git pull --ff-only origin main" ``` +## ⚠️ Am Webdesign-Bereich geändert? Dann ZWEI Zahlen hochzählen + +Die App speichert Dateien zwischen. Nach einer Änderung an `webdesign/` +oder `assets/` müssen **beide** Stellen hoch, sonst bekommen Geräte, die +die Seite schon einmal geöffnet haben, weiterhin den alten Stand: + +``` +webdesign/sw.js const CACHE_NAME = "dogfather-webdesign-vNN"; +assets/js/wd-core.js .register("/webdesign/sw.js?v=NN", …) +``` + +**Warum zwei und nicht eine.** `CACHE_NAME` wirft den Zwischenspeicher +weg, sobald der Service Worker startet. Die Nummer in der Adresse sorgt +dafür, dass er überhaupt neu geladen wird — und das ist hier nicht +selbstverständlich: + +Gemessen am 26.08.2026: Der Server liefert `sw.js` mit +`Cache-Control: no-cache` aus. **Cloudflare ersetzt das durch +`max-age=14400`** — vier Stunden, auch bei `cf-cache-status: MISS`. +Ursache ist eine feste „Browser Cache TTL" in den Cloudflare-Einstellungen. +Ohne die Nummer in der Adresse erreicht jede Änderung am Service Worker +die Geräte also bis zu vier Stunden zu spät. Solange alles läuft, fällt +das nie auf; ist der Stand fehlerhaft, sind es vier Stunden ohne +Reparaturmöglichkeit. + +## Was auf dem Server automatisch läuft + +Beides über `/etc/cron.d/`, beides als root. Die Skripte liegen im Repo +und werden über den normalen `git pull` aktualisiert — ein eigener +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` | + +**Sicherung.** Nutzt SQLites eigenen `.backup`-Befehl, keine Dateikopie — +die Datenbank ist 778 KB groß, ihr WAL 4,1 MB, eine Kopie der `.db` +allein wäre also weitgehend leer. 14 tägliche Stände, sonntags zusätzlich +ein Wochenstand (8 davon). Jeder Stand wird sofort nach dem Anlegen +geprüft. Wiederherstellung: `server-internal/wiederherstellen.sh`, zeigt +ohne Argument die verfügbaren Stände. + +**Wächter.** Prüft sechs Dienste, neun Adressen, Plattenplatz und zwei +Zertifikatslaufzeiten. Meldet per Push, und zwar **nur bei +Zustandswechsel** — nicht alle fünf Minuten dasselbe. Läuft als root und +verschickt selbst; ein Wächter, der über den internen Dienst meldet, +wäre ausgerechnet dann still, wenn dieser das Problem ist. + +Meldeweg prüfen, ohne auf eine Störung zu warten: + +```bash +sudo /usr/local/bin/node /home/dogiweb/dogfather-universe/server-internal/waechter.mjs --probe +``` + +⚠️ **Grenze:** Ist der Server als Ganzes weg — Netz, Strom, Hardware —, +meldet auch der Wächter nichts. Dagegen hilft nur eine Überwachung +außerhalb der Maschine. + +## Die Verwaltung ist eine eigene App + +Seit dem 26.08.2026 hat `webdesign/verwaltung.html` ein **eigenes** +Manifest (`verwaltung.webmanifest`) mit eigener `id` und eigenem Symbol. +Ohne die unterschiedliche `id` hielten Browser beide für dieselbe App, +und die zweite Installation überschriebe die erste. + +Das Manifest steht in der Ausnahmeliste von `server/webdesign-gate.js` — +ohne diesen Eintrag antwortet es mit 302 auf die Zugangswand, und der +Browser bietet „App installieren" gar nicht erst an. + ## Pflicht-Prüfung nach JEDEM Deploy Nicht auf die Erfolgsmeldung des Deploy-Befehls verlassen, sondern **die echte Domain fragen**: @@ -169,14 +239,45 @@ Deploy vom Rechner aus überschrieben worden. ## Offene Punkte -- Mehrere Hintergrundbilder liegen **nur auf dem Server und auf Filipes Rechner**, aber in - keiner Git-Ablage (`bg-bewerben-modi*.jpg`, `bg-bewerben-scout*.jpg`, `bg-links-seite*.jpg`, - `bg-medien-casper*.jpg`, `bg-medien-hasidog*.jpg`, `bg-supporter*.jpg`, `bg-modis.jpg`, - Ordner `assets/img/stimmen-avatare/`). Die Seiten `bewerben-modi.html`, `links.html`, - `medien-casper.html`, `supporter.html` u.a. benutzen sie live. Geht der Server verloren, - fehlen sie. Sie sind bewusst **nicht** in `.gitignore` — sie wurden schlicht nie hinzugefügt. -- CORS im Postfach-Worker weiterhin offen (`"*"`), siehe TODO in - `cloudflare-worker/src/lib/http.js`. +- ~~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 + `assets/img/stimmen-avatare/` (8 Dateien) sind inzwischen versioniert. + `git status --untracked-files=all -- assets/` auf dem Server meldet **null** + unverfolgte Dateien. + + Der Eintrag bleibt hier stehen, statt gelöscht zu werden: Eine Liste offener + Punkte, in der Erledigtes ungekennzeichnet steht, wird beim nächsten Mal gar + nicht mehr gelesen. Wer prüft, will sehen, dass geprüft wurde. + +- **CORS steht auf `*`** — in `server-internal/index.js` (`app.use(cors())`) und im + Altbestand `cloudflare-worker/src/lib/http.js`. + + **Eingeordnet am 26.08.2026, weniger dringend als der alte Hinweis klang:** + Die Antwort enthält *kein* `Access-Control-Allow-Credentials`, und die + Verwaltung weist sich über `Authorization: Bearer …` aus, nicht über ein + Cookie. Ein Browser schickt bei einer fremden Seite deshalb weder Cookies noch + das Token mit — eine fremde Seite erreicht damit nur die ohnehin öffentlichen + Endpunkte (Team, Events, Stimmen). An Kundendaten kommt sie nicht. + + Sauberer wäre es trotzdem: eine feste Liste erlaubter Herkünfte + (`dogfather-universe.com`, `vans-diy-bastelbedarf.com`) statt `*`. Das ist + Härtung, keine Reparatur — und ein Eingriff in einen laufenden Dienst, der bei + zu enger Einstellung die Seite lahmlegt. Also als eigener Vorgang, mit + Live-Test danach. + +- **express 5 vorbereitet, nicht umgestellt.** `pruef-express5.mjs` (Bestand + durchsuchen) und `server/test-express5.mjs` (echter Server gegen 5.2.1) sind + grün — der Umstieg wäre ohne Codeänderung möglich. Nicht durchgeführt, weil + express 4.22.2 gepflegt wird und `npm audit` null meldet. Ebenfalls offen: + 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. ## Alternative Hosting-Optionen (nur als Notfall-Plan)