Dokumentera ditt nätverk med NetBox och Podman utan root

Det här sätter du upp

NetBox håller reda på vad ditt nätverk och dina serverrum innehåller och hur allt hänger ihop: siter, rack och vad som sitter var, enheter och deras gränssnitt, kablarna mellan dem och de IP-adresser, prefix och VLAN som används. Tanken är att det ska vara det enda stället där det står, källan som folk slår upp saker i och skript läser från, i stället för kalkylblad som glider isär. Allt finns i ett webbgränssnitt och i ett REST-API, och varje ändring loggas.

NetBox startades av Jeremy Stretch på DigitalOcean och släpptes som öppen källkod 2016. I dag utvecklas den öppet på GitHub av NetBox Labs, ett amerikanskt bolag, tillsammans med användarna. Själva NetBox är öppen källkod under Apache 2.0-licensen, utan begränsade funktioner. NetBox Labs säljer två saker ovanpå, kontrollerat på netboxlabs.com den 14 oktober 2026: NetBox Cloud, där de kör NetBox åt dig, med en gratisplan för upp till 100 enheter och 500 IP-adresser utan plugins, webhooks och egna skript, och betalplaner med SSO, säkerhetskopior och support; och NetBox Enterprise, som du kör själv, med installationsprogram, inbyggd säkerhetskopiering och återställning, enkel inloggning, certifierade plugins, support och en Air Gap-utgåva för nätverk utan internet. De säljer också separata produkter som fungerar med NetBox: Discovery, som hittar enheter i ditt nätverk, Assurance, som jämför nätverket med det NetBox säger, och Copilot, en AI-assistent som körs som deras molntjänst. Inget av det behövs för det den här guiden gör.

NetBox Labs ger inte ut någon egen containeravbild. Den här guiden använder den från projektet netbox-docker, som drivs av frivilliga i organisationen netbox-community på GitHub, också under Apache 2.0. Dess tagg v4.7 följer varje version av NetBox 4.7.

NetBox behöver PostgreSQL för sina data och Redis för sin jobbkö och cache. Dess dokumentation kräver Redis 6.0 eller senare och nämner inte Valkey, den fria grenen av Redis, men netbox-docker levereras med Valkey och det är vad den här guiden använder. Det fungerade genom alla våra tester.

Här körs NetBox som en pod under en egen användare som heter netbox, med fyra containrar: PostgreSQL, Valkey, NetBox webbserver och en worker som kör bakgrundsjobb som webhooks. Tidigare versioner av netbox-docker hade en femte container för underhåll; det sköter NetBox nu själv, som ett dagligt jobb i workern. Framför står Caddy från Podman-guiden.

Varje steg nedan har körts på en nyinstallerad Melonslab VC-P Titanium (4 vCPU, 16 GB) med Debian 13:

• NetBox 4.7.3 startade med PostgreSQL 18 och Valkey 9.1. Den första administratören skapades och testades genom en SSH-tunnel innan Caddy sattes upp.
• Utan inloggning skickades besökare till inloggningssidan från varje sida, även för uppladdade bilder, och API:et svarade 403.
• En site, ett rack, tre enheter med gränssnitt från importerade enhetstyper, två kablar, ett VLAN, ett prefix och IP-adresser skapades, i webbgränssnittet och med import av CSV och YAML. NetBox visade nästa lediga adress, och API:et delade ut den.
• En kollega i en grupp med bara läsrätt kunde se allt i inventariet och fick 403 vid försök att ändra något.
• En API-token fungerade utifrån. En token som var begränsad till vissa adresser nekades från andra, även när anropet påstod sig komma från en annan adress, när Caddy satte headern som i steg 5.
• En händelseregel skickade en webhook för varje ny IP-adress.
• En avlyssning av serverns trafik visade att NetBox kontaktade NetBox Labs för användningsstatistik, nyheter och listan över plugins. Med ISOLATED_DEPLOYMENT=true gjorde den inga externa anslutningar alls, medan webhooks fortfarande gick ut.
• Pluginet Topology Views byggdes in i avbilden och ritade upp enheterna och kablarna.
• En uppdatering från NetBox 4.6.10 till 4.7.3 körde sina databasmigreringar på omkring tre minuter. NetBox återställdes från en säkerhetskopia till en ny användare, med samma data, användare, bilder och API-tokens, och allt startade igen av sig självt efter en omstart av servern.

