Komodo-MCP, ANAS, Changerawr: drei Wochenend-Projekte von innen gelesen

Freitagabend kursiert eine Liste mit sieben Projekten für das Heimnetz-Wochenende: ein TrueNAS-Plugin für Proxmox, ein Changelog-System, ein MCP-Server für Komodo, ein NAS-Aufsatz für Proxmox-Knoten, Proxmox auf ARM64, Notfallzugänge vor dem Single-Sign-On und Regeln gegen ungewollte Nachbarschaften im Cluster.

Über Punkt 1, das TrueNAS-Plugin, haben wir schon am Quelltext geschrieben: Architektur sauber, Betriebsstand offiziell Beta. Die drei nächsten Punkte waren auf Deutsch bisher nirgends von innen beschrieben. Wir haben Lizenzdatei, Issue-Tracker und Quelltext gelesen und eins der drei Werkzeuge im Labor ausgeführt. Bei keinem der drei sitzt das Problem dort, wo die Empfehlung steht.

Gelesen werden vier Dateien. Die Lizenzdatei selbst, nicht das Abzeichen in der Seitenleiste. Der Issue-Tracker, das einzige Artefakt, das ein Projekt nicht für sich sprechen lassen kann. Contributor-Zahl und Alter des Repos, denn Commits erzeugt heute ein Agent im Schlaf. Und die Frage, was das Werkzeug auf dem Host anfasst. Die Messung im eigenen Bestand kommt unten.

Alle drei haben keine SECURITY.md. Keins der drei Projekte hat einen Weg, einen Fehler vertraulich zu melden. Das ist für sich genommen die schlechteste gemeinsame Nachricht.

Komodo-MCP: die Steuerung ohne Schloss

Komodo ist ein Steuerungsprogramm für Container und Stapel (GPL-3.0, 12.340 Sterne, seit 2022 gepflegt). Der MCP-Server von MyrikLD übersetzt natürliche Sprache in dessen API. Die Readme beschreibt den Zustand ohne OAuth in einem Satz, und dieser Satz ist die Meldung:

„Without OAuth configured, the server accepts all connections without authentication."

Wir haben es nachgebaut: unveränderten Quelltext gestartet, ohne jede OAuth-Variable, gegen eine Komodo-Attrappe auf dem Loopback. Das Protokoll zeigt beide Zeilen, die dazugehören.

OAuth disabled — missing env vars: KOMODO_MCP_OAUTH_JWT_SECRET, KOMODO_MCP_OAUTH_PASSWORD, KOMODO_MCP_BASE_URL
Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

Danach ein einziger POST auf /, ohne Authorization-Feld und ohne MCP-Handschlag, den stateless_http=True ohnehin nicht verlangt. tools/list antwortet mit 200 und allen 53 Werkzeugen. tools/call mit delete_stack antwortet mit 200, und die Attrappe empfängt den Schreibaufruf, den API-Schlüssel bereits angehängt. update_stack reichte einen geänderten Compose-Inhalt mit volumes: ["/:/host"] und einer curl | sh-Zeile unverändert durch. Nach sechs Aufrufen bestand das Protokoll der Brücke aus einer Zeile Zugriffslog: Pfad, Statuscode. Kein Werkzeugname, keine Argumente, kein Anrufer.

Drei Befunde aus dem Quelltext, die die Readme nicht hergibt. Die 53 Werkzeuge kennen keine Leseschutzstufe, keinen Trockenlauf, keine erlaubbare Werkzeugliste, keinen Zustimmungsschritt. Alle sieben delete_*-Werkzeuge sind als unkritisch etikettiert (idempotentHint: True, openWorldHint: False, kein destructiveHint), dem Klienten wird also mitgeteilt, das Löschen eines Stapels sei zerstörungsfrei und wirke nicht nach außen. Und auch mit eingeschaltetem OAuth gilt ein gemeinsames Passwort für alle Klienten bei genau einem Gültigkeitsbereich, ohne Rollen und ohne Sperrschwelle am Anmeldeende.

