Work and Progress
netbox migration
zielserver: SLES 15 SP7, kein direkter internetzugang -> nur über proxy mit einzeln freigeschalteten adressen.
Export der Daten aus Infobloxsetup
CNP-UNpostgresql 17 (default)datenbank)- valkey 8 (redis-kompatibel, caching/background jobs)
→ das ist die von netbox offiziell empfohlene stack-kombi für native installs (kein docker)
warum kein podman/container? hatte ich erst überlegt, aber:
python versions-ärger
server hatte schon python 3.14 drauf (SLES bringt das mit). netbox braucht offiziell min. 3.10, aber:
strawberry-graphql (graphql dependency von netbox) ist mit 3.14 nicht kompatibel
migration bricht mit laufzeitfehler in der feld-initialisierung ab
→ fix: einfach die von SLES mitgelieferte python 3.11 genommen statt 3.14. lief dann sauber durch.
lesson learned: neueste version =! automatisch die beste
proxy shit
server ist nicht air-gapped --> Toggle hierarchical viewproxy (X)freischaltung durch ticket)
genehmigungsprozess:
application/zip und application/gzip mime-types
konkrete probleme die aufgetreten sind:
pip install, curl ging aber
proxy-var nicht dauerhaft gesetzt / sudo killt env
in /etc/environment eintragen + sudo ->E no_proxy aufnehmen
podman pull auf ghcr.io scheitert trotz freigabe
freigabe deckte nur registry-api ab, nicht den separaten blob-storage (pkg-containers.githubusercontent.com)
extra domain nachbeantragt
netbox source code nicht über pypi verfügbar
netbox gibt's nur als github release, kein pypi paket
einmal extern von jemandem mit internet geladen, per datenträger über sprungserver + SynaMan reingebracht
→ takeaway: jedes neue plugin = potenziell neues ticket
installation
psycopg (postgres adapter) will kompilieren, braucht pg_config → fehlte, nachinstalliert: postgresql17-server-devel
Pillow braucht jpeg dev-header → libjpeg8-devel nachinstalliert
postgres/valkey wollten nicht auf localhost hören → server hat das erst auf ::1 (ipv6) aufgelöst, dienste lauschten aber nur auf ipv4 loopback
→ fix: überall 127.0.0.1 statt localhost in der config
postgres auth: ident methode ging nicht (mein domänen-user ≠ db-user netbox) md5 umgestellt
valkey config datei war gar nicht da, musste ich selbst minimal anlegen (nur loopback)
systemd service unter netbox.service angelegt → hat ausversehen die schon vorhandene datei vom netzwerkdienst wicked überschrieben. nach obenneustart → server komplett weg vom netz, nur noch über physische konsole erreichbar. 🙃
→ merke: bei eigenen systemd units immer eindeutige namen die nicht mit bestehenden diensten kollidieren können
plugins
dns (Export)F1)
netbox-dns) → passt nicht zur plugin-api von netbox 4.2, nutzt noch das alte extras.plugins modul das es nicht mehr gibt
netbox-plugin-dns PLUGINS aktiviert
microsoft-typische namen mit unterstrich (z.b. https://ipam.illinois.edu/wapidoc/index.html_msdcs.domain.detolerate_underscores_in_labels setzen
octoDNS test:
NetBoxDNSProvider / octodns-netbox-dns paket) und kann die an andere systeme syncen
testzone test.lokal angelegt (ns + a record), erfolgreich als yaml exportiert
dhcp (F2) - hat einfach nicht geklappt
drei anläufe, alle gescheitert:
netbox-plugin-dhcp (offiziell) → braucht netbox 4.5 + python 3.12, hab aber 4.2/3.11
netbox-kea-dhcp → gibt's nicht mehr auf pypi
netbox-kea-ng → installiert sich, aber migration bricht ab, weil's core.exceptions.JobFailed importiert, was's in 4.2.6 noch nicht gibt
→ fazit: DNS-plugin-ökosystem ist für die netbox version ok, DHCP ist einfach noch nicht reif genug. kein grundsätzliches "geht nicht", eher momentaufnahme.
was ich sonst noch getestet hab
tenant__name) → nur präfixe vom zugewiesenen mandanten sichtbar. funktioniert.
vlan (F6): gleiche VID (100) in zwei verschiedenen vlan-groups → geht problemlos. gleiche VID nochmal in derselben group → wird zurückgewiesen. genau wie erwartet.
custom fields (F9): 3 felder angelegt (domaene, sicherheitsbereichs_id, svn_id) auf präfix-objekte. domaene erstmal als textfeld statt choice-set, weil ich die vollständige werteliste aus infoblox nicht hatte.
filter/export (F8): präfixliste nach mandant/status gefiltert, als csv exportiert. läuft.
ldap (F7): django-auth-ldap installiert, REMOTE_AUTH_BACKEND konfiguriert, verbindungsparameter vorbereitet — aber nicht live getestet, hatte keinen service-account und keinen zugriff aufs AD. offener punkt.