RackTables war großartig. Seit 2007 hat es genau das getan, was es sollte: Racks und IPs verwalten. PHP, MySQL, läuft. Aber die Wahrheit ist: Technik entwickelt sich weiter. Das letzte Update kam im Februar 2022. Keine moderne API. Die alten Migrationsskripte? Völlig nutzlos für moderne Systeme. RackTables ist heute ein Klotz am Bein, der deine IT blockiert.
Wenn sich aber mehrere dieser sechs Punkte vertraut anfühlen, kostet dich das Bleiben mehr als der Wechsel. Einen neutralen Marktüberblick findest du in unserem Vergleich zur Open-Source-Netzwerkdokumentation.
RackTables stammt aus der Zeit vor NetDevOps. Wer Ansible, Terraform oder eigene Skripte an die Doku anbinden will, kämpft gegen das Tool statt mit ihm.
Das letzte Release 0.22.0 stammt vom 15.02.2022. Neuere Stände erscheinen nur als Git-Tags, die GitHub-Releases-Seite bleibt leer.
Ein PHP-Stack mit MySQL/MariaDB will gepatcht, gehostet und abgesichert werden. Das bindet genau die Zeit, die deinem Netzbetrieb fehlt.
RackTables lässt fast jede Eingabe zu. NetBox validiert: Pflichtfelder, Typen, Eindeutigkeit. Erst dadurch wird Dokumentation automatisierbar.
Patchwege, Panels und Stromversorgung auf dem Niveau des NetBox-Modells (Cables, Power Feeds) bildet RackTables nicht ab.
Monitoring, CMDB und Automatisierung brauchen eine maschinenlesbare, validierte Quelle. Genau dafür wurde NetBox gebaut.
Die gute Nachricht: Für fast alles in RackTables gibt es ein sauberes Ziel in NetBox. Die Zuordnung entscheidet darüber, wie viel Handarbeit nach dem Import übrig bleibt.
Jedes Device braucht in NetBox einen Manufacturer und einen Device Type. Generische RackTables-Objects musst du vorher typisieren, sonst scheitert der Import.
NetBox hängt jedes Rack an eine Site, optional an eine Location. Den Standort-Schnitt legst du vor dem Import fest, nicht danach.
Netze werden Prefixes, Adressen werden IP Addresses inklusive Interface-Zuordnung. Kollisionen fallen dank Validierung sofort auf.
Frei definierte Attribute übernimmst du als Custom Fields, jetzt aber mit Datentyp, Pflichtstatus und Validierungsregeln.
NetBox kennt keine Tag-Hierarchie. Verschachtelte Tags bildest du über Namenskonventionen ab, etwa standort-berlin statt Baumstruktur.
Verbindungen werden echte Cable-Objekte zwischen Interfaces. Sie kommen als letzter Importschritt, wenn beide Endpunkte existieren.
Zwei Community-Tools tauchen in jeder Suche auf. Beide haben Verdienste, beide haben dasselbe Problem: Sie stammen aus der NetBox-2.x-Ära. Aktuell ist NetBox 4.6, dazwischen liegen zwei Major-Versionen.
Das meistverlinkte Migrationstool. Die Projektdoku referenziert das Datenmodell von NetBox 2.3.4, eine Kompatibilitätszusage für aktuelle Versionen gibt es nicht. Am 21.05.2024 hat der Autor das Repository archiviert, seitdem ist es read-only (18 Stars, 18 Forks).
Bekanntester Ansatz · nachvollziehbare Mapping-Logik als Code-Referenz
Archiviert seit Mai 2024 · Ziel NetBox 2.x · keine Pflege mehr
Das Skript mit dem größten Funktionsumfang: Es liest per SQL direkt aus der RackTables-Datenbank und schreibt über die NetBox-API. Laut README migriert es Racks samt Sites, Geräteplatzierungen, VMs und Cluster, Parent-Child-Beziehungen (Server im Chassis, Patchpanel im Patchpanel), IPs, Netze, VLANs, Interfaces mit IPs, Verbindungen sowie Tags, Labels und Asset-Nummern.
Umfangreichster Scope · SQL-Zugriff statt fragiler Exporte
One-Shot auf leere Instanz · letzter Push 28.08.2022 · VMs mit doppelten Namen fallen raus
Statt eine sechs Jahre alte NetBox zu installieren, damit ein Skript von 2022 läuft, exportierst du gezielt aus der RackTables-Datenbank und importierst direkt in die aktuelle Version. NetBox hilft dabei kräftig: Der CSV-Bulk-Import legt neue Objekte an und aktualisiert bestehende, sobald die CSV ein id-Feld enthält. Die REST-API wendet beim Import dieselben Validierungsregeln an wie die UI-Formulare und erstellt viele Objekte in einem einzigen Request. Für Massendaten und Verkabelung ist pynetbox das Werkzeug der Wahl.
Die Reihenfolge ist kein Stilmittel: Devices brauchen Device Types, Interfaces brauchen Devices, und Kabel brauchen beide Endpunkte. Deshalb kommen Sites zuerst und die Verkabelung fast zuletzt. Es ist dieselbe Sequenz, die auch die Migrationsskripte intern abarbeiten.
Der gleiche Ablauf, mit dem wir jede NetBox-Migration führen, hier auf RackTables zugeschnitten. Wenn du die Phasen lieber mit uns gehst: Genau dafür gibt es die Migrationsberatung.
Bestandsaufnahme direkt in RackTables: Was ist aktuell, was ist Leiche, was ist doppelt? Aufräumen vor dem Export spart jede Stunde dreifach.
Zuordnung je Objekttyp plus NetBox-Zielmodell: Sites, Tenants, Custom Fields und Namenskonventionen einmal sauber definieren.
Import auf eine Staging-Instanz, Stichproben gegen RackTables, Fehlerliste abarbeiten, wiederholen, bis der Lauf sauber durchgeht.
Finaler Delta-Import, kurze Doppelpflege, dann RackTables auf read-only. Klarer Stichtag, klarer Rollback, kein Feuerwehrmodus.
Alle Prüfpunkte, von Datenhygiene bis Cutover, stecken in unserer kostenfreien 28-Punkte-Checkliste für NetBox-Migrationen.
28-Punkte-Checkliste sichern ›Wikimedia hat seine Hardware-Inventur 2018 öffentlich nachvollziehbar migriert: Export und Import starteten am 21. und 24.09.2018, eine Woche lang wurden beide Tools parallel gepflegt, ab dem 01.10.2018 war RackTables read-only. Am 11.10.2018 wurde der Task als Resolved geschlossen.
Die Mechanik ist dieselbe, die sich auch in unseren Projekten bewährt: kurzer Parallelbetrieb mit klarem Stichtag statt monatelanger Doppelpflege.
Im kostenfreien Erstgespräch schauen wir auf deine RackTables-Instanz und sagen dir ehrlich, welcher Importpfad passt. Lieber erst selbst prüfen? Dann hol dir die Checkliste oder sieh NetBox live.
Wir melden uns innerhalb eines Werktages mit Terminvorschlägen. Kein Vertrieb, keine Verpflichtung. Praktiker zu Praktiker.