Merkwürdige Beobachtung beim Umzug von VM auf BareMetal -- Bug oder Feature?

[white_rabbit]

Hallo.
Ich habe heute ein paar merkwürdige Dinge festgestellt. Bisher lief unsere OPNSense aufgrund der besseren Erreichbarkeit und um alles vorbereiten zu können als VM. Nun habe ich diese config gesichert und auf einer bare-metal-Installation wieder eingespielt. Das hat auch funktioniert, doch offenbar wurden die Erweiterungen/Addons beim Einspielen der config nicht auf dem Zielsystem installiert. Das hatte ein paar Seiteneffekte:

Zum einen fehlte heute Morgen HAProxy. Das fiel mir erst dadurch auf, dass ich plötzlich über die WAN-Schnittstelle mir nichts dir nichts auf die Weboberfläche der OPNSense zugreifen konnte. Normalerweise sollte der HAProxy alle Anfragen auf Port 443 an den richtigen Server dahinter weiterleiten. Da nun aber HAProxy gar nicht da war, wurden offenbar alle Anfragen direkt an die Weboberfläche weitergeleitet. Das wäre ja nicht weiter schlimm -- doch diese Anfragen wurden auch beantwortet, so dass die Weboberfläche "ungesichert" aus dem Internet erreichbar war.

Die zweite Beobachtung ist nicht ganz so dramatisch: Auch Let'sEncrypt fehlte -- das habe ich ebenfalls auf der BareMetal-Installation nachträglich installiert. Auch hier sind alle Settings erhalten geblieben und waren auch sofort verfügbar...

Unter'm Strich frage ich mich daher: Soll das so oder ist das als Bug einzustufen?
Ich tendiere ja zu letzterem, denn wenn man das gar nicht merkt, steht die Firewall plötzlich erreichbar im Internet...

Wie seht ihr das?
Schöne Grüße.

[micneu]

Bin mir nicht sicher, aber denke sowas schonmal gelesen zu haben und ja es soll so sein.


Gesendet von iPad mit Tapatalk Pro

[JeGr]

> Bin mir nicht sicher, aber denke sowas schonmal gelesen zu haben und ja es soll so sein.

Wirklich? Ich wäre da jetzt mit dem weißen Kaninchen einer Meinung gewesen... Wenn ich die Konfig exportiere und in dieser wichtige Pakete wie HAProxy und Acme aktiv(!) sind - nicht nur konfiguriert, sondern wirklich aktiv laufend - dann hoffe ich doch, dass nach

* Neuinstallation
* Restore
* Bare Metal Restore
* Umzug

alles genau so vorhanden bleibt und ich nicht dann dran sitze und die Pakete alle wieder von Hand installieren muss?

Ich gestehe, dass ich das zuletzt auch nicht mehr getestet hatte, aber ich fände das schon sehr irritierend. Dann ist mein Restore ja nicht komplett, wenn nicht _alles_ genau so wieder läuft, wie ich es exportiert habe.

[white_rabbit]

JeGr: Sehe ich so wie du ... und ich fand es auch irritierend, dass ich nun nochmal extra nachsehen muss, ob auch wirklich alle Addons, die vorher drauf waren, auch jetzt noch drauf sind.

micneu: Das Argument, warum es so sein soll, leuchtet mir noch nicht ganz ein ...

[franco]

Die Drittkonfigurationen die gespeichert sind können nur mit Drittcode ausgewertet werden, d.h. ob dieser aktiv sein soll kann nur der Nutzer selbst bestimmen weil der Drittcode nicht da ist. Ab 20.7 warnt das System, dass die relevanten Plugins ggf. fehlen. Und auch in diesem Prozess sind Annahmen verankert, die nicht dem Wunsch des Nutzers entsprechen müssen.

Nachinstalliert wird nichts automatisch. Im Umkehrschluss wird sonst etwas installiert was nicht benötigt wird oder dazu führt, dass dann etwas ggf. nicht so funktioniert wie "gewünscht", weil man ja die Plugins "extra nicht" installiert hat.

