Projekt

Allgemein

Profil

Aktionen

Aufgabe #1651

offen

Aufgabe #1647: Aktualisierung Instanzen NixOS von Version 22.11 auf Version 23.05

Aktualisierung Instanz Anwendung NetBox (NixOS 23.05)

Von MaximilianTraenkler vor 10 Monaten hinzugefügt. Vor 7 Monaten aktualisiert.

Status:
Feedback
Priorität:
Normal
Kategorie:
Instanz NetBox
Beginn:
19.07.2023
Abgabedatum:
% erledigt:

50%

Geschätzter Aufwand:
(Gesamtzahl: 0:00 h)

Untergeordnete Tickets 2 (1 offen1 geschlossen)

Aufgabe #1694: Betreuung Aktualisierung Anwendung NetBox von Version 3.3ErledigtSoerenBoxberger19.07.2023

Aktionen
Aufgabe #1724: Abgleich der Konfiguration der aktuellen und vorherigen Instanz Anwendung NetBox (NixOS 23.05)NeuPaulRiegel22.08.2023

Aktionen
Aktionen #1

Von MaximilianTraenkler vor 10 Monaten aktualisiert

  • Thema wurde von Update NixOs Netbox zu NixOS Update Netbox geändert
Aktionen #2

Von PaulRiegel vor 9 Monaten aktualisiert

  • Thema wurde von NixOS Update Netbox zu Aktualisierung Instanz Anwendung NetBox (NixOS 23.05) geändert
Aktionen #3

Von MaximilianTraenkler vor 8 Monaten aktualisiert

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.

Die Release Notes:
  • 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.

Aktionen #4

Von PaulRiegel vor 8 Monaten aktualisiert

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.)

Aktionen #5

Von PaulRiegel vor 8 Monaten aktualisiert

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

Aktionen #6

Von PaulRiegel vor 8 Monaten aktualisiert

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

Aktionen #7

Von PaulRiegel vor 8 Monaten aktualisiert

  • Untergeordnetes Ticket #1694 wurde hinzugefügt
Aktionen #8

Von MaximilianTraenkler vor 8 Monaten aktualisiert

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" 
          ];
        }

Aktionen #9

Von PaulRiegel vor 8 Monaten aktualisiert

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 ) )

Aktionen #10

Von PaulRiegel vor 8 Monaten aktualisiert

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?

Aktionen #11

Von PaulRiegel vor 8 Monaten aktualisiert

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.)

Aktionen #12

Von SoerenBoxberger vor 8 Monaten aktualisiert

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.

Aktionen #13

Von SoerenBoxberger vor 8 Monaten aktualisiert

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.

Aktionen #14

Von SoerenBoxberger vor 8 Monaten aktualisiert

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

netbox-manage reindex

lösen.

Aktionen #15

Von SoerenBoxberger vor 8 Monaten aktualisiert

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.

Aktionen #16

Von SoerenBoxberger vor 8 Monaten aktualisiert

  • Zugewiesen an wurde von Zuständigkeit Instandhaltung IT-Services zu SoerenBoxberger geändert

Die Schritte aus dem letzten Kommentar und der reindex aus dem vorletzten sind auf dem Cluster gegangen worden und die neue NetBox läuft produktiv.

Aktionen #17

Von SoerenBoxberger vor 8 Monaten aktualisiert

  • Status wurde von Neu zu Feedback geändert
  • Zugewiesen an wurde von SoerenBoxberger zu Bereich Administration Rechentechnik geändert
Aktionen #18

Von PaulRiegel vor 8 Monaten aktualisiert

  • Status wurde von Feedback zu Erledigt geändert

Danke! (Im Übrigen habe ich mir nicht einmal die Mühe gemacht, dass ich da groß "prüfend nachschaue". Wenn du das gesichtet hast, dann sollte das passen. (Solltest du dir "unbedingt" eine Prüfung wünschen, dann bin ich selbstverständlich bereit das zu machen. Dazu womöglich die Aufgabe wieder "aufmachen".))

Aktionen #19

Von PaulRiegel vor 7 Monaten aktualisiert

  • Status wurde von Erledigt zu Feedback geändert
Aktionen #20

Von PaulRiegel vor 7 Monaten aktualisiert

  • Untergeordnetes Ticket #1724 wurde hinzugefügt
Aktionen

Auch abrufbar als: Atom PDF