docs: remove redundant docs, fold migration table into README

Clean up documentation redundancy:

- Delete docs/Archiv_fertig_-_Check_und_Installation.md: an AI hand-off
  transcript (first-person, stale test count, malformed markdown) whose
  useful content is already in INSTALL_FROM_ARCHIVE.md.
- Delete docs/How_to_use.md after moving its one unique asset -- the
  old-script -> new-command migration table -- into the README; drop it
  from the build_archive manifest.
- Fix INSTALL_FROM_ARCHIVE.md drift: list LICENSE/CHANGELOG.md in the
  archive allowlist and use `python -m pytest`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Dieter Schlüter 2026-07-07 10:56:20 +02:00
commit 4a5c2e27e1
5 changed files with 15 additions and 89 deletions

View file

@ -88,7 +88,7 @@ Weitere Aktionen, Optionen und Fehlersuche: [`BEDIENUNGSANLEITUNG.md`](BEDIENUNG
```bash ```bash
pip install -e ".[dev]" pip install -e ".[dev]"
pytest -q python -m pytest -q
``` ```
--- ---
@ -100,7 +100,7 @@ Das Archiv wird reproduzierbar von `build_archive.py` erzeugt. Es
1. prüft, ob alle erforderlichen Projektdateien vorhanden sind, 1. prüft, ob alle erforderlichen Projektdateien vorhanden sind,
2. gleicht die deklarierten Abhängigkeiten in einer frischen venv ab, 2. gleicht die deklarierten Abhängigkeiten in einer frischen venv ab,
3. lässt die komplette Test-Suite laufen, 3. lässt die komplette Test-Suite laufen,
4. baut das `.tar.gz` (nur Allowlist: `src/ tests/ docs/ man/ scripts/` + `pyproject.toml`, `README.md`, `requirements*.txt`, `llama.cpp.config.example`, `build_archive.py`, `BEDIENUNGSANLEITUNG.md`, `INSTALL_FROM_ARCHIVE.md`), 4. baut das `.tar.gz` (nur Allowlist: `src/ tests/ docs/ man/ scripts/` + `pyproject.toml`, `README.md`, `LICENSE`, `CHANGELOG.md`, `requirements*.txt`, `llama.cpp.config.example`, `build_archive.py`, `BEDIENUNGSANLEITUNG.md`, `INSTALL_FROM_ARCHIVE.md`),
5. öffnet das Archiv erneut und verifiziert die enthaltenen Dateien, 5. öffnet das Archiv erneut und verifiziert die enthaltenen Dateien,
6. installiert das Paket aus dem Archiv in einer weiteren frischen venv und testet das Konsolenskript. 6. installiert das Paket aus dem Archiv in einer weiteren frischen venv und testet das Konsolenskript.

View file

@ -123,6 +123,19 @@ Parametern, nicht die Qwen-Version.
Vollständige Optionsliste: `llamacppctl --help` oder die Manpage Vollständige Optionsliste: `llamacppctl --help` oder die Manpage
(`man/llamacppctl.1`, siehe unten). (`man/llamacppctl.1`, siehe unten).
## Migration von den Shell-Skripten
`llamacppctl` ersetzt die einzelnen Shell-Skripte durch Actions **eines**
Werkzeugs (`--profile` ist optional; ohne greift die `[default]`-Sektion):
| Altes Skript | Neuer Aufruf |
|---|---|
| `start-llm-server.sh` | `llamacppctl --start --config llama.cpp.config [--profile <name>]` |
| `status-llm-server.sh` | `llamacppctl --check --config llama.cpp.config [--profile <name>]` |
| Stop-Skript | `llamacppctl --stop --config llama.cpp.config [--profile <name>]` |
| `switch-llm.sh` (Modellwechsel) | `llamacppctl --change --config llama.cpp.config [--profile <name>]` |
| (neu) direkter Chat-Test | `llamacppctl --chat --config llama.cpp.config -p "..."` |
## Sicherheitsmodell (Kurzfassung) ## Sicherheitsmodell (Kurzfassung)
Für Details siehe [`docs/SECURITY_AND_OPERATIONS.md`](docs/SECURITY_AND_OPERATIONS.md). Für Details siehe [`docs/SECURITY_AND_OPERATIONS.md`](docs/SECURITY_AND_OPERATIONS.md).

View file

@ -72,7 +72,6 @@ REQUIRED_FILES = [
"tests/test_http_ops.py", "tests/test_http_ops.py",
"tests/test_lock_ops.py", "tests/test_lock_ops.py",
"tests/test_actions.py", "tests/test_actions.py",
"docs/How_to_use.md",
"scripts/smoke.sh", "scripts/smoke.sh",
"BEDIENUNGSANLEITUNG.md", "BEDIENUNGSANLEITUNG.md",
"INSTALL_FROM_ARCHIVE.md", "INSTALL_FROM_ARCHIVE.md",

View file

@ -1,53 +0,0 @@
Das Archiv ist fertig und übergeben: llamacppctl-installable.tar.gz.
Was gebaut wurde
Statt manuell zu tarballen, gibt es jetzt ein eigenständiges Python-Skript build_archive.py, das:
Prüft, ob alle erforderlichen Projektdateien vorhanden sind (Quellcode, Tests, Doku, Manpage, Config-Beispiel, scripts/smoke.sh)
pyproject.toml-Abhängigkeiten gegen requirements.txt abgleicht
Die deklarierte Abhängigkeit (requests>=2.31,<3) in einer frischen, isolierten virtuellen Umgebung installiert, um echte Installierbarkeit zu bestätigen (nicht nur einen Trockenlauf)
Die vollständige Test-Suite (aktuell 130 Tests, alle grün) laufen lässt
Das .tar.gz über Pythons tarfile-Modul baut (nicht rohes Shell-tar)
Das Archiv erneut öffnet und verifiziert, dass jede erwartete Datei tatsächlich enthalten ist
Das Archiv in ein temporäres Verzeichnis entpackt, in einer weiteren frischen venv installiert und den llamacppctl-Befehl ausführt, um Konsolenskript und Konfigurationsauflösung Ende-zu-Ende zu bestätigen
Da diese Sandbox keinen Docker-Daemon hat, bricht der letzte Schritt erwartungsgemäß an der Docker-Verfügbarkeitsprüfung ab — das Skript erkennt genau diesen Fall und wertet ihn nicht als Fehler, da Paketinstallation, Konsolenskript-Registrierung und Argumentparsing bereits vorher erfolgreich bestätigt wurden.
Enthaltene Projektstruktur
src/llamacppctl/ — die vollständige Implementierung: cli.py, config.py, prompt_io.py (SSRF-gehärtete Eingabeschicht), docker_ops.py, http_ops.py, lock_ops.py, actions.py, main.py
tests/ — 130 Tests (Prompt-Quellen, Datei-/URL-Sicherheit mit gemockter DNS-Auflösung, Konfigurationsauflösung, CLI-Validierung, Docker-/HTTP-Operationen mit gemocktem subprocess/requests, File-Locking)
docs/SECURITY_AND_OPERATIONS.md — vollständige Architektur-, Konfigurations- und Sicherheitsdokumentation
man/llamacppctl.1 — klassische Unix-Manpage
README.md, llama.cpp.config.example, requirements.txt, pyproject.toml
Selbst verifizieren
Nach dem Herunterladen kannst du die Integrität unabhängig prüfen, ohne mir zu vertrauen:
bash
gzip -t llamacppctl-installable.tar.gz && echo "Archiv OK"
tar tzf llamacppctl-installable.tar.gz
Installation:
bash
tar xzf llamacppctl-installable.tar.gz
cd llamacppctl
python3 -m venv .venv && source .venv/bin/activate
pip install .
cp llama.cpp.config.example llama.cpp.config # anpassen
llamacppctl --print-effective-config --config llama.cpp.config --start
Da build_archive.py selbst mit im Archiv liegt, kannst du das Archiv auf deinem eigenen Rechner jederzeit neu bauen und erneut verifizieren, ganz ohne auf mich angewiesen zu sein.

View file

@ -1,33 +0,0 @@
### Ist das start- stop- change-Skript etc auch dabei ?
Ja — aber als ein einziges vereinheitlichtes CLI-Tool statt separater Shell-Skripte. Das war ja genau der Punkt der Neuentwicklung: `llamacppctl` ersetzt die einzelnen Skripte (`start-llm-server.sh`, `status-llm-server.sh`, `switch-llm.sh`, …) durch **eine** Python-Anwendung mit Unterbefehlen (Actions).
Alle Funktionen sind im Archiv enthalten, als Actions von `llamacppctl`:
| Alte Skript-Idee | Neuer Aufruf |
|---|---|
| `start-llm-server.sh` | `llamacppctl --start --config llama.cpp.config --profile <name>` |
| `status-llm-server.sh` | `llamacppctl --check --config llama.cpp.config --profile <name>` |
| Stop-Skript | `llamacppctl --stop --config llama.cpp.config --profile <name>` |
| `switch-llm.sh` (Modellwechsel) | `llamacppctl --change --config llama.cpp.config --profile <name>` |
| (neu) direkter Chat-Test | `llamacppctl --chat --config llama.cpp.config --profile <name> -p "..."` |
Die Logik dahinter liegt in `src/llamacppctl/actions.py` (`do_start`, `do_check`, `do_stop`, `do_change`, `do_chat`) und `src/llamacppctl/docker_ops.py` (baut den `docker run`-Befehl, startet/stoppt/entfernt Container, liest Logs).
Besonderheiten gegenüber den ursprünglichen Shell-Skripten:
- `--change` nutzt eine exklusive Dateisperre (`/tmp/llamacppctl.<container_name>.lock`), damit zwei gleichzeitige Modellwechsel für denselben Container sich nicht in die Quere kommen.
- Die Start-Bereitschaftsprüfung (`--start`/`--change`) wartet auf eine echte Chat-Completion-Antwort, nicht nur auf einen offenen Port — das ist zuverlässiger als ein reiner Port-Check.
- `--dry-run` zeigt dir den vollständigen `docker run`-Befehl an, ohne ihn auszuführen (reine Vorschau: kein Lock, kein Container-Abriss).
- `--change` validiert den Modellpfad **vor** dem Entfernen des laufenden Containers und läuft — wie `--start` — unter Lock; `--force` umgeht einen hängenden Lock.
Neuere Optionen (Details in Manpage/README):
- **Antwortsteuerung:** `--max-tokens` (Reasoning-Modelle brauchen viel Budget, sonst leere Antwort), `--chat-temp`, und `--stream` für token-weise Live-Ausgabe bei `--chat`.
- **Netzwerk/Auth:** Port wird per Default nur auf `127.0.0.1` veröffentlicht; `--expose` bindet auf alle Interfaces, `--api-key` schützt die Chat-API (Bearer-Token).
- **Scriptbar:** `--check` liefert Exit-Code 0 (läuft/erreichbar) bzw. 5 — geeignet für Monitoring/Cron.
- **`hf_home`** darf Env-Variablen enthalten, z. B. `hf_home = ${HF_HOME}`.
- **End-to-End-Test:** `scripts/smoke.sh` (opt-in) gegen einen echten Server.
Die vollständige Referenz zu allen Optionen steht in der Manpage (`man/llamacppctl.1`) und in `README.md`/`docs/SECURITY_AND_OPERATIONS.md`.