Inhalte pflegen¶

Plattform-Admins erstellen und pflegen alle Lerninhalte: Module, Lektionen und Aufgaben. Diese Seite beschreibt den typischen Workflow.

Die Inhalts-Hierarchie¶

graph TD
    M[Modul] --> L1[Lektion 1]
    M --> L2[Lektion 2]
    L1 --> T1[Aufgabe 1.1]
    L1 --> T2[Aufgabe 1.2]
    L2 --> T3[Aufgabe 2.1]

Modul – Themenpaket (Top-Level)
Lektion – konkretes Lernszenario in einer VM
Aufgabe – einzelner Validator-Check

Alle drei Ebenen sind unter Admin → Lab → Module erreichbar.

Neues Modul anlegen¶

Admin → Lab → Module → Neues Modul
Felder:

Feld	Beschreibung	Pflicht?
Slug	URL-tauglicher Kurzname, z.B. `deploy-and-tls`. Unveränderlich nach Erstellung.	✓
Titel (DE)	Anzeigetitel auf Deutsch	✓
Titel (EN)	Anzeigetitel auf Englisch	✓
Beschreibung (DE)	Markdown, was lernt der Lerner	✓
Beschreibung (EN)	Markdown, englische Variante	✓
Schwierigkeit	Einsteiger / Fortgeschritten / Experte	✓
Geschätzte Dauer	Minuten, typisch 30–60	✓
Display-Order	Reihenfolge im Katalog (kleiner = oben)	✓
Veröffentlicht	Default `false` (Entwurf)	–

Speichern

Solange Veröffentlicht=false ist, sehen nur Admins das Modul. Lerner sehen es erst, wenn Sie es explizit auf true setzen.

Lektionen zu einem Modul anlegen¶

Modul-Detailseite → Tab Lektionen → Neue Lektion
Felder:

Feld	Beschreibung	Pflicht?
Slug	Global eindeutig, z.B. `nginx-deploy-tls`. Unveränderlich.	✓
Titel (DE/EN)	Anzeigetitel	✓
Intro-Markdown (DE/EN)	Voller Anweisungstext, der links im Player erscheint	✓
Cloud-Init-Overrides	Optional: Anpassungen der VM-Konfiguration (siehe unten)	optional

Speichern

Intro-Markdown – was reinschreiben?¶

Das ist der primäre Lehrtext. Empfehlungen:

Einleitung – was lernt der Schüler?
Schritt-für-Schritt-Anleitung mit nummerierten Abschnitten
Befehls-Beispiele in Code-Blöcken
Hinweise auf Aufgaben – "Aufgabe 1 prüft, dass nginx läuft"
Externe Links – nur zu langfristig stabilen Quellen

Vermeiden:

Aktuelle Datumsangaben oder Versionen, die schnell altern
Links auf private Wikis oder GitHub-Branches
Spoiler zu Aufgaben (dafür gibt es Hint-Levels)

Cloud-Init-Overrides¶

Standardmäßig erhalten alle Lektionen dieselbe VM-Basis (Debian/Ubuntu, vorinstallierte Tools). Wenn Sie für eine bestimmte Lektion eine abweichende Vorbereitung brauchen (z.B. eine Datenbank vorinstalliert), tragen Sie das im Cloud-Init-Override-Feld ein.

Das Feld erwartet YAML in einem Subset des Standard-cloud-init-Formats. Konsultieren Sie das Operations-Team, bevor Sie das nutzen – falsche Overrides können Lektionen unbrauchbar machen.

Aufgaben zu einer Lektion anlegen¶

Lektions-Detailseite → Tab Aufgaben → Neue Aufgabe
Felder:

Feld	Beschreibung	Pflicht?
Slug	Eindeutig pro Lektion, z.B. `nginx-listening`	✓
Titel (DE/EN)	Was prüft die Aufgabe	✓
Beschreibung (DE/EN)	Markdown – was soll der Schüler erreichen	✓
Display-Order	Reihenfolge in der Lektion	✓
Validator-Config	JSON – wie wird geprüft (siehe unten)	✓
Hinweis 1 (DE/EN)	Leichter Anstoß	✓
Hinweis 2 (DE/EN)	Konkretere Hilfe	✓
Hinweis 3 (DE/EN)	Schritt-für-Schritt-Lösung	✓

Speichern

Validator-Config¶

Die Validator-Config ist ein JSON-Objekt, das definiert, wie geprüft wird. Verfügbare Check-Typen (kann sich erweitern):

Typ	Was es prüft	Beispiel-Config
`command_output`	Output eines Befehls auf der VM	`{"type": "command_output", "command": "systemctl is-active nginx", "expected": "active"}`
`file_content`	Inhalt einer Datei	`{"type": "file_content", "path": "/etc/nginx/sites-available/default", "contains": "listen 80"}`
`port_listening`	Lauscht ein Port	`{"type": "port_listening", "port": 80}`
`http_response`	HTTP-Antwort auf einer URL	`{"type": "http_response", "url": "http://localhost", "status": 200}`

