NetBox im abgeschotteten Netz: Podman-Bundle für Rocky Linux 8.10

EdwardMoon

Für einen NetBox-Aufbau im abgeschotteten Netz werden Pakete und OCI-Images auf einem Internetserver gesammelt, auf Integrität geprüft und anschließend auf den Offline-Server übertragen. Das Kopieren von Image-Dateien allein reicht oft nicht: Podman-Abhängigkeiten, Image-Tags, Datenbankinitialisierung, Sicherheit und automatischer Start nach Neustarts müssen ebenfalls stimmen.

Dieser Leitfaden verwendet Rootful Podman auf Rocky Linux 8.10 x86_64. Die am 20. Juli 2026 geprüften Beispielversionen sind NetBox v4.6.5-5.0.2, PostgreSQL 18-alpine und Valkey 9.1-alpine. Vor der produktiven Übernahme offizielle Versionshinweise und Registry-Digests erneut prüfen.

Voraussetzungen und Prüfkriterien

• Rocky-Linux-Nebenversion, CPU-Architektur und aktivierte Repositories auf Erstellungs- und Offline-Server abstimmen.
• Für Container-Images genaue Versionstags statt latest verwenden und Digests dokumentieren.
• RPMs mit --resolve --alldeps einschließlich bereits installierter Abhängigkeiten herunterladen.
• Nach der Online-Erstellung die Offline-Installation auf einem Testserver mit identischen Bedingungen reproduzieren.
• Rootful und Rootless Podman im Betrieb nicht vermischen. Alle Offline-Befehle dieses Artikels verwenden einheitlich sudo podman.

cat /etc/rocky-release
uname -m
sudo dnf repolist --enabled
sudo podman --version

Architektur des Offline-NetBox-Aufbaus

NetBox-Webdienst, Worker, PostgreSQL sowie je eine Valkey-Instanz für Aufgaben und Cache laufen in einem Pod. Seine Container teilen den Netzwerk-Namensraum; die Anwendung erreicht Datenbank und Valkey daher über 127.0.0.1. Nur NetBox-Port 8080 wird auf Hostport 8000 veröffentlicht.

netbox-pod
├── netbox             127.0.0.1:8080  ← host:8000
├── netbox-worker      RQ worker
├── netbox-postgres    127.0.0.1:5432
├── netbox-valkey      127.0.0.1:6379  (tasks)
└── netbox-valkey-cache 127.0.0.1:6380 (cache)

Eine Einführung in die Netzwerkkonzepte bietet die interne Anleitung Container-Grundlagen mit Praxisbeispielen.

Offline-Bundle im verbundenen Netz erstellen

1. Versionen und Verzeichnisse festlegen

Versionen über Variablen festlegen, damit nach der Übernahme dieselben Tags verfügbar sind. Versions- und Architekturangaben in Dateinamen verringern Verwechslungen beim Aufbewahren mehrerer Bundles.

NETBOX_TAG="v4.6.5-5.0.2"
POSTGRES_TAG="18-alpine"
VALKEY_TAG="9.1-alpine"
BUNDLE_ID="netbox-airgap-${NETBOX_TAG}-rocky8-$(uname -m)"
BUNDLE_ROOT="/opt/${BUNDLE_ID}"

sudo mkdir -p "${BUNDLE_ROOT}"/{rpms,images,env,scripts,manifests}
sudo chown -R "$(id -u):$(id -g)" "${BUNDLE_ROOT}"

2. Podman-RPMs und Abhängigkeiten sammeln

dnf download --resolve kann auf dem Erstellungsserver bereits installierte Pakete überspringen. Für Offline-Bundles deshalb zusätzlich --alldeps verwenden. Abweichende aktive Repositories zwischen Quell- und Zielserver können Signatur- oder Abhängigkeitsprobleme verursachen. Die Repository-Liste ebenfalls im Manifest erfassen.

sudo dnf install -y dnf-plugins-core

sudo dnf download --resolve --alldeps   --destdir="${BUNDLE_ROOT}/rpms"   podman tar gzip openssl

