LOOM gemeinsam betreiben

⚠ Ein Schlüssel über eine unverschlüsselte Verbindung ist mitlesbar

Wenn euer Server ohne HTTPS im Internet steht, wandert der Zugangsschlüssel im Klartext durchs Netz — jeder auf dem Weg dorthin kann ihn abfangen und danach als euer Teammitglied hereinspazieren. Dann steht euer Project Memory offen: eure Namen, eure Entscheidungen, eure ganze Diplomarbeits-Geschichte.

Die eine Frage, die alles entscheidet: habt ihr eine öffentliche IP?

Nur mit einer öffentlichen IP-Adresse kann jemand von außen zu euch verbinden. Testet es auf der Maschine, die den Server spielen soll:

curl -s https://api.ipify.org; echo

Vergleicht die Ausgabe mit der WAN-Adresse in eurem Router/Modem. Sind sie verschieden — oder beginnt die Router-Adresse mit 100.64. bis 100.127. — dann sitzt ihr hinter dem Provider-NAT: Portfreigabe und DynDNS bleiben wirkungslos, Weg 3 fällt aus.

Wichtig für Mobilfunk (4G/5G): dort ist Provider-NAT der Normalfall — aber kein Schicksal. Bei den österreichischen Anbietern könnt ihr für eure SIM eine öffentliche IP anfordern; danach genügt ein kleiner Router, und Weg 3 steht euch offen. Ein Anruf, kein Umbau.

Kurz zum Selbst-Einordnen

Ihr arbeitet ohnehin meist gemeinsam vor Ort? → Weg 1, fangt heute an. · Ihr wollt von zuhause dran und habt keine öffentliche IP? → Weg 2. · Ihr betreibt eine eigene VM oder einen Server und wollt, dass Außenstehende ohne Installation zugreifen können? → Weg 3.

Ehrlich dazu: Weg 2 haben wir selbst noch nicht im Schulbetrieb erprobt, und wie viele Geräte der kostenlose Tailscale-Tarif erlaubt, solltet ihr vor der Entscheidung nachsehen. Wenn ihr Erfahrungen macht — gute wie schlechte — sagt uns Bescheid.

Schritt für Schritt, mit jedem Befehl

Diese fünf Zeilen sind die Kurzfassung. Wenn ihr Weg 3 wirklich einrichtet, nehmt die ausführliche Weg-3-Anleitung — neun Schritte von der IP-Prüfung bis zum Dienst, geschrieben von einem Schüler, der es selbst gemacht hat.

Den Passwort-Hash erzeugen

Mit caddy hash-password — Caddy fragt nach dem Passwort und gibt den Hash aus, den ihr oben einsetzt. Das Passwort selbst steht nie in der Datei.

Wenn euch das zu viel ist — das ist völlig in Ordnung

Ihr müsst diesen Weg nicht gehen. Weg 1 und Weg 2 oben brauchen keine Portfreigabe, kein Zertifikat und keines dieser Regelwerke — und ihr könnt jederzeit später umsteigen. Ein Team, das mit Weg 1 anfängt und arbeitet, ist besser dran als eines, das an Weg 3 hängen bleibt.

Nur für Linux: welche Architektur habt ihr?

Auf der Maschine, die den Server spielen soll, im Terminal:

uname -m

Die Antwort sagt euch das Paket:

⚠ Ehrlich gesagt: auf einem echten Pi haben wir es noch nicht laufen sehen

Das ARM-Paket ist gebaut und wurde in einer echten ARM-Linux-Umgebung gestartet — LOOM antwortet dort, die Hilfe-Seiten werden ausgeliefert, im Start-Protokoll steht kein Fehler. Was nicht geprüft ist: euer Pi mit eurem Betriebssystem-Abbild, und ob seine Leistung im Alltag reicht. Ihr seid die Ersten. Wenn etwas klemmt, ist das ein Befund und kein Anwenderfehler — sagt Bescheid, wir wollen es genau wissen.

Wer darf den Modus ändern?

Wer die Datei bearbeiten kann. LOOM hat dafür keine eigene Rolle — wer Zugriff auf den Server hat, betreibt ihn. Das ist keine Lücke, sondern Absicht: eine Berechtigung weniger, die falsch stehen kann.

Wie stoppt ihr einen Team-Server?

Auf der Maschine, nicht im Browser. Im lokalen Modus hat LOOM oben rechts einen Aus-Knopf — auf einem Team-Server ist der bewusst nicht da: ein Klick würde LOOM für das ganze Team beenden, und daran ändert auch eine Anmeldung nichts. Stattdessen zeigt die Leiste dort einen Hinweis TEAM SERVER.

