Securepoint Support Forum

Hallo,

ich habe gestern aus der Ferne einen UTM-Cluster (2 x RC340) von 12.7.5.1 auf 14.0.2 aktualisiert und danach die Finalisierung bestätigt. Mit der neuen Version hatte ich ein Problem (Der DHCP-Server hat keine Leases mehr vergeben). Also wollte ich wieder zurück auf die 12.x Version. Die Master UTM startete wie geplant neu. Nach dem Neustart war wieder die Version 14.x aktiv. Als ich das erneut versuchte, war dann die Master-Node nicht mehr in funktionsfähigem Zustand. Das System war noch per ping erreichbar, aber SSH ging nicht mehr und die GUI auch nicht mehr. Die Cluster-IP-Adressen waren beiden Nodes zugewiesen. ( => Split-Brain)

Nachdem ich dann das System vom Personal vor Ort ausschalten lies, kam es wieder hoch (Version 14). Nachdem das DHCP-Problem gelöst werden konnte, besteht aktuell keine Notwendigkeit für einen Downgrade mehr.

Geht der Downgrade von der 14.x auf die 12.x grundsätzlich nicht mehr?

Viele Grüße,
Tobias

Die Frage ist, wie das gemacht wurde. Ein reines Rollback ist auf jeden Fall durchführbar. Das Installieren einer älteren Softwareversion dagegen unterstützt die UTM nicht.

Das ist der aktuelle Stand:
Das wollte ich per Rollback auf die alte Version zurückspielen. Das hat den beschriebenen Fehler verursacht.

Ist eine Konfiguration mit einem "*" vorhanden?

Sonst sollte das Rollback problemlos möglich sein. Zuerst auf der Slave, danach auf der Master

Mario hat geschrieben: Ist eine Konfiguration mit einem "*" vorhanden?

Eine Konfiguration, in deren Name das * - Zeichen enthalten ist? Nein.

Sonst sollte das Rollback problemlos möglich sein. Zuerst auf der Slave, danach auf der Master

Ich habe den Rollback auf dem Master begonnen. Wenn das ein Fehler ist, dann weiss ich das das nächste Mal.

Erneuter Downgrade Versuch fehlgeschlagen.

Durchführung:

• Secondary System auf Version 12.7.5.1 zurück gesetzt via GUI. Hat problemlos funktioniert.
• Primary System per GUI zurück gesetzt. Nach fünf Minuten immer noch online, ohne dass die rebootet hat
• Primary System sicherheitshalber rebootet.
• Danach Primary immer noch auf 14.0.2
• Anschließend erneuter Versuch via Konsole: spcli system upgrade rollback
• Nach ca. 8 Minuten ist das Primary System nicht mehr erreichbar. GUI nicht erreichbar. SSH nicht erreichbar. Cluster ist im Split Brain (Virtuelle IP-Adressen auf beiden Nodes zugewiesen (getestet mit arping))
• Primary System vom Strom genommen. Wieder hochgefahren. Hat Versoin 14.0.2 aktiv.
• Secondary System wieder auf 14.0.2 aktualisiert.

Meine Vermutung dass das Primary System ein Software-/Konfigurationsproblem hat.

Ich schlage vor eher bei der v14 zu bleiben. Für das DHCP-Thema lässt sich wahrscheinlich eine Lösung findet, bis die 14.0.3 dieses Problem an sich behebt

a) Ja. Ich werde wohl bei 14.x bleiben. Ein Downgrade zu 12.x wäre schwierig. Vermutlich würde das Neuinstallation mit altem Config-Import bedeuten. Aktuell keine Störungen mit DHCP.

b) Für mich ist 100% zuverlässige Rollback-Möglichkeit ein wichtiges Feature. Die Tatsache, dass das wohl doch nicht so zu 100% zuverlässig geht, finde ich sehr schlecht.

Da ich nicht weiß, was schief gelaufen ist, kann ich dazu nicht viel sagen.

Bei einem Rollback kann nicht viel schief gehen, da die Dateien aus einem Backup geholt werden. Beim Cluster besteht aber das Problem, das man den Firmwarestand übertragen kann, wo dann, wenn man nicht hinschaut, ein Rollback zu einem Downgrade wird, welches so nicht vorgesehen ist.

Nachtrag: Die nicht mehr funktionierende Rollback-Funktion betrifft jetzt jede Version. Also auch z. B. von 14.0.5 auf 14.0.4 geht nicht mehr.

Das Thema wurde als Ticket gemeldet und dieser Thread wurde verlinkt.

Das kann so nicht passieren aus meiner Sicht.

Wenn Maschine A sich ein Update zieht und Sie von v14.0.4 auf die 14.0.5 aktualisieren, bleibt das Backup der 14.0.4 so lange, bis eine neue Firmwareversion herunter geladen wurde. Wird dann das Updatepaket zu Maschine B verschoben und hier ein Update gemacht, wird die vorherige Firmwareversion von Maschine B (Die theoretisch bei Fehlbedienung anders sein kann), ebenfalls als Backup gehalten.

Im Falle des Cluster kann man durch senden der Firmware an die andere Maschine ebenfalls das Überschreiben des Backups auslösen. Man sollte somit nicht versuchen, unnötig die Firmware von einer Maschine zur anderen zu schieben. Dies sollte nur bei Bedarf getan werden.

Was die anderen beschriebenen Probleme angeht: Hier muss dann wohl ein Blick auf die Konfiguration geworfen werden. An sich kann das so nicht sein, da die Konfiguration als Backup gesichert ist und mit der Firmwareversion widerhergestellt wird. Die UTM hat somit die alte Firmware mit der identischen Konfiguration von vor dem update. Wenn nun also Probleme auftauchen (UTM nicht erreichbar) gibt es ein inhärentes Konfigurationsproblem, oder irgendetwas anderes externes spielt mit.

Oder es wurde eine alte Firmware als Update eingeschoben, was, wie schon erwähnt, ein Update statt eines Rollback auslöst. Da die Konfiguration von einer neueren Softwareversion nicht in eine alte Version übernommen werden sollte, kann das vielleicht das beschriebene Verhalten erklären. Dieses Backup ist auch nach Neustart der UTM defekt und taugt nicht zum Rollback.