Maßnahmen Monitor

Schuljahreswechsel

Es muss noch geklärt werden, was bei Schuljahreswechsel passiert werden soll?

• Sollen die bestehenden Maßnahmen ins neue Schuljahr übernommen werden?
• Nein -> Alle Daten entfernen -> /data/massnahmen.sqlite3 umbenennen + Server neu starten
• Filter nach Schuljahr einbauen
  • mit Auswahl Zugriff auf alte schuljahre beschränken
  • nur aktuelles Schuljahr anzeigen
• nur Abgangsklassen löschen?

Vorschlag: Skript erstellen und Einträge bestimmter Klassen löschen/ausblenden? -> Abgangsklassen Maßnahmen von z.B.: 2BFE1 werden in 2BFE2 übernommen. Vorraussetzung: Daten sind an Loginname vom Schüler gebunden.

Konfiguration

• Die Konfiguration liegt ausschließlich auf dem Server.
• config/config.py und config/departments.py aus den jeweiligen .sample-Dateien erstellen und mit den Serverwerten pflegen.
• config/popups.json aus config/popups.json.sample erstellen. Die Anwendung liest ausschließlich diese Datei. Dort werden die Info-Texte der Detailkategorien, der Löschdialog und die DokuWiki-URL für den Hinweis neben der Überschrift gepflegt.
• In config/config.py müssen insbesondere OIDC- und Linuxmuster.net-Zugangsdaten sowie APP["secret_key"] gesetzt sein. Die OIDC-Redirect-URI muss exakt als gültige URI im Keycloak-Client hinterlegt werden.
• APP["student_homepage"] ist die URL, auf die Schüler nach dem Login weitergeleitet werden. Lehrkräfte öffnen die App.
• APP["debug"] aktiviert (True) oder deaktiviert (False) die Diagnose-Seite /debug. Standardmäßig ist sie deaktiviert.
• config/stufen.json enthält die Maßnahmen und Stufen für Fehlzeiten und Fehlverhalten.

Voraussetzungen und Installation

• Python mit venv sowie Zugriff auf die konfigurierte OIDC- und Linuxmuster.net-Instanz.
• Im Projektverzeichnis die virtuelle Umgebung erstellen und Abhängigkeiten installieren:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

• Vor dem ersten Start die beiden Konfigurationsdateien aus den Vorlagen anlegen.

Aktualisieren und starten

• Verzeichnis wechseln

cd /var/www/mm

• falls aktualisierungen vorhanden, git Repository holen

git pull

• Virtuelle Umgebung aktivieren, um den Server manuell zu starten:

source .venv/bin/activate

• Server im Hintergrund starten:

nohup uvicorn main:app --host 127.0.0.1 --port 8000 > uvicorn.log 2>&1 &

Service stoppen:

pkill -f uvicorn

Automatischer Start mit systemd

Für den automatischen Start beim Booten einen Dienst unter /etc/systemd/system/massnahmenmonitor.service anlegen. www-data bei Bedarf durch den Linux-Benutzer ersetzen, dem die Anwendung gehört:

[Unit]
Description=Maßnahmen Monitor
After=network.target

[Service]
User=www-data
WorkingDirectory=/var/www/mm
ExecStart=/var/www/mm/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000
Restart=on-failure

[Install]
WantedBy=multi-user.target

Den Dienst laden, beim Systemstart aktivieren und sofort starten:

sudo systemctl daemon-reload
sudo systemctl enable --now massnahmenmonitor
sudo systemctl status massnahmenmonitor

Logs anzeigen:

sudo journalctl -u massnahmenmonitor -f

• Der Server lauscht hier nur auf 127.0.0.1; der Zugriff von außen erfolgt über den konfigurierten Webserver/Reverse-Proxy mit HTTPS.
• Die SQLite-Datenbank liegt unter data/massnahmen.sqlite3 und sollte zusammen mit den Konfigurationsdateien regelmäßig gesichert werden.

Protokollierung

Anmeldung, Abmeldung, HTTP-Aktionen, SQLite-Operationstypen, Transaktionen und Uvicorn-Meldungen werden in logs/application.log protokolliert. Der Pfad kann über APP["log_file"] geändert werden. Die Datei rotiert bei 10 MiB; fünf alte Dateien werden aufbewahrt. Neue Logdateien sind nur für den ausführenden Benutzer lesbar. Das Logverzeichnis muss für diesen Benutzer schreibbar sein und auch bei bestehenden Dateien vor fremdem Zugriff geschützt werden.

