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.
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
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
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)
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
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)
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)
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).
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
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).
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
