Tja... Der neue YADS-Installer: Ein Glas voller Probleme
Tja... wer hätte gedacht, dass ein einfacher Installer so viel Kopfschmerzen bereiten kann? Ich jedenfalls nicht. Aber hey... so ist das eben, wenn man meint, man müsste das Ganze "modern" und "hübsch" machen. ;-)
Ehrlicherweise war der alte Installer... naja... zweckmäßig. Ein paar Shell-Skripte, viel Hoffen und Beten, dass der User weiß, was er tut. Damit ist jetzt Schluss. Wir haben (fast) alles auf links gedreht. Und während ich das hier schreibe, sitze ich immer noch vor dem Code und frage mich, warum ich mir das eigentlich antue. Aber der Reihe nach... wir wollen ja ehrlich bleiben.
🏗️ Das neue "Glass" Design: Hübsch, aber zickig
Ich wollte etwas, das nach 2026 aussieht. Weg von diesen tristen, grauen Boxen. Also PySide6 geschnappt und ein bisschen mit qfluentwidgets rumgespielt. Das Ziel: Ein "Glassmorphism" Design mit Mica-Effekt.
Der erste Schritt: Alles sieht noch friedlich aus.
Das Problem? Was unter Windows 11 super schick mit transparentem Hintergrund und Frosting-Effekt aussieht, bricht einem unter Linux oder Mac einfach das Genick. Entweder ist der Hintergrund schwarz, oder die Transparenz zieht so viel CPU, dass der Lüfter denkt, er wäre eine Jet-Turbine.
Ich hab Stunden damit verbracht, die Stylesheets so zu biegen, dass sie "gnädig" degradieren. Wenn Mica nicht geht, dann halt simpler Dark-Mode. Wenn der User kein Composite-Window-Manager hat, dann halt solide Flächen. Klingt logisch, ist aber in PySide6 ein echtes Gefummel, weil man die Windows-API oder die X11-Eigenschaften teilweise direkt anfassen muss. Und das alles für ein Tool, das man eigentlich nur einmal im Monat sieht. Aber hey... der erste Eindruck zählt, oder? ;)
🕵️ Dependency-Hölle: "Ist Docker da?" ist keine einfache Frage
Bevor wir überhaupt anfangen können, muss das System gecheckt werden. Klingt trivial: docker --version. Fertig. Tja... schön wär's.
Einer der Punkte ist immer rot. Immer.
In der Realität müssen wir wissen: Läuft der Daemon? Hat der aktuelle User überhaupt die Berechtigungen, docker compose auszuführen, ohne sudo zu benutzen? (Ein Klassiker in Enterprise-Umgebungen). Ist genug Speicherplatz auf der Partition von /var/lib/docker?
Ich hab im Installer jetzt einen kompletten Diagnose-Lauf eingebaut. Der prüft nicht nur, ob die Binaries da sind, sondern auch, ob die Versionen zueinander passen. Wenn Docker 20.x auf ein Compose V1 trifft, fliegen bei YADS im Backend später die Exceptions. Also: Harte Checks. Tut weh, spart uns im Support aber massiv Zeit. Und glaubt mir, ich HASSE langweilige Support-Tickets wie "Docker geht nicht".
🌐 Die Proxy-Saga: ZScaler lässt grüßen (The Enterprise Endboss)
Das hier ist mein persönlicher Endgegner. Wer YADS in einem Enterprise-Umfeld betreiben will, landet unweigerlich hinter einem Proxy. Und wir reden hier nicht von einem freundlichen kleinen Squid, sondern von den dicken Brocken wie ZScaler.
Hier konfigurieren wir die Welt... theoretisch.
Wisst ihr, was richtig spaßig ist? Dass gefühlt jedes zweite Security-Tool seine eigenen Vorstellungen davon hat, wie es Proxy-Settings liest. Playwright? Will eine eigene Config. Nuclei? Ignoriert HTTPS_PROXY manchmal gepflegt, wenn es um das Laden von Templates geht. Raw DNS Queries? Gehen natürlich gar nicht durch den Proxy.
Ich hab dazu massenweise nifos (Netz-Infos / Notes) in den Projekten hinterlassen. Die Strategie ist jetzt: Wir forcieren Proxy-Support auf jeder Ebene. Der Installer sammelt die Daten ein (Host, Port, User, Pass) und schreibt sie in jede verdammte .env, Config-XML oder NGINX-Vorlage, die YADS braucht. Wenn der User hier einen Fehler macht, bricht der Installer zwar nicht sofort ab, aber der Health-Check am Ende wird rot wie eine Ampel in der Rush-Hour.
🔐 Datenbank, Secrets & BSI-Paranoia
Früher haben wir oft Default-Passwörter benutzt. Schande über mein Haupt. Aber YADS ist ein Security-Tool. Wir können nicht "Admin/Admin" als Standard lassen.
Konfigurieren der Innereien.
Passwörter sind auch so eine Sache. Ich hab mich an die BSI-Empfehlungen gehalten. 12 Zeichen, Mix aus allem. Der Installer prüft das jetzt in Echtzeit.
Wer hier 'password123' eintippt, bekommt eins auf die Finger.
Wir generieren jetzt für jeden Dienst (Postgres, Redis, RabbitMQ, API) eigene, hochkomplexe Secrets. Der Installer würfelt die aus, speichert sie in der .env und sorgt dafür, dass sie bei einem Upgrade nicht überschrieben werden. Das klingt einfach, ist aber ein logischer Albtraum: Was ist, wenn der User die .env manuell geändert hat? Was ist, wenn er von einer uralten Version kommt, die noch gar keine Secrets für Service X hatte? Ich hab im InstallationManager inzwischen mehr Code für "Idempotenz" und "State-Management" als für die eigentliche Installation. Tja... Sicherheit kostet eben Nerven.
🆔 Identität & OIDC: "Wer bin ich und wenn ja, wie viele?"
Ein Security-Dashboard ohne vernünftiges Identity Management? Witzlos.
Wähle deine Waffe...
Wir unterstützen jetzt Local Auth, Keycloak und generische OIDC-Provider. Der Installer muss hier die Brücke schlagen. Er fragt die Endpunkte ab, validiert (optional) die Connectivity und bereitet den Stack vor. Das Problem dabei: Jeder OIDC-Provider (Okta, Azure AD, Google) schickt leicht andere Scopes oder erwartet andere Claims. Wir versuchen, das im Installer schon so weit es geht zu normalisieren. Wenn man Keycloak wählt, zieht der Installer sogar automatisch einen vorkonfigurierten Keycloak-Container hoch, falls gewünscht. "Ab Werk" sicher. Das war das Ziel.
📊 Monitoring & Lizenzen: Alles unter Kontrolle?
YADS produziert massiv Daten. Aber wer schaut schon gerne in Docker-Logs? Keiner.
Bunte Bilder für die Teppichetage.
Wir haben jetzt Prometheus, Grafana und Loki direkt im Stack. Der Installer fragt dich: "Willst du das volle Paket?" Wenn ja, werden die Dashboards direkt mit ausgerollt. Die Herausforderung hier: Ressourcen. Wer YADS auf einem kleinen VPS mit 2 GB RAM installieren will, dem fliegt der Monitoring-Stack um die Ohren. Also haben wir Ressourcen-Checks eingebaut. Wenn die Kiste zu schwach ist, warnt der Installer. Tja... Hardware kann man nicht herbeizaubern. ;-)
Und ja, die Lizenzprüfung... ein Thema für sich. Aber darüber hab ich ja neulich schon geschrieben. Hier wird es ernst: Ohne gültigen Key geht nichts.
Show me the money... oder eben kein Key, kein YADS.
Wenn der Key fehlt oder ungültig ist, bleibt der Installer hart. Wir haben hier extra feingranulare Fehlermeldungen eingebaut, damit man nicht raten muss, ob der Key abgelaufen ist oder einfach der Server nicht erreichbar war. Enterprise-Geraffel eben.
🛠️ Der eigentliche Pain: Nuitka & das Standalone-Versprechen
Der Installer soll als eine einzige Datei kommen. yads-setup.exe oder yads-setup.bin. Keiner will erst Python installieren, um ein Setup-Tool zu starten.
Upgrade, Reinstall oder einfach nur Kaputt?
Ich kompiliere das ganze Geraffel mit Nuitka. Das ist ein fantastisches Tool, aber es ist... sagen wir mal... eigenwillig. Da PySide6 und die ganzen Networking-Libs hunderte von Abhängigkeiten haben, muss Nuitka hunderte von DLLs/SOs einsammeln. Der Build-Prozess dauert auf meiner Workstation locker 10 Minuten. Und wehe, eine Library macht im Hintergrund dynamische Imports, die Nuitka nicht sieht – dann startet die Binary am Ende mit einer kryptischen Fehlermeldung.
Jetzt wird's ernst.
Inzwischen hab ich ein eigenes Release-Skript, das den Installer in verschiedenen Umgebungen (Ubuntu, Windows) testet, bevor die Binary überhaupt das Licht der Welt erblickt. Aufwand? Enorm. Aber für den Enduser ist es halt einfach nur ein Doppelklick. So soll es sein.
🤖 Vibecoding – Mein Alltag mit der KI
Ich will hier mal ganz ehrlich sein: Ein Großteil dieses Installers ist mit Unterstützung von LLMs wie Claude und Gemini ("Antigravity" in meinem Setup) entstanden. Warum? Weil ich wegen meiner Parkinsonerkrankung an manchen Tagen einfach nicht die Feinmotorik habe, um tausende Zeilen UI-Code fehlerfrei zu tippen.
Aber "Vibecoding" heißt nicht, dass man auf einen Knopf drückt und fertig ist. Es ist ein ständiger Kampf. Ich werfe der KI einen bug hin, sie fixiert ihn, bricht dabei aber drei andere Sachen. Ich korrigiere das Design, sie macht die Logik kaputt. Es ist ein interaktiver Prozess – fast wie ein Junior-Entwickler, der zwar extrem schnell tippt, aber keine Ahnung vom großen Ganzen hat.
Oft sitze ich bis 2 Uhr nachts da, lese Logs, justiere Prompts nach und schaue zu, wie der Installer langsam Form annimmt. Es ist anstrengend, aber es ermöglicht mir, Projekte dieser Größenordnung überhaupt noch alleine zu stemmen. Ohne KI gäbe es den neuen YADS-Installer wahrscheinlich gar nicht. Das ist die Realität 2026.
🏁 Das Ziel im Blick
Wenn dann am Ende alles grün wird...
Läuft. Endlich.
...dann weiß ich wieder, warum ich das mache. YADS ist mein Baby. Und der Installer ist die Tür zu diesem Baby. Sie muss stabil sein, sie muss gut aussehen und sie darf niemanden aussperren (außer die Bad Guys natürlich).
Wir sind noch nicht am Ende. Es gibt immer noch Edge Cases, die wir nicht gefangen haben. Aber die Basis steht. Der neue Installer ist ein Biest, aber ein schönes Biest.
Läuft... :)
Transparency Note (weil's ehrlich ist):
Dieser Post wurde mit kräftiger Unterstützung meiner KI-Peers (Antigravity/Claude) geschrieben. Wir haben den Code analysiert, die Screenshots sortiert und den Marco-Vibe drübergekippt. KI als Tool, Mensch als Pilot. Wie immer... sonst wär's ja nicht ehrlich. ;-)