Server-Bibliothek
vor 18 Std. 9b3bf078061d2d02e7ebe7fb3c31869e35272be1
README.md
@@ -1,156 +1,140 @@
# Server-Bibliothek – Prototyp
# Software-Bibliothek
> **Für eine technische Übergabe (z. B. Git-Repository):** Diese Datei ist
> die Bedienungsanleitung. Die technische Architektur (Datenbankschema,
> Kernkonzepte, bekannte Grenzen) steht in `ARCHITEKTUR.md`, die
> Entwicklungshistorie in `CHANGELOG.md`.
Zentrale Softwareverteilung für den Betrieb: Ein Server hält Installer und interne
Werkzeuge auf dem aktuellsten Stand, alle anderen laden sie über den Browser herunter.
Ein einfaches internes Web-Tool für euren Windows-11-Server:
- Katalog aller Software-Tools mit Version, Installer-Pfad und Dokumentation
- Status-Anzeige: **Aktuell / Bitte prüfen / Nie geprüft** (Warnung ab 30 Tagen ohne Prüfung)
- Protokoll: welcher Mitarbeiter hat welche Software auf welchem Rechner bekommen
Die Bibliothek holt sich die Dateien selbst — aus GitHub-Releases, über winget, aus SVN,
von einem Direktlink oder indem sie ein Git-Repository klont und baut. Es wird nichts von
Hand hochgeladen, und niemand muss mehr suchen, ob eine Version noch aktuell ist.
Läuft komplett lokal auf eurem Server, keine Cloud, keine Installation von Zusatzsoftware
außer Python. Die Daten liegen in einer einzigen Datei (`data/bibliothek.db`).
Die technische Innensicht steht in [ARCHITEKTUR.md](ARCHITEKTUR.md).
---
## 1. Einmalige Einrichtung auf dem Server
## Betrieb
### Schritt 1 – Ordner kopieren
Kopiert den kompletten Ordner `server-bibliothek` auf den Windows-11-Server,
z. B. nach `C:\server-bibliothek`.
### Die fertige Programmdatei
### Schritt 2 – Python installieren (falls noch nicht vorhanden)
1. Öffnet im Browser: https://www.python.org/downloads/
2. Ladet die neueste Version für Windows herunter und startet die Installation.
3. **Wichtig:** Auf der ersten Seite des Installers unten das Kästchen
   **"Add python.exe to PATH"** anhaken, bevor ihr auf "Install Now" klickt.
Der Auslieferungsstand ist eine einzelne `software-bibliothek.exe`. Sie braucht kein
installiertes Node, keine Laufzeitumgebung und keine Installation — ablegen, starten,
fertig. Beim ersten Start legt sie ihren Datenordner an und meldet im Fenster, wo er liegt.
### Schritt 3 – Einrichtung starten
Im Ordner `C:\server-bibliothek` die Datei **`install.bat`** doppelklicken.
Es öffnet sich ein schwarzes Fenster, das die benötigte Bibliothek installiert.
Am Ende steht "Fertig!" – das Fenster kann dann geschlossen werden.
(Falls Python noch fehlt, sagt dir das Fenster das und verlinkt die Download-Seite.)
## 2. Programm starten
Im Ordner `C:\server-bibliothek` die Datei **`start.bat`** doppelklicken.
Es öffnet sich ein Fenster mit der Meldung, dass der Server läuft.
Dieses Fenster muss offen bleiben, solange das Tool genutzt werden soll –
es ist quasi der "Motor", der die Web-Seite im Hintergrund am Laufen hält.
Jetzt im Browser öffnen:
```
http://localhost:5000
Software-Bibliothek läuft auf http://localhost:3000
Daten:         C:\ProgramData\Software-Bibliothek\data
Einstellungen: C:\ProgramData\Software-Bibliothek\konfiguration.json
```
Von **anderen Rechnern im selben Netzwerk** erreicht ihr es über die IP-Adresse
des Servers, z. B. `http://192.168.1.50:5000` (steht auch direkt im
Konsolenfenster von `start.bat`, in der Zeile die NICHT mit `127.0.0.1`
beginnt).
### Wo die Daten liegen
**Klappt der Zugriff von einem anderen Rechner nicht?** Das liegt fast immer
an der Windows-Firewall, die eingehende Verbindungen auf Port 5000
standardmäßig blockiert. Einmalig `firewall-freigabe-einrichten.bat`
doppelklicken – richtet die nötige Firewall-Regel automatisch ein.
Standard ist `%ProgramData%\Software-Bibliothek` — bewusst außerhalb des Programmordners,
damit ein Austausch der Programmdatei nichts mitreißt. Ein anderer Ort lässt sich in den
Einstellungen hinterlegen (Zahnrad oben rechts, nur direkt am Server erreichbar).
Zum Beenden: das Konsolenfenster einfach schließen (oder `STRG+C` drücken).
| Unterordner | Inhalt |
|---|---|
| `files/<id>/` | Die bereitgestellten Programmdateien — das, was heruntergeladen wird |
| `sources/<id>/` | Arbeitskopien der Git-Repositories, die selbst gebaut werden |
| `secrets/<id>.json` | Hinterlegte API-Schlüssel; Zugriff auf SYSTEM, Administratoren und das Dienstkonto beschränkt |
| `bibliothek.db` | Katalog und Zugriffsprotokoll (SQLite) |
Für die Datensicherung genügt dieser Ordner.
### Wer was darf
Die Grenze verläuft an der Netzwerkschnittstelle, nicht an einer Anmeldung:
- **Direkt am Server** (`localhost`) — vollständige Verwaltung: Einträge anlegen, ändern,
  löschen, Quellen prüfen, Schlüssel hinterlegen, Einstellungen, Zugriffsprotokoll.