Beim oben beschriebenen systemd-Dienst gehen die Ausgaben zusätzlich ins Journal: journalctl -u massnahmenmonitor -f. restart.sh nutzt bei verfügbarem Journal systemd-cat: journalctl -t massnahmenmonitor -f. Ohne verfügbares Journal wird die Serverausgabe wie bisher in uvicorn.log geschrieben. Für dauerhaftes Journal müssen die systemd-Journal-Einstellungen des Servers entsprechend konfiguriert sein.

Die Audit-Ereignisse enthalten Benutzerkennung, Zeitpunkt, Aktion, Status, Clientadresse und Vorgangs-ID; SQLite-Ereignisse können über die Vorgangs-ID zugeordnet werden. Es werden keine Formularinhalte, OAuth-Parameter oder SQL-Werte in diesen Ereignissen gespeichert; Schüler- und Klassenkennungen werden pseudonymisiert. Der Uvicorn-Standard-Access-Log ist deaktiviert, da er vollständige URLs mit sensiblen Parametern enthalten kann. Separate Proxy- und Keycloak-Logs müssen eigenständig geprüft und geschützt werden; Fehler-Stacktraces anderer Bibliotheken können dennoch sensible Angaben enthalten. Bei Reverse-Proxys hängt die protokollierte Clientadresse von der vertrauenswürdigen Proxy-Konfiguration ab.

Auch diese Logs enthalten personenbezogene Daten. Zugriff, Aufbewahrung und Löschung müssen mit dem Datenschutzkonzept abgestimmt werden. Die rotierenden Dateien und das Journal allein sind kein manipulationssicheres Auditarchiv; dafür ist eine separate geschützte Log-Sammlung erforderlich. Fehlgeschlagene Passwortprüfungen erfolgen bei Keycloak und stehen in dessen Logs.

Anmeldung und Klassenrechte

• Anmeldung über OIDC; Keycloak bestimmt die Rolle.
• Beim Laden der Hauptseite prüft eine OIDC-Anfrage mit prompt=none die Keycloak-Sitzung erneut. Falls diese nicht mehr besteht, wird die lokale Anmeldung gelöscht und erneut angemeldet. Die Prüfung benötigt eine Verbindung zu Keycloak.
• Bereits geöffnete Seiten und direkte API-Aufrufe werden erst beim nächsten Laden der Hauptseite erneut geprüft. Die Anwendung speichert keine Sitzungen in SQLite.
• Die Abmeldung beendet auch die Keycloak-Sitzung und gegebenenfalls Sitzungen anderer verbundener Anwendungen. Keycloak kann eine Bestätigung verlangen. Optional kann OIDC["post_logout_redirect_uri"] auf eine in Keycloak als gültige Post-Logout-Redirect-URI registrierte Adresse gesetzt werden; sonst zeigt Keycloak seine Abmeldeseite an.
• Schüler werden nach der Anmeldung an die in APP["student_homepage"] konfigurierte Homepage weitergeleitet.
• Lehrkräfte sehen Klassen aus ihren Keycloak-Gruppen */<klasse>-teachers.
• In departments.py konfigurierte Lehrkräfte erhalten zusätzlich Zugriff auf die passenden Abteilungsklassen.

Funktionen

• Klassenübersicht mit Klassenwechsel, Schülerzahl, Zahl der Schüler mit mindestens einem Eintrag und Datum des neuesten Eintrags
• Schülerliste mit Nachname, Vorname, Alter, Stufen für Fehlzeiten und Fehlverhalten sowie der Anzahl der Sonstiges-Einträge
• Schülerdetails in den Bereichen Fehlzeiten, Fehlverhalten und Sonstiges
• Die höchste gespeicherte Maßnahmestufe bestimmt die angezeigte Stufe.
• Sonstiges enthält nur Datum und Kommentar.
• Gestaltung orientiert sich an der Offline-App.

Klassenbezeichnungen

• Mit Zahl: Großschreibung; ein abschließendes a, b oder c bleibt klein.
• Ohne Zahl: Kleinschreibung.

Speicherung

• Einträge werden in SQLite unter data/ gespeichert.
• Der eindeutige Schlüssel eines Schülers ist sein Loginname (cn).
• Einträge enthalten Datum, Kommentar, Ersteller sowie Stufe und Maßnahme aus config/stufen.json.
• Benutzer dürfen eigene Einträge bearbeiten und löschen, aber keine fremden.

Debug und API

• Die Diagnose-Seite ist unter https://<deine-domain>/debug erreichbar, wenn APP["debug"] auf True steht.
• Linuxmuster.net API: https://<server>:8001 (nur im Schulnetz erreichbar)
• In der API-Dokumentation unter Authorize anmelden, über /v1/auth/token einen API-Key abrufen und anschließend autorisieren.