MiBee Steward v0.7.3 ersetzt Go-Agent durch Rust und erzwingt Schema-Resets

Am 12. Oktober 2026 veröffentlichte der Entwickler hinter MiBee Steward die Version 0.7.3, ein bedeutendes Update für das selbst gehostete Netzwerk-Monitoring-Tool. Diese Veröffentlichung enthält eine Breaking Change, die den Start mit Datenbanken aus früheren Versionen verweigert und Benutzer zu einem neuen Scan zwingt. Zudem wird der in Go geschriebene verteilte Agent durch eine neue Implementierung in Rust ersetzt, um die Leistung auf Hardware mit geringen Ressourcen zu verbessern.

Was ist passiert

Die unmittelbarste Auswirkung für bestehende Nutzer ist die bewusste Ablehnung alter Datenbankdateien. MiBee Steward v0.7.3 startet nicht, wenn es eine Datenbank von v0.6 oder früher erkennt, noch akzeptiert es Datenbanken von v0.7.0 bis v0.7.2. Der Entwickler hat die komplexe Migrationskette beim Start entfernt, die zuvor inkrementelle Updates ermöglichte und zu Parallel-DDL-Fehlern führte, bei denen teilweise Schemaänderungen das System in einem inkonsistenten Zustand hinterließen. Stattdessen prüft die Binary nun, ob die Schemaversion in der Datenbank mit der einzigen Quelle der Wahrheit in db/schema.sql übereinstimmt. Wenn dies nicht der Fall ist, beendet sich die Anwendung sauber, um Datenkorruption zu verhindern.

Für das Upgrade müssen Administratoren ihre bestehenden Daten sichern, die neue Binary gegen ein leeres Datenverzeichnis starten und dem System erlauben, die Asset-Tabelle durch einen neuen Netzwerkscan neu zu befüllen. Dieser Prozess gilt auch für die lokale Mini-Datenbank des Agents, was bedeutet, dass Scan-Historie und lokal gespeicherte SNMPv3-Zugangsdaten nicht migriert werden. Der Entwickler betont, dass dieser harte Reset sicherstellt, dass kein Teilzustand übrig bleibt, der das System während des Betriebs verwirren könnte.

Ein wesentlicher architektonischer Wandel in dieser Veröffentlichung ist der Ersatz des Go-basierten verteilten Agents durch eine Rust-Version. Der neue Agent, im Verzeichnis agent-rs/ lokalisiert, erzeugt statische musl-Builds für die Architekturen amd64, arm64 und armv7. Während die Konfigurationsdatei agent.yaml kompatibel bleibt, um manuelle Bearbeitungen zu vermeiden, hat sich die zugrunde liegende Laufzeitumgebung erheblich geändert, um ältere Hardware mit begrenztem Speicher zu unterstützen. Der Entwickler testete diese Änderung auf einem NanoPi NEO mit 512 MB RAM und verglich die Ressourcennutzung der beiden Implementierungen über zwei Tage hinweg durch Stichprobenmessung.

Wichtige Details

• Datenbank-Kompatibilität: v0.7.3 weigert sich, mit jeder Datenbank von v0.6 oder älter sowie v0.7.0–v0.7.2 zu starten, und erzwingt so einen sauberen Schema-Zustand.
• Agent-Umschreibung: Der verteilte Agent ist nun in Rust geschrieben und ersetzt die vorherige Go-Implementierung, um den Speicherverbrauch zu reduzieren und die Stabilität zu verbessern.
• Leistungsmetriken: Auf einem NanoPi NEO nutzte der Rust-Agent median 12 MB RSS im Vergleich zu 54 MB beim Go-Agenten, mit einer deutlich engeren Varianz (11–12 MB vs. 38–63 MB).
• Durchsatzsteigerung: Der Rust-Agent erreichte etwa den 1,7-fachen Durchsatz des Go-Agenten bei einem /24-Subnetz-Sweep auf derselben Hardware.
• Föderationsunterstützung: Die Veröffentlichung fügt schreibgeschützte Föderation zwischen zwei Zentren hinzu, sodass jede Seite die Geräte der anderen sehen kann, ohne Zugangsdaten preiszugeben oder Remote-Befehle zu ermöglichen.
• Topologie-Korrekturen: Updates umfassen eine bessere Handhabung von Multi-Homed-Geräten, um Identitäts-Ping-Pong-Effekte zu verhindern, sowie eine verbesserte Root-Bridge-Erkennung unter Verwendung von STP-Port-Rollen.

Hintergrund

MiBee Steward ist ein Single-Binary-Netzwerk-Monitoring-Tool, das entwickelt wurde, um die Frage zu beantworten, welche Geräte in einem lokalen Netzwerk vorhanden sind. Es verwendet Go für die Hauptserver-Komponente mit dem Chi-Router und SQLite via modernc, um CGO-Abhängigkeiten zu vermeiden. Die Benutzeroberfläche ist mit SvelteKit gebaut und direkt in die Binary eingebettet. Das Tool identifiziert Geräte nach Anbieter, Typ, offenen Ports und Zertifikaten und bildet Nachbarschaftsbeziehungen ab. Es steht unter der Lizenz AGPL-3.0, wobei eine kommerzielle Dual-Lizenz für diejenigen verfügbar ist, die es in geschlossene Produkte oder gehostete Services forken möchten.

