KantSites/zentrale

KantSites Zentrale (sites.kant-it.de)

Die Übersicht aller KantSites-Installationen: welche Domain, welche Fassung, wann zuletzt gemeldet, und ein Knopf für Updates – einzeln oder für alle. Entscheidung und Protokoll: ADR 123 in docs/ARCHITECTURE.md.

Reines PHP (ab 8.1) mit SQLite, ohne Composer und ohne Framework. Nötig sind die Erweiterungen pdo_sqlite und curl (oder allow_url_fopen) – beides ist auf üblichem Webhosting da.

Hochladen

1. Den Ordner zentrale/ komplett per FTP hochladen, zum Beispiel nach /sites.kant-it.de/.
2. Die Subdomain sites.kant-it.de auf den Unterordner public/ zeigen lassen. Geht das beim Hoster nicht, auf den Ordner selbst – die .htaccess dort leitet nach public/ und sperrt app/, var/ und config.php.
3. HTTPS (Let's Encrypt) für die Subdomain einschalten. Die Installationen melden nur über HTTPS.
4. config.example.php als config.php kopieren und einen zufälligen einrichtungscode (mindestens 16 Zeichen) eintragen.
5. var/ muss für PHP beschreibbar sein (dort liegen zentrale.db und der Fassungs-Cache).
6. https://sites.kant-it.de aufrufen, mit dem Einrichtungscode das erste Konto anlegen und anmelden. Danach wird der Code nicht mehr gebraucht.

Prüfen: https://sites.kant-it.de/api/melden im Browser antwortet mit {"ok":false,"fehler":"Nur POST."} – dann ist die Schnittstelle erreichbar.

Wie die Installationen sich melden

Ab KantSites 1.36.0 meldet sich jede Installation alle 15 Minuten über die Aufgabe „Bei der Zentrale melden“ (Verwaltung → Aufgaben). Sie läuft wie alle Aufgaben beim Besuch, in der Verwaltung oder über den URL-Cronjob. Ältere Installationen erscheinen erst nach dem Update auf 1.36.0 – das letzte Mal von Hand über „System“.

Nicht gemeldet wird von Installationen, deren SITE_ORIGIN auf localhost, 127.0.0.1, *.test oder *.localhost zeigt. Abschalten pro Installation: ZENTRALE_URL=aus in .env.

Übertragen werden: Adresse, Fassung, PHP-Version, Datenbankart (sqlite/mysql), Git oder Archiv, Wartungszustand, Stand des letzten Updates. Keine Inhalte, keine Besucher, keine Zugangsdaten. Die Zentrale speichert zusätzlich die IP-Adresse der letzten Meldung.

Übersicht

Die Zählerkacheln oben sind zugleich Filter (aktuell, veraltet, verstummt, ohne Kunde). Die Suche findet Domain, frühere Domain, Kunde/Notiz, Fassung und IP-Adresse; Suche und Filter lassen sich kombinieren. Die Suche filtert schon beim Tippen; Kacheln und Seitenzahlen wechseln nur die Liste (public/app.js, ohne JavaScript funktioniert alles als normales Formular). 25 Installationen je Seite, Domains natürlich sortiert und ohne „www.“.

Update aus der Ferne

1. In der Übersicht „Auf x.y.z“ (oder „Alle aktualisieren“ mit Bestätigung) drücken.
2. Die Installation holt den Auftrag mit ihrer nächsten Meldung ab, legt eine Sicherung an, lädt das Release mit Prüfsumme, tauscht die Dateien und ruft sich selbst einmal auf. Diese Anfrage führt mit dem neuen Code die Migrationen aus, prüft die Startseite und gibt die Website frei – oder schaltet auf die alte Fassung zurück.
3. Das Ergebnis erscheint mit der nächsten Meldung in der Zentrale.

Einschränkungen:

• Git-Arbeitskopien werden nicht aus der Ferne aktualisiert.
• Erreicht sich eine Website nicht selbst (manche Hoster sperren das), schließt der nächste Besucher oder Cron-Aufruf das Update ab. So lange zeigt sie die Wartungsseite.
• Ein abgeholter Auftrag ohne Ergebnis nach 2 Stunden erscheint als „keine Rückmeldung“.

KantTresor

Der Reiter KantTresor (/kanttresor) zeigt die KantTresor-Instanzen. Ab KantTresor 1.82.0 meldet sich jede Instanz alle 15 Minuten über den beat-Task controlplane.zentrale_melden an POST /api/kanttresor/melden – gleiches Verfahren wie KantSites (Schlüssel bei der ersten Meldung, danach HMAC-Unterschrift in beide Richtungen).

Übertragen werden: Adresse, Fassung, Python/Django, Datenbank, Anzahl aktiver Mandanten, Namen gestörter Dienste und belegter Speicher in Prozent. Keine Mandantennamen, Dokumente oder Zugangsdaten.

Unterschiede zu KantSites:

• Kein Update von hier. Die Zentrale gibt KantTresor nie einen Auftrag; aktualisiert wird auf dem Server mit ./update.sh.
• „Aktuell“ und „veraltet“ richten sich nach der höchsten gemeldeten Fassung – die KantArchiv-Releaseseite ist nicht öffentlich.
• Statt der PHP-Kachel gibt es „Dienst gestört oder Speicher knapp“ (ab 90 % belegt).
• Abschalten pro Instanz: ZENTRALE_URL=aus in .env.prod. Instanzen mit DJANGO_DEBUG=True oder nur lokaler Adresse melden nie.

Fremde Installationen erkennen

Jede Installation, der in der Detailansicht kein Kunde zugeordnet ist, steht als Unbekannt in der Liste. Meldet sich eine bekannte Kennung unter einer anderen Domain, zeigt die Liste „vorher …“. Wer KantSites verändert und die Meldung ausbaut, taucht nicht auf – einen vollständigen Schutz gibt es ohne Lizenzschlüssel nicht.

Lokal ausprobieren

php -S 127.0.0.1:8115 -t zentrale/public zentrale/public/index.php

Protokollprüfung zwischen CMS und Zentrale (ohne Netz):

php scripts/zentrale-check.php

Sicherung

Alles Wichtige steht in var/zentrale.db. Geht sie verloren, melden sich die Installationen bei ihrer nächsten Meldung neu an; Kundenzuordnungen und Auftragsverlauf sind dann weg.