sudo dnf repolist --enabled > "${BUNDLE_ROOT}/manifests/dnf-repolist.txt"
rpm -Kv "${BUNDLE_ROOT}"/rpms/*.rpm   > "${BUNDLE_ROOT}/manifests/rpm-signatures.txt"

3. Images mit genauen Tags laden und speichern

NetBox Docker bietet Tags aus NetBox-Version und Version der netbox-docker-Unterstützungsdateien. Produktiv einen genauen Tag verwenden und unmittelbar nach dem Pull Digest sowie Image-ID dokumentieren. podman save erhält Image-Layer und Tags; podman export exportiert dagegen nur das zusammengefasste Containerdateisystem.

podman pull "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"
podman pull "docker.io/postgres:${POSTGRES_TAG}"
podman pull "docker.io/valkey/valkey:${VALKEY_TAG}"

{
  podman image inspect --format 'netbox {{.Digest}} {{.Id}}'     "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"
  podman image inspect --format 'postgres {{.Digest}} {{.Id}}'     "docker.io/postgres:${POSTGRES_TAG}"
  podman image inspect --format 'valkey {{.Digest}} {{.Id}}'     "docker.io/valkey/valkey:${VALKEY_TAG}"
} > "${BUNDLE_ROOT}/manifests/image-digests.txt"

podman save --format oci-archive   -o "${BUNDLE_ROOT}/images/netbox.tar"   "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"
podman save --format oci-archive   -o "${BUNDLE_ROOT}/images/postgres.tar"   "docker.io/postgres:${POSTGRES_TAG}"
podman save --format oci-archive   -o "${BUNDLE_ROOT}/images/valkey.tar"   "docker.io/valkey/valkey:${VALKEY_TAG}"

4. Umgebungsdateien ohne Standardpasswörter erstellen

Beispielpasswörter nicht veröffentlichen oder wiederverwenden. Die folgenden Befehle erzeugen bei der Online-Erstellung Zufallswerte und beschränken die Umgebungsdateien auf Modus 600. Adressen und Namen in ALLOWED_HOSTS an das tatsächliche Offline-Netz anpassen.

umask 077

DB_PASSWORD="$(openssl rand -hex 24)"
VALKEY_PASSWORD="$(openssl rand -hex 24)"
VALKEY_CACHE_PASSWORD="$(openssl rand -hex 24)"
ADMIN_PASSWORD="$(openssl rand -hex 18)"
API_TOKEN_PEPPER_1="$(openssl rand -hex 32)"
SECRET_KEY="$(podman run --rm   "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"   python /opt/netbox/netbox/generate_secret_key.py)"

cat > "${BUNDLE_ROOT}/env/postgres.env" << EOF
POSTGRES_DB=netbox
POSTGRES_USER=netbox
POSTGRES_PASSWORD=${DB_PASSWORD}
EOF

cat > "${BUNDLE_ROOT}/env/valkey.env" << EOF
VALKEY_PASSWORD=${VALKEY_PASSWORD}
EOF

cat > "${BUNDLE_ROOT}/env/valkey-cache.env" << EOF
VALKEY_PASSWORD=${VALKEY_CACHE_PASSWORD}
EOF

cat > "${BUNDLE_ROOT}/env/netbox.env" << EOF
DB_HOST=127.0.0.1
DB_PORT=5432
DB_NAME=netbox
DB_USER=netbox
DB_PASSWORD=${DB_PASSWORD}

REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DATABASE=0
REDIS_PASSWORD=${VALKEY_PASSWORD}
REDIS_SSL=false

REDIS_CACHE_HOST=127.0.0.1
REDIS_CACHE_PORT=6380
REDIS_CACHE_DATABASE=1
REDIS_CACHE_PASSWORD=${VALKEY_CACHE_PASSWORD}
REDIS_CACHE_SSL=false

SECRET_KEY=${SECRET_KEY}
API_TOKEN_PEPPER_1=${API_TOKEN_PEPPER_1}
ALLOWED_HOSTS=netbox.internal 10.20.30.40 localhost
TIME_ZONE=Asia/Seoul
LOGIN_REQUIRED=true
ISOLATED_DEPLOYMENT=true
CENSUS_REPORTING_ENABLED=false
COPILOT_ENABLED=false

SKIP_SUPERUSER=false
SUPERUSER_NAME=admin
SUPERUSER_EMAIL=netbox-admin@example.internal
SUPERUSER_PASSWORD=${ADMIN_PASSWORD}
EOF

chmod 600 "${BUNDLE_ROOT}"/env/*
printf 'admin password: %s
' "${ADMIN_PASSWORD}"   > "${BUNDLE_ROOT}/env/initial-admin-password.txt"
chmod 600 "${BUNDLE_ROOT}/env/initial-admin-password.txt"

Nach der ersten Anmeldung das Administrationspasswort ändern, aus netbox.env den Eintrag SUPERUSER_PASSWORD entfernen und auf SKIP_SUPERUSER=true umstellen. Die Variable des offiziellen Images heißt nicht SUPERUSER_USERNAME, sondern SUPERUSER_NAME.

5. Startskript für Offline-NetBox

NetBox-Webdienst und Worker erst starten, wenn PostgreSQL und beide Valkey-Instanzen bereit sind. Entsprechend der offiziellen Konfiguration laufen Webdienst und Worker als netbox:root; beim Worker wird die Superuser-Erstellung übersprungen.

cat > "${BUNDLE_ROOT}/scripts/run-netbox-pod.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

NETBOX_TAG="v4.6.5-5.0.2"
POSTGRES_TAG="18-alpine"
VALKEY_TAG="9.1-alpine"
BUNDLE_ROOT="/opt/netbox-airgap-${NETBOX_TAG}-rocky8-$(uname -m)"

NETBOX_ENV="${BUNDLE_ROOT}/env/netbox.env"
PG_ENV="${BUNDLE_ROOT}/env/postgres.env"
VALKEY_ENV="${BUNDLE_ROOT}/env/valkey.env"
VALKEY_CACHE_ENV="${BUNDLE_ROOT}/env/valkey-cache.env"

for file in "${NETBOX_ENV}" "${PG_ENV}" "${VALKEY_ENV}" "${VALKEY_CACHE_ENV}"; do
  [[ -r "${file}" ]] || { echo "[ERROR] missing ${file}" >&2; exit 1; }
done

if ! podman pod exists netbox-pod; then
  podman pod create --name netbox-pod -p 8000:8080
fi

for volume in netbox-postgres netbox-valkey-data netbox-valkey-cache-data               netbox-media-files netbox-reports-files netbox-scripts-files; do
  podman volume inspect "${volume}" >/dev/null 2>&1 || podman volume create "${volume}"
done

if ! podman container exists netbox-postgres; then
  podman run -d --name netbox-postgres --pod netbox-pod     --env-file "${PG_ENV}"     -v netbox-postgres:/var/lib/postgresql     "docker.io/postgres:${POSTGRES_TAG}"
fi

if ! podman container exists netbox-valkey; then
  podman run -d --name netbox-valkey --pod netbox-pod     --env-file "${VALKEY_ENV}"     -v netbox-valkey-data:/data     "docker.io/valkey/valkey:${VALKEY_TAG}"     sh -c 'valkey-server --appendonly yes --port 6379 --requirepass "$VALKEY_PASSWORD"'
fi

if ! podman container exists netbox-valkey-cache; then
  podman run -d --name netbox-valkey-cache --pod netbox-pod     --env-file "${VALKEY_CACHE_ENV}"     -v netbox-valkey-cache-data:/data     "docker.io/valkey/valkey:${VALKEY_TAG}"     sh -c 'valkey-server --port 6380 --requirepass "$VALKEY_PASSWORD"'
fi

dependencies_ready=0
for attempt in $(seq 1 90); do
  if podman exec netbox-postgres sh -c        'pg_isready -q -t 2 -d "$POSTGRES_DB" -U "$POSTGRES_USER"'     && podman exec netbox-valkey sh -c        'valkey-cli --pass "$VALKEY_PASSWORD" -p 6379 ping 2>/dev/null | grep -qx PONG'     && podman exec netbox-valkey-cache sh -c        'valkey-cli --pass "$VALKEY_PASSWORD" -p 6380 ping 2>/dev/null | grep -qx PONG'; then
    dependencies_ready=1
    break
  fi
  sleep 2
done

[[ "${dependencies_ready}" -eq 1 ]] || {
  echo "[ERROR] PostgreSQL or Valkey did not become ready" >&2
  exit 1
}

if ! podman container exists netbox; then
  podman run -d --name netbox --pod netbox-pod     --user netbox:root     --env-file "${NETBOX_ENV}"     -v netbox-media-files:/opt/netbox/netbox/media     -v netbox-reports-files:/opt/netbox/netbox/reports     -v netbox-scripts-files:/opt/netbox/netbox/scripts     "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"
fi

netbox_ready=0
for attempt in $(seq 1 120); do
  if podman exec netbox curl -fsS http://127.0.0.1:8080/login/ >/dev/null 2>&1; then
    netbox_ready=1
    break
  fi
  sleep 2
done

[[ "${netbox_ready}" -eq 1 ]] || {
  echo "[ERROR] NetBox did not become ready" >&2
  podman logs --tail 100 netbox >&2
  exit 1
}

if ! podman container exists netbox-worker; then
  podman run -d --name netbox-worker --pod netbox-pod     --user netbox:root     --env-file "${NETBOX_ENV}"     -e SKIP_SUPERUSER=true     -v netbox-media-files:/opt/netbox/netbox/media     -v netbox-reports-files:/opt/netbox/netbox/reports     -v netbox-scripts-files:/opt/netbox/netbox/scripts     "docker.io/netboxcommunity/netbox:${NETBOX_TAG}"     /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py rqworker
fi

podman pod ps
podman ps --pod
echo "NetBox: http://<server-ip>:8000"
SCRIPT

chmod 700 "${BUNDLE_ROOT}/scripts/run-netbox-pod.sh"

6. Stopp- und Rücksetzskript mit Datenerhalt

Wer wie im früheren Artikel alle Container und Volumes mit postgres oder redis im Namen löscht, kann Daten anderer Dienste auf demselben Server entfernen. Das folgende Skript adressiert nur die genauen NetBox-Ressourcen und erhält Daten-Volumes beim Standardaufruf.

cat > "${BUNDLE_ROOT}/scripts/reset-netbox-pod.sh" << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

mode="${1:-keep-data}"

podman pod rm -f netbox-pod 2>/dev/null || true
podman rm -f netbox netbox-worker netbox-postgres   netbox-valkey netbox-valkey-cache 2>/dev/null || true

if [[ "${mode}" == "--delete-data" ]]; then
  read -r -p '데이터를 완전히 삭제하려면 DELETE-NETBOX-DATA 입력: ' answer
  [[ "${answer}" == "DELETE-NETBOX-DATA" ]] || {
    echo "취소했습니다."
    exit 1
  }

  for volume in netbox-postgres netbox-valkey-data netbox-valkey-cache-data                 netbox-media-files netbox-reports-files netbox-scripts-files; do
    podman volume rm -f "${volume}" 2>/dev/null || true
  done
else
  echo "컨테이너만 제거했습니다. 데이터 볼륨은 보존됩니다."
fi
SCRIPT

chmod 700 "${BUNDLE_ROOT}/scripts/reset-netbox-pod.sh"

7. SHA-256-Manifest und Archiv erstellen

chmod 600 "${BUNDLE_ROOT}"/env/*

(
  cd "${BUNDLE_ROOT}"
  find rpms images env scripts manifests -type f -print0     | sort -z     | xargs -0 sha256sum > SHA256SUMS
)

cd /opt
sudo tar --xattrs --selinux -czf "${BUNDLE_ID}.tar.gz" "${BUNDLE_ID}"
sudo sha256sum "${BUNDLE_ID}.tar.gz" > "${BUNDLE_ID}.tar.gz.sha256"

Offline installieren

1. Integrität von Archiv und enthaltenen Dateien prüfen

Vor dem Entpacken die externe SHA-256-Prüfsumme kontrollieren, danach das interne Bundle-Manifest prüfen. Scheitert auch nur eine Prüfung, nicht installieren, sondern Übertragungsmedium und ursprüngliches Bundle erneut prüfen.

cd /opt
sudo sha256sum -c netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64.tar.gz.sha256
sudo tar --xattrs --selinux -xzf netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64.tar.gz

cd /opt/netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64
sudo sha256sum -c SHA256SUMS
sudo chown -R root:root .
sudo chmod 600 env/*

2. Podman ohne externe Repositories installieren

cd /opt/netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64
sudo dnf install -y --disablerepo='*' ./rpms/*.rpm
sudo podman --version

Bei Abhängigkeitsfehlern keine beliebigen RPMs im abgeschotteten Netz ergänzen. Zuerst Betriebssystem, Architektur und aktive Repositories des Erstellungsservers mit dem Ziel vergleichen und das Bundle neu erstellen.

3. OCI-Images laden und Tags prüfen

cd /opt/netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64

sudo podman load -i images/netbox.tar
sudo podman load -i images/postgres.tar
sudo podman load -i images/valkey.tar

sudo podman images --digests   | grep -E 'netboxcommunity/netbox|postgres|valkey/valkey'
cat manifests/image-digests.txt

Bei Abweichungen zwischen Ladeergebnis und Manifest nicht starten. Rootless geladene Images sind unter sudo podman nicht sichtbar. Images daher mit demselben Benutzerkontext laden und ausführen.

4. Firewall beschränken und erstmals starten

Das Beispiel erlaubt TCP 8000 nur aus dem Verwaltungsnetz 10.20.0.0/16. Den Bereich anpassen. Zuerst die Firewall konfigurieren und danach Container starten, um Probleme durch erneute Anwendung der Netzwerkregeln zu verringern.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port protocol="tcp" port="8000" accept'
sudo firewall-cmd --reload

cd /opt/netbox-airgap-v4.6.5-5.0.2-rocky8-x86_64
sudo ./scripts/run-netbox-pod.sh

curl -fsS http://127.0.0.1:8000/login/ -o /dev/null
sudo podman pod ps
sudo podman ps --pod

Im Browser http://<IP-des-Offline-Servers>:8000 öffnen. Für den langfristigen Betrieb Port 8000 nicht breit freigeben, sondern einen internen Reverse-Proxy mit TLS verwenden.

Automatischen Start nach Neustarts einrichten

Bis zur folgenden systemd-Umstellung erstellt das Startskript neue Ressourcen. Existieren bereits gestoppte Container mit denselben Namen, zunächst sudo podman pod start netbox-pod verwenden. Nach der Umstellung Start und Stopp einheitlich über systemctl steuern. Vor dem Rücksetzskript den verwaltenden Dienst mit sudo systemctl stop pod-netbox-pod.service stoppen.

Mit Podman aus dem Rocky-Linux-8.10-Repository können erzeugte systemd-Units verwendet werden. Das Ergebnis von --new wird nach bestem Bemühen generiert; die Dateien vor der Installation unbedingt prüfen. In Podman 5 ist dieser Befehl als veraltet eingestuft. Für neue Plattformen vorrangig Quadlet prüfen.

unit_dir="$(mktemp -d)"
cd "${unit_dir}"
sudo podman generate systemd --new --files --name netbox-pod

sudo install -m 0644 ./*.service /etc/systemd/system/
sudo restorecon -Rv /etc/systemd/system

sudo podman pod rm -f netbox-pod
sudo systemctl daemon-reload
sudo systemctl enable --now pod-netbox-pod.service
sudo systemctl status pod-netbox-pod.service --no-pager

Sicherheitskontrollen

• Kein ALLOWED_HOSTS=* verwenden; nur tatsächliche FQDNs und IP-Adressen sowie localhost angeben.
• Zufällige Geheimnisse statt Beispielpasswörter erzeugen und Umgebungs- sowie Sicherungsdateien auf Modus 600 beschränken.
• Nach der ersten Anmeldung Administrationspasswort ändern und initiales Superuser-Passwort aus der Umgebungsdatei entfernen.
• Port 8000 per Firewall auf das Verwaltungsnetz begrenzen und möglichst einen internen TLS-Proxy verwenden.
• Neben Tags auch Image-Digests und SHA-256 des gesamten Bundles im Freigabeprotokoll dokumentieren.
• Das Rücksetzskript löscht nur genaue NetBox-Ressourcen und führt kein globales prune automatisch aus.

Zustand prüfen und Störungen behandeln

Grundzustand und Logs prüfen

sudo podman pod ps
sudo podman ps -a --pod

sudo podman logs --tail 100 netbox
sudo podman logs --tail 100 netbox-worker
sudo podman logs --tail 100 netbox-postgres
sudo podman logs --tail 100 netbox-valkey
sudo podman logs --tail 100 netbox-valkey-cache

sudo podman exec netbox   /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py version

Ist das Root-Dateisystem durch Logs voll, nicht wahllos Container löschen. Nach dem Diagnoseablauf für No space left on device zunächst Datenblöcke, Inodes und gelöschte, noch geöffnete Dateien unterscheiden.

Häufige Fehler und Ursachen

sudo podman exec netbox-postgres sh -c   'pg_isready -d "$POSTGRES_DB" -U "$POSTGRES_USER"'

sudo podman exec netbox-valkey sh -c   'valkey-cli --pass "$VALKEY_PASSWORD" -p 6379 ping'

sudo podman network reload --all

Migrationen laufen beim Start des NetBox-Containers. Ein manuelles manage.py migrate nur als letzte Maßnahme nach Prüfung der Datenbanksicherung und Image-Kompatibilität ausführen.

Sicherung und Wiederherstellung

Vor Upgrade oder erneuter Bereitstellung PostgreSQL-Dump und Media-Volume gemeinsam sichern. Redis beziehungsweise Valkey dienen als Aufgabenwarteschlange und Cache; die wesentlichen Quelldaten liegen in PostgreSQL und Medien. Je nach Wiederherstellungszielen auch scripts- und reports-Volumes aufbewahren.

# Datenbank und Medien im Änderungsfenster bei gestoppten Anwendungsschreibzugriffen gemeinsam sichern.
sudo bash -euo pipefail <<'BASH'
backup_dir="/var/backups/netbox/$(date +%F-%H%M%S)"
install -d -m 0700 "$backup_dir"
umask 077
podman exec netbox-postgres pg_dump -U netbox -d netbox -Fc > "$backup_dir/netbox.dump"
test -s "$backup_dir/netbox.dump"
podman exec -i netbox-postgres pg_restore --list < "$backup_dir/netbox.dump" > "$backup_dir/dump-contents.txt"
podman volume export --output "$backup_dir/netbox-media-files.tar" netbox-media-files
(cd "$backup_dir" && sha256sum netbox.dump netbox-media-files.tar dump-contents.txt > SHA256SUMS && sha256sum -c SHA256SUMS)
BASH

Das Erzeugen von Sicherungsdateien allein genügt nicht. PostgreSQL-Wiederherstellung und Zugriff auf Anhänge regelmäßig auf einem separaten Testserver prüfen.

Häufige Fragen

Warum wird für Offline-NetBox ein Pod verwendet?

Container im Pod teilen den Netzwerk-Namensraum und erreichen Datenbank sowie Valkey über 127.0.0.1. Externe Portfreigaben lassen sich zentral verwalten. Sind Ressourcenisolation und unabhängige Skalierung wichtiger, getrennte Pods oder einen Orchestrator prüfen.

Welche Voraussetzungen braucht der RPM-Erstellungsserver?

Am verlässlichsten sind dasselbe Rocky Linux 8.10, dieselbe CPU-Architektur und dieselben aktiven Repositories wie auf dem Ziel. Mit --alldeps auch Abhängigkeiten aufnehmen, die auf dem Erstellungsserver bereits installiert sind.

Kann latest verwendet werden?

Das ist nicht empfehlenswert. Derselbe Name kann später auf ein anderes Image zeigen und die Reproduktion eines freigegebenen Bundles erschweren. Genauen Versionstag und Digest gemeinsam erfassen. Upgrades als neues, separat geprüftes Bundle behandeln.

Zusammenfassung

Für einen sicheren NetBox-Aufbau im abgeschotteten Netz sind festgelegte Versionen, identische RPM-Repository-Bedingungen, Image-Digests, SHA-256-Prüfungen, Geheimnisverwaltung, genaue Löschgrenzen und Wiederherstellungstests entscheidend. Mit diesem Ablauf lässt sich NetBox auf Podman auch ohne Internet reproduzierbar unter Rocky Linux betreiben.

Offizielle Dokumentation

• Offizielles NetBox-Docker-Repository und Image-Tag-Richtlinie
• Offizielle NetBox-Docker-Image-Tags
• Dokumentation des DNF-download-Plugins
• Podman-save-Dokumentation
• Podman 4.4: systemd-Units erzeugen