Fairness halber die Gegenprobe: Es gibt eine unabhängig entstandene zweite Brücke für dasselbe Problem (nicolasestrem/komodo-mcp). Apache-2.0 als echte Datei, Bearer-Token mit konstantem Zeitvergleich, Logausgabe mit Schwärzung der Zugangsdaten, und ohne gesetztes Token bindet das Programm nur auf dem Loopback. Dieselbe Aufgabe, zwei Voreinstellungen. Die eine Variante ist eine Wahl, keine Notwendigkeit.

Komodo braucht außerdem gar keine Brücke, um mit Rechten umzugehen: Die Plattform hat ein eigenes Rollenmodell mit den Stufen None, Read, Execute und Write je Ressource. Ein Dienstbenutzer mit Read, ein befristeter Schlüssel, die Entscheidung im Steuerungsprogramm statt in einer offenen Brücke mit 53 Werkzeugen, das ist die Bauart, die zu unseren MCP-Grundsätzen passt. Der Nachweis im Labor kostet zehn Zeilen und verändert an einem laufenden System nichts:

curl -sS -X POST http://ZIEL:8000/ \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Kommt die Werkzeugliste zurück, steht der Befund im eigenen Protokoll statt in einem Blogartikel. Die Antwort kommt als Server-Sent-Events, das stört beim ersten JSON-Parsen.

ANAS: sauberer Kern, blinder Eingang