Falls Sie eine Aufgabe entwerfen, für die noch kein passender Validator-Typ existiert, sprechen Sie mit dem Lab-Engineering-Team.

Hinweis-Levels gestalten¶

Die drei Hinweis-Levels sollten echte Eskalation sein:

Hinweis 1: Lerner soll selbst denken. Frage oder Konzept ohne Lösungsspoiler.
- Beispiel: "Welcher Befehl prüft, ob ein Service läuft?"
Hinweis 2: Konkrete Methode, aber nicht alle Schritte.
- Beispiel: "Nutze systemctl status nginx. Wenn das inactive zeigt, musst du starten."
Hinweis 3: Direkte Lösung als Lehrmaterial. Lerner soll nicht raten müssen.
- Beispiel: "Führe diese Befehle aus: sudo apt install nginx, dann sudo systemctl start nginx, dann sudo systemctl enable nginx."

Inhalte testen¶

Bevor Sie ein Modul veröffentlichen:

Legen Sie sich ein Test-Lerner-Konto an (eigene E-Mail mit Endung +test@…).
Modul auf Veröffentlicht=true setzen – Schüler des Test-Kontos sehen es im Katalog.
Lektion durchspielen, alle Aufgaben lösen, Hinweise prüfen.
Wenn alles passt: alle anderen Schüler haben es ebenfalls verfügbar.

Wenn Sie Fehler finden: Modul wieder auf Veröffentlicht=false setzen, korrigieren, erneut testen.

Veröffentlichungen sind sofort sichtbar

Sobald Veröffentlicht=true und ein Lerner den Katalog neu lädt, sieht er das Modul. Testen Sie also vor dem Veröffentlichungs-Klick gründlich.

Inhalte bearbeiten¶

Alle Felder (außer Slug) können später geändert werden. Die Änderung wirkt sofort für alle Lerner.

Aufgaben-Texte und Hinweise: Lerner sehen die neue Version beim nächsten Aufruf der Lektion.
Validator-Config-Änderungen: Wirken auf alle neuen Validierungs-Versuche. Bereits bestandene Aufgaben werden nicht neu bewertet.

Versions-Konflikte vermeiden¶

Wenn Sie eine Aufgabe wesentlich ändern (z.B. ein zusätzlicher Check), kann das Schüler überraschen, die bereits "bestanden" hatten. Empfehlung:

Kleine Korrekturen (Tippfehler, Klarstellung): direkt ändern
Wesentliche Änderungen (anderer Lerninhalt): neue Aufgabe anlegen und die alte deaktivieren

Inhalte löschen¶

Inhalte sollten nicht hart gelöscht werden. Wenn ein Modul/Lektion/Aufgabe nicht mehr aktuell ist:

Modul: auf Veröffentlicht=false setzen → bleibt im Schüler-Statistik-Verlauf, ist aber nicht mehr im Katalog
Aufgabe: als deaktiviert markieren (Feld is_active=false – wenn verfügbar)
Echte Löschung: nur durch Operations-Team und nur, wenn keine Lerner-Daten daran hängen

Marketing-Inhalte (Content-Blöcke)¶

Unter Admin → Lab → Content finden Sie textuelle Bausteine für die Lab-Landing-Page und andere statische Bereiche:

Hero-Headline
FAQ-Einträge
Pricing-Perks
Module-Vorschau-Texte für TikTok-Promotion etc.

Jeder Block hat:

Schlüssel (z.B. lab.hero.headline) – wird im Code referenziert
Inhalt DE/EN – Markdown

Änderungen werden meist innerhalb einer Minute live, da die Landing-Page Server-side gerendert wird.

Häufige Fragen¶

"Ich habe einen Tippfehler in einem veröffentlichten Modul"¶

Direkt korrigieren – die Änderung wirkt beim nächsten Lerner-Aufruf. Kein Versions-Management nötig.

"Schüler beschweren sich, dass eine Aufgabe nicht lösbar ist"¶

Mit Test-Konto die Aufgabe selbst lösen.
Wenn lösbar: Schüler nachfragen, welcher Befehl scheitert; oft fehlt ein Detail.
Wenn unlösbar: Validator-Config prüfen, ggf. mit dem Engineering-Team analysieren.

"Kann ich eine Lektion in mehrere Sprachen über DE/EN hinaus anbieten?"¶

Aktuell sind DE und EN fest verdrahtet. Weitere Sprachen erfordern Plattform-Erweiterung – Anfrage an das Engineering-Team.

"Warum kann ich einen Slug nicht ändern?"¶

Slugs sind in URLs und Datenbank-Referenzen verbaut. Eine Änderung würde alle bestehenden Schüler-Fortschritts-Einträge verwaisen lassen und URLs in Hausaufgaben-Beschreibungen brechen.

"Wie viele Aufgaben pro Lektion sind sinnvoll?"¶

3–7 Aufgaben sind typisch. Bei mehr als 10 wird die Lektion oft zu lang für eine 60-Minuten-Session – teilen Sie das Modul lieber in zwei Lektionen auf.

Nächster Schritt¶

Einstellungen – globale Plattform-Parameter (Quota, Session-TTL, AGB).