2.5.1: seltsamer UI Bug?

JeGr

Vielleicht hatte das schonmal jemand und ist ggf. dahinter gekommen? Ich habs auch mal offiziell angefragt, aber hier nochmal:

Ich habe 2 VMs, exakt identisch aufgesetzt mit gleichem ISO und teils side by side nebeneinander geklickt. Trotzdem hat eine VM in System/General jetzt das hier:

und die andere das hier:

Wie man sieht fehlt bei einer VM die GW Auswahl hinter den DNSen.

NANU?

Bob.Dig

Ich würde es nicht vermissen, denn wenn ein Gateway down ist, verzögerten sich die Antworten, wenn ich es recht in Erinnerung habe.
Vielleicht taucht es erst auf, wenn man mehr als ein Gateway hat?

JeGr

@bob-dig

a) Es ist nicht richtig, dass es auf einer VM auftaucht, auf der anderen nicht, wenn beide EXAKT GLEICH aufgesetzt wurden
b) ich habe MultiWAN und auch das ist auf beiden Kisten exakt identisch aufgesetzt. Gerade deshalb ist es ja merkwürdig.

:)

slu

@jegr
spannendes Problem.

Hast Du mal ein diff -u der beiden Konfigs gemacht, vielleicht kommt man dann auf die Spur.

JeGr

@slu Bevor ich mich wiederhole, hier mein en Posting: https://forum.netgate.com/topic/163869/2-5-1-new-vm-install-a-few-ui-glitches-and-bugs

Aber guter Hinweis mit dem XML. Ich hatte schonmal reingesehen, da fehlten beim Node1 die beiden Einträge <dns1gw> und <dns2gw>. Aber selbst mit manuellem reineditieren und config einspielen war trotzdem kein Ergebnis zu finden. Irgendwo muss noch was sein...

JeGr

@slu said in 2.5.1: seltsamer UI Bug?:

@jegr
spannendes Problem.

Hast Du mal ein diff -u der beiden Konfigs gemacht, vielleicht kommt man dann auf die Spur.

OK interessant. Ich habe es gefunden. Eine Kombination von @slu und @Bob-Dig: Beim zweiten WAN Interface war das Upstream Gateway beim Interface Setting zwar angelegt worden aber im Interface nicht ausgewählt, sondern wie bei einem LAN "nichts".

Witzig daran: ich habe sogar noch einen Screenshot bei dem ich sehe, dass bei beiden VMs beide WANs richtig konfiguriert und MIT Upstream Gateway gespeichert waren. Warum die eine VM das Setting wieder vergessen hat - ungeklärt. Aber nun sind (nachdem auch 2 Upstreams erkannt werden) auch die Settings im General Setup wieder da UND die beiden dns1gw/dns2gw Tags im XML verschwinden nicht mehr sondern bleiben (zumindest leer) im File.

Sehr skurril!

Da beide Nodes auch noch völlig andere XML Files schreiben (Reihenfolge der Tags, etc.) ist das Vergleichen gar nicht so einfach.

Das zweite geschilderte Problem im Thread (mit der falschen Anzeige des Default-v6 Gateways) ist aber immer noch da. Komisch.

NOCling

@jegr said in 2.5.1: seltsamer UI Bug?:

Da beide Nodes auch noch völlig andere XML Files schreiben (Reihenfolge der Tags, etc.) ist das Vergleichen gar nicht so einfach.

Das ist aber echt Kacke!

Da gehört eine klare Struktur rein, nur so kann man sauber in der xml eine config mit einer anderen vergleichen oder gleich daraus ein Template für die nächste zusammen setzen.
Wenn es aber gewürfelt wird, no way das mal eben sauber hin zu bekommen.

Das hat z.B. Cisco deutlich besser im Griff, da ist immer eine ganz klare Struktur drin und Vergleiche in Sekunden möglich.

slu

@nocling
die Frage ist ja schon warum es gewürfelt wird, das ergibt keinen Sinn.
Alleine schon dafür muss es ein Grund geben...

JeGr

@nocling @slu Naja das Problem ist da eher wohl die Software. Der XML Parser von PHP macht eben valides XML. Aber alles was da auf der gleichen Ebene ist, ist auch gleichberechtigt. Die Reihenfolge ist da also egal. Darum kanns eben sein, dass du bei der einen VM eine leicht andere Tag Reihenfolge hast als bei der zweiten. Darum ist mir das im ersten Diff auch nicht so leicht aufgefallen - erst als Slu es erwähnt hat hab ich nochmal reingesehen.

Gewürfelt ist da vielleicht der falsche Begriff, aber die Reihenfolge innerhalb der Schachtelung ist eben für die UI oder die Config egal, wichtig sind die Parameter. Da die XML Tags hier quasi Parametern oder Attributen gleichgesetzt sind ist die Reihenfolge egal.