- **Aus dem Netzwerk** — Katalog ansehen und herunterladen. Jede verwaltende Route
  antwortet mit 403.
Jeder Download wird protokolliert: Zeitpunkt, IP, aufgelöster Rechnername, Programm.
### Aktualität
Einmal täglich prüft die Bibliothek alle Quellen selbsttätig; „Alle prüfen" stößt es von
Hand an. Liefert eine Quelle nichts Brauchbares — Seite tot, HTML statt Programmdatei,
plötzlich winzige Datei — bleibt die zuletzt bereitgestellte Datei unangetastet und der
Eintrag meldet das Problem. Ein kaputter Link führt nie dazu, dass ein funktionierender
Download verschwindet.
---
## 3. Bedienung
## Entwicklung
- **Software-Katalog** (Startseite): alle Tools mit Status auf einen Blick.
  Über "+ Neues Tool anlegen" ein neues Tool mit Installer-Pfad, Silent-Parametern
  und Doku-Text hinterlegen.
- Auf einem Tool auf **Details** klicken → dort steht die komplette Anleitung,
  außerdem der Button **"Jetzt als geprüft markieren"** – das solltet ihr klicken,
  wann immer ihr den Installer manuell aktualisiert habt. Danach zählt der
  30-Tage-Timer wieder von vorn.
- **Zuweisungen**: Protokolliert dort jede Installation (Mitarbeiter, Rechnername,
  installierte Version, Datum). Über die Filterfelder lässt sich nach Mitarbeiter
  oder Rechnername suchen.
Node 22 oder neuer (die eingebaute SQLite-Schnittstelle wird gebraucht), npm-Workspaces.
```bash
npm install
```
Server und Oberfläche laufen getrennt:
```bash
npm run dev:server
```
```bash
npm run dev:client
```
Der Server bedient `http://localhost:3000` und liefert dort auch die gebaute Oberfläche
aus. Der Entwicklungsserver auf `http://localhost:5000` bringt Hot Reload mit und leitet
`/api` an Port 3000 weiter — Änderungen an der Oberfläche sind dort sofort sichtbar, auf
Port 3000 erst nach einem Bau.
### Aufteilung
| Paket | Inhalt |
|---|---|
| `packages/bibliothek-types` | Gemeinsame Typen — der Vertrag zwischen Server und Oberfläche |
| `packages/bibliothek-server` | Express, SQLite, Bezugsquellen, Zugriffsgrenze |
| `packages/bibliothek-client` | Oberfläche aus dh-components (Lit) |
### Bauen
```bash
npm run build
```
```bash
npm run build:exe
```
Der zweite Befehl erzeugt die eigenständige Programmdatei: TypeScript übersetzen, den
Server mit esbuild bündeln, die Oberfläche als Ressourcen einbetten und beides über Nodes
Single-Executable-Verfahren in eine `.exe` schreiben.
---
## 3a. Rechner einrichten (Verteilung an neue Rechner)
## Ein internes Werkzeug anbinden
Menüpunkt "Rechner einrichten": Häkchen bei den benötigten Tools setzen,
Mitarbeiter eintragen, "Installations-Paket herunterladen" klicken. Das
erzeugte ZIP enthält die ausgewählten Installer-Dateien **direkt mit** (kein
Nachladen vom Server nötig).
Werkzeuge, die selbst gebaut werden, beschreiben ihren Bau im eigenen Repository — die
Bibliothek muss nichts über sie wissen. Dafür liegt eine `software-bibliothek.json` im
Wurzelverzeichnis:
Auf dem **neuen Rechner**: ZIP entpacken, `Rechner-einrichten-starten.bat`
doppelklicken. Das Skript:
- fragt bei Bedarf automatisch nach Admin-Rechten
- installiert jedes Tool still mit dem hinterlegten Silent-Parameter
- trägt automatisch eine Windows-Defender-Ausnahme für `C:\ClientBibliothek`
  ein (dort landen alle Dateien gesammelt)
