# NetBox aus realer Infrastruktur befüllen mit ToolMesh > Wie man mit ToolMesh-Konnektoren eine frische NetBox-Instanz aus Linode, Hetzner Cloud, Xen Orchestra und weiteren Quellen befüllt — mit einem vertrauensbildenden Ansatz vom Import bis zum Autopilot. Canonical: https://www.toolmesh.io/de/blog/populating-netbox-from-real-infrastructure/ Ein typisches Szenario: drei Cloud-Provider, zwei Hypervisoren, eine Handvoll Edge-Standorte. Irgendwo um die 200 Geräte und VMs, Pi mal Daumen. Man startet [NetBox](https://netbox.dev/), starrt auf das leere Dashboard und merkt, dass die eigentliche Arbeit noch nicht angefangen hat. Import-Skripte für fünf verschiedene APIs zu schreiben, ist eine Woche Arbeit, die niemand machen will — also bleibt NetBox leer, und die Tabellenkalkulation gewinnt wieder. Dieser Beitrag zeigt, wie man sich diese Woche spart. Wir gehen durch, wie man mit ToolMesh Live-Infrastrukturdaten aus mehreren Quellen abruft und über den NetBox-DADL-Konnektor in NetBox schreibt. Für den Business Case und das breitere „Warum" lies den Schwester-Artikel auf [dunkel.cloud](https://dunkel.cloud/blog/populating-netbox-from-real-infrastructure). Hier geht es um das „Wie". :::tip[Auf der Suche nach dem NetBox-MCP-Server?] Setup, Beispiele und die einsatzbereite DADL-Definition: **[NetBox MCP Server auf toolmesh.io](/de/integrations/netbox/)**, oder die Rohdefinition unter **[dadl.ai/d/netbox](https://dadl.ai/d/netbox)**. In ToolMesh einklinken und schon hat man einen NetBox-MCP-Server ohne eine Zeile eigenen Code. ::: ## Architektur-Überblick Der Datenfluss: ``` Hetzner Cloud ───┐ Linode ───┤ Xen Orchestra ───┼── ToolMesh ── NetBox DADL ── NetBox API Unifi ───┤ Tailscale ───┘ ``` Jedes Quellsystem hat seine eigene API, seine eigene Authentifizierung und sein eigenes Datenmodell. ToolMesh fungiert als Gateway: Es authentifiziert sich gegen jede Quelle mit hinterlegten Credentials, normalisiert die Antworten und schreibt die Ergebnisse über die NetBox-DADL-Definition in NetBox. [DADL](/de/dadl/) (Declarative API Definition Language) ist ein YAML-basiertes Format, das REST-APIs als Tool-Definitionen beschreibt. Statt für jede API einen eigenen MCP-Server-Wrapper zu schreiben, beschreibt man Endpoints, Parameter und Authentifizierung in einer einzigen Datei. ToolMesh verwandelt diese Beschreibung zur Laufzeit in aufrufbare Tools — und erledigt Credential-Injection, Autorisierung und Audit-Logging automatisch. Die NetBox-DADL deckt den Großteil der NetBox-[REST-API](https://docs.netbox.dev/en/stable/integrations/rest-api/) ab; jede Quell-DADL deckt eine Cloud oder Appliance ab. Dazwischen sitzt kein eigener Glue-Code. ## Mapping: Quellobjekte auf NetBox-Objekte Die Kernaufgabe ist die Übersetzung zwischen Datenmodellen. Ein Hetzner-„Server" wird zu einem NetBox-„Device". Eine Linode-„Instance" wird ebenfalls zu einem Device, aber die Feldnamen unterscheiden sich. So sieht das Mapping der wichtigsten Objekte aus: | Quelle | Quellobjekt | NetBox-Objekt | Schlüsselfelder | |---|---|---|---| | Hetzner Cloud | Server | Device | name, server_type → device_type, datacenter → site | | Hetzner Cloud | Network | Prefix | ip_range → prefix, name → description | | Linode | Instance | Device | label → name, type → device_type, region → site | | Linode | IPv4/IPv6 | IP Address | address → address, linode_id → zugewiesenes Device | | Xen Orchestra | VM | Virtual Machine | name_label → name, power_state → status | | Xen Orchestra | Network | VLAN | name_label → name, MTU | | Unifi | Device | Device | name, model → device_type, site → site | | Tailscale | Node | Device | hostname → name, addresses → IP Addresses | Konkret sieht ein einzelner Hetzner-Server in der Antwort so aus: ```json { "id": 42891337, "name": "web-fra-01", "server_type": { "name": "cx22", "cores": 2, "memory": 4 }, "datacenter": { "name": "fsn1-dc14", "location": { "name": "fsn1" } }, "public_net": { "ipv4": { "ip": "95.217.xx.xx" } }, "status": "running" } ``` Nachdem ToolMesh das Objekt durch die NetBox-DADL geschickt hat, erzeugt dieses eine Quellobjekt drei verknüpfte NetBox-Records: eine `Site` (`fsn1`), einen `DeviceType` (`cx22`, 2 Cores, 4 GB) und ein `Device` (`web-fra-01`) mit angehängter primärer IP. `Site` und `DeviceType` werden einmal angelegt und bei jedem weiteren Hetzner-Server im selben Rechenzentrum wiederverwendet. Mappings sind nicht hartcodiert. Die Logik für die Feldübersetzung lebt in der Orchestrierungsschicht zwischen Quell-DADL und NetBox-DADL. Mappings lassen sich überschreiben, eigene Felder hinzufügen oder Objekte komplett überspringen — wenn die Server eine Rolle im Hostnamen kodieren (`web-fra-01`, `db-fra-02`), setzt eine kleine Transformation das `device_role` entsprechend. Abhängigkeiten werden automatisch aufgelöst: Voraussetzungs-Objekte werden vor dem Haupt-Record angelegt. ## Das Trust-Escalation-Modell Cloud-Inventar blind in eine produktive NetBox zu synchronisieren, ist zu Recht etwas, wovor man Respekt haben sollte. Der empfohlene Ansatz ist graduelles Vertrauen — mit null Risiko starten und mit wachsender Sicherheit eskalieren. Nichts davon ist ein eigens gebautes CLI; alles läuft als Prompt in natürlicher Sprache an Claude (oder einen beliebigen Agenten) mit angebundenem ToolMesh. Die folgenden Beispiele sind die tatsächlich verwendeten Prompts. **Phase 1: Initial-Import (leere Datenbank).** Bevor Devices angelegt werden können, braucht NetBox ein minimales Grundgerüst: mindestens eine Site (Devices müssen einer zugeordnet sein), einen Manufacturer für Device Types und idealerweise einen Tenant zur organisatorischen Gruppierung. Man füttert Claude mit den Fakten zur eigenen Infrastruktur und lässt es einrichten: > Richte NetBox für meine Firma ein. Unser Tenant ist „Acme GmbH". Ich betreibe Infrastruktur in zwei Regionen: Linode Frankfurt (`eu-central`) und Linode Amsterdam (`nl-ams`) — leg die als Sites unter einer Region namens „Europe" an. Der Manufacturer für alle Linode-Instanzen ist „Akamai/Linode". Sobald das steht, importiere alle meine Linode-Instanzen als Devices, leg die passenden Device Types (g6-standard-2, g6-standard-4 usw.) direkt mit an und häng die öffentlichen IPv4- und IPv6-Adressen dran. NetBox ist leer, also kein Dry-Run nötig — mach es einfach und zeig mir am Ende eine Zusammenfassung. Claude ruft die Linode-Tools auf, um Instanzen zu listen, und die NetBox-Tools, um Sites, Tenant, Manufacturer, Device Types, Devices und IPs in der richtigen Reihenfolge anzulegen. Die Zusammenfassung am Ende sagt, wie viele von jedem Objekttyp angelegt wurden. **Phase 2: Read-only-Diff.** Sobald NetBox Daten enthält, fragt der nächste Check, was sich ändern würde, ohne irgendetwas anzufassen: > Vergleiche meine aktuellen Linode-Instanzen mit dem, was in NetBox steht. Ändere nichts — sag mir nur in einfachen Worten, was die Unterschiede sind. Die Antwort ist Prosa, kein Maschinen-Diff: > Ich habe 23 Linode-Instanzen mit den 22 Devices in NetBox verglichen, die mit `source=linode` getaggt sind. Vier Unterschiede: > > 1. **Neue Instanz**: `db-ams-04` existiert bei Linode (Region `nl-ams`, Typ `g6-standard-4`, gestern angelegt), ist aber noch nicht in NetBox. > 2. **IP-Änderung**: `web-ams-01` hat in NetBox eine primäre IPv4 (`172.104.x.12`), Linode meldet jetzt aber `172.104.x.47`. Sieht nach einem Rebuild aus. > 3. **Status-Drift**: `worker-ams-03` ist in NetBox als `active` markiert, Linode meldet ihn aber als `offline` (vor 6 Tagen heruntergefahren). > 4. **Fehlt an der Quelle**: `legacy-bastion-ams` existiert in NetBox, ist bei Linode aber nicht mehr vorhanden. Wahrscheinlich außer Betrieb genommen — vor dem Anfassen lieber bestätigen lassen. > > Soll ich 1–3 anwenden und 4 zur Prüfung markieren? An dieser Stelle wird der größte Teil des Vertrauens aufgebaut. Man sieht genau, was passieren würde, in einer Sprache, die man auf einen Blick auditieren kann. **Phase 3: Reconcile mit Bestätigung.** Änderungen werden angewendet, mit einem Menschen in der Schleife bei allem Destruktiven: > Mach mit 1, 2 und 3 weiter. Für alles, was ein Device löscht oder als außer Betrieb markiert, frag mich vorher. Anlegen und Updates passieren direkt; die Legacy-Bastion löst eine Rückfrage aus („Soll `legacy-bastion-ams` aus NetBox gelöscht oder auf `decommissioning` gesetzt und der Record behalten werden? [delete / decommission / skip]"), bevor etwas Unwiderrufliches geschieht. Destruktive Operationen erfordern immer eine explizite Bestätigung, auch wenn der Workflow später automatisiert läuft. **Phase 4: Geplanter Sync.** Sobald das Mapping vertrauenswürdig ist, übergibt man den Workflow an einen geplanten Agenten: > Hol jede Stunde den aktuellen Linode-Stand und gleich ihn mit NetBox ab. Neue Einträge und Feld-Updates wend direkt an. Für alles, was ein Device löschen oder seinen Status auf decommissioned setzen würde, öffne stattdessen ein Ticket in unserem Tracker — das prüfe ich manuell. ToolMesh führt den Prompt nach Zeitplan aus, der Agent macht dieselbe Arbeit wie im interaktiven Lauf, und destruktive Aktionen bleiben hinter einer Freigabe durch einen Menschen. Neue Server tauchen Minuten nach dem Provisionieren in NetBox auf. Jeder Tool-Call landet im Audit-Log, sodass sich später jederzeit nachvollziehen lässt, *was* geändert wurde, *wann* und *warum*. ## Wie es weitergeht Der [NetBox-DADL-Konnektor](https://dadl.ai/d/netbox) deckt den Großteil der NetBox-4.x-REST-API ab. Quell-Konnektoren für [Hetzner Cloud](https://dadl.ai/d/hetzner-cloud), [Linode](https://dadl.ai/d/linode), [Xen Orchestra](https://dadl.ai/d/xen-orchestra), Unifi und [Tailscale](https://dadl.ai/d/tailscale) sind heute verfügbar. Falls die eigene Infrastruktur noch nicht abgedeckt ist, ist eine neue DADL-Datei eine Sache von Minuten, nicht Tagen — die [DADL Registry](https://dadl.ai/browse) auf bestehende Definitionen prüfen oder selbst auf [GitHub](https://github.com/DunkelCloud/dadl-registry) beitragen. Der eigentliche Gewinn kommt nach dem Import. Eine befüllte NetBox ist nicht nur Dokumentation — sie wird zum Substrat, über das ein KI-Agent argumentieren kann. „Welche Server in Falkenstein laufen auf Kernel 5.x und brauchen nächsten Dienstag ein Reboot-Fenster?" ist eine NetBox-Abfrage plus ein ToolMesh-Tool-Call, keine Woche Shell-Skripte. Genau deshalb starten wir hier: NetBox ist die Karte, ToolMesh ist die Art, wie Agenten sie sicher lesen und neu zeichnen. Für die strategische Sicht lies die vollständige Analyse auf [dunkel.cloud](https://dunkel.cloud/blog/populating-netbox-from-real-infrastructure).