Der Wechsel von Go zu Rust für die Agent-Komponente spiegelt einen üblichen Trade-off in der Systemprogrammierung wider. Go bietet schnelle Entwicklung und starke Concurrency-Primitiven, kann aber aufgrund seines Garbage Collectors einen höheren Speicherverbrauch haben. Rust bietet zwar eine steilere Lernkurve, gewährleistet jedoch Speichersicherheit ohne Garbage Collector, was zu kleineren Binaries und vorhersagbarer Ressourcennutzung führt. Dies ist besonders wichtig für Edge-Geräte wie Einplatinencomputer, die möglicherweise nur 512 MB RAM haben und mehrere Dienste gleichzeitig ausführen.

Warum es wichtig ist

Für Teams, die ihre eigene Infrastruktur betreiben, ist die Entscheidung, die Datenbank-Kompatibilität zu brechen, eine erhebliche operative Überlegung. Während der Entwickler argumentiert, dass das Entfernen inkrementeller Migrationen eine Klasse subtiler Bugs im Zusammenhang mit teilweisen Schemaupdates eliminiert, auferlegt es den Nutzern einen manuellen Wiederherstellungsprozess. Administratoren müssen Downtime während des Rescan-Zeitraums einplanen, da die Asset-Tabelle leer sein wird, bis die neue Binary ihren Discovery-Zyklus abgeschlossen hat. Dies hebt die Spannung zwischen langfristiger Code-Wartbarkeit und kurzfristigem operativem Komfort in selbst gehoster Software hervor.

Die Leistungsverbesserungen durch den Rust-Agenten sind für Organisationen relevant, die ältere oder energieeffiziente Hardware für das Netzwerk-Monitoring nutzen. In Umgebungen, in denen jedes Megabyte RAM zählt, wie Homelabs oder kleine Büronetzwerke auf Einplatinencomputern, ist die Reduktion von ~54 MB auf ~12 MB median RSS erheblich. Das engere Memory-Band unterstützt auch die Kapazitätsplanung, da das System weniger wahrscheinlich plötzliche Spitzen erlebt, die Out-of-Memory-Kills auf eingeschränkten Geräten auslösen könnten.

Die Einführung der schreibgeschützten Föderation adressiert ein häufiges Bedürfnis verteilter Teams oder Multi-Site-Organisationen, die Sichtbarkeit über Netzwerke hinweg wünschen, ohne die Sicherheit zu gefährden. Indem eine Instanz die Geräteliste einer anderen ansehen kann, ohne Befehlszugriff zu gewähren, reduziert das Tool das Risiko lateraler Bewegung im Falle eines Kompromisses. Diese Designentscheidung stellt sicher, dass Bugs oder Schwachstellen in einem Zentrum nicht ausgenutzt werden können, um Geräte im Peer-Netzwerk zu kontrollieren, und hält eine strenge Sicherheitsgrenze zwischen administrativen Domänen aufrecht.

Was Sie tun können

• Backup vor dem Upgrade: Führen Sie das bereitgestellte Skript ./scripts/backup.sh aus, bevor Sie versuchen, v0.7.3 zu installieren, um kritische historische Daten zu sichern.
• Auf Rescan vorbereiten: Planen Sie ein Wartungsfenster für das Upgrade ein, da das System Zeit benötigt, um alle Assets im Netzwerk nach dem Start mit einer leeren Datenbank wiederzufinden.
• Agent-Konfigurationen aktualisieren: Stellen Sie sicher, dass Ihre agent.yaml-Dateien für den neuen Rust-Agenten bereit sind; obwohl das Format kompatibel bleibt, überprüfen Sie Pfade und Berechtigungen für die neue Binary.
• Auf Zielhardware testen: Wenn Sie ressourcenarme Geräte verwenden, deployen Sie den neuen Rust-Agenten zuerst auf einer Testeinheit, um zu bestätigen, dass die statischen musl-Builds korrekt mit Ihrer spezifischen Kernel-Version funktionieren.
• Föderations-Einstellungen prüfen: Wenn Sie die neue Föderationsfunktion nutzen möchten, generieren Sie Auth-Tokens auf der Peer-Seite und konfigurieren Sie die Einstellungen center_url und cidr sorgfältig, um die Exposition zu begrenzen.
• Topologie-Graphen prüfen: Überprüfen Sie nach dem Upgrade, ob der Topologie-Graph die Root-Bridge korrekt identifiziert und ob Multi-Homed-Geräte im UI nicht mehr zwischen Segmenten hin- und herspringen.