Skip to content

Sessions & Betrieb

Im Admin-Bereich unter "Lab" finden Sie die Live-Übersicht aller aktiven Sessions sowie das Notfall-Werkzeug "Kill-Switch".

Aktive Sessions

Die Tabelle zeigt alle Sessions plattformweit, die nicht beendet sind:

Spalte Bedeutung
Session-ID Eindeutige UUID, beim Support-Anfragen nützlich
Lerner E-Mail oder Pseudo-Adresse (bei Klassen-Schülern)
Lektion Slug der gerade bearbeiteten Lektion
Status Provisioning / Ready / Active / Expiring
VM Hetzner-Server-ID + IPv4-Adresse
Gestartet Wann begann die Provisionierung
Restzeit Wie lange noch bis Auto-Ende
Kosten (geschätzt) Aktueller Kostenstand der Session

Sie können nach allen Spalten sortieren und nach Lerner-Adresse, Lektion oder Status filtern.

Auto-Refresh

Die Tabelle aktualisiert sich automatisch alle ~10 Sekunden. Damit sehen Sie z.B. Provisioning-Sessions wechselnd in den Ready-Status.

Wann auf Auffälligkeiten achten?

Plausible Werte im Normalbetrieb:

  • Aktive Sessions: typisch 0–50 (je nach Tageszeit)
  • Provisioning-Dauer: unter 90 Sekunden
  • Failed-Sessions: sollten sehr selten sein (<1% aller Versuche)
  • Sessions, die "Expiring" sind, aber nicht enden: möglicher Reaper-Fehler

Warnsignale

Beobachtung Mögliche Ursache Aktion
Plötzlich >100 Sessions Stoßzeit oder Bot/Abuse Kill-Switch in Bereitschaft, Logs prüfen
Lerner mit >5 Sessions/Stunde Quota-Bug oder Mehrfach-Konten Konto temporär suspendieren
Sessions hängen in "Provisioning" Hetzner-API-Problem Operations-Team
Sessions hängen in "Expiring" Reaper läuft nicht Operations-Team

Einzelne Session beenden

Per Klick auf eine Session-Zeile öffnen Sie die Detail-Sicht. Optionen:

  • Session beenden – die VM wird sofort gelöscht, Lerner-Quota wird nicht zurückerstattet
  • Lerner-Profil öffnen – Sprung zur User-Detailseite (Konto-Status, MFA, AGB, Eltern-Consent, suspended_at)

Nutzen Sie das Beenden einzelner Sessions, wenn ein Lerner offensichtlich Probleme hat (gemeldet via Feedback) oder Sie eine Test-Session aufräumen wollen.

Kill-Switch

Der Kill-Switch beendet alle aktiven Sessions plattformweit und löscht die VMs. Er ist gedacht für:

  • Sicherheitsvorfälle – z.B. Verdacht auf Missbrauch der VMs für Mining/DDoS
  • Hetzner-Notfälle – plötzliche Tarifänderungen, Service-Probleme im Datacenter
  • Wartungsfenster – wenn Sie ein Schema-Update fahren wollen, das keine laufenden Sessions verträgt

Auslösen

  1. Admin-Lab-Übersicht → Kill-Switch auslösen
  2. Bestätigungsdialog mit Zähler der betroffenen Sessions (z.B. "23 Sessions werden beendet")
  3. Geben Sie zur Bestätigung den Text KILL ein (Schreibmaschinen-Sicherheitsabfrage)
  4. Auslösen

Innerhalb von 30 Sekunden sollten alle VMs gelöscht sein. Lerner sehen einen Hinweis "Session wurde administrativ beendet".

Was Lerner sehen

  • Banner mit "Session beendet" – ohne Detail-Begründung
  • Aufgaben-Fortschritt bleibt erhalten
  • Neue Session kann sofort gestartet werden, sobald der Auslöser behoben ist

Quota-Erstattung