ANAS ist der Storage-Aufsatz, der Proxmox-Knoten zum NAS macht, mit Panels in der Proxmox-Oberfläche. Positiv zuerst, weil es den Rest glaubwürdiger macht. Eine echte Lizenzdatei (AGPL-3.0-or-later, von uns gelesen), 630 Commits, 19 Versionen seit Mitte Juli, 158 Sterne bei 8 Forks, drei offene Issues, und alle drei stammen von Fremden und fragen nach Funktionen statt nach Hilfe (#62 Samba-Papierkorb, #61 „Let ANAS work on PVE-Pool too", #57 Cloud-Synchronisierung). Auf zwölf Anfragen von außerhalb hat der Betreiber elf geantwortet, eine davon mit „Confirmed — excellent diagnosis".

Auch die Sicherheitsmechanik ist echt, nicht Deko. Zerstörende Eingriffe verlangen serverseitig einen vorab abgeholten Code, an 33 Stellen gerufen; zwölf Hexzeichen, zwei Minuten gültig, einmalig, gebunden an Operation und Parameter. Der Speicherpool, der die eigene Wurzel trägt, lässt sich nicht zerstören, es gibt keinen Übersteuerungspfad, und harte Abweisungen während eines laufenden Wiederaufbaus haben keine Übersteuerungskennung. mdadm --action=repair auf einem RAID1-Verbund verweigert der Code mit einem eigenen Prüfschritt, weil das Überkopieren des ersten in-sync-Beins ein halbes Mal Falsches billigen würde; der Prüfschritt ist absichtlich so eingebaut, dass es keinen Weg daran vorbei gibt. Befehle werden ausschließlich als Argumentliste über execFile oder spawn gebaut, nie durch eine Shell, Namen und Pfade sind zeichengesetzt geprüft, Passwörter laufen über die Standardeingabe statt über die Argumentliste. Und es gibt keinen Rechte-Beschleuniger im Projekt, keine sudoers-Datei, kein pkexec, keine setuid-Hilfe. Das ist mehr Sicherheitsdenken, als viele etablierte Produkte zeigen.

Die Befunde, die entscheiden, sitzen woanders.

Die wiederholte Patcherei. ANAS patcht Proxmox-eigene Dateien an Ort und Stelle: eine Skriptzeile in /usr/share/pve-manager/index.html.tpl, einen Proxy-Haken in /usr/share/perl5/PVE/APIServer/AnyEvent.pm. Damit ein Upgrade diese Stellen nicht verliert, legt der Installer einen apt-Haken ab, und der steht wörtlich so da (aus packages/pve-integration/install.sh, Zeile 413, von uns gelesen):

DPkg::Post-Invoke { "if [ -x ${SCRIPT_DIR}/install.sh ]; then ${SCRIPT_DIR}/install.sh || true; fi"; };

Nach jeder Pakettransaktion auf dem Hypervisor läuft damit der Installer von ANAS noch einmal, als Root, mit || true, damit ein Fehlschlag das apt nicht stört. Gemeint ist Selbstheilung, und sie ist sauber abgesichert, mit einem Syntaxtest vor dem Austausch und einer Sicherungskopie .anas-orig. Es bleibt ein Wurzel-Skript, das nach jedem apt-get upgrade von allein wieder ausgeführt wird. Dasselbe Paket holt Node.js über curl -fsSL https://deb.nodesource.com/setup_22.x | bash - und zieht Samba, nfs-kernel-server, targetcli-fb, mdadm und btrfs-progs nach, was ein Proxmox-Wirt nicht mitbringt; die Paketlaufwerke aktivieren und starten smbd und nfs-server dabei selbst. Aus dem Rechner, der fremde virtuelle Maschinen ausführt, wird ein Dateiserver im Netz. Und die Voreinstellung dieses neuen Dienstes ist dieselbe Fehlerkategorie wie beim MCP-Werkzeug: bind interfaces only ist nicht gesetzt, der ausgelesene Wert heißt no, Samba antwortet also auf jeder Schnittstelle, auch auf der Maschinenbrücke, bis jemand es einschränkt.

Der blinde Eingang. Die Anmeldung ist echte Kryptographie: Das Gateway prüft das PVEAuthCookie gegen /etc/pve/authkey.pub, Signatur, Zwei-Stunden-Fenster, dreihundert Sekunden Toleranz. Dahinter kommt nichts. Ein Suchlauf über Daemon- und Gateway-Quelltext nach Zugriffsprüfung ergibt null Treffer, kein pvesh, kein /access/, keine Rollenabfrage. Das projektinterne CLAUDE.md sagt es als Regel: „Add roles, permissions, or authorization logic — auth is binary." Wer ein gültiges Proxmox-Ticket hat, gleich aus welchem Realm und mit welchen Rechten, bekommt auf diesem Knoten Speicher-Gewalt bis zum Bestätigungscode. Und dieser Code ist ein Unfallpuffer, keine Autorisierung: Er geht an denselben Anrufer zurück, der damit herausgefordert wird, sein Prüfwert deckt Operation und Parameter ab, nie den Benutzer, und ein Neustart des Dienstes wirft alle offenen Herausforderungen weg.

Zwei Wahrheiten über dieselben Blöcke. Das ist der Satz, an dem für uns die Entscheidung fällt, und er ist im Quelltext belegbar. Eine Prüfung, ob ein ZFS-Volumen die Platte einer laufenden Maschine ist, existiert im Zerstörungspfad nicht; die Funktion isPveManagedPool wird für Replikation und Zeitpläne herangezogen und ist fehleroffen geschrieben (catch { return false }), im Zerstörungshandler fragt sie niemand. Ein rekursives zfs destroy -r braucht genau einen Bestätigungscode, die Zahl der Kinder geht als Warnung mit. Die Aufbewahrung räumt ungeplant auf: Ein Zeitplan ruft die Prüfmethode für Sicherungspunkte und damit zfs destroy ohne jeden Code, weil er aus dem Zeitplan läuft. Und die Prüfspur ist dünner als der Ton der Doku: protokolliert wird aus der Auftragswarteschlange, ein abgewiesener Zerstörungsvorschlag hinterlässt nichts, und der Auftragsspeicher ist eine Karte im Prozess.

Die Herkunftsfrage. Die beiden neuesten Versionen tragen ihre Tarballs nicht aus der Pipeline. Der Release-Lauf für v0.3.2 endete am 15. September nach 35 Sekunden mit Fehlerstatus, der für v0.3.1 ebenso; die Felder der Release-Schnittstelle zeigen als Hochlader der angebotenen Dateien das Betreiberkonto, bei v0.3.0 und v0.2.12 noch github-actions[bot]. Die Doku im Projekt sagt derweil über den Prozess: „Ultimately GitHub Actions builds the release artifacts." Kein signierter Commit, keine Attestierung, keine Prüfsumme in der Doku: nichts bindet die angebotene Datei an den markierten Stand. Die Pipeline selbst prüft Bau, Unit-Tests und Stillepost; die 19 Integrationsprüfungen brauchen eine lokale Proxmox-Attrappe und laufen auf GitHub nie. Auf 630 Commits kommen 33 Pipeline-Läufe, die letzten 100 Commits in 20 Tagen wurden in fünf Läufen geprüft, und 95 davon tragen einen KI-Autorschaftsvermerk. Ein zwei Monate altes Einzelpersonenprojekt mit 19 Versionen ist als solches erkennbar, wenn man diese vier Felder liest statt der Versionszahl.

Unsere Entscheidung: Testknoten ja, pve1 bis pve6 nein. Nicht wegen der Reife, sondern weil bei uns die Produktion über LINSTOR mit DRBD läuft, PBS die Sicherung fährt, und ein zweiter Storage-Grundriss mit eigenem Wurzel-Pfad auf demselben Knoten zwei Wahrheiten über dieselben Blöcke erzeugt. Dieselbe Rechnung haben wir bei Vitastor getroffen.

Changerawr: intern erlaubt, weitergegeben nicht

Changerawr ist ein Changelog-System (Next.js 16, Prisma, PostgreSQL, Node.js 24 oder neuer) und taugt als Betriebsjournal, wie die Empfehlung zu Recht sagt. Die Lizenzdatei ist eine firmeneigene „CHANGERAWR NON-COMMERCIAL OPEN SOURCE LICENSE" von Supernova Software, LLC, kein OSI-Standard. Der Text unterscheidet sauber zwischen zwei Dingen, die sonst vermischt werden: Betrieb in der eigenen Firma ist ausdrücklich erlaubt („Deploy the Software on your own infrastructure, including for use in commercial organizations and business operations"), Verkauf, Vermietung, bezahlte gehostete Instanzen und als eigener Punkt „Billing System Integration" sind verboten. Gerichtsstand ist der Sitz der LLC, ohne Verweis auf unser Recht. Für Eigenbetrieb klare Regeln, für alles, was wir bei Kunden betreiben oder in Auftragsverarbeitung gäben, Zweckbetrieb mit fremdem Gerichtsstand.

