Work and Progress

netbox migration
zielserver: SLES 15 SP7, kein direkter internetzugang -> nur über proxy mit einzeln freigeschalteten adressen.
setup
postgresql 17 (datenbank)
valkey 8 (redis-kompatibel, caching/background jobs)
nginx (reverse proxy davor)
gunicorn (wsgi server für die django-app)
→ das ist die von netbox offiziell empfohlene stack-kombi für native installs (kein docker)
warum kein podman/container?
hatte ich erst überlegt, aber:
plugins gehen über pip → bei container müsste ich bei jedem plugin ein neues image bauen
hätte den proxy-freigabeprozess (siehe unten) nur noch mehr belastet
→ native installation gewählt
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 --> proxy (freischaltung durch ticket)
genehmigungsprozess:
ticket an proxy-team → quellsystem, zieladresse, port 443 ohne auth
weil proxy SSL terminiert: zusätzliches ticket an infosec → SSL-bypass + freischaltung für 
application/zip und 
application/gzip mime-types
dazu noch nen risikobogen ausfüllen (auswirkung bei nichtverfügbarkeit, alternativen geprüft etc.)
konkrete probleme die aufgetreten sind:
problem
ursache
fix
407 bei 
pip install, curl ging aber
proxy-var nicht dauerhaft gesetzt / sudo killt env
in 
/etc/environment eintragen + 
sudo -E nutzen
407 bei internen suse-manager repos
interne adressen liefen fälschlich über externen proxy
intern in 
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) → auf 
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 neustart → 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 (F1)
erst falsches paket installiert (
netbox-dns) → passt nicht zur plugin-api von netbox 4.2, nutzt noch das alte 
extras.plugins modul das es nicht mehr gibt
richtiges paket: 
netbox-plugin-dns v1.2.14 → über 
PLUGINS aktiviert
microsoft-typische namen mit unterstrich (z.b. 
_msdcs.domain.de) sind nach RFC 1034 eigentlich nicht erlaubt → musste 
tolerate_underscores_in_labels setzen
octoDNS test:
externes tool, liest zonen aus netbox (via 
NetBoxDNSProvider / 
octodns-netbox-dns paket) und kann die an andere systeme syncen
testzone 
test.lokal angelegt (ns + a record), erfolgreich als yaml exportiert
nicht getestet: gegen echten microsoft-dns server, dafür hätte ich nen provider gebraucht den's für das ökosystem nicht gab + schreibzugriff auf produktive windows infra
→ F1 = architektur-mäßig belegt, aber nicht produktiv verifiziert
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
rechte (F5): testgruppe mit constraint (
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.
datenimport
572 standorte aus infoblox importiert (region/site group/site mapping)
4.262 präfixe importiert, über eigenes python-skript + netbox REST API
standortzuordnung war nervig weil netbox numerische IDs will, infoblox hatte klartext-kurzbezeichnungen
direkt eindeutig zuordenbar: 63,1%
über zusatzmatching (kurzbezeichnung ↔ beschreibungsfeld): +17,0% → macht 80,1% insgesamt
rest (15,9%) ohne standort importiert, 4,1% hatten gar keine standort-id im quelldatensatz
encoding-ärger: teile vom datensatz waren windows-1252 statt utf-8 → umlaute in ortsnamen kaputt, musste nachbearbeiten
~500 nameserver-einträge + ein paar dns-zonen mit importiert
nicht importiert: einzelne IP-adressen (nur die präfixe/subnetze als ganzes). infoblox hat da schätzungsweise 10.000er bis 100.000er einträge, hätte entweder direkten API-zugriff aufs produktive infoblox gebraucht oder manuellen export pro subnetz — beides nicht machbar im rahmen der arbeit.
offene punkte
 ldap gegen echtes AD testen (braucht service-account)
 einzelne IP-adressen importieren für vollständige skalierbarkeits-aussage
 die ~16% unzugeordneten präfixe manuell nacharbeiten
 DHCP nochmal probieren sobald netbox 4.5 + python 3.12 möglich ist, oder netbox labs enterprise variante anschauen (soll DHCP vorkonfiguriert für offline-betrieb haben)