Bereich Administration Rechentechnik

Netbox 3.3.10 ist EOL (kam aus der Errormessage von nixos-rebuild switch) kann damit nicht mehr so "einfach", im Sinne von so wenig wie möglich aber so viel wie nötig konfigurieren, gebaut werden.

• netbox was updated to 3.5. NixOS’ services.netbox.package still defaults to 3.3 if stateVersion is earlier than 23.05. Please review upstream’s breaking changes for 3.4.0 and for 3.5.0, and upgrade NetBox by changing services.netbox.package. Database migrations will be run automatically.

Daher wurde die system.StateVersion auf 23.05 gesetzt.

Das Bauen war erfolgreich, aber es gibt einen BadGateway Error der nun gefixed werden muss.

MaximilianTraenkler schrieb (#note-3):

Daher wurde die system.StateVersion auf 23.05 gesetzt.

Meinem ersten Eindruck nach ist das aber eben doch genau falsch.

system.stateVersion soll doch (immer einfach) gleich bleiben.

Hast du mal versucht services.netbox.package. (festlegend auf Version 3.3 (vermutlich mit pkgs.netbox_3_3)) zu setzen?
So verstand ich eben beim Lesen den Hinweis von NixOS.

BTW: Wenn die Aktualisierung fehlschlägt, dann setze doch bitte einfach erst einmal den vorherigen Stand wieder her. (Wenn da gerade wer was lesen, oder gar eintragen, möchte, kann das doch gerade nicht machen, oder? Das ist doof.)

Im Übrigen könnte der ideale Pfad der Aktualisierung "How to upgrade from version 3.3" im Wiki (von NixOS) vermerkt werden.
https://nixos.wiki/wiki/NetBox
https://nixos.wiki/wiki/Talk:NetBox

Wurde vor der Aktualisierung von NixOS (22.11 zu 23.05) noch einmal alles mögliche aktualisiert (aka nixos-rebuild switch --upgrade)?

PaulRiegel schrieb (#note-4):¶

Meinem ersten Eindruck nach ist das aber eben doch genau falsch.

system.stateVersion soll doch (immer einfach) gleich bleiben.

In meinem Verständniss kann es "(immer einfach)" gleich bleiben, wann sinnvoll und wann nicht hab ich noch kein Gefühl dafür. In diesem konkreten Fall kann mans nicht. Ich hab die Release Notes nicht ordentlich gelesen bzw. den wichtigsten Part überlesen...fail.

Hast du mal versucht services.netbox.package. (festlegend auf Version 3.3 (vermutlich mit pkgs.netbox_3_3)) zu setzen?
So verstand ich eben beim Lesen den Hinweis von NixOS.

Der Default für diese Option ("if versionAtLeast config.system.stateVersion "23.05" then pkgs.netbox else pkgs.netbox_3_3";) setzt bei einer stateVersion kleiner 23.05 das Package automatisch auf Netbox Version "3.3.10". Diese ist aber EOL und deshalb muss folgendes gesetzt werden damit das weiter laufen kann:

 nixpkgs.config.permittedInsecurePackages = [
    "netbox-3.3.10" 
  ];

BTW: Wenn die Aktualisierung fehlschlägt, dann setze doch bitte einfach erst einmal den vorherigen Stand wieder her. (Wenn da gerade wer was lesen, oder gar eintragen, möchte, kann das doch gerade nicht machen, oder? Das ist doof.)

Geht klar!

PaulRiegel schrieb (#note-6):¶

Wurde vor der Aktualisierung von NixOS (22.11 zu 23.05) noch einmal alles mögliche aktualisiert (aka nixos-rebuild switch --upgrade)?

Das habe ich getan, ja!

Hab die Errormessage reproduziert beim Bauen mit der stateVersion 22.05:¶

(Die ist mir letztes mal "abhanden" gekommen und dann hab wollte ich mir den Aufwand des reproduzierens nicht machen.)

error: Package ‘netbox-3.3.10’ in /nix/store/s4x0fspf7s2q06vpv0fhqcmgd1a9kcp9-nixos-23.05/nixos/pkgs/servers/web-apps/netbox/generic.nix:125 is marked as insecure, refusing to evaluate.

   Known issues:
    - Netbox version 3.3.10 is EOL; please upgrade by following the current release notes instructions.

   You can install it anyway by allowing this package, using the
   following methods:

   a) To temporarily allow all insecure packages, you can use an environment
      variable for a single invocation of the nix tools:

        $ export NIXPKGS_ALLOW_INSECURE=1

    Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
    (Flake) command, `--impure` must be passed in order to read this
    environment variable.

   b) for `nixos-rebuild` you can add ‘netbox-3.3.10’ to
      `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
      like so:

        {
          nixpkgs.config.permittedInsecurePackages = [
            "netbox-3.3.10" 
          ];
        }

   c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
      ‘netbox-3.3.10’ to `permittedInsecurePackages` in
      ~/.config/nixpkgs/config.nix, like so:

        {
          permittedInsecurePackages = [
            "netbox-3.3.10" 
          ];
        }

MaximilianTraenkler schrieb (#note-8):

PaulRiegel schrieb (#note-4):

Meinem ersten Eindruck nach ist das aber eben doch genau falsch.

system.stateVersion soll doch (immer einfach) gleich bleiben.

In meinem Verständniss kann es "(immer einfach)" gleich bleiben, wann sinnvoll und wann nicht hab ich noch kein Gefühl dafür. In diesem konkreten Fall kann mans nicht. Ich hab die Release Notes nicht ordentlich gelesen bzw. den wichtigsten Part überlesen...fail.

Im allgemeinen (und auch in dem konkreten) Fall sollte das Verständnis ganz einfach sein: system.stateVersion immer lassen. (Da nie nur Gefühl leiten lassen, sondern höchstens durch (eigenes oder fremdes belegbares) Verständnis leiten lassen).

Im Übrigen überlege ich mir gerade, ob es sinnvoll ist, dass das noch einmal irgendwo erwähnt wird. (In meiner Welt war das bisher klar.)

BTW: Haben wir mal irgendwo "einfach" den Wert für system.stateVersion "manipuliert"? (Das wäre nämlich aus meiner Sicht massiv dokumentationswürdig. (Die "ö's" sind mit flakes wahrscheinlich schon über solche Probleme erhaben hinaus. :-D ) )

MaximilianTraenkler schrieb (#note-8):

PaulRiegel schrieb (#note-4):

Meinem ersten Eindruck nach ist das aber eben doch genau falsch.

Hast du mal versucht services.netbox.package. (festlegend auf Version 3.3 (vermutlich mit pkgs.netbox_3_3)) zu setzen?
So verstand ich eben beim Lesen den Hinweis von NixOS.

Der Default für diese Option ("if versionAtLeast config.system.stateVersion "23.05" then pkgs.netbox else pkgs.netbox_3_3";) setzt bei einer stateVersion kleiner 23.05 das Package automatisch auf Netbox Version "3.3.10". Diese ist aber EOL und deshalb muss folgendes gesetzt werden damit das weiter laufen kann:

[...]

Ich formuliere es anders: Was passiert, wenn - so kann die Meldung von NixOS gedeutet werden - wir (den Schlüssel) services.netbox.package mit (dem Wert) pkgs.netbox versehen?

NixOS will uns ja nur vor "Breaking Changes" bei der Aktualisierung bewahren und stellt - neben der normal aktualisierten Version - ein Paket mit der veralteten Version bereit, sodass nichts direkt kaputt geht. Oder?

PaulRiegel schrieb (#note-10):

NixOS will uns ja nur vor "Breaking Changes" bei der Aktualisierung bewahren und stellt - neben der normal aktualisierten Version - ein Paket mit der veralteten Version bereit, sodass nichts direkt kaputt geht. Oder?

Im Übrigen müsste halt mal nachgeschaut werden, ob und was bei
https://docs.netbox.dev/en/stable/release-notes/version-3.4/#breaking-changes
https://docs.netbox.dev/en/stable/release-notes/version-3.5/#breaking-changes
bricht (brechen wird (oder soll)). Vielleicht betrifft uns das gar nicht (nennenswert).

(offbyone - unsere eigene fachspezialexpertin zur anwendung netbox beim stura - kann das vermutlich am ehesten bewerten. goeranh - unsere eigene fachspezialexpertin für den dienst datenbanken im stura - könnte entsprechend vielleicht notwendig einträge (rum)schmieden.)

Soweit ich das verstanden habe, als ich mir die Breaking Changes der NetBox angeschaut habe, nutzen wir die geänderten Features nicht.
Insofern und da in der Doku stand, dass immer (außer über Major-Releases) ein simples Update gefahren werden kann, sollte es eigentlich keine Probleme geben, die NetBox auf Version 3.5.x zu updaten.
Ich hatte angefangen im Container https://10.1.0.17:8006/#v1:0:=lxc%2F100:4::::::: erstmal testweise eine NetBox mit stateVersion 23.05 und NetBox 3.5.x einzurichten.
Einen simplen Datenbank-Dump der produktiven NetBox einzuspielen und vermutlich ein update/migration Skript laufen zu lassen sollte theoretisch funktionieren.

Falls falls das geht, können wir das produktiv nochmal auf dem Cluster machen.

Ich habe das mal wie beschrieben gemacht.

Das Migration-Script läuft dank NixOS automatisch. Mir sind keine Fehler aufgefallen.

Der Test-Container läuft mit unstable-Channel, stateVersion 23.05 und NetBox 3.5.6 auf dem Test-Server.

Ich würde eventuell morgen das selbe auf dem Produktiv-Cluster machen und die alte Instanz löschen.
Vater wollte eine Kopie der alten configuration.nix, welche in der neuen Instanz oder im (leider noch nicht für alle zugänglichen) Forgejo als Vergleich/Historie/Dokumentation liegen soll.

Einziger Fehler der mir noch aufgefallen ist: Die Suchfunktion funktionierte nicht mehr, das ließ sich mit einem

netbox-manage reindex

Ablauf:

1. Neuen Container vorbereiten
2. Datenbankdump erstellen
3. Alte Konfiguration und DB-Dump auf Host kopieren
4. Alten Container aus HA entfernen und ausschalten
5. Neuen Container starten und zu HA hinzufügen
6. Alte Konfiguration und DB-Dump in Container kopieren
7. Neue Konfiguration aus dem Test-Container kopieren und anpassen
8. Konfiguratuion bauen
9. Datenbank-Dump in Postgresql gießen
10. Das secretFile erstellen

Letzteres blockiert solange es nicht existiert das Migration-Script und verhindert, dass das Script und der Import der Datenbank sich stören.