Der Tracker lohnt hier mehr als anderswo. Am 15. April 2026 eröffnete der Betreiber eine angeheftete Ausgabe „Security Vulns Found - please shut off your instance." mit dem Satz „At this time, I recommend that you shut off your instance. The next update will have all of these issues fixed." Geschlossen als erledigt am 16. April. Welche Schwachstellen gemeint waren, welche Version sie behebt, ob ein Meldepfad beteiligt war: nirgends im Repo nachzulesen. Am 18. September ist eine offene Ausgabe vorhanden, vom Betreiber selbst eröffnet. Am Rand liegen auf master eine CHANGELOG.md.backup-2026-04-16T07-12-45-733Z und ein package-lock.json.backup, und die mitgelieferte Compose-Datei startet zusätzlich einen Container mit KI-Tagger, der beim ersten Start rund 1 GB Modellgewichte lädt. 1.046 Commits bei 2 Wächtern ist Angebotsseite.

Unsere Konsequenz: Interner Betrieb wäre mit dieser Lizenz vertretbar, dokumentationspflichtig wegen Gerichtsstand und Lizenzkette. Der Vorfall vom April wäre bei uns meldepflichtig behandeltes Material gewesen, und wer so ein Werkzeug bewertet, liest den Tracker, bevor die Featureliste interessant wird; derselbe Griff ist bei uns Vorbereitung auf den NIS2-Fall. Für Kundenbetrieb: nein.

Zwei Punkte, die man korrigieren darf

ARM64 ist mehr, als die Liste sagt, und weniger für das, wofür die Liste es hält. Proxmox VE 9.2 für arm64 erschien am 5. August 2026 und ist keine Vorschau: „Proxmox VE on arm64 is fully supported on the platforms listed above, with the same release lifecycle and support windows as the x86-64 builds." Voll unterstützt sind aber genau zwei Familien (NVIDIA Grace Hopper, NVIDIA Vera), alles andere nur best effort, und ein Raspberry Pi ist ausdrücklich ausgeschlossen, weil ein arm64-Wirt über UEFI starten und seine Hardware über ACPI beschreiben muss. Dazu Live-Migration nur innerhalb derselben Architektur, Ceph auf arm64 erst ab Tentacle, arm64-Schlüssel nur auf Anfrage. Für uns ohne Folge, wir fahren x86. Für jeden Plan „Proxmox offiziell auf dem Pi" ist das die Antwort.