Podden använde omkring 1,5 GB minne, det mesta för webbserverns fyra processer.

Innan du börjar

Du behöver:

• en server uppsatt som i Podman-guiden, med Caddy igång;
• en A-post och en AAAA-post för netbox.example.com som pekar på din server.

Exemplen använder netbox.example.com för NetBox, 203.0.113.10 för serverns IPv4-adress, anna för ditt eget konto och erik för en kollega. Byt ut dem genomgående.

1. Skapa användaren

Som root:

useradd -m -s /bin/bash netbox
loginctl enable-linger netbox
machinectl shell netbox@

Allt fram till steg 5 körs som netbox.

2. Skapa hemligheterna

openssl rand -base64 48 | tr -d '\n' | podman secret create netbox-secret-key -
openssl rand -base64 48 | tr -d '\n' | podman secret create netbox-api-pepper -
openssl rand -hex 24 | tr -d '\n' | podman secret create netbox-db-password -

Den första är NetBox hemliga nyckel, som signerar inloggningar och sessioner. Den andra är den peppar som NetBox blandar in i API-tokens innan den sparar deras hashar: utan den slutar de tokens du skapar i steg 10 att fungera, så steg 15 sparar en kopia av båda. Den tredje är databaslösenordet. Alla tre lagras av Podman, inte i filerna nedan.

3. Definiera podden

mkdir -p ~/.config/containers/systemd
cd ~/.config/containers/systemd

Skapa netbox.pod:

[Pod]
PodName=netbox
# Only Caddy, on this server, can reach NetBox: the port is not open to the internet.
PublishPort=127.0.0.1:8190:8080

[Install]
WantedBy=default.target

Skapa netbox-db.container:

[Container]
ContainerName=netbox-db
Image=docker.io/library/postgres:18-alpine
Pod=netbox.pod
Volume=netbox-db:/var/lib/postgresql
Environment=POSTGRES_DB=netbox POSTGRES_USER=netbox POSTGRES_PASSWORD_FILE=/run/secrets/db_password
Secret=netbox-db-password,target=db_password
HealthCmd=pg_isready -U netbox -d netbox
HealthInterval=10s
Notify=healthy
AutoUpdate=registry

[Service]
Restart=always

Skapa netbox-valkey.container:

[Container]
ContainerName=netbox-valkey
Image=docker.io/valkey/valkey:9.1-alpine
Pod=netbox.pod
Volume=netbox-valkey:/data
Exec=valkey-server --appendonly yes
HealthCmd=valkey-cli ping
HealthInterval=10s
Notify=healthy
AutoUpdate=registry

[Service]
Restart=always

Skapa netbox.container:

[Unit]
Requires=netbox-db.service netbox-valkey.service
After=netbox-db.service netbox-valkey.service

[Container]
ContainerName=netbox
Image=docker.io/netboxcommunity/netbox:v4.7
Pod=netbox.pod
User=netbox
Group=root
EnvironmentFile=%h/netbox.env
Secret=netbox-secret-key,target=secret_key
Secret=netbox-db-password,target=db_password
Secret=netbox-api-pepper,target=api_token_pepper_1
Volume=netbox-media:/opt/netbox/netbox/media
Volume=netbox-scripts:/opt/netbox/netbox/scripts
HealthCmd=curl -sf http://localhost:8080/login/ -o /dev/null
HealthInterval=15s
Notify=healthy
AutoUpdate=registry

[Service]
Restart=always
# The first start, and an update, can spend minutes on database migrations.
TimeoutStartSec=1800

