📚 Improved IHK Projektdokumentation and logs for better clarity & error handling in backend installation process. 🖥️🔍

IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md

@@ -131,65 +131,65 @@ Gesamtinfrastruktur
 
 [4.4 Abnahme [15](#abnahme)](#abnahme)
 
-[Anlagen [15](#anlagen)](#anlagen)
+# Anlagen
 
-[Netzwerkdiagramme und Systemarchitektur
-[15](#netzwerkdiagramme-und-systemarchitektur)](#netzwerkdiagramme-und-systemarchitektur)
+## Netzwerkdiagramme und Systemarchitektur
 
-[API-Dokumentation [15](#api-dokumentation)](#api-dokumentation)
+(Inklusive Zenmap-Visualisierung der DNS-Problematik)
 
-[Benutzerhandbuch [16](#benutzerhandbuch)](#benutzerhandbuch)
+## API-Dokumentation
 
-[Testprotokolle [16](#testprotokolle)](#testprotokolle)
+## Benutzerhandbuch
 
-[Screenshots der Benutzeroberfläche
-[16](#screenshots-der-benutzeroberfläche)](#screenshots-der-benutzeroberfläche)
+## Testprotokolle
 
-[Konfigurationsdateien und Deployment-Skripte
-[16](#konfigurationsdateien-und-deployment-skripte)](#konfigurationsdateien-und-deployment-skripte)
+## Screenshots der Benutzeroberfläche
+
+## Konfigurationsdateien und Deployment-Skripte
 
 # 1. Einleitung
 
 ## 1.1 Analyse des Projektauftrages
 
 Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am
-Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller
-(Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen
-höherer Prioriät sozusagen). Diese Geräte stellen eine wichtige
-Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche
-technische Limitierungen auf; beispielsweise verfügen die Drucker weder
-über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche
-Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten
-bislang eine koordinierte digitale Verwaltung und eine damit
-einhergehende Übersicht von Reservierungen und Nutzungsplänen der
-Azubis.
+Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller –
+Prusa, Anycubic. B-Ware im Vergleich zu 3D-Druckern von Kostenstellen
+höherer Priorität, aber für unsere Zwecke vollkommen ausreichend. Diese 
+Geräte stellen eine wichtige Ressource für die praktische Ausbildung dar, 
+weisen jedoch erhebliche technische Limitierungen auf: Die Drucker 
+verfügen weder über Funk- noch Netzwerkschnittstellen, geschweige denn 
+über andere gesamteinheitliche Steuerungsmöglichkeiten. Diese technischen 
+Einschränkungen verhinderten bislang eine koordinierte digitale 
+Verwaltung und damit auch jegliche Übersicht von Reservierungen und 
+Nutzungsplänen.
 
-Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann -
-basierte auf einem analogen Whiteboard, welches neben den Druckern
-positioniert war. Dies führte zu systematischen Problemen:
-Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich
-Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der
-Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und
-erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der
-tatsächlichen Nutzungszeiten existierte nicht, wodurch weder
-aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für
-Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung
-möglich waren.
+Das bestehende 'Reservierungssystem' – wenn man ein analoges Whiteboard 
+neben den Druckern überhaupt so nennen möchte – führte zu systematischen 
+Problemen. Doppelbuchungen waren an der Tagesordnung, die manuelle 
+Aktivierung und Deaktivierung der Geräte wurde regelmäßig vergessen (was 
+zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte), und eine 
+verlässliche Dokumentation der tatsächlichen Nutzungszeiten? 
+Fehlanzeige. Weder Verantwortungszuordnung für Aufräumarbeiten noch 
+verursachungsgerechte Kostenzuordnung waren möglich.
 
 Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
-Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von
-Next.js hervorgebracht. Der Prototyp verfügte über eine moderne
-Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte
-ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb
-die auf Prototypen-basierende Projektarbeit des Torben Haacks in der
-praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die
-Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im
-Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort
-mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren
-konnte und ich keine notwendige Obligation - wie bei anderen
-Projektmöglichkeiten die sich mir boten - verspürte, sondern einen
-Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es
-kitzelte meine Leidenschaft.
+Haack – Fachrichtung Daten- und Prozessanalyse – hatte einen
+vielversprechenden Frontend-Prototyp auf Basis von Next.js
+hervorgebracht. Der Prototyp verfügte über eine moderne
+Benutzeroberfläche mit umfangreichen Analysefunktionen. Nur fehlte
+dummerweise die komplette Backend-Funktionalität. Ohne Backend blieb 
+die Projektarbeit des Herrn Haack in der praktischen Anwendung 
+funktionslos. Ursprünglich war angedacht, API-Endpunkte zu 
+implementieren, welche die Daten- und Prozessanalyse seines Frontends 
+ermöglicht hätten – eine Aufgabe, die naturgemäß außerhalb meines 
+Fachgebiets der digitalen Vernetzung lag.
+
+Ich sah die Chance, die Idee aufzugreifen und im Rahmen meiner 
+Projektarbeit weiterzuentwickeln. Die Schnittstelle der Vernetzung zum 
+cyber-physischen System lag im Backend – genau mein Ding. Mehrere 
+Möglichkeiten zur Einbringung meiner Fachrichtung sprangen mir direkt 
+ins Auge. Keine lästige Pflichtaufgabe wie bei anderen Projektoptionen, 
+sondern echtes Interesse. Es kitzelte meine Leidenschaft.
 
 ## 1.2 Ableitung der Projektziele
 
@@ -238,13 +238,24 @@ erfordert, die weder zeitlich noch wirtschaftlich vertretbar gewesen
 wären – ganz zu schweigen von den Garantieverlusten, die solche
 Eingriffe unweigerlich nach sich gezogen hätten.
 
-Ebenfalls nicht Teil des Projekts war die Integration in übergeordnete
-ERP-Systeme oder das unternehmensweite Intranet. Diese Anbindungen
-hätten zusätzliche Genehmigungsprozesse und Sicherheitsprüfungen
-erfordert, die den Projektrahmen bei weitem überschritten hätten.
+Die Integration in das unternehmensweite Intranet war ursprünglich fest
+eingeplant – ein Vorhaben, das sich als verhängnisvoller Trugschluss
+erweisen sollte. Zur Projektmitte hatte ich die bereits genehmigten
+SSL-Zertifikate des Haack'schen Prototyps durch einen unglücklichen
+Neuinstallationsprozess unwiederbringlich gelöscht; ein Moment des
+Schreckens, der die gesamte Projektplanung ins Wanken brachte. Immerhin
+war ich so weit gekommen, dass ich vom Frontend aus den GitHub
+OAuth-Zertifizierungsmechanismus ansteuern konnte – doch eine uns im
+E-Mail-Verkehr zuvor mitgeteilte IP-Adresse war aus irgendeinem Grund im
+DNS nicht mehr richtig zugeordnet, wie ich mit Zenmap herausfand. Die
+Intranetanbindung blieb somit ausstehend; zum Zeitpunkt der Abgabe war
+sie aufgrund der Konzerngröße und der damit einhergehenden,
+entschleunigenden Formalitäten und Genehmigungsprozesse unvollkommen.
+Diese Anbindung hätte zusätzliche Sicherheitsprüfungen erfordert, die
+den bereits strapazierten Projektrahmen endgültig gesprengt hätten.
 Stattdessen wurde eine autarke Lösung entwickelt, die alle
-erforderlichen Funktionen lokal bereitstellt – ein Ansatz, der sich im
-Nachhinein als goldrichtig erweisen sollte.
+erforderlichen Funktionen lokal bereitstellt – ein Ansatz, der sich
+trotz der Rückschläge als gangbar erwies.
 
 ## 1.4 Projektumfeld
 
@@ -289,9 +300,8 @@ Funktionsumfang und Benutzerfreundlichkeit.
 Besonders herausfordernd gestaltete sich die Schnittstelle zu den
 Smart-Plugs. Die ursprüngliche Annahme, dass sich die TAPO P110-Steckdosen
 von TP-Link problemlos integrieren lassen würden, erwies sich als
-naiv. Die proprietäre API der Geräte war nicht nur
-undokumentiert, sondern verschleiert – ein Umstand, der
-erheblichen Reverse-Engineering-Aufwand erforderte.
+naiv. Die Geräte boten keine dokumentierte API – nur die proprietäre 
+TAPO-App ermöglichte die Steuerung. Das war ein Problem.
 
 ## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen
 
@@ -306,25 +316,30 @@ Lösungsansätzen zwang.
 Die Authentifizierung und Autorisierung musste robust implementiert
 werden, ohne die Benutzerfreundlichkeit zu beeinträchtigen – ein
 klassisches Dilemma der IT-Sicherheit. Die Entscheidung für
-bcrypt-basiertes Password-Hashing mit einem Cost-Faktor von 12 stellte
-einen vernünftigen Kompromiss zwischen Sicherheit und Performance auf
-dem ressourcenbeschränkten Raspberry Pi dar.
+bcrypt-basiertes Password-Hashing stellte einen vernünftigen Kompromiss
+zwischen Sicherheit und Performance auf dem ressourcenbeschränkten
+Raspberry Pi dar; die Details der Implementierung überließ ich – 
+naturgemäß außerhalb meiner Kernkompetenz der digitalen Vernetzung
+liegend – der bewährten Flask-Login-Bibliothek.
 
 Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte.
 Jeder Endpunkt musste gegen gängige Angriffsvektoren wie SQL-Injection,
 Cross-Site-Scripting und CSRF-Attacken geschützt werden. Die
-Implementierung eines Rate-Limiting-Mechanismus verhindert zudem
+Implementierung eines Rate-Limiting-Mechanismus erschwert
 Brute-Force-Angriffe auf die Authentifizierungsschnittstelle – eine
-Maßnahme, die sich später als weitsichtig erweisen sollte.
+Maßnahme, die zwar keinen absoluten Schutz bietet, aber die Hürde für
+Angreifer signifikant erhöht.
 
 ## 1.7 Darstellung der vorhandenen Systemarchitektur
 
-Die vorgefundene Systemarchitektur – wenn man sie denn überhaupt so
-nennen möchte – bestand aus isolierten Komponenten ohne jegliche
-Integration. Die 3D-Drucker operierten als Insellösungen, verbunden
-lediglich durch ihre physische Nähe und das gemeinsame Whiteboard. Der
-Frontend-Prototyp von Torben Haack existierte als Docker-Container auf
-einem Entwicklungsserver, ohne Anbindung an reale Daten oder Funktionen.
+Die vorgefundene Systemarchitektur – möchte man sie überhaupt so nennen –
+bestand aus diffusen Komponenten ohne jegliche Integration. Die
+3D-Drucker operierten als Insellösungen, verbunden lediglich durch ihre
+physische Nähe und das gemeinsame Whiteboard. Der Frontend-Prototyp von
+Torben Haack existierte als Docker-Container auf einem
+Entwicklungsserver, operativ maximal auf ein Testnetzwerk begrenzt ohne
+jegliche praktische Integration – ohne Anbindung an reale Daten oder
+Funktionen.
 
 Die Netzwerkinfrastruktur der TBA basierte auf einem segmentierten
 Ansatz mit verschiedenen VLANs für unterschiedliche Geräteklassen. Die
@@ -338,7 +353,15 @@ erforderlich war. Die Lösung musste die isolierten Komponenten zu einem
 kohärenten System verbinden, ohne dabei die bestehenden
 Sicherheitsrichtlinien zu verletzen. Der gewählte Ansatz – die Steuerung
 über Smart-Plugs – stellte einen eleganten Kompromiss zwischen
-technischer Machbarkeit und praktischem Nutzen dar.
+technischer Machbarkeit und praktischem Nutzen dar; eine Entscheidung,
+die nicht zuletzt auf meiner privaten Erfahrung mit TAPO-Geräten
+basierte. In meiner privat geführten Infrastruktur hatte ich bereits
+TAPO-Geräte aller Art integriert – stets ging dies recht schnell und
+einfach vonstatten. Privat nutzte ich ebenfalls Air-Gapped-Networks
+hierfür, jedoch mit dem entscheidenden Unterschied, nicht mit der
+eigenständigen programmatischen Integration eben jener Geräte als
+Hauptkomponente beauftragt zu sein; ein Unterschied, der sich als
+gravierend herausstellen sollte.
 
 # 2. Projektplanung
 
@@ -437,6 +460,13 @@ nicht nur Unabhängigkeit von proprietären Lösungen, sondern erfüllte
 auch die strikte Offline-Anforderung des Projekts – ein Umstand, der
 sich als Segen erwies.
 
+Als Betriebssystem stand zunächst eine Entscheidung zwischen OpenSUSE
+und NixOS im Raum – wir hatten uns bereits gedanklich auf NixOS
+festgelegt, da es durch seine deklarative Konfiguration für diesen
+Einsatzzweck prädestiniert schien. Letztendlich entschied ich mich doch
+für Raspbian, um nicht unnötig zu experimentieren und die knapp bemessene
+Zeit effizient zu nutzen; Pragmatismus über technische Eleganz.
+
 ## 2.3 Planung der Qualitätssicherung
 
 Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede 
@@ -499,25 +529,23 @@ kategorisch aus, was die Optionen erheblich einschränkte. Die
 Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten
 Zertifikaten war pragmatisch, aber effektiv.
 
-Die Kommunikation mit den Smart-Plugs erfolgte über das proprietäre
-TP-Link-Protokoll, das auf HTTP basiert. Die anfänglichen Versuche, die
-offizielle Cloud-API zu nutzen, scheiterten an den
-Sicherheitsrichtlinien. Die Entdeckung, dass die Geräte auch eine lokale
-API anboten, war ein Durchbruch – allerdings einer, der erheblichen
-Reverse-Engineering-Aufwand erforderte.
+Die Kommunikation mit den Smart-Plugs stellte die größte Herausforderung 
+dar. Die TAPO-Geräte boten keine dokumentierte Schnittstelle – nur die 
+proprietäre App konnte sie steuern. Also griff ich zu Wireshark und 
+analysierte den Netzwerkverkehr zwischen App und Steckdosen. Was ich 
+fand, war ernüchternd: verschlüsselte Kommunikation mit sich ständig 
+ändernden Session-Keys.
 
-Hier kam Wireshark ins Spiel. Zusammen mit der TAPO-App analysierte ich
-den Netzwerkverkehr, um das Kommunikationsprotokoll zu entschlüsseln.
-Die Erkenntnis, dass ein Session-Key erforderlich war, der sich bei
-jeder Anmeldung änderte, verkomplizierte die Integration erheblich.
-Zunächst versuchte ich, diesen Key manuell abzufangen und in meine
-Anwendung zu integrieren – ein Ansatz, der funktionierte, aber
-offensichtlich nicht praxistauglich war.
+Mein erster Versuch mit einem vielversprechenden Python-Modul schlug 
+fehl – es funktionierte einfach nicht mit meinen Geräten. Der 
+Wireshark-Mitschnitt offenbarte immer dieselben verschlüsselten 
+Responses. Ohne Erfolg beim Simulieren einzelner Anfragen dämmerte 
+es mir: Die Anfragensequenz musste stimmen! Die Verbindung nutzte 
+temporäre Cookies und proprietäre Verschlüsselung.
 
-Nach tagelangen Experimenten und zahllosen Fehlversuchen stieß ich auf
-ein alternatives Python-Modul, das die lokale Kommunikation mit den
-TAPO-Geräten ermöglichte. Dieses Modul – versteckt in den Tiefen von
-GitHub – löste die Session-Key-Problematik elegant und ermöglichte eine
+Nach tagelangen Experimenten stieß ich auf PyP100 – ein alternatives 
+Python-Modul, versteckt in den Tiefen von GitHub. Dieses Modul löste 
+die Session-Key-Problematik elegant und ermöglichte endlich eine 
 stabile Integration.
 
 ## 2.6 Planung der Prozess-/ und Systemschnittstellen
@@ -582,24 +610,24 @@ iterativen, problemgetriebenen Herangehensweise.
 
 Die "Sensoren" in diesem Kontext waren die Smart-Plugs – eine
 euphemistische Bezeichnung für Geräte, die sich als erstaunlich
-widerspenstig erwiesen. Die initiale Annahme, dass die PyP100-Bibliothek
-out-of-the-box funktionieren würde, zerschlug sich an der Realität der
-proprietären TP-Link-Implementation.
+widerspenstig erwiesen. Meine erste Hoffnung, ein bestehendes 
+Python-Modul zur Steuerung zu finden, zerschlug sich schnell. 
+Das gefundene Modul funktionierte schlicht nicht.
 
-Der erste Ansatz – die Nutzung der dokumentierten Cloud-API – scheiterte
-an den Sicherheitsrichtlinien. Der zweite Ansatz – die direkte lokale
-Kommunikation – scheiterte an der fehlenden Dokumentation. Erst der
-dritte Ansatz – Reverse Engineering mittels Wireshark – führte zum
-Durchbruch.
+Also Plan B: Wireshark. Ich schnitt den Netzwerkverkehr zwischen 
+TAPO-App und Smart-Plugs mit. Die Analyse offenbarte das komplexe
+Authentifizierungsprotokoll der TAPO-Geräte – verschlüsselte 
+Kommunikation mit Session-Tokens, die sich bei jeder Anmeldung 
+änderten. Die Verschlüsselung basierte auf einer Kombination aus 
+RSA und AES. Respektabel für Consumer-Hardware, aber auch verdammt 
+nervig für meine Zwecke.
 
-Die Wireshark-Analyse offenbarte das komplexe
-Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation
-erforderte einen verschlüsselten Handshake, gefolgt von einem
-Session-Token, der für alle weiteren Operationen benötigt wurde. Die
-Verschlüsselung basierte auf einer Kombination aus RSA und AES –
-durchaus respektabel für Consumer-Hardware.
+Nach tagelangen Experimenten stieß ich endlich auf PyP100 – ein 
+Python-Modul, das die lokale Kommunikation mit den TAPO-Geräten 
+tatsächlich beherrschte. Versteckt in den Tiefen von GitHub, löste 
+es die Session-Key-Problematik elegant. Endlich.
 
-Die Implementierung der Datenabfrage erfolgte schließlich über eine
+Die Implementierung der Datenabfrage erfolgte über eine
 selbstentwickelte Wrapper-Klasse, die die Komplexität der Kommunikation
 kapselte. Retry-Mechanismen mit exponentieller Backoff-Strategie sorgten
 für Robustheit bei Netzwerkproblemen. Die Abfrage umfasste nicht nur den
@@ -645,16 +673,19 @@ konsolidieren, vereinfachte nicht nur die Architektur, sondern
 reduzierte auch Kosten und Stromverbrauch.
 
 Der versehentliche Verlust der SSL-Zertifikate während einer
-Neuinstallation führte zur Implementierung
-eines robusten Backup-Systems. Kritische Konfigurationsdateien werden nun dreifach
-gesichert.
+Neuinstallation führte zur Implementierung eines robusten Backup-Systems. 
+Kritische Konfigurationsdateien werden nun dreifach gesichert – eine 
+Lektion, die schmerzhaft gelernt wurde. Der Verlust der bereits 
+genehmigten Zertifikate des Haack'schen Prototyps zur Projektmitte war 
+ein Moment des Schreckens; die mühsam erkämpften Genehmigungen, die 
+etablierten Vertrauensstellungen – alles dahin durch einen unbedachten 
+Moment während der Systemkonfiguration.
 
-Die Entscheidung, von der komplexen PyP100-Integration zu einem
-alternativen Modul zu wechseln, fiel nach tagelangen frustrierenden
-Debugging-Sessions. Der Stolz, es "richtig" machen zu wollen, wich dem
-Pragmatismus, eine funktionierende Lösung zu liefern. Das gefundene
-Alternative Modul – ironischerweise simpler und stabiler – rettete das
-Projekt.
+Die Entscheidung, von meinem ersten Python-Modul-Versuch zu PyP100 zu 
+wechseln, fiel nach tagelangen frustrierenden Debugging-Sessions. Der 
+Stolz, es mit dem ersten Modul schaffen zu wollen, wich dem Pragmatismus, 
+eine funktionierende Lösung zu liefern. PyP100 – ironischerweise simpler 
+und stabiler – rettete das Projekt.
 
 ## 3.3 Maßnahmen zur Qualitätskontrolle
 
@@ -704,7 +735,7 @@ für die Offline-Anforderung.
 Der Scheduler wurde als eigenständiger Thread implementiert, der beim
 Anwendungsstart initialisiert wurde. Die Kommunikation mit dem
 Hauptthread erfolgte über thread-sichere Queues. Diese Architektur
-ermöglichte asynchrone Hardware-Operationen ohne Blockierung der
+ermöglicht asynchrone Hardware-Operationen ohne Blockierung der
 Web-Requests.
 
 ## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur
@@ -721,10 +752,11 @@ erheblich, aber notwendig für die Compliance.
 
 Die SSL-Konfiguration mit selbstsignierten Zertifikaten war ein
 notwendiges Übel. Ohne Internet-Zugang war Let's Encrypt keine Option.
-Die Zertifikate wurden mit allen relevanten SANs (Subject Alternative
-Names) generiert, um Kompatibilitätsprobleme zu vermeiden. Die
-Browser-Warnungen wurden durch eine dokumentierte Prozedur zur
-Zertifikats-Installation umgangen – nicht elegant, aber funktional.
+Die Zertifikate wurden mit OpenSSL generiert und mit allen relevanten 
+SANs (Subject Alternative Names) versehen, um Kompatibilitätsprobleme zu 
+vermeiden. Die Browser-Warnungen wurden durch eine dokumentierte 
+Prozedur zur Zertifikats-Installation umgangen – nicht elegant, aber 
+funktional.
 
 Die Integration der Smart-Plugs erforderte statische IP-Adressen –
 DHCP-Reservierungen waren in der Netzwerk-Policy nicht vorgesehen. Die
@@ -744,11 +776,11 @@ API-Endpunkte wurden systematisch gegen die OWASP Top 10 abgesichert.
 Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX,
 Server-seitig für Sicherheit; Vertrauen ist gut, Kontrolle ist besser.
 
-Die Implementierung eines Rate-Limiters verhinderte
+Die Implementierung eines Rate-Limiters erschwerte
 Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde
 die IP-Adresse für 30 Minuten gesperrt – lang genug, um Angriffe
-unwirtschaftlich zu machen, kurz genug, um legitime Nutzer nicht
-übermäßig zu frustrieren; ein Balanceakt zwischen Sicherheit und
+unattraktiv zu machen, kurz genug, um legitime Nutzer nicht übermäßig zu
+frustrieren; ein Balanceakt zwischen Sicherheit und
 Benutzerfreundlichkeit.
 
 DSGVO-Compliance wurde durch Privacy-by-Design erreicht.
@@ -789,6 +821,24 @@ Energiemonitorings. Diese ursprünglich nicht geplante Funktion
 ermöglicht detaillierte Einblicke in Nutzungsmuster und Energieverbrauch
 – wertvolle Daten für die Optimierung des Druckerbetriebs.
 
+Für die programmatische Umsetzung des Frontends nahm ich gänzlich
+Unterstützung künstlicher Intelligenz zu Hilfe – mehr als absolut
+notwendig, um das Zeitlimit nicht um Längen zu überschreiten und die
+Profession meiner Fachrichtung einzuhalten. Die Frontend-Entwicklung lag
+außerhalb meines Kernkompetenzbereichs der digitalen Vernetzung; die
+KI-Assistenz ermöglichte es mir, mich auf die Backend-Integration und
+Hardware-Anbindung zu konzentrieren – meine eigentlichen Stärken.
+
+Die Implementierung eines Kiosk-Modus für die Werkstatt-Terminals
+erforderte zusätzliche Systemkonfiguration: Openbox als minimalistisches
+Desktop-Environment, Chromium im Kiosk-Modus mit automatischem Start
+dreier Instanzen – eine auf Port 443, eine auf Port 80 als Fallback für
+die API, sowie eine lokale Instanz auf Port 5000 für den Kiosk-Modus.
+Die Mercedes Root-CA-Zertifikate mussten manuell installiert werden; ein
+Shell-Skript automatisierte diesen Prozess, eine systemd-Service-Datei
+gewährleistete den Autostart. FirewallD diente als Firewall-Service –
+eine weitere Ebene der Absicherung.
+
 Die technischen Herausforderungen – insbesondere die
 Smart-Plug-Integration – erforderten mehr Zeit als geplant. Die
 investierte Mühe zahlte sich jedoch aus: Die finale Lösung ist robuster
@@ -889,17 +939,3 @@ chaotisch zu strukturiert, von manuell zu automatisiert ist vollbracht.
 Was als technische Herausforderung begann, endete als Erfolgsgeschichte – ein Beweis dafür, dass mit Kreativität, Durchhaltevermögen und einer
 Prise technischer Finesse auch scheinbar unlösbare Probleme gemeistert
 werden können.
-
-# Anlagen
-
-## Netzwerkdiagramme und Systemarchitektur
-
-## API-Dokumentation
-
-## Benutzerhandbuch
-
-## Testprotokolle
-
-## Screenshots der Benutzeroberfläche
-
-## Konfigurationsdateien und Deployment-Skripte