- meldet das Ergebnis am Ende automatisch ans zentrale Protokoll zurück
  (Rechnername wird dabei selbst erkannt)
```json
{
  "buildCommand": "npm install && npm run build-win",
  "artifact": "dist/MeinWerkzeug.exe"
}
```
Tools ohne einzelne Installer-Datei (z. B. bereits entpackte/portable Tools
wie Blender) werden als ZIP nach `C:\ClientBibliothek\pakete\` gelegt –
bewusst ohne automatisches Entpacken, das entscheidet ihr von Fall zu Fall
selbst.
Braucht der Bau einen API-Schlüssel, wird er dort deklariert und sein Wert in der
Bibliothek hinterlegt; beim Bau steht er als Umgebungsvariable bereit. Das vollständige
Verfahren beschreibt der Skill `build-secrets` im Repository `dh-claude-rules`.
⚠️ Die Windows-spezifischen Teile (Admin-Rechte-Anfrage, stille Installation)
wurden nicht auf einem echten Windows-Rechner entwickelt und getestet, nur
mit dem echten PowerShell-Parser auf Syntaxfehler geprüft sowie die
Netzwerk-/Datei-Logik separat verifiziert. Bei größerem Rollout zuerst an
1–2 unkritischen Rechnern gegentesten.
Im Katalog wird als Quelle **nur die Repository-URL ohne Benutzernamen** eingetragen — die
Kennung kommt aus den Einstellungen der Bibliothek, damit ein Kontowechsel nicht jeden
Eintrag berührt.
---
## 4. Automatische Aktualisierung
## Offen
Bei jedem Tool kann beim Anlegen/Bearbeiten "Automatische Aktualisierung
aktivieren" angehakt werden. Dann sucht das Tool selbst nach neuen Versionen
und **ersetzt die Installer-Datei automatisch, ohne Rückfrage**. Dabei:
- wird die alte Datei vorher immer in einen Unterordner `_sicherungen`
  kopiert (Sicherheitsnetz, falls mal etwas schiefgeht)
- wird jeder Check protokolliert (sichtbar auf der Detailseite des Tools
  unter "Update-Protokoll")
- bleibt ein Tool bei "Bitte prüfen" stehen, wenn eine Prüfung fehlschlägt
  (z. B. Server nicht erreichbar) – Fehler werden nie stillschweigend
  übergangen
Als Quelle stehen drei Möglichkeiten zur Wahl: **winget** (für die meisten
bekannten Programme, siehe `Update-Quellen-Uebersicht.md`), **GitHub-Projekt**
(für Open-Source-Tools) oder ein **direkter Download-Link**. Tools ohne
Häkchen bleiben komplett unangetastet – ideal für interne oder bewusst
fest angepinnte Software.
**Update jetzt manuell auslösen:**
- Für ein einzelnes Tool: auf der Detailseite "Jetzt automatisch prüfen & aktualisieren"
- Für alle Tools auf einmal: Button oben im Software-Katalog, oder Doppelklick auf `pruefe_updates.bat`
**Täglich automatisch im Hintergrund laufen lassen (empfohlen):**
Einmalig `automatisierung_einrichten.bat` doppelklicken. Das richtet in der
Windows-Aufgabenplanung einen täglichen Lauf um 03:00 Uhr nachts ein – dann
kümmert sich das Tool von selbst darum, auch wenn niemand die Weboberfläche
geöffnet hat. Falls eine Fehlermeldung kommt: Rechtsklick auf die Datei →
"Als Administrator ausführen".
⚠️ **Hinweis zum winget-Pfad:** Dieser Teil konnte in meiner Entwicklungsumgebung
nicht direkt getestet werden, da winget nur unter Windows existiert (der
GitHub-Pfad wurde dagegen live gegen die echte GitHub-Schnittstelle getestet).
Probiert den winget-Weg daher am besten zuerst an einem unkritischen Tool aus,
bevor ihr euch vollständig darauf verlasst.
## 5. Dauerhafter Betrieb der Weboberfläche
Aktuell müsst ihr `start.bat` manuell starten, wenn ihr den Katalog im Browser
ansehen wollt – die automatische Update-Prüfung (siehe oben) läuft davon
unabhängig auch ohne offene Weboberfläche. Falls gewünscht, kann auch die
Weboberfläche selbst automatisch mit dem Server starten – dafür einfach
melden, wenn ihr so weit seid.
## 6. Datensicherung
Alle Daten liegen in der Datei `data\bibliothek.db`. Diese Datei ab und zu zu
sichern (z. B. in euer normales Backup einschließen) reicht als Absicherung
gegen Datenverlust vollständig aus.
- HTTPS; solange die Verbindung unverschlüsselt ist, bleiben dem Browser die Schnittstellen
  für Dateizugriff verwehrt
- Betrieb als Windows-Dienst mit Autostart
- Automatisierte Tests
- Rollen und Rechte (im Ticket bewusst zurückgestellt)