Och netbox-worker.container:

[Unit]
Requires=netbox.service
After=netbox.service

[Container]
ContainerName=netbox-worker
Image=docker.io/netboxcommunity/netbox:v4.7
Pod=netbox.pod
User=netbox
Group=root
EnvironmentFile=%h/netbox.env
Secret=netbox-secret-key,target=secret_key
Secret=netbox-db-password,target=db_password
Secret=netbox-api-pepper,target=api_token_pepper_1
Volume=netbox-media:/opt/netbox/netbox/media
Volume=netbox-scripts:/opt/netbox/netbox/scripts
Exec=/opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py rqworker
AutoUpdate=registry

[Service]
Restart=always

Båda NetBox-containrarna läser resten av sina inställningar från en och samma fil. Skapa ~/netbox.env:

ALLOWED_HOSTS=netbox.example.com
TIME_ZONE=Europe/Stockholm
MEDIA_ROOT=/opt/netbox/netbox/media
DB_HOST=127.0.0.1
DB_NAME=netbox
DB_USER=netbox
REDIS_HOST=127.0.0.1
SKIP_SUPERUSER=true
ISOLATED_DEPLOYMENT=true

Vad inställningarna gör:

• Avbilden läser varje hemlighet från en fil i /run/secrets, med namnet i target=. Det är där Podman lägger dem.
• ALLOWED_HOSTS är namnet som NetBox svarar på; ett anrop till något annat namn får "400 Bad Request". Avbilden lägger själv till localhost, för sina egna kontroller och för SSH-tunneln i steg 4.
• TIME_ZONE visar tider i svensk tid.
• MEDIA_ROOT måste anges: utan den letar avbilden efter uppladdningar i en katalog som NetBox inte kan skriva i, och uppladdning av en bild misslyckas med ett behörighetsfel.
• ISOLATED_DEPLOYMENT=true hindrar NetBox från att kontakta NetBox Labs. Steg 13 har detaljerna.
• SKIP_SUPERUSER=true hindrar avbilden från att skapa ett administratörskonto med ett standardlösenord. Du skapar ditt eget i steg 4.
• Alla NetBox-containrar ligger i samma pod, så de når PostgreSQL och Valkey på 127.0.0.1, och inget utanför podden gör det. Valkey sparar jobbkön på disk med --appendonly yes, så att köade webhooks klarar en omstart.
• Webbservern körs som användaren netbox inne i containern, som netbox-docker är tänkt. Volymen netbox-media innehåller uppladdade bilder och filer, och netbox-scripts egna skript som du laddar upp. Allt annat ligger i databasen.
• Workern kör bakgrundsjobben: webhooks, skript och NetBox dagliga underhåll, som tar bort utgångna sessioner och gamla poster i ändringsloggen.
• PostgreSQL ligger kvar på 18 och Valkey på 9.1, och AutoUpdate=registry tar in deras buggrättningar. NetBox 4.7 kräver PostgreSQL 15 eller senare.

Starta den:

systemctl --user daemon-reload
systemctl --user start netbox-pod
systemctl --user enable --now podman-auto-update.timer

Vid första starten laddas omkring 1 GB avbilder ner, och sedan bygger NetBox upp sin databas: hela första starten tog tio minuter i vårt test. Följ den med journalctl --user -fu netbox. Den är klar när loggen säger Initialisation is done och det här skriver ut 200:

curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8190/login/

4. Skapa den första administratören

podman exec -it netbox /opt/netbox/netbox/manage.py createsuperuser

Ange ett användarnamn, till exempel anna, din e-postadress och ett lösenord. NetBox vill ha minst 12 tecken, med stora och små bokstäver och en siffra, och frågar om du vill gå förbi det om lösenordet är svagare: svara N och välj ett annat.

Innan NetBox kommer ut på nätet kontrollerar du kontot från din egen dator genom en SSH-tunnel:

ssh -L 8190:127.0.0.1:8190 root@203.0.113.10

Så länge den anslutningen är öppen är http://localhost:8190 i din webbläsare NetBox på servern. Logga in och stäng sedan tunneln med exit.

5. Sätt Caddy framför

Gå tillbaka till root med exit, byt till machinectl shell caddy@ och lägg till det här blocket sist i ~/Caddyfile:

netbox.example.com {
    reverse_proxy 127.0.0.1:8190 {
        header_up X-Real-IP {remote_host}
    }
}

Starta om Caddy med systemctl --user restart caddy och öppna https://netbox.example.com.

NetBox tar besökarens adress från headern X-Real-IP i första hand. Caddy sätter den inte själv, så utan raden header_up kunde vem som helst skicka en egen och påstå att de kom från vilken adress som helst. Det spelar roll för API-tokens som är begränsade till vissa adresser (steg 10). I vårt test godtog en sådan token en förfalskad header utan raden, och nekade den med raden på plats.

6. Kontrollera vem som kommer in

NetBox 4.7 kräver alltid inloggning: en besökare utan inloggning skickas till inloggningssidan, och API:et svarar 403. Uppladdade bilder kräver också inloggning. Den gamla inställningen LOGIN_REQUIRED, som kunde stänga av det, är på väg bort och försvinner i NetBox 5.0; låt bli den.

Det finns ingen sida för att registrera sig. Du skapar varje konto själv (steg 9), och en användare som glömmer sitt lösenord får ett nytt av dig: NetBox har ingen återställning av lösenord via e-post. Den skickar bara e-post vid fel, till administratörer i inställningen ADMINS, som den här guiden lämnar tom, så det finns ingen e-post att sätta upp.

NetBox kan också lämna inloggningen till en tjänst för enkel inloggning, till exempel authentik, via OpenID Connect eller SAML, eller till LDAP. Det ställs in med REMOTE_AUTH_BACKEND och inställningarna som börjar med SOCIAL_AUTH_ i dokumentationen för netbox-docker. Vi har inte testat det här.

7. Bygg upp ett litet serverrum

Menyerna till vänster följer NetBox egen ordning: en site rymmer rack, ett rack rymmer enheter, enheter har gränssnitt och kablar förbinder gränssnitt. Allt du skapar går att hitta med sökrutan högst upp.

1. Organization > Sites > Add: namnet Stockholm DC1, status Active och tidszonen. Välj Create.
2. Racks > Racks > Add: siten Stockholm DC1, namnet R01. Ett 19-tumsrack på 42U är standard. Välj Create.
3. Devices > Manufacturers > Add: namnet Generic. Välj Create.

En enhetstyp beskriver en modell av utrustning en gång, med höjd och portar, så att varje enhet av den typen får dem. Under Devices > Device Types väljer du Import, klistrar in det här, sätter Format till YAML och väljer Submit:

manufacturer: Generic
model: Switch 8
slug: generic-switch-8
u_height: 1
interfaces:
  - name: port1
    type: 1000base-t
  - name: port2
    type: 1000base-t
  - name: port3
    type: 1000base-t
  - name: port4
    type: 1000base-t
---
manufacturer: Generic
model: Server 1U
slug: generic-server-1u
u_height: 1
interfaces:
  - name: eth0
    type: 1000base-t
  - name: eth1
    type: 1000base-t

För riktig utrustning finns filer som de här för tusentals modeller i användarnas bibliotek av enhetstyper på GitHub, netbox-community/devicetype-library, som du klistrar in på samma sätt.

De flesta listor har en knapp Import som tar emot CSV. Under Devices > Device Roles > Import klistrar du in:

name,slug,color
Switch,switch,2196f3
Server,server,4caf50

Och under Devices > Devices > Import:

name,role,manufacturer,device_type,site,rack,position,face,status
sw1,Switch,Generic,Switch 8,Stockholm DC1,R01,42,front,active
web1,Server,Generic,Server 1U,Stockholm DC1,R01,40,front,active
db1,Server,Generic,Server 1U,Stockholm DC1,R01,39,front,active

