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.

Nr.	Schritte	Kompetenzband	Stufe 1	Stufe 2	Stufe 3
1	Projektplan (aufbauend)	C	Strukturierter und sinnvoller Projektplan in Mermaid-Diagrammform im Repository.	Verwendung individueller Farben und sinnvolle Festlegung von Meilensteinen für Backups im Mermaid-Diagramm. Strukturierter Plan mit Schweizer Datumsformat und wöchentlicher Gliederung.	Separater Migrations-Zeitpunkt (Cutover). Rollback-Punkt definiert und Downtime-Strategie (auch wenn theoretisch), sowie eigene Ideen eingebracht.
2	Architekturdiagramm + Systemdatenblatt (aufbauend)	A	Vorlage Architekturdiagramm – Vollständige und korrekte Darstellung der "Soll-Situation Minimales Systemdatenblatt.md	Hostnames mit FQDN, IP-Adressen und AWS-Informationen für jede Komponente angegeben. Vollständiges Systemdatenblatt.md	Gut strukturierte Darstellung mit sinnvoll eingesetzten Farben für klare Visualisierung. Umfangreiches Systemdatenblatt.md
3	Umgebung aufbauen/einrichten (aufbauend)	B	AWS-Umgebung eingerichtet und funktioniert (In der Anleitung werden zwei Subnetze erstellt, was fürs M158 nicht notwendig ist)	AWS-Umgebung wurde mit sämtlichen Angaben aus der Planung eingerichtet	Sie arbeiten mit einer öffentlichen Domain. Falls Sie keine eigene Domain besitzen können Sie kostenlos eine erstellen https://dynv6.com/ (verwenden Sie v6.rocks) oder https://www.duckdns.org/.
4	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.
5	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
6	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).
7	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
8	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
9.1	SFTP oder FTPS-Zugang (nicht aufbauend)	B	SFTP-Zugang über Keyfile mit präzise definiertem Zugriff auf das DocumentRoot, eingeschränkt auf relevante Verzeichnisse für maximale Sicherheit	FTPS-Zugriff über Passwort FTP-Benutzer mit präzise definiertem Zugriff auf das DocumentRoot, eingeschränkt auf relevante Verzeichnisse für maximale Sicherheit
10	WordPress-Migration (aufbauend)	B	DB wurde migriert WP-Files mit korrekten Berechtigungen in DocumentRoot	Konfiguration der wp-config.php mit den entsprechenden DB-Informationen.	WP_HOME and WP_SITEURL in Datenbank angepasst MD5 Hash in wp_users Tabelle ersetzt damit Login möglich ist.
10.1	WP-CLI (aufbauend)	B	WP-CLI ist installiert, läuft unter dem Webserver-User und kann WordPress korrekt ansprechen (wp core version, wp option get siteurl).	Die alte Domain wurde mit WP-CLI korrekt durch die neue Domain ersetzt (wp search-replace) (Erklären Sie in Ihrer Dokumentation, warum nicht per SQL 'SQL REPLACE' ersetzen sollte?
11	Backup (aufbauend)	C	Datenbank- & Datei-Backup über CRON mit sinnvoller Periodizität und gezielter Löschung alter Backups nach Aufbewahrungsrichtlinien.	Backup wird automatisch auf Backblaze B2 hochgeladen (rclone). Exitcodes aller Befehle werden geprüft und Fehler in ein Errorlog (backup.log) geschrieben. Siehe rclone & Backblaze B2	Bei einem Fehler im Backup-Skript wird automatisch eine E-Mail via SMTP versendet.
12	Testing (aufbauend)	E	Der Testkatalog enthält 20 spezifische Testfälle, die gezielt auf die Anforderungen und Funktionen einer Webapplikation abgestimmt sind.	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)
13	Monitoring (aufbauend)	B	Sie erstellen eine zweite EC2 Instanz und setzen dort erneut einen Webserver mit WordPress(Default) auf.	Sie erstellen mit mit der Hilfe von Ki ein WordPress-Plugin mit welchem Sie anderen Webauftritte "überwachen" können, indem Sie den HTTP Statuscode periodisch abfragen.	Das Monitoring versendet über SMTP-Mail(FluentSMTP) Meldungen, wenn die zu überwachende Website den HTTP-Statuscode wechselt https://de.wikipedia.org/wiki/HTTP-Statuscode
14	Deployment (aufbauend)	B	Auto-Deployment über CI/CD-Tools wurde eingerichtet.	Es existieren ein Staging- und ein Live-Branch, wobei Staging-Commits automatisch deployed werden.	Eigenes WordPress-Plugin für LIVE und STAGE mit Umgebungsvariablen ist eingerichtet