diff --git a/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md b/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md index ad3c3d6d..227dd1b9 100644 --- a/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md +++ b/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. diff --git a/backend/setup.sh b/backend/setup.sh index 48821088..6dca88bc 100755 --- a/backend/setup.sh +++ b/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)..."