Rackets sida ritar nu upp de tre enheterna på sina höjder, och varje enhet har gränssnitten från sin typ. En import skapar antingen alla rader eller ingen: är en rad fel visar NetBox felet och inget sparas. Varje importsida listar under formuläret vilka kolumner den tar emot.

För att koppla in en kabel öppnar du sw1, går till fliken Interfaces, öppnar den gröna knappen Connect cable på raden för port1 och väljer Interface. Välj enheten web1 och gränssnittet eth0, ge kabeln en etikett som C001 och en typ, och välj Create. Den andra kabeln kommer med CSV, under Connections > Cables > Import:

side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name,type,status,label
sw1,dcim.interface,port2,db1,dcim.interface,eth0,cat6,connected,C002

Varje gränssnitt visar nu vad det är kopplat till, och genom vilken kabel.

För att lägga till ett foto av racket öppnar du det och väljer Attach an image. Bilder hamnar i volymen netbox-media.

8. IP-adresser och VLAN

1. IPAM > VLANs > Add: VID 10, namnet Servers, status Active, siten Stockholm DC1. Välj Create.
2. IPAM > Prefixes > Add: prefixet 10.10.10.0/24, status Active, Scope DCIM > Site och Stockholm DC1, VLAN Servers och en beskrivning som Server LAN. Välj Create.

Prefixets sida visar hur mycket av det som används, och under First available IP nästa lediga adress, 10.10.10.1/24. Väljer du den öppnas en ny IP-adress med adressen ifylld: ge den beskrivningen Gateway och välj Create. Fliken IP Addresses på prefixet listar de använda adresserna med de lediga intervallen emellan.

För att ge en server dess adress lägger du till ytterligare en IP-adress från samma länk, väljer enheten web1 och gränssnittet eth0 under Assignment och kryssar i Make this the primary IP for the device/VM. Enhetens sida visar den sedan som dess primära IPv4-adress.

9. Användare, grupper och behörigheter

En användare som inte är superuser kan inte göra något förrän en behörighet tillåter det. Behörigheter ges till grupper, så ge kollegan en grupp. Under Admin > Authentication:

1. Groups > Add: namnet Read-only. Välj Create.
2. Permissions > Add: namnet View inventory. Under Object types markerar du varje typ i grupperna Circuits, DCIM, IPAM, Tenancy, Virtualization, VPN och Wireless i listan Available (håll ner Skift för att markera flera) och flyttar dem till Selected med den gröna knappen. Under Actions kryssar du bara i Can view, och under Assignment väljer du gruppen Read-only. Välj Create.
3. Users > Add: användarnamnet erik, ett lösenord och gruppen Read-only. Välj Create.

Nu kan Erik öppna varje enhet, rack, kabel och adress, men får "403 Forbidden" när han försöker lägga till eller ändra något, och kan inte se användare eller behörigheter. Grupperna Core, Extras och Users är utelämnade med avsikt: där finns jobb, skript, webhooks, användare och tokens. En behörighet kan också begränsas till vissa objekt med Constraints, till exempel en enda site. Det har vi inte testat.

NetBox är inte översatt till svenska. Varje användare kan välja ett av dess 17 språk, och tema, under Preferences i användarmenyn uppe till höger.

10. Använd REST-API:et

Skript och andra verktyg läser och skriver i NetBox genom dess REST-API, med en token. I användarmenyn väljer du API Tokens > Add a Token, låter Version vara v2, kryssar i Write enabled om token ska kunna ändra saker och väljer Create. NetBox visar token en enda gång, och den börjar med nbt_; kopiera den då.

Från valfri dator, med din token i stället för nbt_…:

TOKEN='nbt_…'
curl -s -H "Authorization: Bearer $TOKEN" "https://netbox.example.com/api/ipam/prefixes/?prefix=10.10.10.0/24"

