133 lines
6.5 KiB
Markdown
133 lines
6.5 KiB
Markdown
# Automatisches Update-Paket
|
|
|
|
Auf dem Arbeitsplatz die gelieferte `.run`-Datei und ihre `.sha256`-Datei per SCP
|
|
auf den Server übertragen. Auf dem Server im selben Verzeichnis prüfen/starten:
|
|
|
|
```bash
|
|
sha256sum -c app-backup-update-VERSION.run.sha256
|
|
sudo bash app-backup-update-VERSION.run
|
|
```
|
|
|
|
VERSION durch den tatsächlichen Dateinamen ersetzen. Ein Git-Checkout auf dem
|
|
Server ist nicht erforderlich. Der Installer benötigt die vorhandene Konfiguration
|
|
`/etc/app-backup/app-backup.conf` und die bisherigen aktiven Zugangsdaten.
|
|
|
|
Der Start ist die Freigabe für das Update einschließlich eines vollständigen
|
|
Backups mit zeitweiliger Unterbrechung der konfigurierten Anwendungen.
|
|
|
|
## Was automatisch passiert
|
|
|
|
1. Paketinhalt per SHA-256 prüfen und geschützt unter `/var/tmp` entpacken.
|
|
2. Bestehende Einstellungen nach `/var/backups/app-backup-upgrade-XXXXXXXX` sichern.
|
|
3. Aktuelle Pfade und Einstellungen übernehmen; sichere Betriebsoptionen ergänzen.
|
|
4. Vorhandene Webdienste und direkt erkennbare Nextcloud-systemd-Writer zuordnen.
|
|
5. Crypt-Konfiguration und DB-Dateien prüfen; vorhandene Schlüssel/Passwörter erhalten.
|
|
6. Vorprüfung mit geschützten Kopien durchführen. Bei Fehlern bleibt das installierte
|
|
Paket samt Anwendungskonfiguration und Timer unverändert.
|
|
7. Einen von SSH unabhängigen systemd-Auftrag `app-backup-upgrade.service` starten.
|
|
8. Backup-Timer stoppen, Paket mit Rollback-Inventar installieren, Konfiguration
|
|
atomar übernehmen und Rechte der aktiven root-eigenen Zugangsdaten korrigieren.
|
|
9. Vollständiges Backup ohne lokale/Remote-Retention durchführen. Anschließend den
|
|
abgeschlossenen Satz nochmals über Crypt herunterladen und mit dem Restore prüfen.
|
|
10. Erst bei Erfolg den Backup-Timer aktivieren und das Ergebnis protokollieren.
|
|
|
|
Es findet kein Import in produktive Anwendungen oder Datenbanken statt. Der
|
|
Remote-Prüflauf belegt Archivlesbarkeit, ersetzt aber keinen fachlichen Test-Restore.
|
|
|
|
## Verlauf und Ergebnis
|
|
|
|
```bash
|
|
sudo journalctl -fu app-backup-upgrade.service
|
|
```
|
|
|
|
Der Starter nennt außerdem den **konkreten** Ergebnisordner:
|
|
|
|
```bash
|
|
sudo cat /var/backups/app-backup-upgrade-XXXXXXXX/result.txt
|
|
sudo less /var/backups/app-backup-upgrade-XXXXXXXX/update.log
|
|
```
|
|
|
|
Erwartet wird `SUCCESS`. Solange `RUNNING` steht, nicht parallel erneut starten.
|
|
Nach Ende verschwindet die kurzlebige systemd-Unit; Log und Ergebnis bleiben erhalten.
|
|
Bei `QUEUED` wurde der Auftrag übergeben und wartet auf den Start.
|
|
`--foreground` führt den Vorgang stattdessen im aktuellen Terminal aus und ist
|
|
für Tests/Diagnose gedacht; dabei besteht keine Absicherung gegen SSH-Abbruch.
|
|
|
|
## Gezielte Rückfragen und Grenzen
|
|
|
|
- **Rclone-Datei nicht eindeutig:** Pfad im Dialog oder mit `--rclone-config FILE`
|
|
angeben. Eine user-eigene Datei wird in eine neue root-eigene Datei kopiert;
|
|
die vom Benutzer verwendete Originaldatei bleibt unverändert.
|
|
- **Gitea bisher nicht konfiguriert:** Aufnahme bestätigen oder bewusst
|
|
`--no-gitea` setzen. Absolute explizite Pfade und der MySQL-DB-Name können aus
|
|
`app.ini` übernommen werden. Mehrdeutige/relative Pfade müssen zuerst in der
|
|
vorhandenen Backup-Konfiguration ergänzt werden; es werden keine geratenen
|
|
Repository-Pfade eingetragen.
|
|
- **Nextcloud in crontab:** Der Installer fragt, ob der gefundene Cron-Dienst
|
|
während jeder Sicherung angehalten werden darf. Das betrifft auch andere
|
|
Cronjobs; währenddessen fällige Jobs können ausfallen. Alternativ Nextcloud
|
|
zuvor in einen eigenen systemd-Service/Timer übertragen. Bereits gestartete
|
|
direkte `cron.php`-/`occ`-Prozesse werden nach dem Writer-Stopp abgewartet
|
|
(Default 300 Sekunden), nicht blind beendet. Shell-Wrapper, externe Scheduler
|
|
und nicht direkt erkennbare Writer müssen explizit berücksichtigt werden.
|
|
- **Fehlende Basispakete:** Installation über `dnf` nach Rückfrage oder mit
|
|
`--install-deps`. Keine automatische Aktualisierung von PHP, DB-Server oder
|
|
rclone auf eine möglicherweise inkompatible Version.
|
|
- **Verschlüsselte rclone-Konfigurationsdatei:** Die für rclone benötigte
|
|
Entsperrung muss auch im systemd-Kontext verfügbar sein. Ohne verfügbare
|
|
Entsperrung bricht die Prüfung ab, statt unsichtbar auf eine Passworteingabe zu warten. Der Installer legt
|
|
keine neuen Crypt-Passwörter an und exportiert keine fremden Secret-Stores.
|
|
- **Früher eingecheckte DB-Passwörter:** Passwortrotation bleibt separat, weil
|
|
weitere Benutzer derselben Accounts nicht zuverlässig ermittelt werden können.
|
|
|
|
Optionen können kombiniert werden:
|
|
|
|
```bash
|
|
sudo bash app-backup-update-VERSION.run \
|
|
--rclone-config /root/.config/rclone/rclone.conf \
|
|
--enable-gitea --cron-services nextcloudcron.timer,nextcloudcron.service
|
|
```
|
|
|
|
Die Remote-Retention bleibt nach der Migration ausgeschaltet. Nach einem echten
|
|
Test-Restore bei Bedarf bewusst wieder aktivieren. Bestehende Timer-Zeitpläne
|
|
bleiben erhalten; beim Aktivieren kann `Persistent=true` einen Lauf nachholen.
|
|
|
|
## Fehler und Rückweg
|
|
|
|
Bei einem Fehler nach Beginn der Installation bleibt der Backup-Timer gestoppt.
|
|
Es erfolgt kein automatisches Zurücksetzen über möglicherweise noch laufende oder
|
|
teilweise wiederhergestellte Anwendungen. Logs und gegebenenfalls
|
|
`recovery-*.json` im Workdir prüfen. Das kombinierte Rollback stellt die vorherigen
|
|
Paketdateien **und** die vorherige Backup-Hauptkonfiguration wieder her:
|
|
|
|
```bash
|
|
sudo bash /var/backups/app-backup-upgrade-XXXXXXXX/rollback-update.sh
|
|
```
|
|
|
|
Es verändert keine gesicherten Anwendungsdaten, rotiert keine Zugangsdaten und
|
|
startet den Timer nicht ungeprüft. Neu erzeugte root-eigene Kopien von rclone-Dateien
|
|
sowie strengere Dateirechte bleiben erhalten. Bei unterbrochener Vorbereitung
|
|
ohne Installationsbeginn ist kein Paket-Rollback erforderlich.
|
|
|
|
## Paket reproduzieren
|
|
|
|
Aus einem sauberen, eingecheckten Repository:
|
|
|
|
```bash
|
|
python3 tools/build-update-package.py
|
|
```
|
|
|
|
Ausgabe: `dist/app-backup-update-COMMIT.run` und zugehörige SHA-256-Datei.
|
|
Das Paket enthält nur explizit freigegebene Programm-/Dokumentationsdateien und
|
|
Credential-Vorlagen; keine Git-Historie, echten CNF-Dateien oder Backupdaten.
|
|
Die Prüfsumme schützt vor Übertragungsfehlern, ist keine digitale Signatur.
|
|
Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal beziehen.
|
|
|
|
## Verifikation der Lieferung
|
|
|
|
30 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
|
|
Die Tests enthalten echte MariaDB-Dumps/Imports und lokale rclone-Crypt-Roundtrips;
|
|
systemd/occ und die systemd-run-Übergabe sind simuliert. Die tatsächliche
|
|
Server-/OneDrive-Prüfung erfolgt beim ersten Paketlauf. Ein fachlicher Restore
|
|
auf einem separaten Testsystem bleibt erforderlich.
|