Document verified v2.0.91 release and production key recovery
This commit is contained in:
@@ -8,6 +8,9 @@ Diese Datei hält den verifizierten technischen Arbeitsstand fest. Sie enthält
|
||||
|
||||
## Zuletzt verifizierter Stand
|
||||
|
||||
- Abgeschlossen am 22. September 2026: `v2.0.91` auf GitHub und Forgejo veröffentlicht, Tag auf beiden Remotes exakt `0aa8c7ac4024f5739ef7e6c2c350ad0a934bd296`. Titel und neuester stabiler Release identisch; GitHub-Changelog Englisch, Forgejo-Changelog Deutsch. Alle zwölf öffentlichen Assets vollständig erneut heruntergeladen und Größen/SHA-256 mit den lokalen Originalen verglichen. Beide `latest.yml` bestätigen Version 2.0.91 und Installer-SHA-512. Setup-SHA-256 `0cabc0206300a3060f7d5028a6e8020772673d31267bfb55e552998bc9245369`, Portable-SHA-256 `1b57b016ec01c62e55d76bca802b5b5b2b2610fb87e478e9d1e66f369eecf00d`. Lokale Originale unter `release/staging-v2.0.91`; Source-ZIP mit 7-Zip geprüft und Git-Kommentar entspricht dem Tag-Commit.
|
||||
- Abschließende Live-Prüfung: ausschließlich Downloader umgestellt, Dienst aktiv und öffentliche Recovery-Konfiguration erreichbar; ursprüngliche zwölf Datensätze bytegenau unverändert. Während der Arbeit kam unabhängig ein weiterer Datensatz ohne Recovery-Kopie hinzu und wurde unverändert belassen (13 insgesamt bei Abschluss). Schlüsselwiederherstellung benötigt einen neuen Export mit Client ab 2.0.91; alte Exporte bleiben nicht nachträglich wiederherstellbar. Windows-Anwendung auf Saschas Rechner nicht installiert oder neu gestartet. Desktop-Anleitung mit konkreten SSH-Befehlen, Zwischenablagehinweisen und verschlüsseltem Off-Server-Backup aktualisiert.
|
||||
|
||||
- 22. September 2026, v2.0.91 zur Veröffentlichung vorbereitet; Sascha hat ausschließlich den Downloader (nicht den parallel in anderem Chat betreuten Uploader) sowie produktive Schlüssel-Einrichtung, kurzen Dienstneustart und anschließendes Release auf beiden Plattformen ausdrücklich freigegeben. Neuer Arbeitsbranch `release/v2.0.91`, Paketversion 2.0.91.
|
||||
- Produktiver Downloader-Backup-Dienst `mdd-backup-api.service` unter Benutzer `mdd-backup` auf `217.182.174.208` umgestellt: `/opt/mdd-backup-api/current` zeigt auf `/opt/mdd-backup-api/releases/20260922-v2.0.91`. Systemd-Drop-in `/etc/systemd/system/mdd-backup-api.service.d/recovery.conf` setzt `RECOVERY_PUBLIC_KEY_FILE=/etc/mdd-backup-recovery/public.pem`. Privater Schlüssel ausschließlich unter `/root/mdd-recovery-keys/private.pem` (0600, Verzeichnis 0700); Dienstzugriff darauf ausdrücklich negativ geprüft. Öffentlicher Schlüsselfingerabdruck `dyUMhSqnlCdfQjyHTCBvA0EklRtSXSjel8MUzafpjCY`.
|
||||
- Vorherige zwölf Sicherungen aus `/var/lib/mdd-backup-api`, Dienst und Konfiguration nach `/root/mdd-recovery-preflight-YbOuCU/rollback.tar.gz` gesichert; SHA-256 `e4bfe2f80f4d05dcb095888d28bd8b1e65723630a4c27ca5da036d26f0237bf3`. Archiv extrahiert und Daten/Config per Hash verifiziert. Staging auf Kopie: alle 16 Server-Tests unter Node 20.20.2 bestanden, zwölf alte Blobs unverändert abrufbar, neuer Export/Admin-Recovery/Import/Löschen erfolgreich. Nach freigegebener Umstellung denselben Ablauf über `https://downloader.24-music.de/backup-api` geprüft; künstliche Testsicherung wieder per API gelöscht, alle zwölf Bestandsdateien unverändert. Altes Dienstziel für Rollback: `/opt/mdd-backup-api/releases/20260807T183300`.
|
||||
|
||||
Reference in New Issue
Block a user