Notfallzugänge (Punkt 6) sind keine Wochenendaufgabe, sondern eine Regel. Bei uns läuft die Anmeldung über Keycloak und Authentik; ein lokaler Zugang, der den Verzeichnisdienst nicht braucht, ist Selbstverständnis. Messbar ist nicht, ob es ihn gibt, sondern wer ihn testet, bevor er gebraucht wird.

Und unsere eigene Messung

Punkt 7, redundante Maschinen unwissentlich auf demselben Knoten, ist der einzige Punkt ohne Werkzeugfrage. Also haben wir nachgemessen: Produktionscluster, sechs Knoten, Proxmox VE 9.2.20, 63 Gäste (61 Maschinen, 2 Vorlagen), Stand 18. September 2026, 23 Uhr.

Erstens: Die Regeln existieren bei uns seit Jahren, und sie heißen nicht /cluster/affinity. Im Bestand liegen sechs Regeln in /cluster/ha/rules: drei strenge Positiv-Regeln, die Gäste auf je ein Knotenpaar binden (pve1+pve2, pve3+pve4, pve5+pve6), und drei Negativ-Regeln, die je ein Redundanzpaar auseinanderhalten, DNS, Domaincontroller, Caddy. Die beiden DNS-Maschinen liegen damit auf pve1 und pve5, die Domaincontroller auf pve2 und pve6, die beiden Caddy auf pve2 und pve5. Das Beispiel der Empfehlung ist hier Produktionsrealität, nur mit dem echten API-Pfad.

Zweitens: Affinity-Regeln sind eine Hochavailable-Funktion, und das ist die Falle. Eingeführt mit Proxmox VE 9.0 am 5. August 2025, gültig ausschließlich für Ressourcen in /etc/pve/ha/resources.cfg, und die Erweiterung über die hochverfügbaren Dienste hinaus steht bis heute als nicht geliefertes Ziel auf der Straßenkarte. Der Abgleich beider Regelwelten bei uns: 58 Einträge in den HA-Ressourcen, davon zwei Vorlagen (ein Altlast, den wir aufräumen), und fünf aktive Maschinen außerhalb jeder Regel. Bei allen fünf ist der Grund plausibel und ungeschrieben, vier GPU-Arbeitsplätze und ein Terminalserver. Wer Punkt 7 der Liste nachbaut und nur auf die Verteilung schaut, sieht diese fünf nie. Die Asymmetrie muss man kennen: Regeln über Knotenmengen sind weich, erst strict macht sie zur Pflicht; Regeln über Ressourcenverbünde sind hart und setzen die Ressource im Fehlerfall in eine Wiederherstellungs- oder Fehlerlage.

Drittens: Der API-Pfad der Empfehlung existiert nicht. Bei uns antwortet GET /cluster/affinity mit 501 Not Implemented. Gemeint ist /cluster/ha/rules, gepflegt mit ha-manager rules. Und die Option affinity im Maschinenkonfig ist Kernzuweisung für CPU-Threads, keine Knotenplatzierung, was die Verwechslung erklärt. Die Antwort auf „läuft das bei uns schon?" ist zwei Zeilen lang:

pvesh get /cluster/resources --type vm --output-format json \
  | jq -r '.[] | [.node, .name] | @tsv' | sort | awk '{c[$1]++} END{for(n in c) printf "%-6s %s\n", n, c[n]}'

pvesh get /cluster/resources --type vm --output-format json \
  | jq -r '.[] | [.node, .name] | @tsv' \
  | awk -F'\t' '{ if (match($2,/-pve[0-9]+$/)) { w=substr($2,RSTART+1,RLENGTH-1);
      if (w!=$1) print "ABW  "$2"  gemeldet:"$1 } }'

