DogFatherGitandClaude Opus 5
fc26597083
Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."
DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.
Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.
DREI RIEGEL, NICHT EINER
1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
der Person -- ausser der einen, aus der heraus der Code gerade erneuert
wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
Uebung und wird eigens geprueft.
2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
schlimmer als gar keiner.
3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
dem Zugang.
KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
einen Protokolleintrag, und es gibt nichts zu erraten.
Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.
GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.
Co-Authored-By: Claude Opus 5 <[email protected]>
207 lines
8.2 KiB
Markdown
207 lines
8.2 KiB
Markdown
# Wiederherstellung des Creator Workspace
|
|
|
|
Für den Tag, an dem etwas kaputt ist. Geschrieben, damit sie auch dann
|
|
funktioniert, wenn man aufgeregt ist und keine Zeit zum Nachdenken hat.
|
|
|
|
**Der wichtigste Satz zuerst:** Die Datei `workspace.db` allein ist **nicht** die
|
|
Datenbank. Im WAL-Betrieb stehen die neuesten Änderungen in `workspace.db-wal`.
|
|
Wer nur die `.db` kopiert, kopiert unter Umständen **nichts** — genau das war am
|
|
31.08.2026 der Fall (Datenbank 4 KB, WAL 2,1 MB).
|
|
|
|
Deshalb: **Nie Dateien kopieren. Immer die fertigen Sicherungen benutzen.**
|
|
|
|
---
|
|
|
|
## Wo alles liegt
|
|
|
|
| Was | Wo |
|
|
|---|---|
|
|
| Datenbank | `/home/dogiweb/workspace-daten/workspace.db` |
|
|
| Hochgeladene Dateien | `/home/dogiweb/workspace-daten/dateien/` |
|
|
| Wissens-Bibliothek (PDFs) | `/home/dogiweb/workspace-daten/wissen/` |
|
|
| Sicherungen (Server) | `/home/dogiweb/workspace-daten/sicherungen/` |
|
|
| Sicherungen (dieser PC) | `~/Documents/Obelix/Sicherungen/workspace/` |
|
|
|
|
Aufgehoben werden **7 tägliche, 4 wöchentliche, 6 monatliche**. Geschrieben wird
|
|
jede Nacht ab 3 Uhr, geprüft direkt danach.
|
|
|
|
---
|
|
|
|
## Fall 0: „Ich komme nicht mehr rein"
|
|
|
|
Der häufigste Notfall — und der einzige, bei dem nichts kaputt ist. Passiert
|
|
am 02.09.2026: neuen Code für sich selbst erzeugt, im selben Moment abgemeldet,
|
|
Code weg, bevor er abgeschrieben war.
|
|
|
|
**Der alte Code ist nicht wiederherstellbar.** In der Datenbank steht nur seine
|
|
Prüfsumme, nirgends der Klartext — auch nicht in den Sicherungen. Es gibt nur
|
|
den Weg nach vorn: einen neuen setzen.
|
|
|
|
Auf dem Server, angemeldet als `dogi`, **ein Block**:
|
|
|
|
```
|
|
sudo -u dogiweb bash /home/dogiweb/dogfather-universe/tools/notfall-code.sh
|
|
```
|
|
|
|
Für jemand anderen den Namen anhängen, z. B.
|
|
`... notfall-code.sh "Cigdem"`. Ohne Namen nimmt es DogFather. Ein falscher
|
|
Name schadet nichts — das Skript listet dann auf, wen es gibt.
|
|
|
|
Das Skript setzt einen neuen Code, zeigt ihn an und löscht die Sperre nach
|
|
acht Fehlversuchen gleich mit (die hätte sonst 10 Minuten gekostet).
|
|
|
|
**Das `-u dogiweb` muss dranbleiben.** Als `root` ausgeführt gehören die
|
|
Hilfsdateien der Datenbank danach `root`, und der Dienst kann nicht mehr
|
|
schreiben — dann ist wirklich etwas kaputt.
|
|
|
|
Danach: Code **sofort nach Bitwarden**, nicht in eine Notiz, nicht in einen Chat.
|
|
|
|
**Warum es keinen fest hinterlegten Notfall-Code in der Anwendung gibt:** Der
|
|
wäre eine Hintertür, die dauerhaft offensteht — jeden Tag, für jeden, der sie
|
|
findet, ohne dass es auffällt. Dieser Weg verlangt Zugang zum Server,
|
|
hinterlässt einen Protokolleintrag, und es gibt nichts zu erraten.
|
|
|
|
**Seit dem 02.09.2026 sollte er kaum noch nötig sein:** Wer seinen eigenen Code
|
|
erneuert, bleibt in dieser Sitzung angemeldet (alle anderen Geräte fliegen
|
|
weiterhin hinaus), und der Kasten mit dem Code verschwindet nicht mehr von
|
|
selbst. Festgehalten in `server/pruef-code.mjs`.
|
|
|
|
---
|
|
|
|
## Fall 1: „Ich habe aus Versehen etwas gelöscht"
|
|
|
|
Nichts überstürzen. Die Sicherung von heute Nacht hat es noch.
|
|
|
|
**Erst nachsehen, ob es sich lohnt** — ohne irgendetwas anzufassen:
|
|
|
|
```
|
|
ssh dogfather-server "cd /home/dogiweb/workspace-daten/sicherungen && ls -la && for f in *.db; do echo \"--- \$f\"; sqlite3 \$f 'SELECT COUNT(*) FROM personen; SELECT COUNT(*) FROM aufgaben;'; done"
|
|
```
|
|
|
|
Dann weiter mit Fall 2.
|
|
|
|
---
|
|
|
|
## Fall 2: Datenbank zurückspielen
|
|
|
|
**Ein Block, von oben nach unten.** Er stoppt den Dienst, legt den kaputten Stand
|
|
zur Seite (nicht löschen — vielleicht braucht man ihn noch), spielt die Sicherung
|
|
ein, prüft sie und startet erst dann wieder.
|
|
|
|
`DATUM` vorher auf die gewünschte Sicherung ändern.
|
|
|
|
```
|
|
ssh dogfather-server 'DATUM=2026-08-31; S=/home/dogiweb/workspace-daten; sudo systemctl stop dogiweb.service && sleep 2 && mv $S/workspace.db $S/kaputt-$(date +%Y%m%d%H%M).db 2>/dev/null; rm -f $S/workspace.db-wal $S/workspace.db-shm; cp $S/sicherungen/taeglich-$DATUM.db $S/workspace.db && chown dogiweb:dogiweb $S/workspace.db && sqlite3 $S/workspace.db "PRAGMA integrity_check; PRAGMA foreign_key_check; SELECT COUNT(*) || \" Personen\" FROM personen;" && sudo systemctl start dogiweb.service && sleep 3 && systemctl is-active dogiweb.service'
|
|
```
|
|
|
|
Danach **auf der echten Domain nachsehen**, nicht nur auf die Erfolgsmeldung
|
|
vertrauen:
|
|
|
|
```
|
|
curl -s -o /dev/null -w "%{http_code}\n" https://dogfather-universe.com/workspace/ && curl -sI https://dogfather-universe.com/ | grep -i via
|
|
```
|
|
|
|
**Wichtig:** `mv` statt `rm`. Die kaputte Datei bleibt als `kaputt-…db` liegen.
|
|
Wenn sich herausstellt, dass die Sicherung älter war als gedacht, kann man
|
|
daraus noch Einzelnes herausholen. Später von Hand aufräumen.
|
|
|
|
---
|
|
|
|
## Fall 3: Der Server ist ganz weg
|
|
|
|
Dann liegt die letzte Sicherung auf diesem PC. Zuerst holen, was noch geht —
|
|
falls der Server noch antwortet:
|
|
|
|
```
|
|
bash ~/Documents/Obelix/DogiHompage/tools/sicherung-holen.sh
|
|
```
|
|
|
|
Wiederaufbau in dieser Reihenfolge:
|
|
|
|
1. Server neu aufsetzen, Benutzer `dogiweb` anlegen (**macht Filipe**, nicht ich —
|
|
siehe `CLAUDE.md`)
|
|
2. `git clone` von Gitea nach `/home/dogiweb/dogfather-universe`
|
|
3. Ordner `/home/dogiweb/workspace-daten/` anlegen
|
|
4. Neueste Sicherung von diesem PC hochladen:
|
|
```
|
|
scp ~/Documents/Obelix/Sicherungen/workspace/taeglich-*.db dogfather-server:/home/dogiweb/workspace-daten/workspace.db
|
|
```
|
|
5. `dogiweb.service` und Caddy einrichten, Dienst starten
|
|
6. Auf `https://dogfather-universe.com/workspace/` anmelden und prüfen
|
|
|
|
7. Hochgeladene Dateien und Bibliothek zurückspielen — die stecken **nicht** in
|
|
der Datenbanksicherung, sondern liegen als Dateien daneben:
|
|
```
|
|
scp -r ~/Documents/Obelix/Sicherungen/workspace/dateien/. dogfather-server:/home/dogiweb/workspace-daten/dateien/ && scp -r ~/Documents/Obelix/Sicherungen/workspace/wissen/. dogfather-server:/home/dogiweb/workspace-daten/wissen/
|
|
```
|
|
|
|
---
|
|
|
|
## Sicherungen auf diesen PC holen
|
|
|
|
**Das läuft von allein** — täglich um 13:30 über die Windows-Aufgabenplanung
|
|
(„Dogfather Workspace - Sicherung holen"). War der Rechner zu der Zeit aus, holt
|
|
Windows den Lauf beim nächsten Hochfahren nach.
|
|
|
|
Eingerichtet wurde das einmalig mit:
|
|
|
|
```
|
|
powershell -ExecutionPolicy Bypass -File ~/Documents/Obelix/DogiHompage/tools/sicherung-einrichten.ps1
|
|
```
|
|
|
|
Von Hand anstoßen geht trotzdem jederzeit:
|
|
|
|
```
|
|
bash ~/Documents/Obelix/DogiHompage/tools/sicherung-holen.sh
|
|
```
|
|
|
|
Holt **drei** Dinge: die Datenbanksicherungen, die hochgeladenen Dateien und die
|
|
PDFs der Bibliothek. Prüft danach jede Datenbankdatei sofort auf Unversehrtheit und
|
|
darauf, dass wirklich Personen darin stehen — und sagt es, wenn etwas nicht stimmt.
|
|
|
|
**Warum die Dateien nur hier landen und nicht auch auf dem Server:** Eine zweite
|
|
Kopie auf derselben Platte hilft gegen nichts, was die erste nicht schon überlebt
|
|
hätte. Und weil `scp` nie löscht, bleibt ein hier einmal geholtes PDF erhalten,
|
|
auch wenn es auf dem Server verschwindet.
|
|
|
|
---
|
|
|
|
## Von Hand sichern, bevor man etwas Größeres anfasst
|
|
|
|
Im Workspace unter **Automationen → Sicherung & Zustand → „Jetzt sichern"**.
|
|
Dauert Millisekunden. Oder über die Kommandozeile:
|
|
|
|
```
|
|
ssh dogfather-server "sudo systemctl status dogiweb.service --no-pager | head -3"
|
|
```
|
|
|
|
---
|
|
|
|
## Was noch fehlt
|
|
|
|
- **Nur ein Ort.** Server und dieser PC stehen beide bei uns. Gegen Feuer oder
|
|
Diebstahl hilft das nicht. Eine verschlüsselte Kopie an einem dritten Ort wäre
|
|
die Ausbaustufe — kostenlos möglich, aber eine eigene Entscheidung.
|
|
|
|
---
|
|
|
|
## Woran man sieht, dass es noch läuft
|
|
|
|
Im Workspace unter **Automationen → Sicherung & Zustand**. Dort steht in der Zeile
|
|
**„Kopie außer Haus"**, wann dieser Rechner zuletzt geholt hat.
|
|
|
|
Kommt zehn Tage lang nichts, wird der Kasten gelb und nennt den Grund. Das ist der
|
|
eigentliche Zweck der Rückmeldung: Eine Sicherung, die still aufhört zu laufen, ist
|
|
gefährlicher als gar keine — weil man sich auf sie verlässt.
|
|
|
|
Prüfen, ob die Aufgabe eingerichtet ist:
|
|
|
|
```
|
|
powershell -Command "Get-ScheduledTaskInfo -TaskName 'Dogfather Workspace - Sicherung holen' | Select-Object LastRunTime, LastTaskResult, NextRunTime"
|
|
```
|
|
|
|
`LastTaskResult` muss **0** sein. Jeder Lauf steht außerdem in
|
|
`~/Documents/Obelix/Sicherungen/workspace/lauf-protokoll.txt` — auch die
|
|
gescheiterten. Ohne das wäre hinterher nicht zu klären, ob die Aufgabe gar nicht
|
|
lief oder ob sie lief und scheiterte. Das sind zwei sehr verschiedene Fehler.
|