Bspw. wäre das so als wenn ich die OpenSSL Speed berechne mit:

openssl speed -evp -elapsed aes-256-gcm    # openssl speed test

Würde ich das in Config-Style à la *sense abbilden, wäre das so ungefähr:

<openssl>
  <speed>
    <evp/>
    <elapsed/>
    <cipher>aes-256-gcm</cipher>
    <descr><![CDATA[openssl speed test]]></descr>
  </speed>
<openssl>

Da evp und elapsed Parameter sind und nur interessant, ob sie gesetzt sind (da sind) oder nicht, reicht da ein self-closed Tag. Cipher ist der benötigte um die Geschwindigkeit zu prüfen. Ohne gehts nicht. Und das Kommentar hintendran (nur als Beispiel, in der Praxis wäre das quatsch), ist ein CDATA Block im XML, damit da auch Umlaute und Kram ordentlich codiert werden. descr könnte aber auch komplett fehlen, dann gäbe es eben nichts. Und die ganzen Parameter könnten auch komplett in anderer Reihenfolge gespeichert werden, das wäre egal, denn wenn das Command zusammengesetzt wird, wird einfach nur geschaut "evp da? -> OK", "elapsed da? -> OK", "Cipher da? -> OK einfügen hintendran". Ob man nun zuerst das eine oder andere schreibt ist der Sprache (bzw. der BNF der Sprache für die theoretischen Informatiker) relativ wurscht ;)

Da *sense das so auswertet ist wie gesagt es eben egal, in welcher Reihenfolge die XML Tags und Blocks geschrieben sind, wichtig ist nur dass sie syntaktisch korrekt sind und ordentlich vom Parser ausgewertet werden. Der GUI Code (PHP) ist dann dafür zuständig, den Kram in der korrekten Ordnung auszugeben und zusammenzusetzen.

Tatsächlich wäre es schwieriger/schlechter hier noch zusätzlich Logik hineinzupacken und eine Reihenfolge zu erzwingen, denn dann müsste der Logikcode und ggf. auch der Parser jedes Mal prüfen dass alles korrekt und in richtiger Reihenfolge zusammengestellt und gebaut wurde und könnte nicht einfach dem XML Parser sagen "füge einen Rule-Block mit Parametern X, Y, Z neu hinzu und speichere ihn wie es das Schema vorsieht", sondern müsste exakte Reihenfolgen etc. sicherstellen, einhalten und auswerten.

@nocling

Das hat z.B. Cisco deutlich besser im Griff, da ist immer eine ganz klare Struktur drin und Vergleiche in Sekunden möglich.

Also zu Cisco sage ich da lieber nichts. Bei pfSense gibts zumindest seit Jahren nicht das Phänomen, dass ich nicht auf eine neue Version updaten kann, weil meine Config "zu alt" ist und die neue es nicht geschissen bekommt, die alte zu konvertieren. Das hat mir schon mehrere Cisco-genervte Kunden eingebracht

Cheers
\jegr (das Orakel)

NOCling

Boahh voll gemin, 9.1 auf 9.8 ja das hatten wir auch.
Hat ein Kollege rum gebastelt und das alles per Skript geparst und um geschrieben.

War übel.

Aber ja hast recht, Cisco ist auch nicht perfekt und haben genug dreckige Wäsche im Keller.
Aber auf die CLI lasse ich da nix kommen, die ist geil...

Und für das Programm mag der Ablauf egal sein, bin aber nen Mensch, da hätte ich schon gern Struktur, dann kann ich das leichter vergleichen.

JeGr

@nocling said in 2.5.1: seltsamer UI Bug?:

Und für das Programm mag der Ablauf egal sein, bin aber nen Mensch, da hätte ich schon gern Struktur, dann kann ich das leichter vergleichen.

Joa mag sein, aber du schreibst Software nicht primär dafür, dass ein Mensch sie hinterher lesen kann ;) sondern dass sie primär ihren Einsatzzweck erfüllt, schnell und flexibel ist. Wenn du anfängst irgendwelche Fußangeln einzubauen damit es "Mensch" lesen kann, dann läuft was falsch ;)

Man würde eher sinnvoll hingehen und einen XML Parser/Diff schreiben, der den Vergleich macht nach der gleichen Logik als dass man die Ausgabe in eine spezifische Form gießt :)

Siehe: https://pypi.org/project/xmldiff/ :)

NOCling

Software nicht, aber eine Konfigurationsdatei, die ein Mensch lesen, verstehen und nach eigenen Wünschen einfach anpassen kann, hat gewisse Vorteile.