KantTresor instances (from 1.82.0) report to /api/kanttresor/melden with the same key-then-HMAC protocol. The new tab lists them with tenants, disk usage and failing services; it never offers or accepts an update order, since KantTresor is updated with ./update.sh on the server. See ADR 124. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
108 lines
5.3 KiB
Markdown
108 lines
5.3 KiB
Markdown
# 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
|
||
|
||
```bash
|
||
php -S 127.0.0.1:8115 -t zentrale/public zentrale/public/index.php
|
||
```
|
||
|
||
Protokollprüfung zwischen CMS und Zentrale (ohne Netz):
|
||
|
||
```bash
|
||
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.
|