📝 "Update IHK project documentation with Gitmoji emojis in setup.sh" 🌟

IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md

@@ -279,22 +279,19 @@ mit der bestehenden Netzwerkinfrastruktur der TBA harmonieren, ohne
 dabei Sicherheitsrichtlinien zu verletzen. Die Schnittstelle zur
 IT-Abteilung erwies sich als besonders kritisch, da jede
 Netzwerkkonfiguration und jede Port-Freischaltung einer expliziten
-Genehmigung bedurfte – ein bürokratischer Tanz, der Fingerspitzengefühl
-erforderte.
+Genehmigung bedurfte.
 
 Die Benutzerschnittstelle musste so gestaltet werden, dass sowohl
 technisch versierte Auszubildende als auch weniger IT-affine Nutzer das
 System intuitiv bedienen können. Dies erforderte eine Balance zwischen
-Funktionsumfang und Benutzerfreundlichkeit – eine Balance, die nicht
-immer leicht zu finden war, aber letztendlich gelang.
+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
-erstaunlich naiv. Die proprietäre API der Geräte war nicht nur
-undokumentiert, sondern geradezu verschleiert – ein Umstand, der
-erheblichen Reverse-Engineering-Aufwand erforderte und mich in die
-Tiefen der Netzwerkanalyse führte.
+naiv. Die proprietäre API der Geräte war nicht nur
+undokumentiert, sondern verschleiert – ein Umstand, der
+erheblichen Reverse-Engineering-Aufwand erforderte.
 
 ## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen
 
@@ -327,8 +324,7 @@ 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
-– ein digitales Potemkinsches Dorf, wenn man so will.
+einem Entwicklungsserver, 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
@@ -342,8 +338,7 @@ 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; eine Lösung, die in
-ihrer Simplizität genial war.
+technischer Machbarkeit und praktischem Nutzen dar.
 
 # 2. Projektplanung
 
@@ -351,7 +346,7 @@ ihrer Simplizität genial war.
 
 Die Projektplanung folgte einem agilen Ansatz nach Scrum-Prinzipien –
 eine Entscheidung, die sich angesichts der zahlreichen Unwägbarkeiten
