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

Manage-Server aufsetzen und mit einer Testinstanz vollständig durchspielen.
Instanz psa-test anlegen und den Umbau an einer Kopie von psa erproben.
Erst danach die Produktivinstallation umstellen – mit frischem Backup über den alten Weg, bevor der alte Weg abgeschaltet wird.
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

MIGRATION_PSA.md 4.3 KB Verlauf Originalformat