Läuft LOOM als Dienst (so richtet es die ausführliche Weg-3-Anleitung ein), dann:

Abmelden ist kein Stoppen. Nach dem Abmelden fragt LOOM wieder nach dem Zugangsschlüssel — dieser Bildschirm sieht aus wie ein ausgeschaltetes LOOM, aber der Server läuft weiter und hält seinen Port. Das hat schon ein Team gekostet, das genau das versucht hat.

⚠ Reihenfolge beachten — sonst sperrt ihr euch aus

Die Schlüssel werden im lokalen Modus erzeugt, bevor ihr auf hosted umstellt. Sonst braucht ihr zum Anmelden einen Schlüssel, den ihr nur im angemeldeten Zustand erzeugen könntet.

Schlüssel verloren?

Einfach einen neuen erzeugen — der alte hört im selben Moment auf zu funktionieren. Es gibt kein „Passwort vergessen", weil es kein Passwort gibt.

Wo die Schlüssel liegen

Neben app-settings.yaml auf der Maschine, und zwar nur als Prüfsumme — der Schlüssel selbst steht nirgends. Er landet nie in eurem Projekt-Ordner, denn der liegt in Git und wäre damit in jedem Klon.

Live-Aktualisierung braucht Durchlass

LOOM hält eine offene Verbindung nach /api/events, um Änderungen zu melden. Manche Reverse Proxys puffern solche Verbindungen und halten sie zurück. Bei Caddy funktioniert es out of the box; bei nginx braucht es proxy_buffering off; und eine großzügige proxy_read_timeout.

Ollama muss LOOM hereinlassen

Euer Ollama nimmt standardmäßig nur Anfragen vom eigenen Rechner an — LOOM kommt aber vom Server. Das gilt pro Gerät: jede und jeder, der die KI benutzen will, setzt das einmal auf dem eigenen Rechner, nicht auf dem Server.

Dasselbe sagt euch LOOM auch selbst, wenn es klemmt — die Karte im Dashboard nennt die Zeile für euer System.

Wenn es trotzdem nicht wirkt (macOS)

Zwei Dinge scheitern hier lautlos, und beide haben uns schon einen Vormittag gekostet:

Nach jedem Neustart des Macs — ein Block statt vier Handgriffe

Weil die Einstellung auf dem Mac das Hochfahren nicht überlebt, braucht ihr sie danach erneut. Diese vier Zeilen erledigen alles auf einmal — setzen, stoppen, starten, prüfen. Einfach am Stück ins Terminal einfügen. Windows und Linux brauchen das nicht: dort bleibt die Einstellung gespeichert.

launchctl setenv OLLAMA_ORIGINS "*"
killall Ollama; pkill -x ollama; sleep 3
open -a Ollama; sleep 8
curl -s -o /dev/null -w "%{http_code}\n" -H "Origin: https://euer-server" http://localhost:11434/api/tags

Die letzte Zeile ist das Urteil: 200 heißt, es wirkt — ihr könnt LOOM neu laden. 403 heißt, der Wert ist nicht im laufenden Ollama angekommen; dann hat wahrscheinlich das Beenden nicht funktioniert (siehe Kasten darüber). Setzt für euer-server die Adresse ein, unter der ihr LOOM aufruft.

Dauerhaft — für Erfahrene (macOS)

Wer den Block nicht nach jedem Hochfahren einfügen will, kann ihn dem Mac überlassen. Dieser Block richtet eine kleine Hilfe ein, die bei jeder Anmeldung läuft: sie setzt den Wert, wartet auf Ollama, fragt Ollama selbst — und startet es nur dann neu, wenn es LOOM noch abweist. Lässt Ollama LOOM schon herein, passiert nichts.

Das ist bewusst die zweite Stufe, nicht die erste: die Hilfe beendet bei Bedarf eine fremde App (Ollama). Wenn ihr nicht sicher seid, was das heißt, bleibt beim Block oben — der reicht.

