Kapitel 18/Free Rohtext.md hinzugefügt

2025-10-22 19:29:53 +00:00
parent 02371ad8e1
commit dfc1ce2b92
1 changed files with 844 additions and 0 deletions
--- a/Rohtext.md
+++ b/Rohtext.md
@@ -0,0 +1,844 @@
 # Kapitel 18 – Ollama (Lokale KI-Inferenz)
 ## Einleitung
 Künstliche Intelligenz ist längst kein Zukunftsthema mehr – sie ist ein Werkzeug.  
 Für viele Aufgaben im Homelab, in der Automatisierung oder Content-Produktion kann eine lokal laufende KI enorme Vorteile bringen:  
 Antworten in Echtzeit, volle Kontrolle über Daten und keine Abhängigkeit von Cloud-Diensten.
 **Ollama** ist eine Open-Source-Plattform, die genau das ermöglicht.  
 Sie erlaubt es, Sprachmodelle (z. B. Llama 3, Mistral, Phi oder Gemma) direkt auf deinem eigenen System auszuführen –  
 entweder CPU-basiert oder mit GPU-Beschleunigung.  
 Damit erhältst du eine **lokale Chat- und Inferenz-Engine**, die du in Tools wie n8n, Affine, deinem Kontrollzentrum oder eigenen Apps einsetzen kannst.  
 Kein API-Key, keine Kosten, kein Tracking – volle Datensouveränität.
 👉 **Screenshot geeignet:** UCC-Dashboard mit markiertem „Ollama“-Container, sichtbar neben n8n und Nextcloud
 > [!NOTE]  
 > Ollama ist kein einzelnes KI-Modell, sondern eine Laufzeitumgebung.  
 > Sie stellt einen lokalen API-Server bereit, über den du beliebige Modelle laden, verwalten und abfragen kannst.  
 > Die Modelle selbst sind eigenständige Dateien und können unabhängig voneinander installiert oder entfernt werden.
 Nach diesem Kapitel hast du eine vollständig funktionsfähige lokale KI-Umgebung,  
 die du direkt über die Kommandozeile, per HTTP-Request oder in anderen UCC-Diensten ansprechen kannst.
 ---
 ## Voraussetzungen & Ressourcen
 Ollama lässt sich auch auf schwächerer Hardware stabil betreiben – entscheidend ist die richtige Modellauswahl.  
 Da dein Host ein älterer Office-PC ist, liegt der Fokus auf effizientem Ressourceneinsatz statt maximaler Leistung.
 ### Container-Ressourcen
 * **CPU:** 4 vCPU  
  Ollama nutzt Multithreading, daher sind vier virtuelle Kerne sinnvoll.  
  Weniger funktioniert, verlängert aber die Antwortzeiten.
 * **RAM:** 8 GB  
  Für leichte Modelle wie Phi-3 Mini, Gemma 2B oder Mistral 7B in Q4-Quantisierung ausreichend.  
  Wichtig ist, dass nie mehrere große Modelle gleichzeitig geladen werden.
 * **Speicherplatz:** 50 GB  
  Modelle liegen als `.gguf`-Dateien lokal im Container.  
  Plane je nach Modellgröße zwischen 4 und 15 GB ein, plus 10 GB Reserve für temporäre Daten.
 * **Netzwerk:** Statische IP oder DHCP-Reservierung  
  Damit andere Container (z. B. n8n oder Affine) die API zuverlässig erreichen.
 * **Betriebssystem:** Debian 12 (Bookworm)  
  Stabil, ressourcenschonend und optimal für den Einsatz auf älterer Hardware.
 👉 **Screenshot geeignet:** Proxmox-Maske beim Erstellen des Ollama-Containers (4 vCPU | 8 GB RAM | 50 GB Storage | Debian 12)
 ### Technische Voraussetzungen
 Vor der Einrichtung sollte dein UCC folgendes erfüllen:
 * **Proxmox VE** ist betriebsbereit und kann Container erstellen.  
 * **Nginx Proxy Manager (NPM)** ist installiert und erreichbar.  
 * **DNS-Eintrag** für `ollama.deinedomain.tld` zeigt auf deinen Server.  
 * **Internetverbindung** ist stabil – Modelle werden online geladen.  
 * **SSH-Zugriff** auf den Container funktioniert:  
  ```bash
  ssh root@<IP-des-Containers>
  ```
  Ersetze `<IP-des-Containers>` durch die tatsächliche Adresse des Ollama-LXC.
 > [!IMPORTANT]  
 > GPU-Unterstützung ist hier nicht vorgesehen.  
 > Ollama läuft vollständig CPU-basiert und kann trotzdem stabile Ergebnisse liefern,  
 > solange Modelle mit moderater Parameterzahl (bis 7B) verwendet werden.
 ---
 ### Schritt 1 – Container vorbereiten und System aktualisieren
 Starte den frisch erstellten Ollama-Container in Proxmox und öffne die Konsole (Web-Shell oder SSH).
 Systempakete aktualisieren:
 ```bash
 apt update && apt upgrade -y
 ```
 Container neu starten:
 ```bash
 reboot
 ```
 Danach wieder einloggen:
 ```bash
 ssh root@<IP-des-Containers>
 ```
 > [!NOTE]
 > Ein aktuelles System verhindert Installationsfehler und Abbrüche beim Laden der Modelle.
 👉 **Screenshot geeignet:** Proxmox-Konsole nach erfolgreichem `apt upgrade`
 ### Schritt 2 – Ollama installieren
 Ollama stellt ein offizielles Installationsskript bereit, das automatisch alle Abhängigkeiten einrichtet und den Dienst als systemd-Service konfiguriert.
 Führe im Container folgenden Befehl aus:
 ```bash
 curl -fsSL https://ollama.com/install.sh | sh
 ```
 Nach Abschluss prüfe den Dienststatus:
 ```bash
 systemctl status ollama
 ```
 Die Ausgabe sollte `active (running)` anzeigen.
 > [!NOTE]  
 > Der Dienst startet automatisch beim Booten des Containers und lauscht auf Port `11434`.  
 > Sollte die Ausgabe `inactive` oder `failed` lauten, kontrolliere mit  
 > ```bash
 > journalctl -u ollama -xe
 > ```  
 > ob Pakete oder Abhängigkeiten fehlgeschlagen sind.
 👉 **Screenshot geeignet:** Terminalausgabe von `systemctl status ollama` mit aktivem Dienst
 ### Schritt 3 – Erste Funktionsprüfung & Modelle installieren
 Nach der erfolgreichen Installation läuft der Ollama-Dienst bereits im Hintergrund.  
 Jetzt prüfst du, ob die API reagiert und lädst anschließend die beiden benötigten Modelle.
 #### Installation prüfen
 ```bash
 curl http://localhost:11434/api/tags
 ```
 Wenn eine leere JSON-Liste zurückkommt, ist der Server bereit:
 ```json
 []
 ```
 👉 **Screenshot geeignet:** Terminalausgabe von `curl /api/tags` mit leerer JSON-Liste
 #### Modell 1 – Mistral 7B
 Dieses Modell übernimmt die strukturierten Aufgaben innerhalb deines UCC –  
 z. B. präzise Auswertungen, systemnahe Antworten oder die Verarbeitung von Nachrichten, die über WAHA eingehen.
 Modell herunterladen:
 ```bash
 ollama pull mistral
 ```
 Nach dem Download prüfen, ob es korrekt installiert wurde:
 ```bash
 ollama list
 ```
 In der Ausgabe sollte `mistral` erscheinen.
 👉 **Screenshot geeignet:** Terminalausgabe von `ollama list` mit sichtbarem Eintrag `mistral`
 #### Modell 2 – Phi-3 Mini
 Phi-3 ist kompakt und läuft stabil auch auf schwächerer Hardware.  
 Es eignet sich ideal für natürlich klingende, kreative Texte und ergänzt Mistral in allen inhaltlich offeneren Aufgaben.
 Modell laden:
 ```bash
 ollama pull phi3
 ```
 Anschließend erneut prüfen:
 ```bash
 ollama list
 ```
 Beide Modelle sollten nun angezeigt werden: `mistral` und `phi3`.
 👉 **Screenshot geeignet:** Terminalausgabe von `ollama list` mit sichtbaren Modellen `mistral` und `phi3`
 ### Schritt 4 – Funktionstest und erste Abfrage
 Nach der Installation und dem Laden beider Modelle folgt nun der Praxistest.  
 Damit stellst du sicher, dass Ollama korrekt arbeitet und die Modelle einsatzbereit sind.
 #### Test mit Mistral
 Starte Mistral direkt über die Konsole:
 ```bash
 ollama run mistral
 ```
 Nach dem Start erscheint die Eingabeaufforderung (`>>>`).  
 Gib eine einfache Testfrage ein, die sich ohne Internetzugriff beantworten lässt:
 ```
 Erkläre mir, was ein Container ist.
 ```
 Mistral sollte in wenigen Sekunden eine sachliche und technisch korrekte Antwort liefern.  
 Beende den Lauf anschließend mit `CTRL + C`.
 👉 **Screenshot geeignet:** Terminal mit sichtbarer Mistral-Antwort auf Testfrage
 #### Test mit Phi-3
 Starte danach das zweite Modell:
 ```bash
 ollama run phi3
 ```
 Diese Variante ist sprachlich freier und eignet sich besser für kreative Texte.  
 Verwende deshalb eine etwas erzählerische Testfrage:
 ```
 Beschreibe eine Fantasiewelt mit einem eigenen Kontrollzentrum.
 ```
 Phi-3 reagiert meist mit lebendigen, bildhaften Formulierungen.  
 Auch hier die Sitzung mit `CTRL + C` beenden.
 👉 **Screenshot geeignet:** Terminal mit Phi-3-Antwort auf Testfrage
 > [!NOTE]  
 > Ollama-Modelle haben **keinen Internetzugriff** und kennen weder „Bratonien“ noch dein reales System.  
 > Sie antworten ausschließlich auf Basis des Prompt-Inhalts.  
 > Damit sie künftig deine eigene Welt verstehen, werden wir im Premium-Kapitel zeigen,  
 > wie du Kontextwissen und interne Dokumente lokal einbindest.
 ### Schritt 5 – API-Zugriff aktivieren
 Ollama stellt lokal eine HTTP-API bereit, über die du Anfragen aus anderen Systemen senden kannst – etwa von n8n, Affine oder deinem Kontrollzentrum.  
 Die API läuft standardmäßig auf Port `11434`.
 #### Erreichbarkeit prüfen
 Führe im Container folgenden Befehl aus:
 ```bash
 curl http://localhost:11434/api/tags
 ```
 Wenn eine JSON-Antwort erscheint, z. B.:
 ```json
 [{"name": "mistral"}, {"name": "phi3"}]
 ```
 dann ist die API aktiv und betriebsbereit.
 👉 **Screenshot geeignet:** Terminalausgabe von `curl /api/tags` mit sichtbaren Modellen
 #### Zugriff über das Netzwerk
 Damit andere Container im UCC (z. B. n8n oder Affine) auf die API zugreifen können,  
 muss der Nginx Proxy Manager (NPM) den internen Port **11434** weiterleiten.  
 Dazu braucht Ollama **keine öffentliche Bindung** – der Dienst bleibt intern und sicher.
 Prüfe zunächst, ob der Dienst korrekt läuft:
 ```bash
 systemctl status ollama
 ```
 Wenn der Status `active (running)` lautet,  
 kannst du mit `ss` kontrollieren, ob der Port intern aktiv ist:
 ```bash
 ss -tulpen | grep 11434
 ```
 Wird hier `127.0.0.1:11434` angezeigt, ist alles korrekt –  
 Ollama lauscht lokal, und NPM greift intern über die Container-IP zu.
 > [!NOTE]  
 > Du musst **keine** Änderung in der Ollama-Konfiguration vornehmen  
 > (z. B. `--host 0.0.0.0`).  
 > Der Dienst bleibt bewusst auf `localhost` beschränkt,  
 > um keine ungeschützten Ports ins interne Netz zu öffnen.
 #### Proxy-Host in NPM anlegen
 1. Öffne das **Nginx Proxy Manager Dashboard**.  
 2. Wähle **Add Proxy Host**.  
 3. Trage folgende Werte ein:
 | Feld | Wert |
 |------|------|
 | **Domain Names** | `ollama.deinedomain.tld` |
 | **Scheme** | `http` |
 | **Forward Hostname / IP** | `<IP-des-Ollama-Containers>` |
 | **Forward Port** | `11434` |
 | **Block Common Exploits** | aktivieren |
 | **Websockets Support** | aktivieren |
 Wechsle anschließend in den Reiter **SSL** und aktiviere:
 - **Request a new SSL Certificate**  
 - **Force SSL**  
 - **HTTP/2 Support**  
 - **HSTS Enabled**
 > [!NOTE]  
 > Achte darauf, dass `ollama.deinedomain.tld` bereits im DNS  
 > auf deinen Server zeigt und dass interne Firewalls (z. B. Proxmox oder UFW)  
 > Verbindungen zwischen NPM und Ollama zulassen.  
 > Eine Freigabe des Ports **11434** nach außen ist nicht erforderlich.
 👉 **Screenshot geeignet:** NPM-Dashboard mit geöffnetem Proxy-Host `ollama.deinedomain.tld`
 #### Verbindung testen
 Öffne im Browser:
 ```
 https://ollama.deinedomain.tld/api/tags
 ```
 Wenn du dieselbe JSON-Ausgabe erhältst wie zuvor, ist die API über HTTPS erreichbar.  
 Ab diesem Punkt können n8n, Affine oder andere UCC-Dienste Ollama direkt über Requests ansprechen.
 > [!TIP]  
 > Im Premium-Kapitel lernst du, wie Ollama über **llm-axe** zusätzlich aktuelle Webdaten beziehen kann,  
 > um Antworten mit externen Informationen zu erweitern – bei weiterhin vollständiger lokaler Kontrolle.
 ### Schritt 6 – API-Nutzung aus einem anderen Container
 Nachdem die Ollama-API über den Nginx Proxy Manager eingerichtet wurde,  
 kann sie jetzt von jedem anderen Container im UCC-Netzwerk angesprochen werden.  
 Dieser Schritt zeigt, wie du die Verbindung praktisch nutzt – ohne zusätzliche Tools oder Oberflächen.
 #### Zugriff aus einem anderen LXC prüfen
 Wechsle in die Konsole eines anderen Containers,  
 z. B. deines n8n-LXC oder eines beliebigen Debian-Containers im selben Netz,  
 und führe folgenden Befehl aus:
 ```bash
 curl -k https://ollama.deinedomain.tld/api/tags
 ```
 Wenn du eine JSON-Antwort erhältst, z. B.:
 ```json
 [{"name":"mistral"},{"name":"phi3"}]
 ```
 dann ist die Verbindung erfolgreich und die API von außen erreichbar.
 👉 **Screenshot geeignet:** Terminalausgabe im anderen Container mit erfolgreicher JSON-Antwort
 > [!NOTE]  
 > Die Option `-k` ignoriert Zertifikatswarnungen.  
 > Bei gültigem Let’s-Encrypt-Zertifikat kann sie entfallen.
 #### Erste API-Abfrage an ein Modell
 Um die API praktisch zu testen, sende eine kurze Anfrage an das Mistral-Modell:  
 ```bash
 curl -X POST https://ollama.deinedomain.tld/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral",
    "prompt": "Erkläre in einem Satz, was ein Homelab ist."
  }'
 ```
 Wenn alles funktioniert, antwortet Ollama mit einem JSON-Block,  
 der den generierten Text enthält:
 ```json
 {
  "model": "mistral",
  "created_at": "2025-10-22T17:32:00Z",
  "response": "Ein Homelab ist eine private IT-Umgebung zum Lernen, Testen und Automatisieren."
 }
 ```
 👉 **Screenshot geeignet:** Terminalausgabe mit erfolgreicher API-Antwort
 #### Verwendung im Alltag
 Über diese Schnittstelle kannst du Ollama ab jetzt  
 aus beliebigen Skripten, Shell-Befehlen oder Tools im UCC aufrufen –   
 z. B. zur Textgenerierung, Zusammenfassung von Logs oder automatisierten Statusmeldungen.  
 Der Aufruf bleibt dabei vollständig lokal und erfordert keine Cloud-Verbindung.
 > [!TIP]  
 > Diese API bildet die technische Grundlage für spätere Erweiterungen –  
 > etwa automatisierte Workflows oder grafische Oberflächen.  
 > Für den Moment genügt sie, um Ollama sicher aus jedem Container im UCC zu steuern.
 ### Schritt 7 – Zugriff absichern
 Damit die Ollama-API nicht von außen erreichbar ist,  
 muss der Zugriff konsequent über den Nginx Proxy Manager (NPM) und die interne Firewall geschützt werden.  
 Dieser Schritt ist zwingend erforderlich, um unbefugten Zugriff auf dein System zu verhindern.
 #### Zugriff über NPM absichern
 Öffne das Dashboard des **Nginx Proxy Manager**  
 und bearbeite den Proxy-Host `ollama.deinedomain.tld`.
 Wechsle in den Reiter **Access List**  
 und lege eine neue Zugriffsregel an:
 1. **Add Access List** → Name: `ollama-intern`  
 2. Unter *Access* aktiviere  
   - **Authorization:** „HTTP Basic Authentication“  
   - Lege einen sicheren Benutzernamen und ein starkes Passwort fest.  
 3. Unter *Access Control* wähle  
   - **Allow IP Addresses:** den internen Adressbereich deines UCC (z. B. `192.168.100.0/24`)  
   - Alle anderen Zugriffe werden automatisch blockiert.
 Speichern und im Proxy-Host diese Access-List aktivieren.
 > [!NOTE]  
 > Damit ist Ollama ausschließlich intern erreichbar  
 > und erfordert bei jedem Aufruf Benutzername und Passwort.
 👉 **Screenshot geeignet:** NPM-Dashboard mit aktivierter Access-List „ollama-intern“
 #### Zugriff testen
 Von einem erlaubten Container (z. B. n8n-LXC):
 ```bash
 curl -u benutzername:passwort -k https://ollama.deinedomain.tld/api/tags
 ```
 Wenn du die korrekten Zugangsdaten angibst,  
 antwortet die API wie gewohnt mit der Modellliste.  
 Ohne Authentifizierung oder von einer nicht freigegebenen IP  
 erscheint die Meldung `403 Forbidden`.
 👉 **Screenshot geeignet:** Terminalausgabe mit erfolgreicher Authentifizierung
 #### Firewall-Regeln im Ollama-LXC setzen
 Der API-Port 11434 muss zusätzlich auf Systemebene abgesichert werden.  
 Erlaubt wird ausschließlich der Zugriff vom NPM-Container.  
 Führe im Ollama-LXC folgende Befehle aus:
 ```bash
 ufw allow from <IP-des-NPM-Containers> to any port 11434
 ufw deny 11434
 ufw enable
 ```
 Anschließend den Status prüfen:
 ```bash
 ufw status numbered
 ```
 Die Ausgabe sollte zeigen, dass **nur die NPM-IP** Zugriff auf Port 11434 hat.
 👉 **Screenshot geeignet:** Terminalausgabe von `ufw status numbered` mit aktiver Regel
 > [!IMPORTANT]  
 > Ohne diese Firewall-Regeln bleibt der Port im internen Netz offen.  
 > Das wäre ein kritisches Sicherheitsrisiko – führe diesen Schritt daher immer durch.
 #### Ergebnis
 Die Ollama-API ist jetzt:
 - nur über den internen Proxy erreichbar,  
 - durch HTTP-Authentifizierung geschützt,  
 - über die Firewall auf NPM-IP beschränkt,  
 - und damit vollständig abgeschottet gegen direkten Zugriff.
 Das System ist damit sicher, stabil und bereit  
 für alle weiteren Integrationen innerhalb deines UCC.
 ### Schritt 8 – Nutzung über die lokale CLI
 Neben der API kannst du Ollama auch direkt im Container verwenden.  
 Das ist der schnellste Weg, um Modelle zu testen, einfache Texte zu generieren oder Systemfunktionen zu prüfen –  
 ohne dass eine Netzwerkverbindung oder Proxy nötig ist.
 Alle Befehle in diesem Schritt führst du **innerhalb des Ollama-Containers** aus,  
 entweder über die Proxmox-Konsole oder per SSH:
 ```bash
 ssh root@<IP-des-Ollama-Containers>
 ```
 Nach dem Login steht dir die Ollama-CLI zur Verfügung.
 #### Verfügbare Modelle anzeigen
 Um zu prüfen, welche Modelle auf deinem System vorhanden sind:
 ```bash
 ollama list
 ```
 Beispielausgabe:
 ```
 NAME         ID              SIZE      MODIFIED
 mistral      5d43f1d3bdfd    4.1GB     3 days ago
 phi3         e2412cd927a8    2.8GB     2 days ago
 ```
 👉 **Screenshot geeignet:** Terminalausgabe mit sichtbaren Modellen
 #### Interaktive Sitzung starten
 Um direkt mit einem Modell zu interagieren, starte es über:
 ```bash
 ollama run mistral
 ```
 Sobald die Eingabeaufforderung (`>>>`) erscheint, kannst du Fragen stellen:
 ```
 >>> Was ist ein Homelab?
 Ein Homelab ist eine private IT-Umgebung, in der Systeme, Server und Netzwerke
 zu Lern- oder Testzwecken betrieben werden.
 ```
 Beende die Sitzung mit `CTRL + C`.
 👉 **Screenshot geeignet:** Terminal mit laufender Mistral-Sitzung und Antwort
 #### Einmalige Abfrage (non-interaktiv)
 Für einfache Einzelfragen kannst du den Prompt direkt mitgeben:
 ```bash
 ollama run mistral "Erkläre kurz den Unterschied zwischen Container und virtueller Maschine."
 ```
 Das Modell gibt eine einmalige Antwort zurück und beendet sich automatisch.
 #### Modelle wechseln
 Du kannst jederzeit ein anderes Modell verwenden:
 ```bash
 ollama run phi3
 ```
 Phi-3 eignet sich besonders für kreative Texte, Storylines oder Ideenentwürfe.
 #### Modelle aktualisieren oder löschen
 Aktualisieren:
 ```bash
 ollama pull mistral
 ```
 Entfernen:
 ```bash
 ollama rm phi3
 ```
 > [!NOTE]  
 > Der Befehl `pull` benötigt eine aktive Internetverbindung, um das Modell neu zu laden.  
 > In Offline-Umgebungen bleiben vorhandene Modelle funktionsfähig.
 #### Beispiel: praktische Nutzung
 ```bash
 ollama run mistral "Schreibe eine kurze Streamankündigung für Bratonien_TV."
 ```
 Erwartete Antwort:
 ```
 "🎬 Der Stream ist live! Willkommen zu einem neuen Abend voller Chaos, Magie und Möhrenpower."
 ```
 👉 **Screenshot geeignet:** Terminalausgabe mit generierter Beispielantwort
 #### Ergebnis
 Ollama ist jetzt vollständig nutzbar:
 - Du kannst Modelle direkt über die CLI starten.  
 - Anfragen funktionieren ohne Internetverbindung.  
 - Alle Aktionen laufen lokal im Container.  
 ## Troubleshooting & Tipps
 Ollama läuft im Normalbetrieb sehr stabil. Trotzdem kann es – besonders auf älterer Hardware oder bei ersten Installationen – zu Problemen kommen.  
 In diesem Abschnitt lernst du, wie du typische Fehler erkennst, Ursachen findest und dein System stabil hältst.
 ### Ollama startet nicht
 Wenn Ollama sich nicht starten lässt oder direkt wieder beendet wird, liegt das meist an zu wenig Arbeitsspeicher oder beschädigten Dateien.
 #### Arbeitsspeicher prüfen
 Ollama lädt komplette Modelle in den RAM.  
 Ist zu wenig Speicher frei, startet der Dienst gar nicht erst oder bricht beim Laden ab.
 ```bash
 free -h
 ```
 In der Zeile **Mem:** siehst du, wie viel Arbeitsspeicher belegt ist und wie viel noch frei ist.  
 Wenn weniger als 2 GB frei sind, reicht das nicht aus, um ein Modell zu laden.  
 Starte den Container neu, um Arbeitsspeicher freizugeben:
 ```bash
 reboot
 ```
 > [!NOTE]  
 > Bei 8 GB Gesamtspeicher sollte Ollama mindestens 6 GB reserviert bekommen.  
 > Andernfalls kann das Modell nicht stabil geladen werden.
 #### Dienststatus prüfen
 Wenn genug Speicher vorhanden ist, prüfe, ob der Dienst aktiv ist:
 ```bash
 systemctl status ollama
 ```
 Wenn dort **inactive** oder **failed** steht, starte ihn neu:
 ```bash
 systemctl restart ollama
 ```
 Zeigt der Status anschließend **active (running)**, läuft der Dienst korrekt.  
 Wenn er erneut fehlschlägt, schaue dir die Logdateien an.
 #### Logdateien prüfen
 ```bash
 journalctl -u ollama -xe
 ```
 Die Ausgabe zeigt, warum der Dienst nicht startet.  
 Häufige Ursachen sind:
 - beschädigte oder unvollständige Modelldateien  
 - kein freier Speicherplatz auf der Systempartition  
 - fehlende Berechtigungen  
 Wenn ein Modell beschädigt ist, entferne es und lade es neu:
 ```bash
 ollama rm mistral
 ollama pull mistral
 ```
 > [!TIP]  
 > Wenn Ollama nach einem Neustart automatisch wieder startet, ist alles korrekt konfiguriert.  
 > Sollte der Dienst dauerhaft ausfallen, prüfe die Datei `/etc/systemd/system/ollama.service`.  
 > Achte darauf, dass dort `Restart=always` gesetzt ist.
 ### Modelle reagieren nicht oder brechen ab
 Wenn ein Modell zwar startet, aber nicht antwortet oder mitten im Text abbricht, liegt das meist an Speicherproblemen oder unvollständigen Downloads.
 #### Modellverfügbarkeit prüfen
 ```bash
 ollama list
 ```
 Wenn das Modell fehlt oder eine ungewöhnliche Größe hat, lade es neu:
 ```bash
 ollama pull mistral
 ```
 #### Testlauf mit Debug-Informationen
 ```bash
 ollama run mistral -v
 ```
 Der Parameter `-v` zeigt dir den Fortschritt beim Laden.  
 Wenn der Prozess bei „Loading model…“ stehen bleibt, hat Ollama nicht genug RAM oder die Datei ist defekt.
 > [!NOTE]  
 > Beende alle laufenden Sitzungen mit `CTRL + C`, bevor du ein neues Modell startest.  
 > Mehrere aktive Prozesse können den Speicher blockieren.
 ### API antwortet nicht
 Wenn du über den Browser oder per `curl` keine Antwort erhältst, kann die Verbindung zwischen Ollama und dem Nginx Proxy Manager (NPM) unterbrochen sein.
 #### Verbindung prüfen
 Prüfe zunächst, ob der Ollama-Dienst läuft:
 ```bash
 systemctl status ollama
 ```
 Wenn er aktiv ist, teste die direkte Verbindung aus dem NPM-Container:
 ```bash
 curl http://<IP-des-Ollama-Containers>:11434/api/tags
 ```
 Wenn keine Antwort kommt, stimmt etwas mit der Firewall oder dem Routing nicht.
 #### Firewall-Regeln prüfen
 ```bash
 ufw status numbered
 ```
 Achte darauf, dass die IP-Adresse des NPM-Containers für Port 11434 freigegeben ist.  
 Wenn keine entsprechende Regel vorhanden ist, füge sie hinzu:
 ```bash
 ufw allow from <IP-des-NPM-Containers> to any port 11434
 ufw reload
 ```
 Danach den Zugriff erneut testen.  
 Wenn du dich vertippt hast, kannst du falsche Regeln mit  
 ```bash
 ufw delete <Nummer>
 ```  
 entfernen. Die Nummer siehst du in der Ausgabe von `ufw status numbered`.
 > [!TIP]  
 > Wenn der Browser trotz korrekter Firewall keine Verbindung aufbaut, starte den NPM-Container neu:  
 > ```bash
 > docker restart npm-app
 > ```
 ### Modelle laden nicht oder brechen beim Download ab
 Wenn `ollama pull` mit Fehlermeldungen stoppt oder sehr langsam lädt, liegt das meist an DNS-Problemen oder instabiler Verbindung.
 #### Internetverbindung prüfen
 ```bash
 ping google.com
 ```
 Wenn keine Antwort kommt, fehlt die Netzverbindung.  
 Prüfe die DNS-Einstellungen:
 ```bash
 cat /etc/resolv.conf
 ```
 Falls die Datei leer ist oder fehlerhafte Einträge enthält, setze die Nameserver neu (z. B. `1.1.1.1` oder `8.8.8.8`).
 #### Download neu starten
 Wenn ein Modell unvollständig heruntergeladen wurde, entferne es und lade es neu:
 ```bash
 ollama rm mistral
 ollama pull mistral
 ```
 > [!NOTE]  
 > Wenn die Verbindung regelmäßig abbricht, liegt das Problem meist am Hostnetzwerk oder einer Proxy-Instanz.  
 > Teste den Download direkt im Hostsystem – wenn er dort stabil ist, prüfe die Container-Netzwerkkonfiguration.
 ### Hohe CPU- oder RAM-Auslastung
 Wenn Ollama dauerhaft hohe CPU-Last oder Speicherverbrauch zeigt, liegt das meist an zu vielen gleichzeitig laufenden Prozessen.
 ```bash
 htop
 ```
 Damit kannst du sehen, welches Modell gerade aktiv ist.  
 Beende unnötige Prozesse mit:
 ```bash
 pkill ollama
 ```
 Starte den Container anschließend neu, um Speicher freizugeben:
 ```bash
 reboot
 ```
 Wenn die Auslastung danach weiter hoch bleibt, erhöhe die CPU-Zuteilung oder reduziere die Anzahl gleichzeitig geladener Modelle.
 > [!TIP]  
 > Eine dedizierte CPU-Zuweisung in Proxmox (z. B. 2 Kerne fest, keine Lastverteilung) sorgt für stabileres Verhalten.
 ### Logdateien und Statusüberwachung
 Ollama protokolliert alle Ereignisse über das Systemjournal.  
 Das ist hilfreich, um Startverhalten und API-Aufrufe nachzuvollziehen.
 ```bash
 journalctl -u ollama -f
 ```
 Damit siehst du in Echtzeit, welche Anfragen ankommen und ob Fehler auftreten.
 > [!TIP]  
 > Wenn Ollama längere Zeit stabil läuft, ändere an der Grundkonfiguration nichts.  
 > Teste neue Modelle oder Versionen immer zuerst in einem separaten Container.  
 > Das verhindert Konflikte und sichert dir ein zuverlässiges Hauptsystem.
 ---
 ## Ergebnis
 Mit diesem Kapitel hast du ein voll funktionsfähiges, lokales KI-System in dein UCC integriert.  
 Ollama läuft stabil, ist abgesichert und kann sowohl über die Konsole als auch über die interne API genutzt werden.  
 Alle Vorgänge bleiben vollständig innerhalb deiner eigenen Infrastruktur – keine Cloud, keine externen Server, keine Abhängigkeiten.
 ### Dein aktueller Stand
 - **Ollama-Container** ist eingerichtet und betriebsbereit  
 - **API-Zugriff** funktioniert sicher über den internen Proxy  
 - **Modelle Mistral und Phi-3** sind geladen und getestet  
 - **Firewall- und Zugriffsschutz** sind aktiv  
 - **CLI-Nutzung** erlaubt direkte Arbeit im Container  
 - **Fehlerdiagnose und Logs** sind bekannt und überprüft
 Damit steht dir nun ein autarkes, datensicheres KI-System zur Verfügung,  
 das sich in deine bestehende UCC-Umgebung nahtlos einfügt.  
 Du kannst Ollama direkt für eigene Projekte verwenden oder als Grundlage für zukünftige Erweiterungen nutzen.
 > [!TIP]  
 > In den erweiterten Kapiteln werden diese Grundlagen ausgebaut:  
 > Dort geht es um komfortablere Bedienung, Automatisierungen und erweiterte Einsatzmöglichkeiten –  
 > die Basis bleibt jedoch immer dein hier aufgebautes, lokales System.
 👉 **Screenshot geeignet:** Proxmox-Interface mit aktivem Ollama-Container, daneben NPM- und n8n-Container sichtbar