Im Gespräch war erst kürzlich direkt beim Import dafür zu sorgen, dass die fehlenden Plugins auf Rückfrage installiert werden sollen. Das ist die erste praktikable Option, da man so umgehen kann nur anzunehmen was der Nutzer nun wollte, wenn er dies nicht explizit sagt. Daher ist das aktuelle Verhalten kein Bug aber auch kein Feature, sondern ein Zustand im Sinne der "Prinzip der geringsten Überraschung".


Grüsse
Franco

[JeGr]

OK bin etwas geplättet, weil ich das Feature bislang wohl durch pfSense einfach gewohnt war und bei OPNsense es noch nie wirklich zu einem Full-Restore kam bei Kunden, aber ich sehe im Github dazu:

https://github.com/opnsense/core/issues/1663

Ich denke bis das final implementiert ist, sollte man wenigstens in der Doku mal erwähnen, dass es _kein_ volles Restore gibt mit Plugins/Packages, sondern nur von dem was alles Standard OPNsense ist.

Edit: Ah Franco erst nach posten gelesen :)

> Daher ist das aktuelle Verhalten kein Bug aber auch kein Feature, sondern ein Zustand im Sinne der "Prinzip der geringsten Überraschung".

Da würde ich in freundlichem Diskurs aber sagen "I agree to disagree"! Für mich ist das ganz und gar nicht die geringste Überraschung, sondern wie bei white_rabbit sogar eine ziemlich große. Gerade im Firmenumfeld ist es nicht unüblich, dass Boxen kommissioniert oder vorkonfiguriert werden, teils auch mit Plugins wie Reverse Proxy für einen Exchange oder sonstwas. Da sind vor Ort dann kaum Leute vorhanden, die mit irgendwelchen Meldungen was anfangen können. Wenn dann ein Gerät ausfällt und ich bspw. auf USB Stick die Konfig habe und wiedereinspiele, dann gehe ich bei einem "Full Restore" der da gemacht wird doch davon aus, dass full auch "FULL" heißt und danach nicht ein Teil der Appliance nicht mehr läuft weil Pakete fehlen?

Ich kann sicherlich Pros und Cons verstehen, aber PdgÜ ist das für mich nicht, eher im Gegenteil. Und natürlich, wenn ich mich verkonfiguriere und will dann ein Backup einspielen das genau irgendwelche verkorksten Konfigs von FRR oder sowas nicht enthält, wäre der aktuelle Zustand schöner. Aber da gebe ich zu bedenken, ob das Szenario "verkorkste Konfiguration" -> Lösung durch Reset via UI/Konsole nicht besser / einfacher zu lösen ist (oder Schrittweisen Restore) als das "normale" Restore statt dessen "abzuschwächen" und Sachen wegzulassen?

Und wie ich im Github sowie Forum gesehen habe, ist das ja nicht erst seit gestern durchaus häufiger mal eine Frage gewesen. Etwas installieren was so nicht funktioniert geht ja eher in die Richtung Debugging und "kaputtgespielt". Reset und Neuanfang ist da doch einfacher - oder partieller Restore - als statt dessen ein Bare-Metal-Restore wegzulassen?

Ich wollte das nur Mal aus Kunden/Dienstleister Sicht zu Bedenken geben.
Aus unserem Kundenstamm kenne ich da nur Fälle, die definitiv Bare-Metal Restore wollen und fordern. Wenn sies selbst verbasteln - dafür gibts Konfig-History und Co. Oder alte Konfig von ein paar Tagen vorher :)

[franco]

Von Erwartungshaltung zu Bequemlichkeitsfeature ist es nicht weit. Über die Jahre ist meine persönliche Einstellung bei Entwicklung / Support kritisch gegenüber Anforderungen zu stehen, welche sich auf die Automatisierung von funktionierenden Vorgängen spezialisieren und 1-2 Mal im Jahr als Ticket aufschlagen.

