Cron
Cron hält Ephraim im Hintergrund sauber: Aufräumen, Sicherheitsprüfungen, Knowledge-Refresh, Jobpflege, Projektabläufe und technische Inventuren laufen nicht im normalen Seitenaufruf, sondern als geplante Wartungsaufgaben.
1. Warum Cron nötig ist
Cron ist die Wartungsschicht von Ephraim. Viele Aufgaben müssen regelmäßig laufen, dürfen aber normale Seitenaufrufe, Chats und Projektarbeit nicht ausbremsen: abgelaufene Jobs bereinigen, alte Sicherheitsdaten kürzen, archivierte Projekte endgültig löschen, zentrale Wissensquellen aktualisieren und Drittanbieter-Komponenten inventarisieren. Genau diese Arbeit bündelt Ephraim im Cron-Lauf.
Die Adminseite zeigt den letzten Lauf, offene Wartung, Logauszüge, Einzelergebnisse pro Task und die wichtigsten Umgebungsdaten. Berechtigte Admins können zusätzlich einen manuellen Lauf starten. Das ist ein Diagnose- und Wartungswerkzeug; es ersetzt im Produktivbetrieb keinen echten systemweiten Zeitplan.
2. Die Adminseite richtig lesen
Oben steht der zusammengefasste Betriebszustand. Bereit bedeutet: Der letzte Lauf wurde ohne gemeldeten Taskfehler beendet und ist nicht veraltet. Läuft gerade bedeutet: Ein Cron-Lauf hat begonnen und noch kein Endergebnis geschrieben. Fehler bedeutet: Mindestens eine Aufgabe hat ein Fehlerergebnis geliefert. Ein veralteter erfolgreicher Lauf wird zurückhaltend markiert, weil er technisch zuletzt erfolgreich war, aber zu lange zurückliegt.
| Bereich | Was Admins daraus lesen |
|---|---|
| Überblick | Status, letzter Erfolg, Dauer, Ausführungsart und fällige Wartung für Knowledge, Projekte und KI-Jobs. |
| Log | Gekürztes, adminlesbares Protokoll des letzten Laufs mit Start, Tasknamen, Erfolg oder Fehlermeldung. |
| Tasks | Ein Ergebnis pro Wartungsaufgabe: Status, Dauer und fachliche Kennzahlen wie gelöschte Einträge oder freigegebene Bytes. |
| Umgebung | Start-/Endzeit, HTTP-Tokenstatus, erlaubte IPs, DDEV-Erkennung und opportunistisches DDEV-Intervall. |
| Refreshes | Letzte Knowledge-Refresh-Läufe mit Quelle, Status, Startzeit, Trigger und erzeugten Chunks oder Ereignissen. |
3. Konkrete Aufgaben
Ephraim führt die Aufgaben nacheinander aus. Jede Aufgabe liefert ein eigenes
ok-Flag, eine Dauer und zusätzliche Kennzahlen. Wenn eine Aufgabe fehlschlägt,
laufen die übrigen Aufgaben weiter; am Ende wird der Gesamtlauf als Fehler markiert.
| Aufgabe | Was konkret passiert | Warum das wichtig ist |
|---|---|---|
| Rate-Limits bereinigen | Einträge in auth_rate_limits, deren Zeitfenster älter als 24 Stunden ist, werden gelöscht. |
Login- und Schutzmechanismen bleiben wirksam, ohne alte Zähler dauerhaft mitzuschleppen. |
| KI-Jobs pflegen | Abgelaufene Snapshots und Chunks werden gelöscht; offene abgelaufene Jobs werden auf Fehler gesetzt; alte terminale Jobs und hängen gebliebene Artefakte werden bereinigt. | Streaming, Wiederaufnahme und Artefakterzeugung hinterlassen keine dauerhaften technischen Altlasten. |
| Archivierte Projekte löschen | Projekte, die archiviert sind und deren Löschdatum erreicht ist, werden endgültig entfernt. | Die Retention-Regel für Projekte wird technisch durchgesetzt. |
| Verwaiste Dateien entfernen | Dateien im Nutzer- und Projektspeicher werden gegen die Datenbankreferenzen geprüft; nicht mehr referenzierte Binärdateien werden gelöscht. | Der Dateispeicher wächst nicht durch gelöschte oder verschobene Metadaten weiter. |
| Nutzerexporte aufräumen | Temporäre Exportdateien im System-Temp-Verzeichnis werden nach Ablauf entfernt. | Datenexporte bleiben kurzlebige Arbeitsdateien und werden nicht dauerhaft im Temp-Bereich vergessen. |
| Nutzersitzungen bereinigen | Abgelaufene Einträge aus der Sitzungsübersicht werden gelöscht. | Die Anzeige aktiver Sitzungen bleibt aussagekräftig und sammelt keine unnötigen Altzustände. |
| Sicherheitsereignisse kürzen | Alte Datei-Sicherheitsereignisse werden nach der vorgesehenen Aufbewahrungsfrist entfernt. | Uploadschutz bleibt nachvollziehbar, ohne dauerhaft alle alten Ereignisse aufzubewahren. |
| Antivirus prüfen | Wenn ClamAV aktiviert ist, prüft Ephraim die Verfügbarkeit des Scanners. | Admins erkennen, ob der Uploadschutz technisch erreichbar ist. |
| Drittanbieter inventarisieren | Lokale Komponenten werden erkannt; erlaubte externe Hinweise werden verarbeitet; Mismatch-Badges und Super-Admin-Hinweise werden aktualisiert. | Komponentenpflege bleibt kontrolliert, ohne Seitenaufrufe mit externen Prüfungen zu blockieren. |
| Basiswissen aktualisieren | Fällige globale Remote-Quellen und serverseitige Wetterquellen werden verarbeitet und für Retrieval vorbereitet; Embedding-Vektoren werden lokal berechnet. | Freigegebenes schulisches Wissen bleibt nutzbar, ohne dass die Spark selbst im Internet sucht oder Embedding-Inhalte dauerhaft speichert. |
| Knowledge-Blobs aufräumen | Verschlüsselte Basiswissen-Dateien im Knowledge-Speicher werden gegen die Datenbank abgeglichen. | Verwaiste Dateien aus zentralen Wissensquellen werden entfernt. |
| Refresh-Diagnosen kürzen | Alte Einträge aus den Knowledge-Refresh-Protokollen werden entfernt. | Die Diagnose bleibt übersichtlich und speichert nicht unbegrenzt alte Refreshdetails. |
4. Ausführungsarten
Im Produktivbetrieb braucht Ephraim einen echten Zeitgeber: Crontab, systemd-Timer,
Container-Cron oder einen gleichwertigen Betriebsmechanismus. Der bevorzugte Weg ist
ein CLI-Aufruf von web/cron.php, weil dafür kein HTTP-Token notwendig ist
und der Lauf nicht vom öffentlichen Webzugriff abhängt.
Der HTTP-Aufruf ist zusätzlich möglich, aber nur mit konfiguriertem
CRON_SECRET_TOKEN und erlaubter Client-IP. Das Token kann als Header
X-Cron-Token oder als Query-Parameter übergeben werden. Fehlt das Token,
antwortet der Endpunkt nicht mit einem Default, sondern mit einem Konfigurationsfehler.
Eine falsche IP wird abgewiesen.
| Ausführungsart | Anzeige in Ephraim | Einordnung |
|---|---|---|
| CLI | cli |
Empfohlener Produktionsweg über Server- oder Container-Zeitplan. |
| HTTP | http |
Nur mit Token und IP-Whitelist verwenden; geeignet für bewusst abgesicherte externe Auslöser. |
| Adminseite | admin |
Manueller Lauf aus dem Adminbereich mit Login und CSRF-Schutz. |
| Admin-Terminal | admin-terminal |
Manueller Lauf über das Supervisor-Webterminal und die Admin-Terminal-API. |
| DDEV-Entwicklung | ddev-opportunistic |
Lokale Entwicklungshilfe: normale HTML-GET-Aufrufe können nach der Antwort einen fälligen Lauf anstoßen. |
5. Was Ephraim speichert
Cron schreibt keine lange Rohhistorie in die Manualoberfläche. Die Adminseite liest Systemsettings mit dem aktuellen Monitorzustand. Dadurch sieht man schnell, ob Cron läuft, wann der letzte Erfolg war und welche Tasks im letzten Lauf auffällig waren.
| Feld | Bedeutung |
|---|---|
cron_last_status |
running, ok oder error. |
| Start, Ende, Erfolg, Fehler | Zeitpunkte für letzten Start, letztes Ende, letzten erfolgreichen und letzten fehlerhaften Lauf. |
| Dauer und Ausführungsart | Laufzeit in Millisekunden und Quelle des Laufs, etwa cli, http oder admin. |
cron_last_summary |
JSON-Ergebnis aller Tasks mit Status, Dauer und Kennzahlen. |
cron_last_log |
Gekürztes Log des letzten Laufs, begrenzt für die Adminanzeige. |
Ein erfolgreicher Lauf gilt im Panel als veraltet, wenn der letzte Erfolg älter als
CRON_MONITOR_MAX_AGE_MINUTES ist. Der Standardwert beträgt 15 Minuten.
Das ist kein Datenverlust, sondern ein Überwachungssignal: Cron hat zu lange keinen
frischen Erfolg geschrieben.
6. Manuelle Läufe
Manuelle Cronläufe sind nützlich nach Konfigurationsänderungen, beim Testen neuer Quellen
oder nach Störungen. Sie ersetzen keinen sauber eingerichteten Zeitplan. Beim manuellen
Start über die Adminseite gelten Login, Adminrolle und CSRF-Schutz. Im Supervisor-Terminal
stehen dafür die Cron-Befehle bereit; technisch ruft das Terminal dieselbe
CronRunner-Logik auf.
Ein manueller Lauf startet alle Wartungsaufgaben, nicht nur eine einzelne Zeile aus der Tabelle. Deshalb sollte man ihn nicht „zum Spaß“ mehrfach hintereinander auslösen. Wenn nur eine Drittanbieter-Prüfung gewünscht ist, wird diese Prüfung in der Komponentenverwaltung angefordert; Cron verarbeitet sie dann im nächsten Lauf.
7. Fehlerverhalten
Cron ist fehlertolerant aufgebaut: Eine fehlgeschlagene Task stoppt nicht den gesamten Lauf. Ephraim protokolliert die fehlgeschlagene Aufgabe, meldet den Fehler im Gesamtergebnis und führt die übrigen Tasks weiter aus. Dadurch bleibt zum Beispiel eine Speicherbereinigung möglich, auch wenn eine Knowledge-Quelle gerade nicht erreichbar ist.
| Beobachtung | Konkrete Bedeutung | Nächster Schritt |
|---|---|---|
Status running bleibt stehen |
Der letzte Lauf hat begonnen, aber kein Ende geschrieben oder läuft noch. | Log, Serverprozess und Zeitpunkt prüfen; danach erneut kontrollieren, ob ein neuer Lauf den Status überschrieben hat. |
Gesamtstatus error |
Mindestens eine Task hat ok=false geliefert. |
Tasktabelle und Log lesen; zuerst die konkrete Task, nicht den ganzen Cron verdächtigen. |
| Letzter Erfolg ist veraltet | Cron lief zu lange nicht erfolgreich. | Zeitplan, Container, CLI-Pfad oder HTTP-Token/IP prüfen. |
| HTTP-Aufruf liefert 401, 403 oder 503 | Token fehlt/falsch, IP nicht erlaubt oder Token nicht konfiguriert. | CRON_SECRET_TOKEN und CRON_ALLOWED_IPS in der Betriebsumgebung prüfen. |
| Knowledge-Refresh schlägt fehl | Eine freigegebene Quelle konnte nicht aktualisiert oder verarbeitet werden. | Refresh-Tabelle lesen und danach den Artikel Admin: Basiswissen prüfen. |
8. Datenschutz und Schlüsselgrenzen
Cron läuft ohne aktive Nutzersitzung. Deshalb besitzt Cron keinen User-DEK und öffnet keine persönlichen Vaults. Persönliche Dateien, private RAG-Inhalte, private Kalender, Erinnerungen und persönliche Chat-Zusammenfassungen werden nicht im Hintergrund massenhaft entschlüsselt oder neu erzeugt.
Zentrales Basiswissen ist anders eingeordnet: Es ist freigegebener schulweiter Kontext und wird serverseitig verschlüsselt verwaltet. Diese Quellen darf Cron kontrolliert aktualisieren. Auch Wetterabrufe laufen serverseitig, damit keine Nutzer-IP direkt an den Wetterdienst geht. Die Spark erhält daraus später nur ausgewählten Kontext für eine konkrete Anfrage; sie erhält durch Cron keinen freien Internetzugang.
Die Schlüsselgrenzen sind im Artikel Kryptoarchitektur ausführlich erklärt. Für Datenschutzfragen zu Basiswissen und Wikipedia siehe Basiswissen und Wikipedia.
9. Sicherheit des Cron-Zugangs
Der öffentliche Cron-Endpunkt ist kein normaler Adminbereich. Er ist bewusst schlicht, damit ein Serverzeitplan ihn aufrufen kann. Deshalb hat er eigene Schutzregeln: kein Defaulttoken, timing-sicherer Tokenvergleich und IP-Whitelist. Der sicherste Weg bleibt der lokale CLI-Aufruf, weil dabei kein HTTP-Token über das Netz verwendet wird.
Die Adminseite und das Admin-Terminal verwenden dagegen die normale Anmeldung, Rollenprüfung und CSRF-Schutz. Normale Nutzer sehen diese Funktionen nicht. Fehlerdetails werden in der Adminanzeige zusammengefasst, damit interne Exceptiondetails nicht an ungeeignete Stellen gelangen.
10. Praktische Diagnose
- Im Adminbereich zuerst Status, letzten Erfolg und Ausführungsart prüfen.
- Wenn der letzte Erfolg veraltet ist, den echten Zeitgeber prüfen: crontab, systemd-Timer, Container-Cron oder HTTP-Aufrufer.
- Bei Fehlerstatus die Tasktabelle lesen und nur die fehlgeschlagene Aufgabe untersuchen.
- Bei Knowledge-Problemen Refresh-Tabelle und Admin-Basiswissen prüfen.
- Bei Komponentenproblemen den Komponentenartikel lesen und kontrollieren, ob eine manuelle Prüfung nur angefordert, aber noch nicht verarbeitet wurde.
- Bei Uploadschutzproblemen ClamAV-Konfiguration und Datei-Sicherheitsseite prüfen.
- Nach einer Korrektur einen manuellen Lauf starten und kontrollieren, ob Status, Log und Taskergebnis plausibel sind.
Cron ist kein Reparaturknopf für jede Störung. Er zeigt aber oft den besten Einstieg: Welche Wartung läuft, welche zuletzt fehlgeschlagen ist und ob Ephraim gerade technische Altlasten aufräumen kann.