Svaret innehåller prefixets id, här 1. Fråga efter dess nästa lediga adress:

curl -s -H "Authorization: Bearer $TOKEN" "https://netbox.example.com/api/ipam/prefixes/1/available-ips/?limit=1"

Eller ta den i samma anrop, så att två skript aldrig får samma adress:

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"description": "mail1", "dns_name": "mail1.example.com"}' \
  https://netbox.example.com/api/ipam/prefixes/1/available-ips/

NetBox svarar med den nya adressen, i vårt test 10.10.10.3/24, nu sparad som aktiv. https://netbox.example.com/api/schema/swagger-ui/ beskriver varje anrop. En token kan begränsas till vissa adresser i fältet Allowed IPs och få ett utgångsdatum. Den har samma rättigheter som sin användare, så ge ett skript en egen användare med bara de behörigheter det behöver.

11. Webhooks och händelseregler

En händelseregel får NetBox att göra något när något ändras, till exempel anropa en webhook, ett annat systems adress, när en IP-adress skapas. För att se vad NetBox skickar startar du dess testmottagare som netbox, i en andra SSH-session:

podman exec -it netbox /opt/netbox/netbox/manage.py webhook_receiver

Den lyssnar på port 9000 inne i podden. Sedan, under Operations > Integrations:

1. Webhooks > Add: namnet Test receiver, URL http://127.0.0.1:9000/, metoden POST och som Body template:

   {"text": "IP address {{ data.address }} was {{ event }} by {{ request.user }}"}
   

   
   Välj Create.
2. Event Rules > Add: namnet New IP addresses, objekttypen IPAM > IP Address, händelsen Object created, åtgärdstypen Webhook och webhooken Test receiver. Välj Create.

Skapa en IP-adress, för hand eller med API-anropet ovan, så skriver mottagaren ut anropet en sekund senare, med "text": "IP address 10.10.10.4/24 was created by anna". Stoppa den med Ctrl+C. Använd 127.0.0.1 i stället för localhost i URL:en: i containern är localhost IPv6-adressen, där mottagaren inte lyssnar.

På riktigt pekar du webhooken mot en tjänst som tar emot den, till exempel ett ämne på ntfy eller ett flöde i n8n. Körs den tjänsten på samma server lägger du till AddHost=ntfy.example.com:host-gateway under [Pod] i netbox.pod, som Podman-guiden förklarar. Workern skickar webhooks, och de som misslyckas listas under Admin > System > Background Tasks, där du kan skicka dem igen. Låt bara personer du litar på skapa webhooks: deras mallar körs på servern.

12. Ändringsloggen

Varje ändring, i webbgränssnittet, med import eller genom API:et, sparas med vem som gjorde den, när, och hur objektet såg ut före och efter. Operations > Logging > Change Log listar alla, och varje objekt har en egen flik Changelog. En import eller en massändring delar ett och samma request-ID, så att du ser allt den ändrade tillsammans.

NetBox sparar ändringar i 90 dagar. Vill du spara dem längre lägger du till CHANGELOG_RETENTION=365 i ~/netbox.env, eller 0 för att spara dem för alltid, och startar om:

systemctl --user restart netbox netbox-worker

13. Externa anslutningar

Vi avlyssnade serverns DNS-uppslagningar och utgående anslutningar medan NetBox startade, medan sidorna användes och medan det dagliga underhållet kördes. Utan ISOLATED_DEPLOYMENT=true gjorde NetBox tre sorters anslutningar:

• Det dagliga underhållsjobbet skickade statistik till census.netbox.oss.netboxlabs.com: NetBox-versionen, Python-versionen och ett slumpat ID, så att NetBox Labs kan räkna installationer. CENSUS_REPORTING_ENABLED=false stoppar bara det.
• Panelen NetBox News på startsidan fick servern att hämta nyheter från api.netbox.oss.netboxlabs.com var fjärde timme.
• Admin > System > Plugins fick servern att hämta NetBox Labs lista över plugins från samma adress.