Die erste Zeile liefert die Verteilung von oben. Die zweite prüft unsere Namensverabredung: 61 von 63 Gästen tragen ein -pveN im Namen, zwei tragen keines, und die Abweichung zwischen Name und tatsächlichem Knoten ist null. Eine Kontrolle war das nie, sie war eine Verabredung; prüfbar wird sie erst, seit ein Skript vergleicht. Gemeldet wird die Differenz, nicht der Aggregatwert, dieselbe Bauart wie beim Patch-Nachlauf. Das Heimnetz nebenan ist übrigens ein Ein-Knoten-Cluster: 22 Gäste auf pve7, 21 davon laufend. Dort stellt sich die Frage nach zwei Rechnern nicht, dort gibt es keinen zweiten.

Was wir jetzt anders machen

1. Lizenzdatei vor Funktionsliste. Vier Dateinamen durchcurlen kostet sechs Sekunden. Kein Lizenztext heißt keine Erlaubnis, nicht „wahrscheinlich in Ordnung".
2. Voreinstellung ist die Aussage, nicht die Möglichkeit. „Kann OAuth" beantwortet nicht die Frage, was beim üblichen Lauf entsteht. Wir fragen nach dem Zustand ohne jede Konfiguration und haben dafür jetzt pro Werkzeug einen zehn-Zeilen-Nachweis.
3. Angebotsseite ignorieren, Nachfrage zählen. Commits, Releases und Versionsnummern erzeugt man heute in beliebiger Menge, 95 von 100 Commits eines der Projekte tragen KI-Vermerke. Sterne, Wächter und Issues von Menschen ohne Projektbezug nicht.
4. Herkunft vor Version. Pipeline-Läufe und die Hochlader-Felder der Anhangdateien lesen, dann sieht man in einer Minute, ob die angebotene Datei aus der geprüften Pipeline stammt. Bei zwei der neunzehn Versionen war sie es nicht.
5. Autorisation ist nicht Authentifizierung. Ein korrekt prüfendes Ticket ohne Rollenmodell endet als Gewalt auf dem Knoten. Diese Frage steht bei uns vor jeder Featureabwägung.
6. Eine eigene Messung vor jeder Empfehlung. Zwei pvesh-Zeilen, und die Liste hat einen Bezugspunkt, den niemand kopieren kann.

Punkt 2 zahlt am schnellsten: eine Zeile Konfiguration, und ein Endpunkt, der bisher alles durfte, was im Netz steht, darf nur noch, was angemeldet ist.

Stand: 18. September 2026, 23 Uhr. Sterne, Wächter und Issue-Zahlen sind Momentaufnahmen dieses Abends. Die Messung am Cluster wiederholen wir vor jedem Audit und bei jeder Knotenänderung, und die fünf Gäste ohne HA-Regel haben einen Nachzieh-Auftrag.

Weiterführende Quellen

• Virtualization Howto: 7 New Home Lab Projects to Try This Weekend, 18. September 2026: die Liste, um die es hier geht
• Komodo-MCP (MyrikLD): Stand des Repos (Sterne, Wächter, Commits), Issue-Tracker, Lizenzpfad 404, pyproject.toml
• Vergleichsbrücke nicolasestrem/komodo-mcp mit Apache-2.0-Lizenzdatei
• Komodo-Plattform (moghtech/komodo) und Rollenmodell der Plattform
• ANAS (ccebelenski/anas): AGPL-3.0-Lizenzdatei, offene Issues, packages/pve-integration/install.sh, packaging/install.sh, Release-Lauf v0.3.2 mit Fehler
• Changerawr (Supernova3339/changerawr): Lizenztext „Non-Commercial Open Source License", Ausgabe #25 vom 15. April 2026
• Proxmox VE Roadmap: Affinity-Regeln mit 9.0, arm64 mit 9.2
• Proxmox VE Administration Guide, Kapitel 15.6.3 zu Node- und Ressourcen-Affinity, weichen und harten Regeln
• Support-FAQ zu Proxmox VE 9.2 für arm64 im Proxmox-Forum, Downloadseite mit arm64-Abbild, Bericht von heise online
• pvesh(1) und jq-Handbuch: Werkzeuge der zwei Zeilen
• Eigene Einordnungen: TrueNAS-Plugin für Proxmox, MCP-Server im Eigenbetrieb, Storage mit DRBD und LINSTOR, PBS und die 3-2-1-Regel, Patch-Nachlauf, Single-Sign-On mit Authentik und Keycloak