mkdir -p ~/.loom ~/Library/LaunchAgents ~/Library/Logs
cat > ~/.loom/ollama-origins.sh <<'EOF'
#!/bin/bash
# LOOM: after every login, make sure the running Ollama lets the team server in.
# Sets the value, waits for Ollama, asks Ollama itself, and restarts it only if it says no.
probe() { curl -s -o /dev/null -w "%{http_code}" -H "Origin: https://loom-check.invalid" http://localhost:11434/api/tags; }
launchctl setenv OLLAMA_ORIGINS "*"
for i in $(seq 1 60); do [ "$(probe)" != "000" ] && break; sleep 2; done
if [ "$(probe)" = "000" ]; then echo "$(date '+%F %T') Ollama is not running - value set for its next start"; exit 0; fi
if [ "$(probe)" = "200" ]; then echo "$(date '+%F %T') ok - Ollama already lets LOOM in"; exit 0; fi
killall Ollama 2>/dev/null; pkill -x ollama 2>/dev/null
for i in $(seq 1 15); do lsof -nP -iTCP:11434 -sTCP:LISTEN >/dev/null || break; sleep 1; done
open -a Ollama
# Ollama may restart itself a few times (an update at login does) - judge only after it settled.
for i in $(seq 1 30); do [ "$(probe)" = "200" ] && break; sleep 2; done
echo "$(date '+%F %T') restarted Ollama - check says $(probe) (200 = it works)"
EOF
cat > ~/Library/LaunchAgents/loom.ollama-origins.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>loom.ollama-origins</string>
  <key>ProgramArguments</key><array><string>/bin/bash</string><string>$HOME/.loom/ollama-origins.sh</string></array>
  <key>RunAtLoad</key><true/>
  <key>StandardOutPath</key><string>$HOME/Library/Logs/loom-ollama-origins.log</string>
  <key>StandardErrorPath</key><string>$HOME/Library/Logs/loom-ollama-origins.log</string>
</dict></plist>
EOF
LOG=~/Library/Logs/loom-ollama-origins.log; BEFORE=$(cat "$LOG" 2>/dev/null | wc -l)
launchctl bootout gui/$(id -u)/loom.ollama-origins 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/loom.ollama-origins.plist
for i in $(seq 1 90); do [ "$(cat "$LOG" 2>/dev/null | wc -l)" -gt "$BEFORE" ] && break; sleep 1; done; tail -1 "$LOG"

Die letzte Ausgabe ist wieder das Urteil, und die Hilfe schreibt es bei jeder Anmeldung mit: tail ~/Library/Logs/loom-ollama-origins.log. ok oder check says 200 heißt: es wirkt. check says 403 heißt: das Beenden hat nicht geklappt — dann hilft der Kasten „Wenn es trotzdem nicht wirkt" oben.

Geprüft am 3. Oktober 2026 mit einem echten Neustart (macOS 27.0.1): ohne irgendetwas einzufügen ließ Ollama danach den Team-Server herein. Ollama hat sich beim Anmelden dabei selbst aktualisiert und dafür mehrmals neu gestartet — deshalb wartet die Hilfe, bis es zur Ruhe kommt, bevor sie urteilt. Den Block erneut einzufügen ist unbedenklich: er ersetzt die vorhandene Hilfe.

launchctl bootout gui/$(id -u)/loom.ollama-origins
rm -f ~/Library/LaunchAgents/loom.ollama-origins.plist ~/.loom/ollama-origins.sh
launchctl unsetenv OLLAMA_ORIGINS
killall Ollama; pkill -x ollama; sleep 3; open -a Ollama

Und wieder zurück — wenn das Projekt vorbei ist

Das * heißt jede Herkunft. Für euren Team-Server ist das richtig, aber es bleibt auf eurem privaten Gerät stehen, bis ihr es zurücknehmt:

Ollama danach neu starten, genau wie beim Setzen. — Ehrlich gesagt: den Mac-Weg kennen wir inzwischen gut — und wissen deshalb, dass er nur bis zum nächsten Hochfahren hält. Windows und Linux haben wir bis heute nicht selbst nachgeprüft; läuft es bei euch anders, sagt uns Bescheid — dann korrigieren wir die Seite.

Safari und https — warum die KI dort ausbleibt

Läuft euer Team-Server über https (Weg 3), ruft LOOM euer Ollama unter http://localhost:11434 auf. Safari erlaubt einer https-Seite keinen Aufruf einer http-Adresse — auch nicht auf dem eigenen Rechner. Die Anfrage verlässt den Browser gar nicht erst; Ollama sieht sie nie. Deshalb hilft hier keine Einstellung an Ollama, auch nicht OLLAMA_ORIGINS.

Ehrlich gesagt: Firefox haben wir noch nicht geprüft. Klappt es bei euch dort, sagt uns Bescheid — dann nehmen wir es hier auf.