Två till är avstängda tills du slår på dem. NetBox Copilot, NetBox Labs AI-assistent, är avstängd för varje användare tills hen slår på den under Preferences; då laddar webbläsaren den från static.copilot.netboxlabs.ai, och det man frågar den går till NetBox Labs. Kontrollen av nya NetBox-versioner är avstängd i den här avbilden och slås på med RELEASE_CHECK_URL=https://api.github.com/repos/netbox-community/netbox/releases, som får servern att fråga GitHub.

ISOLATED_DEPLOYMENT=true stänger av allt det här, och med den visade vår avlyssning inga externa anslutningar alls. Panelen NetBox News visar då "This RSS feed requires an external connection"; ta bort den från startsidan med dess ✕. Inställningen döljer också länkarna till NetBox Labs moln- och företagserbjudanden i menyn. Webhooks går fortfarande ut, till de adresser du anger.

14. Lägg till ett plugin

Plugins lägger till funktioner i NetBox och måste installeras i avbilden. Som netbox skapar du en katalog för en egen liten avbild:

mkdir -p ~/netbox-plugins
cd ~/netbox-plugins

Skapa Containerfile, här med pluginet Topology Views, som ritar upp dina enheter och kablar som en karta:

FROM docker.io/netboxcommunity/netbox:v4.7
RUN uv pip install netbox-topology-views==4.7.0
COPY plugins.py /etc/netbox/config/plugins.py
RUN mkdir -p /opt/netbox/netbox/static/netbox_topology_views/img && \
    DEBUG=true SECRET_KEY=only-used-while-building-only-used-while-building-xx \
    python /opt/netbox/netbox/manage.py collectstatic --no-input

Och plugins.py:

PLUGINS = ["netbox_topology_views"]

Bygg den:

podman build --pull=newer -t localhost/netbox-plugins:v4.7 .

SECRET_KEY där används bara för att samla ihop pluginets filer under bygget och är inte din riktiga nyckel. Ändra sedan två rader i både netbox.container och netbox-worker.container:

Image=localhost/netbox-plugins:v4.7
AutoUpdate=local

Och starta om:

systemctl --user daemon-reload
systemctl --user restart netbox netbox-worker

NetBox skapar pluginets tabeller när den startar, och det syns under Admin > System > Plugins. Under Topology Views > Topology väljer du siten, kryssar i Show Cables och väljer Search för att se switchen med de två servrarna.

Varje version av ett plugin fungerar bara med vissa NetBox-versioner, som dess sida listar. Lås versionen, som ovan, och kontrollera att det finns en ny innan du går över till en ny NetBox-version (steg 16).

15. Säkerhetskopiera

Som netbox:

umask 077
mkdir -p ~/backup
podman exec netbox-db pg_dump -U netbox netbox > ~/backup/netbox-db.sql
podman volume export netbox-media > ~/backup/netbox-media.tar
podman volume export netbox-scripts > ~/backup/netbox-scripts.tar
for s in netbox-secret-key netbox-api-pepper; do podman secret inspect --showsecret --format '{{.SecretData}}' $s > ~/backup/$s.txt; done

Det är allt NetBox behöver: databasen, med alla objekt, användare, behörigheter, tokens och ändringsloggen, de uppladdade bilderna och skripten, och de två hemligheterna. API-tokens fungerar bara med den peppar de skapades med. Dumpen körs medan NetBox fortsätter att fungera. Valkey innehåller bara cachen och jobbkön, som NetBox bygger upp igen. Kopiera ~/backup till en annan maskin, till exempel med restic, och förvara den säkert: databasen innehåller hela din karta över nätverket.

För att återställa på en ny server följer du steg 1 till 3, men skapar de två första hemligheterna från säkerhetskopian i stället för nya, och startar inte podden än:

tr -d '\n' < ~/backup/netbox-secret-key.txt | podman secret create netbox-secret-key -
tr -d '\n' < ~/backup/netbox-api-pepper.txt | podman secret create netbox-api-pepper -
openssl rand -hex 24 | tr -d '\n' | podman secret create netbox-db-password -

Om du använde ett plugin bygger du samma avbild som i steg 14. Läs sedan in säkerhetskopian i tomma volymer:

systemctl --user daemon-reload
for v in media scripts; do podman volume create netbox-$v; podman volume import netbox-$v ~/backup/netbox-$v.tar; done
systemctl --user start netbox-db
podman exec -i netbox-db psql -q -o /dev/null -U netbox -d netbox < ~/backup/netbox-db.sql
systemctl --user start netbox-pod
systemctl --user enable --now podman-auto-update.timer

Genom att bara starta databasen först läses säkerhetskopian in innan NetBox sätter upp en tom databas. Hoppa över steg 4: dina konton finns i säkerhetskopian. För att återställa på samma server stoppar du först podden med systemctl --user stop netbox-pod och tar bort de gamla volymerna med podman volume rm netbox-db netbox-valkey netbox-media netbox-scripts.

16. Uppdatera

podman auto-update letar en gång om dagen efter nya avbilder av NetBox, PostgreSQL och Valkey och startar om podden när någon har ändrats. Taggen v4.7 får varje buggrättning av NetBox 4.7. För att uppdatera direkt:

podman auto-update

En ny mindre version, som 4.8, ändrar databasen och kan ta bort gamla inställningar, så det är ett steg du tar själv:

1. Läs versionsinformationen på GitHub, netbox-community/netbox, efter ändringar som kan ställa till det.
2. Ta en säkerhetskopia som i steg 15.
3. Byt v4.7 mot den nya versionen i netbox.container och netbox-worker.container, eller i Containerfile om du använder plugins, med pluginversioner som stöder den, och bygg om.
4. Starta om:

systemctl --user daemon-reload
systemctl --user restart netbox netbox-worker

NetBox kör sina databasmigreringar när den startar. Från 4.6.10 till 4.7.3 tog det tre minuter i vårt test, och under tiden låg webbgränssnittet nere; följ det med journalctl --user -fu netbox. Inom NetBox 4 kan du hoppa över mindre versioner; NetBox 5.0 kommer att kräva den sista 4.x-versionen först. Låt bakgrundsjobben bli klara innan: versionsinformationen för 4.7 varnar för att köade webhooks från den gamla versionen misslyckas efter uppdateringen.

Med plugins hämtar inte den dagliga automatiska uppdateringen nya NetBox-avbilder. Bygg om avbilden med kommandot från steg 14 för att få den senaste versionen av 4.7, och kör podman auto-update, som startar om containrarna med den nya avbilden.

Felsökning

NetBox svarar inte på flera minuter efter första starten eller en uppdatering. Den bygger upp eller migrerar sin databas, och systemctl --user status netbox visar activating tills den är klar. journalctl --user -fu netbox visar varje migrering. Tjänsten misslyckas först efter 30 minuter, TimeoutStartSec i netbox.container.

"Bad Request (400)". Namnet i adressfältet finns inte i ALLOWED_HOSTS. Rätta ~/netbox.env och starta om.

Uppladdning av en bild misslyckas med "A file permission error was detected" och /etc/netbox/media. MEDIA_ROOT saknas i ~/netbox.env.

Loggen varnar hela tiden för att "LOGIN_REQUIRED is deprecated". netbox-dockers egen konfiguration sätter den fortfarande, och NetBox varnar vid varje start. Det är ofarligt, och inloggning krävs fortfarande.

"Password must have at least one uppercase letter." NetBox lösenordsregler gäller alla konton: minst 12 tecken, med stora och små bokstäver och en siffra.

En webhook misslyckas med "Connection refused". Den mottagande adressen svarar inte inifrån podden. En tjänst på samma server behöver raden AddHost= från steg 11, och där betyder localhost IPv6.