LB2 - Kompetenzmatrix

In dieser Kompetenzmatrix werden die Kompetenzen für die Bewertung der LB2 in drei Stufen angezeigt.

Aufbauend bedeutet, dass die Stufen 1 bis 3 voneinander abhängig sind. Bei nicht aufbauend kann nur eine Stufe gelöst werden.

[!IMPORTANT] Massgebend für die Bewertung ist ausschliesslich die Dokumentation im Git-Repository. Die Umsetzung muss nicht live gezeigt werden.

Im Vordergrund steht das Endresultat – die Dokumentation soll zeigen, was erreicht wurde und wie es funktioniert. Die einzelnen Installationsschritte müssen nicht zwingend dokumentiert werden, dürfen es aber zur Vollständigkeit.

Sobald eine Kompetenz abgeschlossen und dokumentiert ist: Dokumentationsseite im zugehörigen Issue verlinken und den Issue in Review verschieben.

Nr.	Schritte	Kompetenzband	Stufe 1	Stufe 2	Stufe 3
1	Planung & Architektur (nicht aufbauend)	A / C	Vollständiges Systemdatenblatt mit allen relevanten Angaben zur Zielumgebung (Hostname, IP, Betriebssystem, installierte Dienste und Versionen).	Architekturdiagramm – Vollständige und korrekte Darstellung der Soll-Situation mit Hostnames, FQDN, IP-Adressen und AWS-Informationen für jede Komponente.	Strukturierter Projektplan als Mermaid-Diagramm mit individuellen Farben, Schweizer Datumsformat und wöchentlicher Gliederung. Meilensteine für Backups gesetzt, separater Cutover-Zeitpunkt und Rollback-Punkt definiert, Downtime-Strategie beschrieben.
2	DNS (nicht aufbauend)	B	Webserver öffentliche über Domain erreichbar	Punkt wird mit Stufe 3 vergeben	Eigener DNS-Server (z.b. bind9) auf separatem Host oder via Docker. Die öffentliche DynV6 Zone ist als Split-DNS konfiguriert. Wenn Du daran interessiert bist eine öffentlich Zone autoritär auf deinem DNS-Server zu managen sprich Dich mit der Lehrperson ab.
3	Webserver (aufbauend)	B	Einrichtung des Virtual Hosts sowie Aktivierung und Anpassung der Rewrite-Engine(mod_rewrite) für flexible URL-Steuerung und effizientes Routing.	SSL/HTTPS aktiviert und eingerichtet kein self signed (HTTP- oder DNS-Challenge)	Keine Apache default page. HTTP auf HTTPS Weiterleitung eingerichtet und mit curl oder Invoke-WebRequest verifiziert – Statuscode 301 und Location-Header sind in der Dokumentation nachgewiesen. Siehe HTTPS-Redirect verifizieren
4	PHP (aufbauend)	B	PHP-FPM installiert und Apache konfiguriert. Ausgabe der Funktion phpinfo() zeigt korrekte, aktuell unterstützte PHP-Version und Server API: FPM/FastCGI.	PHP-Einstellungen werden über eine .user.ini Datei im DocumentRoot gesetzt (z.B. upload_max_filesize, memory_limit, max_execution_time). Der Unterschied zwischen einer Anpassung direkt in der php.ini und über eine .user.ini ist in der Dokumentation erklärt. Siehe PHP-Einstellungen anpassen	PHP-FPM Statusseite eingerichtet (pm.status_path) und über den Browser erreichbar (nur lokal). Die Ausgabe ist in der Dokumentation erklärt (aktive Prozesse, Verbindungen, Pool-Status).
5	MySQL/MariaDB-Datenbankserver (aufbauend)	B	WordPress-spezifischer Datenbankbenutzer mit eingeschränkten Rechten auf die WordPress-Datenbank. Anmeldung von jedem Host aus möglich.	MySQL-Root-Benutzer mit uneingeschränkten Rechten, Anmeldung ausschliesslich von localhost möglich.	Dedicated DB-Server, Netzwerksegmentierung, DB nicht aus dem Internet erreichbar
6	PhpMyAdmin/Adminer (aufbauend)	B	Standard-Installation auf Webserver, phpMyAdmin erreichbar. In der Dokumentation erklärt: Braucht phpMyAdmin eine eigene Datenbank – ja/nein und warum? Siehe phpMyAdmin Internals	Der phpmyadmin MySQL-User ist in der Dokumentation beschrieben: wo sind die Zugangsdaten definiert, welche Rechte hat er? Welcher Authentifizierungstyp ist konfiguriert und warum ist cookie gegenüber config empfohlen? Siehe phpMyAdmin Internals	Dedicated DB-Server konfiguriert
7	SFTP oder FTPS-Zugang (nicht aufbauend)	B	SFTP-Zugang über Keyfile, eingeschränkt auf das DocumentRoot. Praxistest: Verbindung mit grafischem Tool (z.B. FileZilla, MobaXterm) von extern herstellen, Datei hochladen und korrekte Berechtigungen (Owner, Gruppe, Rechte) in der Dokumentation nachweisen.	FTPS-Zugang über Passwort, eingeschränkt auf das DocumentRoot. Praxistest: Verbindung mit grafischem Tool (z.B. FileZilla, MobaXterm) von extern herstellen, Datei hochladen und korrekte Berechtigungen (Owner, Gruppe, Rechte) in der Dokumentation nachweisen.
8	WordPress-Migration (aufbauend)	B	DB wurde migriert WP-Files mit korrekten Berechtigungen in DocumentRoot	wp-config.php mit korrekten DB-Informationen konfiguriert. MD5-Hash in wp_users ersetzt damit Login möglich ist.	WP-CLI installiert, läuft unter dem Webserver-User. Alte Domain mit wp search-replace korrekt ersetzt, WordPress läuft unter der neuen Domain und Login ist möglich. Dokumentiert: warum wp search-replace gegenüber direktem SQL-REPLACE bevorzugt wird.
9	Backup (aufbauend)	C	Vollständiges Backup (Files + DB-Dump) per CRON-Job mit sinnvoller Periodizität. Backup wird verschlüsselt (GPG), in ein Logfile geschrieben und alte Backups werden nach Aufbewahrungsrichtlinie automatisch gelöscht.	Mindestens 2 Erweiterungen nach eigener Wahl – dokumentiert und begründet. Vorschläge: Cloud-Upload (Backblaze B2, S3 o.ä.), Exitcode-Prüfung mit Errorlog, E-Mail-Benachrichtigung bei Fehler, Statusmeldung via Telegram oder Discord.	Eigene Backup-API: Ein PHP-Skript auf dem Webserver nimmt HTTP-Requests entgegen und löst das Backup aus. Der Endpunkt ist mit einem API-Key gesichert.
10	Testing (aufbauend)	E	Die Seite https://neue-url/wp-admin/site-health.php zeigt min. "gut" an Die Seite https://neue-url/wp-admin/admin.php?page=et_support_center_divi hat keine roten Meldungen	Die WordPress-Webapplikation enthält keine Fehlermeldungen (Inspect/Untersuchen unter Chrome/FF oder Edge)
11	Monitoring (aufbauend)	B	Zweite EC2-Instanz aufgesetzt. Mit Hilfe von KI ein WordPress-Plugin erstellt, das den HTTP-Statuscode anderer Webauftritte periodisch abfragt.	Bei einem Statuscode-Wechsel wird automatisch eine Meldung via ntfy.sh versendet.	Visuelles Status-Dashboard: Eine Seite zeigt alle überwachten Sites mit aktuellem Status (grün/rot), letztem Check-Zeitpunkt und Uptime.
12	Deployment (aufbauend)	B	Punkt wird mit Stufe 2 vergeben	Git-Repo mit staging-Branch, WordPress-Files im Repo. Bei einem Push überträgt eine GitLab CI/CD Pipeline die Dateien automatisch via SSH auf den Server.	Keine Credentials im Repo: wp-config.php wird nicht eingecheckt, sondern via CI/CD-Variable zur Deploy-Zeit auf den Server geschrieben.