manager/docs/MIGRATION_PSA.md

Ablösung des PSA-Bestellsystems

Überblick

Dieses Dokument beschreibt einen Umbau, der noch nicht durchgeführt wurde.

Das PSA-Bestellsystem (/var/www/html/psa) wurde beim Herauslösen von manage nicht verändert. Es läuft unverändert weiter gegen seine eigenen Verzeichnisse update-server/ und backup-server/. Dieses Dokument hält fest, was ein späterer Wechsel bedeuten würde – damit die Entscheidung bewusst getroffen werden kann und nicht nebenbei passiert.

Warum es kein automatischer Wechsel ist

manage spricht ein anderes Protokoll. Der bisherige Stand:

	bisher (psa)	jetzt (manage)
Manifest	öffentlich abrufbar	Token-Pflicht
Paket-Download	öffentlich abrufbar	Token-Pflicht
Backup-Upload	ohne Anmeldung, nur Namensliste	Token-Pflicht
Instanz-Identität	nur beim Backup, als Klartext-Name	Registereintrag mit Token-Hash

Es gibt bewusst keine Kompatibilitätsschicht für das alte Protokoll. Der bestehende Client kann also nicht einfach auf manage gezeigt werden; er müsste ersetzt werden.

Was zu tun wäre

1. Instanz anlegen

Im Manage-Server eine Instanz anlegen, zum Beispiel psa-prod, und das einmalig angezeigte Token notieren.

2. Client einbauen

client-package/manage-client/ nach psa/manage-client/ kopieren und config.php anlegen. Die Zuordnung der bisherigen Konstanten:

bisher in psa/config.php	neu in psa/manage-client/config.php
UPDATE_MANIFEST_URL	entfällt – ersetzt durch MANAGE_SERVER_URL + Token
UPDATE_WORK_DIR	MANAGE_WORK_DIR
UPDATE_BACKUP_DIR	MANAGE_UPDATE_BACKUP_DIR
BACKUP_DIR	MANAGE_BACKUP_DIR
BACKUP_LOCAL_RETENTION	MANAGE_BACKUP_LOCAL_RETENTION
BACKUP_AUTO_INTERVAL_SECONDS	MANAGE_BACKUP_AUTO_INTERVAL_SECONDS
BACKUP_REMOTE_TARGETS mit type => managed	entfällt – eingebaut, über MANAGE_BACKUP_UPLOAD
BACKUP_REMOTE_TARGETS mit s3/sftp/custom	MANAGE_BACKUP_REMOTE_TARGETS, unverändertes Format
–	MANAGE_VERSION_FILE = includes/version.php, MANAGE_VERSION_CONSTANT = APP_VERSION

Die bisherigen Backup-Quellen entsprechen genau:

define("MANAGE_BACKUP_SOURCES", [
    ["as" => "data", "glob" => "data/*.json"],
    ["as" => "data/uploads", "dir" => "data/uploads"],
]);

Damit sind die erzeugten Archive inhaltlich identisch zu den bisherigen.

3. Oberfläche ersetzen

psa/admin/updater.php würde durch eine Seite ersetzt, die manage-client/ui/panel.php einbindet – mit der bestehenden Anmeldeprüfung von psa davor. Der Statusblock in psa/admin/settings.php (settingsGetUpdaterStatus()) würde durch manage-client/ui/status-partial.php ersetzt.

Der Aufruf backupCreateAutomaticIfDue() in psa/admin/index.php würde zu manageBackupCreateAutomaticIfDue().

4. Altes entfernen

Danach könnten entfallen:

• psa/admin/updater.php
• psa/includes/backup.php
• psa/update-server/
• psa/backup-server/
• psa/scripts/create-update-zip.sh (ersetzt durch die angepasste Vorlage aus manage/scripts/create-release-zip.sh)

Die zugehörigen Abschnitte in psa/docs/BACKUP_CONFIGURATION.md und psa/docs/CONFIG_REFERENCE.md würden auf die Client-Dokumentation verweisen.

5. Bestehende Daten

• Backups: Die bisherigen Archive liegen auf dem alten Backup-Server. Sie lassen sich nicht automatisch übernehmen; entweder werden sie dort belassen, bis ihre Aufbewahrungsfrist abläuft, oder sie werden von Hand nach manage/storage/backups/psa-prod/ kopiert und in index.json eingetragen.
• Releases: Die ZIPs aus psa/update-server/packages/ können über die Oberfläche unter Releases hochgeladen werden; Prüfsummen berechnet der Server neu.

Empfohlene Reihenfolge

1. Manage-Server aufsetzen und mit einer Testinstanz vollständig durchspielen.
2. Instanz psa-test anlegen und den Umbau an einer Kopie von psa erproben.
3. Erst danach die Produktivinstallation umstellen – mit frischem Backup über den alten Weg, bevor der alte Weg abgeschaltet wird.
4. Alte Server-Verzeichnisse einige Wochen laufen lassen, bevor sie entfernt werden.

Weiter

• ARCHITECTURE – woher welcher Code stammt
• ../client-package/docs/02_INTEGRATION.md – Einbindung im Projekt