Beim Kill-Switch wird die Lerner-Quota automatisch zurückerstattet – Lerner werden für die abgebrochene Session nicht "bestraft". Bei der nächsten Session-Anfrage gilt der Stand wie vor der unterbrochenen Session.

Kill-Switch ist ein Notfall-Werkzeug

Verwenden Sie ihn nur bei echten Notfällen. Bei einzelnen Problem-Sessions nutzen Sie das Beenden einer einzelnen Session.

Konto-Suspendierung

Wenn Sie einen Lerner verdächtigen, das System zu missbrauchen (Bot, Cracking, ungewöhnliches Verhalten):

  1. Lerner-Profil öffnen (über Session-Detail oder Nutzer-Suche)
  2. Konto suspendieren
  3. Begründung intern dokumentieren (z.B. "Mining-Verdacht, IP-Range XYZ")

Der Lerner kann sich nicht mehr einloggen. Bestehende Sessions des Lerners werden automatisch beendet. Über die hinterlegte E-Mail-Adresse wird informiert, wie der Lerner Einspruch erheben kann.

Suspendierung aufheben

Im Lerner-Profil → Suspendierung aufheben. Der Lerner kann sich wieder einloggen. Alte Daten bleiben unverändert.

Schulen anlegen

Schulen werden manuell angelegt, wenn ein AVV unterzeichnet ist:

  1. Admin → "Schulen" → Neue Schule
  2. Felder:
    • Name – offizieller Schulname
    • Slug – URL-tauglicher Kurzname (z.B. gymnasium-musterstadt)
    • Kontakt-E-Mail – Schul-Sekretariat oder Schulleitung
    • AVV-Unterzeichnungs-Datum
  3. Speichern

Anschließend legen Sie das erste Schul-Admin-Konto an:

  1. Schul-Detailseite → Schul-Admin hinzufügen
  2. E-Mail, Anzeigename eingeben
  3. Speichern – Einladungs-E-Mail wird verschickt

Ab jetzt kann der Schul-Admin selbst Lehrer einladen.

Logs einsehen

Detaillierte Logs (HTTP-Requests, Fehler, VM-Operationen) sind nicht im Admin-UI sichtbar – das ist Operations-Aufgabe.

Im UI verfügbar:

  • Validator-Audit pro Lerner (siehe Lerner-Profil)
  • Session-Historie pro Lerner
  • Feedback-Einträge (Inbox unter "Feedback")

Für tiefergehende Analysen wenden Sie sich an das Operations-Team.

Häufige Fragen

"Kann ich sehen, was ein Lerner gerade in der VM tut?"

Nein. VMs sind isoliert; selbst Admins haben keinen direkten Shell-Zugang zu Lerner-VMs. Sichtbar ist nur, welche Validierungen ausgeführt wurden und welche Ergebnisse sie hatten.

"Wie lange dauert es, bis nach einem Kill-Switch alles wieder normal ist?"

VMs sind innerhalb 30 Sekunden gelöscht. Neue Sessions können sofort gestartet werden. Wenn Sie den Kill-Switch wegen eines Hetzner-Problems ausgelöst haben, müssen Sie ggf. warten, bis Hetzner wieder verfügbar ist.

"Lerner beschwert sich, dass sein Konto plötzlich gesperrt ist – was tun?"

  1. Lerner-Profil öffnen → Status prüfen
  2. Wenn "suspendiert": Grund war eine Auffälligkeit. Lesen Sie die hinterlegte Notiz.
  3. Bei Unklarheit: Operations-Team befragen, das die Suspendierung ausgelöst hat.
  4. Bei Fehlalarm: Suspendierung aufheben, kurz an Lerner zurückmelden.

"Wie viele aktive Sessions verträgt die Plattform?"

Aktuelle Konfiguration: bis ~100 gleichzeitige VMs. Bei höherem Bedarf muss das Operations-Team die Kapazität erhöhen (mehrere Hetzner-Regionen, Quota-Anhebung bei Hetzner).

Nächster Schritt