# Changelog – Server-Bibliothek Entwicklungshistorie in der Reihenfolge, wie das Projekt entstanden ist. Dient als Kontext für die Übergabe: welche Entscheidung wurde warum getroffen, welches Problem hat welche Änderung ausgelöst. ## v1 – Erster Prototyp Ausgangslage: Software-Installer und Dokumentation lagen verstreut, keine Übersicht, wer welche Software auf welchem Rechner hat. Ziel: ein Ort für alles. - Flask-Webanwendung + SQLite-Datenbank (eine Datei, kein DB-Server) - Software-Katalog: Name, Kategorie, Version, Installer-Pfad, Silent-Install- Parameter, Freitext-Dokumentation - Status-Anzeige pro Tool: Aktuell / Bitte prüfen / Nie geprüft (Schwelle: 30 Tage seit letzter Prüfung) – löst das Kernproblem "Installer-Ordner 4 Wochen nicht gepflegt, muss alles neu heruntergeladen werden" - Einfache Zuweisungs-Tabelle (ein Eintrag pro Mitarbeiter+Tool) - Design bewusst zurückhaltend gehalten (kein Frontend-Framework), damit die Zielperson (keine Programmiererfahrung) es per Doppelklick starten kann ## v2 – Bedienbarkeit für Nicht-Entwickler Auslöser: "Ich dachte, ich kann das Tool direkt installieren – ist Python nicht nur zum Programmieren da?" - `install.bat` / `start.bat`: kein Terminal/Befehle mehr nötig, nur Doppelklick - Python-Versionsprüfung mit klarer Fehlermeldung statt kryptischem Absturz ## v3 – Automatische Aktualisierung Auslöser: Wunsch, dass sich Standard-Software selbst aktuell hält, ohne Verteilung an andere Rechner (das war zu diesem Zeitpunkt explizit NICHT gewünscht). - Drei Update-Quellen: winget (Windows-Paketverwaltung), GitHub-Releases, fester Download-Link - Sicherheitskopie der alten Datei vor jedem Ersetzen - Update-Protokoll pro Tool - Mini-Doku-Box im Formular, die je nach gewählter Quelle live erklärt, wo man den passenden Wert findet (ersetzt einen langen Erklärtext) ## v4 – Mehrfach-Zuweisung statt Einzel-Protokollierung Auslöser: "Wenn ich mehrere Tools gleichzeitig zuweise, will ich nicht für jede Software einzeln ein Formular ausfüllen." - Checkliste mit "Alle auswählen", ein Formular erzeugt mehrere Zuweisungen auf einmal ## v5 – Protokolle statt flacher Zuweisungsliste Auslöser: "Bei 40 Mitarbeitern × 40 Tools wird die Liste unübersichtlich." - Neues Datenmodell: `protokolle` (1 Eintrag pro Rechner-Einrichtung) + `zuweisungen` (n Tools pro Protokoll) - Download-Button pro Tool (lokale Datei oder externer Link) ## v6 – Ordner-Organisation und Bugfixes (mehrere Anläufe) Auslöser: reale Nutzung zeigte, dass Installer-Dateien "nackt" im gemeinsamen Ablageordner landeten, weil mehrere Tools denselben Basis-Ordner eingetragen hatten. - Mehrere Iterationen, bis die Lösung wirklich robust war: 1. Automatische Ordner-Erstellung beim Speichern 2. Automatische Dateinamens-Vergabe (aus Tool-Namen abgeleitet) 3. **Endgültige Lösung:** `effektiver_ablageordner()` erzwingt IMMER einen Tool-eigenen Unterordner, unabhängig davon, was im Feld eingetragen ist – auch rückwirkend, ohne bestehende Einträge ändern zu müssen - Bugfix: Wurde eine Installer-Datei manuell gelöscht, meldete das System fälschlich "bereits aktuell" (nur Versionsnummer wurde verglichen, nicht ob die Datei noch existiert) – behoben durch zusätzliche Existenzprüfung - Download-Button erkennt jetzt automatisch Ordner vs. Einzeldatei und bietet bei Ordnern den Inhalt als ZIP an (wichtig für portable Tools wie Blender) - Versions-Anzeige in der Seitenleiste ergänzt (Diagnose-Hilfe, ob wirklich die neueste Version läuft – nötig geworden, weil mehrfach der Verdacht aufkam, ein Fix "greife nicht", obwohl der laufende Prozess nur nicht neu gestartet worden war) ## v7 – Dokumentations-Bilder - Upload/Anzeige/Löschen von Screenshots direkt auf der Tool-Detailseite ## v8 – Verteilung ("Rechner einrichten") Auslöser: Rückbesinnung, dass eine Verteilungsfunktion doch gebraucht wird – allerdings ohne Remote-Zugriff auf fremde Rechner (das wurde bewusst verworfen: zu hoher Aufwand/Risiko ohne vorhandene Domänen-Infrastruktur). Stattdessen: Skript, das man AUF dem neuen Zielrechner selbst ausführt. - Route `/einrichten`: Checkliste aller Tools, erzeugt bei Bedarf ein individuelles Installations-Paket (kein Pflegeaufwand für 100+ feste Skripte) - Generiertes PowerShell-Skript: lädt jedes ausgewählte Tool herunter, installiert es still, meldet danach automatisch ein Protokoll an den Server zurück (Rechnername wird automatisch erkannt) - Tools ohne Installer-Datei (portable/entpackte Tools wie Blender) werden als ZIP bereitgestellt – zunächst automatisch entpackt, nach Rückmeldung ("das will ich selbst entscheiden können") bewusst NICHT mehr automatisch entpackt, sondern nur bereitgestellt - Fester Client-Ordner `C:\ClientBibliothek` auf dem Zielrechner statt verstreuter Temp-Pfade – ermöglicht eine einzelne Antivirus-/Defender- Ausnahme statt vieler Einzelpfade; wird vom Skript beim ersten Lauf automatisch selbst eingetragen (`Add-MpPreference`) - Firewall-Freigabe-Skript ergänzt, nachdem der Test im echten Firmennetzwerk anstand (Port 5000 war durch die Windows-Firewall blockiert) - **Installer-Dateien werden direkt ins Paket gebündelt statt zur Laufzeit nachzuladen.** Auslöser: beim ersten Test im Firmennetz enthielt der Download nur die Skript-Dateien, die eigentlichen Installer wurden erst beim Ausführen auf dem Zielrechner per Netzwerk nachgeladen – das setzt Netzwerkzugriff des Zielrechners auf den Server in genau dem Moment voraus. Jetzt werden die Dateien beim Erzeugen des Pakets direkt mit eingepackt, der Zielrechner braucht für die Installation selbst kein Netzwerk mehr (nur die abschließende, optionale Protokoll-Meldung). ## v9 – Zugriffsbeschränkung lokal (Server) vs. Netzwerk Auslöser: Wird der Server über das Netzwerk erreicht (nicht direkt am Server), soll nur die Software-Anforderung sichtbar sein, um "Blödsinn" zu verhindern (Katalog verändern, Protokolle einsehen usw. nur direkt am Server). Wer aus dem Netzwerk Software herunterlädt, muss sich mit Namen eintragen, und alle Zugriffe werden protokolliert. - Unterscheidung über `request.remote_addr` (127.0.0.1/::1 = lokal, alles andere = Netzwerk) - Für Netzwerk-Zugriffe: alle Routen außer der Software-Anforderung (`/einrichten`) geben 403 mit Hinweisseite zurück - Software-Anforderung heißt bei Netzwerkzugriff bewusst anders ("Software anfordern" statt "Rechner einrichten") und weist auf die Protokollierung hin - Neues Zugriffsprotokoll (`/zugriffslog`, ebenfalls nur lokal einsehbar): Zeitpunkt, IP-Adresse, per Reverse-DNS ermittelter Rechnername (falls auflösbar), selbst angegebener Name, Aktion - **Bewusst nicht umgesetzt:** echte Windows-Benutzername-Erkennung. Das bräuchte NTLM/Kerberos-Integration (z. B. IIS-Reverse-Proxy vor Flask), was über reines Flask/HTTP nicht möglich ist – im Architektur-Dokument als offener Punkt festgehalten, nicht stillschweigend als "erledigt" behandelt ## Offene Design-Frage: Skript-Ansatz vs. automatische Verteilung Nach dem ersten Test im Firmennetz wurde nochmal grundsätzlich hinterfragt, ob der Skript-Ansatz (manueller Download + Ausführen auf dem Zielrechner) der richtige Weg ist, oder ob Daten "automatisch" auf dem Zielrechner landen sollten. Eine echte automatische Verteilung ohne manuellen Schritt am Zielrechner würde entweder eine dauerhaft laufende Helfer-Software auf jedem Zielrechner oder Windows-Remoting (PowerShell Remoting) voraussetzen – beide Wege brauchen im Kern eine Domänen-Infrastruktur bzw. zentrale Zugangsdaten-Verwaltung, die aktuell nicht vorhanden ist. Diese Frage wurde bewusst nicht in diesem Prototyp entschieden, sondern als offener Punkt für die Übernahme festgehalten (siehe README.md). ## Testmethodik (durchgehend) Da die Zielumgebung Windows ist, die Entwicklung aber in einer Linux-Umgebung stattfand, wurde wo immer möglich zusätzlich abgesichert: - PowerShell 7 wurde in der Entwicklungsumgebung nachinstalliert, um generierte Skripte mit dem echten Parser auf Syntaxfehler zu prüfen - Netzwerk-Operationen (Download, Formular-Rückmeldung, ZIP-Erstellung/ -Entpacken) wurden, wo plattformunabhängig möglich, live gegen den laufenden Server ausgeführt statt nur angenommen - Windows-exklusive Teile (Admin-Rechte-Anfrage, `msiexec`, `winget`, Defender-Cmdlets) blieben auf Syntaxprüfung + Dokumentations-Abgleich beschränkt – siehe `ARCHITEKTUR.md`, Abschnitt 7, für Details