Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Vorgehen Update 2.1 nach 2.2

    Scheduled Pinned Locked Moved Deutsch
    5 Posts 3 Posters 946 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bakunin
      last edited by

      Hallo,

      Ich betreibe pfSense in der Version 2.1.5 (eine Master-/Backupinstallation) mit CARP - also 2 Maschinen.
      Als externe Pakete laufen HAProxy und Squid.

      Nun würde ich gerne auf die aktuelle 2.2.2 Version updaten, habe aber mitbekommen, dass sich da das Handling der virtuellen CARP-Schnittstellen deutlich geändert hat.

      Ist es nun notwendig, eine komplette "Parallelinstallation" aufzusetzen, um nicht das Risiko einzugehen, dass mein Produktivsystem kaputtgeht?

      Wie würdet Ihr vorgehen? (Wie hoch kann man die Change einschätzen, dass nach einem Anklicken der Update-Funktion in der GUI der Produktivbetrieb weitergeht?).

      Danke
      bakunin

      1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator
        last edited by

        Ich würde mich an die offiziellen Vorgaben halten:

        https://doc.pfsense.org/index.php/Upgrade_Guide#pfSense_2.2_Upgrade_Notes
        sowie
        https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide

        Ansonsten wäre mir auch kein anderes Vorgehen bekannt als das typische "Slave zuerst, dann Master hinterher". Alles andere sollte von der Konfigurationsunterstützung konvertiert werden, also auch die CARP Schnittstellen.

        Solche größeren Changes in Produktion würde ich allerdings eher zur Nebenzeit nach Ankündigung von Wartungsarbeiten ansetzen.

        Grüße

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • B
          bakunin
          last edited by

          @JeGr:

          Alles andere sollte von der Konfigurationsunterstützung konvertiert werden, also auch die CARP Schnittstellen.

          Heisst das, dass normalerweise gar keine weiteren Konfigurationsanpassungen notwendig wären? (Mir ist schon bewusst, dass nicht immer alles "normal" läuft …)

          @JeGr:

          Solche größeren Changes in Produktion würde ich allerdings eher zur Nebenzeit nach Ankündigung von Wartungsarbeiten ansetzen.

          Gut - das hatte ich auch so geplant …

          Danke

          bakunin

          1 Reply Last reply Reply Quote 0
          • O
            orcape
            last edited by

            Hi,

            Heisst das, dass normalerweise gar keine weiteren Konfigurationsanpassungen notwendig wären? (Mir ist schon bewusst, dass nicht immer alles "normal" läuft …)

            Das Upgrade von 2.1 auf 2.2 verlief bei mir zumindest, vollkommen ohne Probleme.
            Im Gegenteil, es wurden Probleme die beim vorhergehende Upgrade auftraten und sich nicht beheben ließen, noch gefixt.
            Allerdings haben ich keinen Squid am laufen.
            Gruß orcape

            1 Reply Last reply Reply Quote 0
            • JeGrJ
              JeGr LAYER 8 Moderator
              last edited by

              @bakunin:

              Heisst das, dass normalerweise gar keine weiteren Konfigurationsanpassungen notwendig wären? (Mir ist schon bewusst, dass nicht immer alles "normal" läuft …)

              Dann müsste ich ja quasi für das Update "vorarbeiten". Nein, das Update von 2.1 auf 2.2 soll natürlich selbständig die Konfiguration erkennen, evtl. portieren oder konvertieren und dann "einfach laufen". Genauso waren die Updates von 2.0->2.1 oder von 1.2.3->2.0 ebenso, dass die Konfiguration konvertiert wurde und anschließend mit neuem System gebootet.

              Mein Verständnis von den CARP Änderungen ist aber auch dergestalt, dass ich es so verstanden habe, dass man nun kein physikalisches Interface mehr zwingend braucht um eine CARP Adresse zu definieren. Das heißt aber nicht, dass man es nicht weiterhin so tun kann. Wer also bis jetzt CARP im Einsatz hat, der kann auch weiterhin je ein Bein der pfSense mit eigener IP betreiben + die CARP VIP. Nur wer zukünftig den Luxus nicht mehr hat, weil er bspw. ein /30er Transfernetz bekommt und dort nur noch eine einzige Adresse nutzen kann, kann nun hier auch einen CARP Cluster betreiben, da die pfS auf dem WAN nicht mehr für jedes CARP Mitglied eine eigene IP benötigt. Bislang war unter einem /29er Transfernetz mit mind. 4-6 Adressen nichts zu machen.

              Grüße

              Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

              If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.