Umzug auf einen eigenen Server
Eine Schule kann vom geteilten Server auf einen eigenen Server (Schul-Instanz) umziehen — mit allem: Konten, Spaces, Chat-Verläufen, Dateien, Einstellungen. Die Adresse bleibt dieselbe (z. B. rssw.prilog.team).
Die kurze Antwort
Für die Schule ist der Umzug eine kurze Wartung. Danach ist alles wie vorher, unter derselben Adresse. Einmal neu anmelden, die Seite einmal neu laden (Strg+F5) bzw. die installierte App einmal schliessen und neu öffnen — fertig.
Für die Schule
Was ihr merkt
- Wartung: Für die Dauer des Umzugs nimmt Prilog keine Änderungen an. Lesen geht, der Chat pausiert, oben steht ein Hinweis.
- Danach: dieselbe Adresse, dieselben Inhalte — nur auf eurem eigenen Server.
- Einmal neu anmelden. Passwort und Sicherheitsschlüssel (Passkeys) gelten weiter; die Einstellungen eurer Schule (z. B. Passkey-Modus, Mail-Versand) kommen genau so mit, wie sie waren.
- Benachrichtigungen (Push) einmal neu erlauben, wenn der Browser fragt.
„Diese Schule ist auf einen eigenen Server umgezogen“
Diese Meldung sieht, wer noch die alte Fassung der Seite im Browser hat (zwischengespeichert, oder die Adresse zeigte im eigenen Netz noch kurz auf den alten Server). Dann:
- Strg+F5 (Mac: Cmd+Shift+R), oder ein privates Fenster;
- bei installierter App: App schliessen und neu öffnen;
- hilft beides nicht: in den Browser-Einstellungen die Websitedaten dieser Adresse löschen.
An der alten Stelle kann sich niemand mehr anmelden — so landet niemand versehentlich in einer veralteten Kopie.
Für Betreiber
Admin → Umzugspaket, Schule wählen. Vier Schritte, jeder mit Bestätigung durch Eintippen des Kürzels; keine Dialogfenster.
| Schritt | Was passiert |
|---|---|
| 1. Wartung einschalten | Die Schule nimmt keine Änderungen mehr an. Ab jetzt geht nichts verloren. |
| 2. Umzugspaket erstellen (Ziel-Instanz wählen) | Zeilen der Zentrale, Chat, Ablage — verschlüsselt für Betreiber und die Ziel-Instanz. |
| 3. Einspielen (Kürzel der Instanz) | Die Instanz sichert sich selbst, spielt ein und prüft nach: Tabellen, Zeilen, Verknüpfungen, Chat-Medien, Ablage. Nur bei Grün weiter. |
| 4. Umschalten … (Kürzel der Schule) | DNS (Bunny) auf die Instanz, Zertifikat, Web-Client mit der Adresse, Einstellungen der Quelle zurück. Fortschritt in der Seite. |
Die Zentrale lehnt das Umschalten ab, wenn: keine Wartung · Paket älter als die Wartung · Nachprüfung nicht grün · zwei DNS-Einträge für den Namen. So kann nichts verloren gehen, was zwischen Paket und Umschalten geschrieben wurde.
Beim Umschalten:
- Die alte Schule in der Zentrale bleibt im Wartungsmodus und wird mail-gesperrt (ihre Zeitpläne laufen weiter und schrieben sonst doppelt). Mails der Instanz gehen trotzdem raus — die Instanz prüft ihre eigene Sperre.
- Der DNS-Eintrag wird neu angelegt, dann der alte gelöscht — nie ein Moment ohne Eintrag. Kein Abbau einer Schule löscht später einen Eintrag, der auf eine Schul-Instanz zeigt.
- Mail-Adressen der Spaces und Ablage gehören danach der Instanz (Post-Weiche).
- Anmeldungen an der alten Kopie beantwortet die Zentrale mit der Umzugs-Meldung.
Rückfall … (Kürzel der Schule): DNS zurück, Instanz wieder mail-gesperrt, Mail-Sperre der alten Schule wie vorher. Was seit dem Umschalten auf der Instanz geschrieben wurde, fehlt dann auf dem geteilten Server. Die alte Box bleibt bis zum Abbau als Rückweg stehen.
Hängt die Instanz (z. B. gerade mit einem Update beschäftigt): Erneut versuchen … stösst nur die Instanz neu an; DNS und Rückfall-Adressen bleiben.
Beispiel: rssw (06.10.2026)
Wartung 04:25 → Paket (762 912 Zeilen, 344 Tabellen, 293 Chat-Räume, 1 331 Dateien) → Einspielen grün → Umschalten: rssw.prilog.team und rssw.prilog.chat zeigen auf die Instanz rssw2, Zertifikat für alle drei Namen, Passkey-Modus „gemischt“ und die Mail-Sperre der Schule übernommen.
Konzept und Protokoll: Repo hosting-konsolidierung, phasen/phase-6-umzugspaket.md.