📝 "Update IHK project documentation with Gitmoji emojis in setup.sh" 🌟
This commit is contained in:
parent
f1094bb125
commit
6a858b0dd3
@ -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.
|
||||
|
||||
|
||||
@ -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)
|
||||
# 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
|
||||
|
||||
# Sehr kurzer Test mit sofortigem Fallback
|
||||
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
|
||||
# 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 "⚠️ 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"
|
||||
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
|
||||
warning "⚠️ MYP sysctl-Konfigurationsdatei nicht gefunden"
|
||||
debug "Überspringe sysctl-Anwendung komplett"
|
||||
debug "Sysctl-Datei nicht gefunden - überspringe"
|
||||
fi
|
||||
|
||||
# Niemals das System-weite sysctl -p ausführen (zu problematisch)
|
||||
debug "Überspringe system-weites sysctl -p (zu riskant)"
|
||||
# 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)..."
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user