-als goldrichtig erweisen sollte. Die Gesamtprojektdauer von fünf Wochen
+als richtig erweisen sollte. Die Gesamtprojektdauer von fünf Wochen
 (15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints
 unterteilt, wobei jeder Sprint seine eigenen Herausforderungen und
 – ja – auch Überraschungen bereithielt.
@@ -372,12 +367,11 @@ Vorhaben, das zunächst kläglich scheiterte.
 
 Im zweiten Sprint lag der Fokus auf dem Aufbau der
 Backend-Infrastruktur. Die Beantragung der erforderlichen
-Administratorrechte erwies sich als bürokratischer Marathon durch die
-Instanzen der Mercedes-Benz AG. Parallel dazu begannen die ersten
-Experimente mit Wireshark, um das Kommunikationsprotokoll der
-Smart-Plugs zu entschlüsseln – eine Notwendigkeit, die sich aus der
-mangelhaften Dokumentation der PyP100-Bibliothek ergab und mich in die
-Rolle eines digitalen Detektivs drängte.
+Administratorrechte erwies sich als zeitaufwändiger als erwartet. 
+Parallel dazu begannen die ersten Experimente mit Wireshark, um das 
+Kommunikationsprotokoll der Smart-Plugs zu entschlüsseln – eine 
+Notwendigkeit, die sich aus der mangelhaften Dokumentation der 
+PyP100-Bibliothek ergab.
 
 ### Sprint 3 (29. April - 3. Mai 2025)
 
@@ -385,8 +379,7 @@ Der dritte Sprint sollte die Integration von Frontend und Backend
 realisieren. Stattdessen mutierte er zu einer Woche der technischen
 Herausforderungen: Die Verbindung zwischen den Komponenten scheiterte
 wiederholt, die genehmigten SSL-Zertifikate gingen durch einen
-unglücklichen Neuinstallationsprozess verloren (ein Moment, der mich
-die Wichtigkeit von Backups lehrte), und die Einarbeitung in die
+unglücklichen Neuinstallationsprozess verloren, und die Einarbeitung in die
 unternehmensspezifischen Implementierungen von GitHub OAuth und npm
 verschlang wertvolle Zeit.
 
@@ -394,18 +387,16 @@ verschlang wertvolle Zeit.
 
 Ursprünglich für Optimierungen vorgesehen, wandelte sich dieser Sprint
 zur Rettungsmission. Der Zeitdruck erzwang pragmatische Entscheidungen
-und die Konzentration auf essenzielle Funktionen. In marathonartigen
+und die Konzentration auf essenzielle Funktionen. In intensiven
 Coding-Sessions wurde die Grundfunktionalität implementiert – nicht
-unbedingt elegant, aber funktional; ein klassischer Fall von "done is
-better than perfect".
+unbedingt elegant, aber funktional.
 
 ### Sprint 5 (13.-17. Mai 2025)
 
 Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung.
 Die ursprünglich geplanten Schulungen fielen dem Zeitdruck zum Opfer.
-Stattdessen wurde fieberhaft an kritischen Bugfixes gearbeitet und die
-Projektdokumentation erstellt – letztere teilweise in nächtlichen
-Sessions, begleitet von übermäßigem Koffeinkonsum.
+Stattdessen wurde an kritischen Bugfixes gearbeitet und die
+Projektdokumentation erstellt.
 
 ## 2.2 Ressourcenplanung
 
@@ -417,8 +408,7 @@ ausgewählt.
 Als zentrale Serverplattform diente zunächst ein Raspberry Pi 4 mit 4 GB
 RAM – eine Entscheidung, die sich schnell als Fehlkalkulation
 herausstellte. Performance-Tests zeigten, dass das ressourcenhungrige
-Next.js-Frontend die kleine Platine an ihre Grenzen brachte; ein
-digitaler David gegen Goliath, nur dass David diesmal unterlag. Der
+Next.js-Frontend die kleine Platine an ihre Grenzen brachte. Der
 kurzfristige Wechsel auf einen Raspberry Pi 5 mit 8 GB RAM und 128 GB
 Speicher löste die Performance-Probleme, verursachte aber zusätzliche
 Kosten und – was schwerer wog – Zeitverzug.
@@ -449,26 +439,22 @@ sich als Segen erwies.
 
 ## 2.3 Planung der Qualitätssicherung
 
-Das Qualitätssicherungskonzept orientierte sich am V-Modell – eine
-klassische, aber bewährte Herangehensweise. Für jede Entwicklungsphase
-wurden korrespondierende Testaktivitäten definiert, wobei die Realität
-diese saubere Trennung oft genug konterkarierte.
+Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede 
+Entwicklungsphase wurden korrespondierende Testaktivitäten definiert.
 
 Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert
 getestet. Die Datenbankoperationen, API-Eingabevalidierung und
 Kernfunktionen der Reservierungsverwaltung durchliefen umfangreiche
 Testszenarien. Besondere Aufmerksamkeit galt der
 Smart-Plug-Kommunikation, für die spezielle Testfälle entwickelt wurden
-– einschließlich simulierter Netzwerkausfälle und Timeout-Situationen;
-Szenarien, die sich später als prophetisch erweisen sollten.
+– einschließlich simulierter Netzwerkausfälle und Timeout-Situationen.
 
 Die Integrationstests gestalteten sich komplexer als erwartet. Das
 Zusammenspiel zwischen Backend und Smart-Plugs erwies sich als
 fehleranfällig, insbesondere bei gleichzeitigen Zugriffen. Die
 systematischen Tests mit verschiedenen Eingabedaten – einschließlich
 bewusst invalider und potenziell schädlicher Inputs – deckten mehrere
-Sicherheitslücken auf, die nachträglich geschlossen werden mussten; ein
-demütigender, aber lehrreicher Prozess.
+Sicherheitslücken auf, die nachträglich geschlossen werden mussten.
 
 Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer
 Testfall umfasste die Benutzeranmeldung, Reservierungserstellung,
@@ -489,16 +475,14 @@ Die IT-Landschaft der TBA präsentierte sich als bunter Flickenteppich
 verschiedenster Technologien und Standards. Die 3D-Drucker stammten von
 unterschiedlichen Herstellern mit inkompatiblen Steuerungssystemen. Das
 Netzwerk war in multiple VLANs segmentiert, wobei die Dokumentation
-dieser Struktur bestenfalls als lückenhaft bezeichnet werden konnte –
-ein digitales Labyrinth ohne Ariadnefaden.
+dieser Struktur bestenfalls als lückenhaft bezeichnet werden konnte.
 
 Die Herausforderung bestand darin, eine einheitliche Lösung für diese
 heterogene Umgebung zu entwickeln. Der Ansatz über Smart-Plugs erwies
 sich hier als Glücksgriff – er abstrahierte die Unterschiede zwischen
 den Druckern auf die simpelste mögliche Ebene: Strom an oder aus. Diese
 radikale Vereinfachung ermöglichte eine universelle Lösung, die
-unabhängig vom Druckermodell funktionierte; ein Paradebeispiel für das
-KISS-Prinzip in Aktion.
+unabhängig vom Druckermodell funktionierte.
 
 Die Integration in die bestehende Netzwerkinfrastruktur erforderte
 diplomatisches Geschick. Die IT-Abteilung bestand auf strikter
@@ -513,8 +497,7 @@ Die Auswahl der Übertragungssysteme wurde maßgeblich durch die
 Sicherheitsanforderungen bestimmt. Cloud-basierte Lösungen schieden
 kategorisch aus, was die Optionen erheblich einschränkte. Die
 Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten
-Zertifikaten war pragmatisch, aber effektiv – eine Notlösung, die zur
-Dauerlösung wurde.
+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
@@ -523,21 +506,19 @@ Sicherheitsrichtlinien. Die Entdeckung, dass die Geräte auch eine lokale
 API anboten, war ein Durchbruch – allerdings einer, der erheblichen
 Reverse-Engineering-Aufwand erforderte.
 
-Hier kam Wireshark ins Spiel; mein digitales Stethoskop, wenn man so
-will. 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.
+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.
 
 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
-stabile Integration; ein Fund, der mich vor Freude fast hätte tanzen
-lassen.
+stabile Integration.
 
 ## 2.6 Planung der Prozess-/ und Systemschnittstellen
 
@@ -568,37 +549,34 @@ Eleganz bestach.
 Die Sicherheitsplanung folgte dem Prinzip "Security by Design" – ein
 Ansatz, der sich angesichts der sensiblen Umgebung als unerlässlich
 erwies. Jede Komponente wurde von Anfang an mit Sicherheit im Hinterkopf
-entwickelt; Paranoia als Tugend, wenn man so will.
+entwickelt.
 
 Die Authentifizierung basierte auf bcrypt mit einem Cost-Faktor von 12 –
 ein Kompromiss zwischen Sicherheit und Performance auf dem Raspberry Pi.
 Session-Management wurde über Flask-Login realisiert, mit
 konfigurierbaren Timeout-Werten und sicheren Session-Cookies. Die
 Implementierung einer Brute-Force-Protection mit exponentieller
-Backoff-Strategie verhinderte automatisierte Angriffe; ein digitaler
-Türsteher, der keine Kompromisse kannte.
+Backoff-Strategie verhinderte automatisierte Angriffe.
 
 Auf Netzwerkebene wurden restriktive Firewall-Regeln implementiert. Nur
 essenzielle Ports wurden geöffnet, ausgehende Verbindungen auf die
 IP-Adressen der Smart-Plugs beschränkt. Die Verwendung von iptables
-ermöglichte granulare Kontrolle über den Netzwerkverkehr – eine
-Festung aus Bits und Bytes.
+ermöglichte granulare Kontrolle über den Netzwerkverkehr.
 
 Die API-Sicherheit umfasste Input-Validation, Output-Encoding und
 CSRF-Protection. Jeder Endpunkt wurde gegen die OWASP Top 10
 abgesichert. Ein selbstentwickeltes Intrusion Detection System
 überwachte verdächtige Aktivitäten und sperrte bei Bedarf IP-Adressen
-temporär – Big Brother im Dienste der Sicherheit.
+temporär.
 
 # 3. Durchführung und Auftragsbearbeitung
 
 ## 3.1 Prozess-Schritte und Vorgehensweise
 
-Die Durchführung des Projekts glich einer technischen Odyssee, gespickt
-mit unerwarteten Wendungen und kreativen Lösungsansätzen. Die
+Die Durchführung des Projekts glich einer technischen Expedition mit
+unerwarteten Wendungen und kreativen Lösungsansätzen. Die
 ursprünglich geplante lineare Vorgehensweise wich schnell einer
-iterativen, problemgetriebenen Herangehensweise – Agilität nicht als
-Methode, sondern als Überlebensstrategie.
+iterativen, problemgetriebenen Herangehensweise.
 
 ### 3.1.1 Datenabfrage der Sensoren
 
@@ -612,7 +590,7 @@ 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; ein Prozess, der mich die Kunst der Paketanalyse lehrte.
+Durchbruch.
 
 Die Wireshark-Analyse offenbarte das komplexe
 Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation
@@ -636,13 +614,13 @@ Scheduler-Thread prüfte im Minutentakt die Datenbank auf anstehende
 Aktionen und triggerte entsprechende Smart-Plug-Operationen. Die
 Herausforderung bestand darin, die Asynchronität der
 Hardware-Operationen mit der Synchronität der Datenbankzugriffe zu
-vereinen – ein Tanz zwischen zwei Welten.
+vereinen.
 
 Die Lösung war ein Queue-basiertes System, das Kommandos pufferte und
 sequenziell abarbeitete. Dies verhinderte Race Conditions bei simultanen
 Zugriffen und gewährleistete die Konsistenz der Systemzustände. Jede
 Operation wurde in einer Transaktion gekapselt, mit Rollback-Mechanismen
-bei Fehlern – Atomarität als oberstes Gebot.
+bei Fehlern.
 
 Die Verarbeitung der Energiedaten ermöglichte interessante Einblicke in
 die Nutzungsmuster. Anomalien – wie ungewöhnlich hoher Stromverbrauch –
@@ -655,44 +633,40 @@ ein glücklicher Zufall, der zur Kernfunktionalität wurde.
 Die Projektdurchführung war geprägt von kontinuierlichen Anpassungen an
 die Realität. Die größte Abweichung vom ursprünglichen Plan war der
 Wechsel der Systemarchitektur von einer verteilten zu einer
-konsolidierten Lösung – eine Entscheidung, die aus der Not geboren
-wurde.
+konsolidierten Lösung.
 
 Ursprünglich war geplant, dass ich nur die API entwickle und diese mit
 Torbens Frontend auf einem separaten Raspberry Pi verknüpfe. Diese
 Architektur erwies sich als zu komplex – die unterschiedlichen
 Technologie-Stacks (Next.js vs. Python/Flask) und die
-Netzwerksegmentierung machten die Integration zum Albtraum. Die
+Netzwerksegmentierung machten die Integration schwierig. Die
 Entscheidung, beide Komponenten auf einem einzigen Raspberry Pi zu
 konsolidieren, vereinfachte nicht nur die Architektur, sondern
-reduzierte auch Kosten und Stromverbrauch; manchmal ist weniger
-tatsächlich mehr.
+reduzierte auch Kosten und Stromverbrauch.
 
 Der versehentliche Verlust der SSL-Zertifikate während einer
-Neuinstallation – ein Moment des Schreckens – führte zur Implementierung
-eines robusten Backup-Systems. Die Lektion war schmerzhaft, aber
-lehrreich: Kritische Konfigurationsdateien werden nun dreifach
-gesichert; Paranoia als Versicherung.
+Neuinstallation führte zur Implementierung
+eines robusten Backup-Systems. Kritische Konfigurationsdateien werden nun dreifach
+gesichert.
 
 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; ein Beweis dafür, dass der einfachste Weg oft der beste ist.
+Projekt.
 
 ## 3.3 Maßnahmen zur Qualitätskontrolle
 
 Die Qualitätskontrolle erfolgte kontinuierlich und vielschichtig.
 Automatisierte Tests liefen bei jedem Commit, manuelle Tests ergänzten
 diese bei kritischen Funktionen. Die Herausforderung bestand darin, die
-Hardware-abhängigen Komponenten testbar zu machen – ein Problem, das
-kreative Lösungen erforderte.
+Hardware-abhängigen Komponenten testbar zu machen.
 
 Mock-Objekte simulierten die Smart-Plugs für Unit-Tests. Diese Mocks
 replizierten das Verhalten der echten Hardware, einschließlich typischer
 Fehlerszenarien wie Timeouts oder Verbindungsabbrüche. Die Test-Coverage
-erreichte respektable 85% – die fehlenden 15% waren hauptsächlich
+erreichte 85% – die fehlenden 15% waren hauptsächlich
 UI-Code und Error-Handler, deren Test-Aufwand in keinem vernünftigen
 Verhältnis zum Nutzen stand.
 
@@ -700,13 +674,12 @@ Integrationstests mit echter Hardware deckten Probleme auf, die in der
 Simulation nicht auftraten. Timing-Issues bei simultanen Zugriffen,
 Memory-Leaks bei lang laufenden Operationen, Race Conditions im
 Scheduler – all diese Probleme wurden iterativ identifiziert und
-behoben; ein Prozess, der Geduld und Durchhaltevermögen erforderte.
+behoben.
 
 Die Implementierung eines Logging-Systems erwies sich als unschätzbar
 wertvoll. Jede Operation, jeder Fehler, jede Anomalie wurde
 protokolliert. Die Log-Analyse wurde zum wichtigsten Debugging-Tool,
-insbesondere bei sporadisch auftretenden Problemen – digitale Forensik
-im Kleinen.
+insbesondere bei sporadisch auftretenden Problemen.
 
 ## 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme
 
@@ -714,41 +687,37 @@ Die Implementierung der verschiedenen Schnittstellen erfolgte modular
 und iterativ. Die REST-API wurde Blueprint-basiert strukturiert, was
 eine klare Trennung der Funktionsbereiche ermöglichte. Authentication,
 User Management, Printer Management und Job Management erhielten jeweils
-eigene Blueprints – eine Architektur, die Ordnung ins Chaos brachte.
+eigene Blueprints.
 
 Die Smart-Plug-Schnittstelle durchlief mehrere Iterationen. Die finale
 Implementation kapselte die gesamte Kommunikationslogik in einer
 einzigen Klasse, die eine simple API bot: turn_on(), turn_off(),
 get_status(). Diese Abstraktion verbarg die Komplexität des
-darunterliegenden Protokolls und ermöglichte einfache Erweiterungen –
-Simplizität als Designprinzip.
+darunterliegenden Protokolls und ermöglichte einfache Erweiterungen.
 
 Die Datenbank-Schnittstelle nutzte SQLAlchemy's ORM-Funktionalität. Die
 Definition der Models erfolgte deklarativ, Migrationen wurden über
 Alembic verwaltet. Die Entscheidung für SQLite als Datenbank war
 pragmatisch – keine zusätzlichen Services, keine Konfiguration, perfekt
-für die Offline-Anforderung; manchmal ist die einfachste Lösung die
-beste.
+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
-Web-Requests – Parallelität ohne Kopfschmerzen.
+Web-Requests.
 
 ## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur
 
 Die Integration in die Mercedes-Benz-Infrastruktur erforderte zahlreiche
 Kompromisse und kreative Lösungen. Das dedizierte IoT-Subnetz wurde
 speziell für das MYP-System eingerichtet, mit restriktiven
-Firewall-Regeln und ohne Internet-Zugang – eine digitale Quarantäne, die
-Sicherheit gewährleistete.
+Firewall-Regeln und ohne Internet-Zugang.
 
 Die Netzwerkkonfiguration erfolgte in enger Abstimmung mit der
 IT-Abteilung. Jede Änderung erforderte ein Change-Request, jede
 Port-Öffnung eine Security-Review. Der bürokratische Overhead war
-erheblich, aber notwendig für die Compliance – ein notwendiges Übel im
-Konzernumfeld.
+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.
@@ -767,7 +736,7 @@ stabile Verbindungen; manchmal ist der steinige Weg der sicherste.
 Die Informationssicherheit wurde von Anfang an als kritischer
 Erfolgsfaktor behandelt. Jede Designentscheidung wurde durch die
 Sicherheitsbrille betrachtet, jede Implementierung auf Schwachstellen
-geprüft – Security als Religion, nicht als Afterthought.
+geprüft.
 
 Die Authentifizierung implementierte moderne Best Practices:
 bcrypt-Hashing, sichere Session-Verwaltung, CSRF-Protection. Die
@@ -796,8 +765,7 @@ Der Vergleich zwischen geplanten und erreichten Zielen offenbart ein
 gemischtes, aber letztendlich positives Bild. Die Kernfunktionalität –
 digitale Reservierungsverwaltung mit automatischer Hardware-Steuerung –
 wurde vollständig implementiert und übertraf in einigen Aspekten sogar
-die ursprünglichen Anforderungen; ein Erfolg, der süßer schmeckt, weil
-er hart erkämpft wurde.
+die ursprünglichen Anforderungen.
 
 #### Erfolgreich umgesetzte Anforderungen:
 
@@ -819,14 +787,13 @@ er hart erkämpft wurde.
 Die größte positive Überraschung war die erfolgreiche Integration des
 Energiemonitorings. Diese ursprünglich nicht geplante Funktion
 ermöglicht detaillierte Einblicke in Nutzungsmuster und Energieverbrauch
-– wertvolle Daten für die Optimierung des Druckerbetriebs; ein Feature,
-das aus der Not geboren wurde und zum Alleinstellungsmerkmal avancierte.
+– wertvolle Daten für die Optimierung des Druckerbetriebs.
 
 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
 und wartungsfreundlicher als eine Quick-and-Dirty-Implementation gewesen
-wäre; Qualität setzt sich durch, auch wenn der Weg steinig ist.
+wäre.
 
 ## 4.2 Fazit
 
@@ -835,28 +802,25 @@ und technisches Geschick aus scheinbar unüberwindbaren Hindernissen
 elegante Lösungen entstehen können. Die Transformation eines analogen
 Whiteboards in ein modernes cyber-physisches System mag auf den ersten
 Blick trivial erscheinen – die Umsetzung offenbarte jedoch die volle
-Komplexität vernetzter Systeme; ein Eisberg, dessen Spitze täuscht.
+Komplexität vernetzter Systeme.
 
 Die Entscheidung, die fehlenden Schnittstellen der 3D-Drucker durch
 Smart-Plugs zu überbrücken, erwies sich als Glücksgriff. Diese
 Abstraktion auf die grundlegendste Ebene – Stromversorgung – ermöglichte
 eine universelle Lösung, die unabhängig von Druckermodell oder
-Hersteller funktioniert. Ein klassisches Beispiel für laterales Denken,
-das komplexe Probleme durch Perspektivwechsel löst.
+Hersteller funktioniert.
 
 Die technische Exzellenz des Systems zeigt sich in den Details: Über
 9.000 Zeilen sauber strukturierter Python-Code, eine umfassende
 REST-API, robuste Fehlerbehandlung, durchdachte Sicherheitsarchitektur.
 Doch der wahre Erfolg liegt in der Praxistauglichkeit – das System läuft
-stabil, wird aktiv genutzt und hat das manuelle Chaos endgültig beendet;
-ein digitaler Phönix, der aus der Asche des Whiteboards aufstieg.
+stabil, wird aktiv genutzt und hat das manuelle Chaos endgültig beendet.
 
 Persönlich war das Projekt eine Achterbahnfahrt der Emotionen. Von der
 anfänglichen Euphorie über die frustrierenden Debugging-Sessions bis zum
 finalen Triumph – jede Phase bot Lernerfahrungen. Die Fähigkeit, unter
 Zeitdruck pragmatische Entscheidungen zu treffen, ohne dabei die
-Qualität zu kompromittieren, war die wichtigste erworbene Kompetenz; eine
-Lektion, die über das Projekt hinaus Bestand haben wird.
+Qualität zu kompromittieren, war die wichtigste erworbene Kompetenz.
 
 ## 4.3 Optimierungsmöglichkeiten
 
@@ -889,7 +853,7 @@ die Möglichkeiten sind grenzenlos.
 Die formale Projektabnahme erfolgte am 2. Juni 2025 durch die
 Ausbildungsleitung der TBA. Die Präsentation umfasste eine
 Live-Demonstration aller Kernfunktionen sowie eine technische
-Deep-Dive-Session für interessierte Kollegen – ein Moment der Wahrheit.
+Deep-Dive-Session für interessierte Kollegen.
 
 Die Live-Demonstration begann mit einem kleinen Missverständnis: Das
 System war noch nicht vollständig produktiv aufgebaut, da letzte
@@ -898,8 +862,7 @@ zeigte sich die wahre Stärke der Architektur – dank der robusten
 Systemkonzeption konnte ich aus dem Stegreif improvisieren und das
 System dennoch eindrucksvoll demonstrieren. Die automatische Aktivierung
 eines 3D-Druckers zur reservierten Zeit funktionierte einwandfrei und
-löste sichtbare Begeisterung aus; ein Moment, der die monatelange Arbeit
-rechtfertigte.
+löste sichtbare Begeisterung aus.
 
 Besonders positiv wurde die Wirtschaftlichkeit der Lösung bewertet. Mit
 Gesamtkosten unter 600 Euro (inklusive privat finanzierter Komponenten)
@@ -923,8 +886,7 @@ moderner Software-Entwicklung.
 
 Die Transformation der 3D-Drucker-Verwaltung von analog zu digital, von
 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
+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.
 

backend/setup.sh

@@ -1206,86 +1206,33 @@ EOF
         debug "Raspberry Pi Optimierungen zur sysctl-Konfiguration hinzugefügt"
     fi
     
-    # Sysctl-Einstellungen vorsichtig anwenden (non-blocking)
-    progress "Wende sysctl-Einstellungen an (non-blocking)..."
+    # OPTIONAL: Sysctl-Einstellungen anwenden (kann übersprungen werden)
+    progress "OPTIONAL: Versuche sysctl-Einstellungen anzuwenden..."
     
-    # Teste unsere spezielle sysctl-Datei zuerst (mit mehreren Fallbacks)
-    if [ -f "$myp_sysctl_file" ]; then
-        local sysctl_success=false
-        
-        # Strategie 1: Komplette Datei mit Timeout anwenden
-        progress "Versuche komplette sysctl-Datei anzuwenden..."
-        if timeout 10 sysctl -p "$myp_sysctl_file" >/dev/null 2>&1; then
-            success "✅ MYP sysctl-Einstellungen erfolgreich angewendet"
-            sysctl_success=true
-        else
-            warning "⚠️ Komplette sysctl-Datei fehlgeschlagen"
-            debug "sysctl -p $myp_sysctl_file Fehlerausgabe: $(timeout 5 sysctl -p "$myp_sysctl_file" 2>&1 || echo 'Timeout oder Fehler')"
-        fi
-        
-        # Strategie 2: Nur IPv6-Deaktivierung (kritisch)
-        if [ "$sysctl_success" = false ]; then
-            progress "Versuche nur IPv6-Deaktivierung..."
-            local ipv6_settings=(
-                "net.ipv6.conf.all.disable_ipv6=1"
-                "net.ipv6.conf.default.disable_ipv6=1"
-            )
-            
-            local ipv6_applied=0
-            for setting in "${ipv6_settings[@]}"; do
-                if timeout 3 sysctl -w "$setting" >/dev/null 2>&1; then
-                    ((ipv6_applied++))
-                    debug "IPv6-Setting angewendet: $setting"
-                else
-                    debug "IPv6-Setting fehlgeschlagen: $setting"
-                fi
-            done
-            
-            if [ $ipv6_applied -gt 0 ]; then
-                success "✅ IPv6-Deaktivierung teilweise erfolgreich ($ipv6_applied/2)"
-                sysctl_success=true
-            fi
-        fi
-        
-        # Strategie 3: Sicherheits-Grundeinstellungen
-        if [ "$sysctl_success" = false ]; then
-            progress "Versuche Basis-Sicherheitseinstellungen..."
-            local security_settings=(
-                "net.ipv4.ip_forward=0"
-                "net.ipv4.tcp_syncookies=1"
-            )
-            
-            local security_applied=0
-            for setting in "${security_settings[@]}"; do
-                if timeout 3 sysctl -w "$setting" >/dev/null 2>&1; then
-                    ((security_applied++))
-                    debug "Sicherheits-Setting angewendet: $setting"
-                else
-                    debug "Sicherheits-Setting fehlgeschlagen: $setting"
-                fi
-            done
-            
-            if [ $security_applied -gt 0 ]; then
-                success "✅ Basis-Sicherheitseinstellungen angewendet ($security_applied/2)"
-                sysctl_success=true
-            fi
-        fi
-        
-        # Strategie 4: Vollständig überspringen (Graceful Degradation)
-        if [ "$sysctl_success" = false ]; then
-            warning "⚠️ Alle sysctl-Anwendungen fehlgeschlagen"
-            warning "⚠️ Einstellungen werden beim nächsten Neustart automatisch aktiv"
-            info "   📁 Konfiguration verfügbar in: $myp_sysctl_file"
-            info "   🔧 Manuelle Anwendung: sudo sysctl -p $myp_sysctl_file"
-            debug "Sysctl komplett übersprungen - System läuft mit Standard-Einstellungen"
-        fi
-    else
-        warning "⚠️ MYP sysctl-Konfigurationsdatei nicht gefunden"
-        debug "Überspringe sysctl-Anwendung komplett"
+    # Umgebungsvariable zum Überspringen
+    if [ "${SKIP_SYSCTL:-0}" = "1" ]; then
+        warning "⚠️ SKIP_SYSCTL gesetzt - überspringe sysctl komplett"
+        info "   → Einstellungen werden beim nächsten Neustart aktiv"
+        return
     fi
     
-    # Niemals das System-weite sysctl -p ausführen (zu problematisch)
-    debug "Überspringe system-weites sysctl -p (zu riskant)"
+    # Sehr kurzer Test mit sofortigem Fallback
+    if [ -f "$myp_sysctl_file" ]; then
+        # Nur 5 Sekunden für sysctl versuchen
+        if timeout 5 sysctl -p "$myp_sysctl_file" >/dev/null 2>&1; then
+            success "✅ MYP sysctl-Einstellungen angewendet"
+        else
+            warning "⚠️ Sysctl-Anwendung übersprungen (Timeout oder Fehler)"
+            info "   → Konfiguration gespeichert in: $myp_sysctl_file"
+            info "   → Wird beim nächsten Neustart automatisch aktiv"
+            debug "Sysctl nach 5s abgebrochen - keine Blockierung"
+        fi
+    else
+        debug "Sysctl-Datei nicht gefunden - überspringe"
+    fi
+    
+    # Sofort weitermachen - keine weiteren Versuche
+    debug "Sysctl-Phase abgeschlossen - fahre mit Installation fort"
     
     # IPv6 in Netzwerk-Interfaces deaktivieren (robust)
     progress "Deaktiviere IPv6 in Netzwerk-Interfaces (vorsichtig)..."