Die Verantwortung für vollständige Setups können wir nicht übernehmen aus Software-Sicht und bringt uns auch in so einem Fall keine Pluspunkte, da die Erwartung ja schon da war.


Grüsse
Franco

[JeGr]

> Von Erwartungshaltung zu Bequemlichkeitsfeature ist es nicht weit.

Da bin ich prinzipiell dabei. Auch beim Support.

> welche sich auf die Automatisierung von funktionierenden Vorgängen spezialisieren und 1-2 Mal im Jahr als Ticket aufschlagen.

Aber ein Bare-Metal Restore ist doch IMHO kein ungewöhnliches Ding oder gar ein Bequemlichkeitsfeature! Gerade Backup und Sicherheit geht doch immer mehr dahin, dass es essentiell ist mit minimalem Eingriff auf genau den Stand zu kommen, den man kurz vor Crash/FallX hatte. Und ob das nun eine VM ist, ein Server, ein Clientrechner etc.: die erwartete Anforderung an eine Sicherung/Backup ist - gerade wenn ich das Ding "Full Backup" nenne - dass das System dann auch genau in dem Zustand wieder da ist, wie ich es gesichert habe. Wenn das dann nicht der Fall ist, finde ich schon, dass das keine "geringe Überraschung" ist :)

> Die Verantwortung für vollständige Setups können wir nicht übernehmen aus Software-Sicht und bringt uns auch in so einem Fall keine Pluspunkte, da die Erwartung ja schon da war.

Ich sehe da gar keine wahnsinnige Verantwortung als eher eine logische Konsequenz. Es wird ohnehin die Konfiguration der Plugins und Packages mitgesichert. Okay! Super! Warum werden dann nicht die Pakete die aktiv gelaufen sind in der Konfiguration - soweit ich das Ticket verstanden habe, wird das ja inzwischen erkannt? - nicht automatisch wieder hergestellt?

Ich glaube das ist eher ein Fall von "welcher Weg sollte der Standard sein", oder? Ich erinnere mich an unsere Diskussion bei der Umstellung des Outbound NAT Handling auf Round-Robin ;) Da war euer Ansatz auch - wer das nicht möchte soll es abschalten. Aber das war z.B. - wie ich auch hier finde - eben nicht der korrekte Fall, den der User erwartet, sondern genau andersherum. Ich richte mehrere VIPs ein. Warum sollte plötzlich die Outbound NAT über alle VIPs rotieren? Braucht sie doch gar nicht (bzw. wer will das auch?). Hier im Fall Backup & Restore: ich mache in der UI ein volles Backup und wähle dann auf dem neuen/Austausch/VM/wasauchimmer Device ein Restore aus mit ALL. ALL/Full impliziert für mich "komplett", volle Kanone. Ich hab extra deshalb auch nochmal in die Doku geschaut, auch dort ist sogar empfohlen ein "complete Restore" zu machen:

https://docs.opnsense.org/manual/backups.html
->
"Restoring backups can either be performed partially or for the complete configuration. Since configurations usually have various components that depend on each other, it's most safe to restore a complete configuration."

An keiner Stelle wäre für mich als User, Integrator oder Admin ersichtlich, dass ALL/FULL/Complete hier _NICHT_ alles zurücksichert und ich danach noch manuell irgendwas machen muss.

Ich hab im Github Ticket auch die geplante UI mit den Buttons gesehen für das Restore, sieht auf jeden Fall schick aus! Aber dann sollte entweder im Backup Screen und in der Doku explizit irgendwo darauf hingewiesen werden, dass 3rd Party Plugins, Tools, Packages etc. NIE mit installiert werden und da händisch was gemacht werden muss, oder der Standard Usecase sollte (aus meiner Sicht) der sein, den man von Full Restore erwarten würde: das System ist in dem Zustand vom xx.yy.zzzz an dem das Backup gemacht wurde. Und wenn ich davor ggf. was korruptes in meine Reverse Proxy Konfig reingebastelt habe, das dann ebenfalls wiederhergestellt wird, ist das völlig legitim, dann muss ich ein älteres Backup mitnehmen.

Aber wer defniniert dann, was ein "volles" Restore ist? Alles außer 3rd Party? Alles außer korrupter Konfiguration? Finde ich schwierig.

Hoffe trotzdem, dass die (gutgemeinte) Kritik auch so ankommt und nicht als Gemotze ;) Ich versuche hier nur vor Augen zu führen, was die Sicht von User, Kunden, Integratoren wäre wenn man den vorhandenen Status Quo zu Grunde legt und der offenbart mir an keiner Stelle (deshalb habe ich auch zu Beginn weiter oben sehr verdutzt erstmal suchen müssen), dass installierte Zusatzpakete nicht mit wiederhergestellt werden. Und sollte das so bleiben sollen - das ist ja in eurem Ermessen als Entwickler - müsste da IMHO zumindest in der Doku und ggf. auch der UI wirklich drauf hingewiesen werden. Damit jemand, dem das nicht klar ist - und ich vermute, das sind eher mehr als weniger - auch klar gewarnt sind "Hey, nach dem Restore und Reboot musst du noch in den Paketen 3-4x auf Installieren drücken (oder zukünftig ggf. einmal nen Button)" und nicht nach einem nächtlichen Notfallrestore am nächsten Tag plötzlich das Erwachen kommt "oha wir bekommen überhaupt keine Mails mehr, weil der Proxy nicht läuft!". :)

Und ja ich helfe auch gern das zu testen mit dem Restore und Co, sollte es daran mangeln! :)

Viele Grüße

[chemlud]

...ich mach größere Updates bei pfsense grundsätzlich mit Neuinstallation und Einspielen der config.xml. Das automatische installieren der Pakete (Snort, cron, mailreport) hat noch NIE funktioniert, in den ganzen letzten 6 Jahren nicht, sorry...

[JeGr]

...ich mach größere Updates bei pfsense grundsätzlich mit Neuinstallation und Einspielen der config.xml. Das automatische installieren der Pakete (Snort, cron, mailreport) hat noch NIE funktioniert, in den ganzen letzten 6 Jahren nicht, sorry...

Oh schade zu lesen. Bei unseren pf Kunden waren es bislang von sehr wenig einzelnen Fällen (bislang einmal nen FRR und einmal nen FreeRadius der nicht sauber wollte) in den allermeisten Fällen problemlos, aber natürlich hat da jeder seine anderen Erfahrungswerte. Und ja auch pfSense schreibt selbst in den Updates man kann es machen, aber man kanns auch deinstallieren vorher. Der Unterschied ist aber: auf einer Neuinstallation wird eine alte Konfig dann wiederhergestellt und alle Pakete werden dann installiert. Und das klappt bislang sowohl in unseren VM Testumgebungen als auch im Hardware Lab problemlos. Updates - klar - da kann es auch so oder so gehen. Aber PFI mit Neuinstallation? Problemlos bisher auch in großen Setups. Nur interessant, dass unsere OPNsense Kunden anscheinend alle bislang keine oder keine wichtigen Plugins installiert hatten (oder die Sense in VM Umgebung laufen lassen und da einfach nen Rollback machen). Daher ist mir das tatsächlich bis dato noch nie übern Weg gelaufen.

Ich hoffe ich habe mich aber auch halbwegs verständlich und freundlich ausgedrückt: ich fände es sinnvoll und wichtig, das zu haben, aber wenn es nicht _gewünscht_ ist, dann ist das auch eine Aussage. Nur dann fände ich es erst recht wichtig, das an den entsprechenden Stellen überall auch sauber kund zu tun, DAS es so ist, und das ist meines Erachtens momentan überhaupt nicht der Fall.