2.5.2 entwickelt sich IMHO sehr gut

noplan

@bob-dig said in 2.5.2 entwickelt sich IMHO sehr gut:

Netgate hat aber auch nichts anderes versprochen

ich kann mich nicht erinnern das die überhaupt was versprochen haben
wichtig ist das die 2.5.2 stable raus kommt, dann verschwinden nach und nach die 2.4er
und dann irgendwann aber wirklich erst irgendwann wird es spannend für die CE
da rinnt aber noch extrem viel wasser den bach runter ;)

Bob.Dig

@noplan said in 2.5.2 entwickelt sich IMHO sehr gut:

den bach runter ;)

die Donau

JeGr

@bob-dig Sorry ich fang die nutzlose "CE wird sterben" Diskussion jetzt nicht in dem Thread nochmal an. Ich finde das sinnlos an einem Beta/RC Build rumzudiskutieren, weil ein Bug nicht im anderen Build auch drin ist. Keiner kennt die Interna warum weshalb wieso aber dafür alle gleich "der Himmel stürzt ein, wir werden alle sterben, die CE stirb". Jetzt chillt doch mal die Nuggets und lasst sie den verseuchten 2.5 Launch erstmal ausbügeln. An jedem kleinen Pups sich aufzuhängen bringt keinen weiter. Wie @noplan schon schreibt: wir brauchen jetzt erstmal ne stabile 2.5.x (also die 2.5.2) damit wir auf der neuen Basis überhaupt ne ordentliche Plattform haben. Vorher von irgendwas zu schwadronieren ist kompletter Nonsens. Logisch gleicht die CE der Plus nicht mehr. Wenn ich 3 ARM Plattformen (2 sehr ähnlich weil gleicher SOC) und dann noch 3(!) andere x64 Kisten habe (weil 5,6 und 7 der gleiche Käse sind sind nur noch die beiden XGs "anders") kann ich meinen Kernel, mein Build etc. natürlich ganz anders optimieren als nen whitelabel box build für alle x86-64 und NICs auf der Welt. Dass DAS dann nicht mehr gleich ist mit CE ist logisch und völlig klar. Und dass da Unterschiede drin sind, hat man auch schon gesehen (Vorbereitung für den Whitelabel 2.6 stand, Intel QAT Unterstützung für die Atoms etc. etc.)

Meine Güte.

JeGr

@slu said in 2.5.2 entwickelt sich IMHO sehr gut:

[1] https://redmine.pfsense.org/issues/12069

Im entsprechenden Thread wo er reportet wurde, schreiben die Reporter schon, dass es im jüngsten Build nicht mehr vorkommt, also scheint sichs wohl schon erledigt oder zumindest getrackt zu haben. Rekonstruiert werden konnte es zumindest. So wie es sich liest könnte es auch RAM abhängig oder auch activity based sein - Verweis auf ZFS gabs ja auch. "find /" when on zfs klingt danach. Und da Netgate/Plus Büchsen bspw. noch nicht auf ZFS laufen auch ein Punkt wo sich Systeme unterschiedlich verhalten.

Vielleicht wird auch jetzt klar, was Netgate meinte mit "Plus Kisten sind eine begrenztere HW Auswahl und deshalb besser/schneller testbar". Siehe voriger Post.

slu

@jegr
ja das sind schon Punkte die man nachvollziehen kann.
Ich freue mich auf das 2.5.2 Release :)

fireodo

@slu said in 2.5.2 entwickelt sich IMHO sehr gut:

Ich freue mich auf das 2.5.2 Release :)

... ich auch, bin gespannt wann es soweit ist!

Schönes WoE,
fireodo

p54

@slu ja ich auch. Kann es kaum erwarten, aber da ich jetzt Urlaub habe brennt es mich gerade nicht so sehr unter den Fingern.
@fireodo Der Status seit dieser Woche verändert sich nur geringfügig im redmine. Aber wenigstens kommen nun keine weiteren mehr dazu. Könnte bald soweit sein. Aber was bedeutet der Status: Feedback jetzt genau wenn dieser im request darauf gesetzt wird?

fireodo

@p54 said in 2.5.2 entwickelt sich IMHO sehr gut:

Aber was bedeutet der Status: Feedback jetzt genau wenn dieser im request darauf gesetzt wird?

Man wartet ab ob die Änderungen tatsächlich so wirken wie beabsichtigt und wartet auf Rückmeldungen von den Usern bevor man die Änderung auf gelöst/geschlossen setzt. (Oder hab ich deine Frage falsch verstanden?)

Schöne WoE,
firodo

p54

@fireodo ne alles richtig verstanden. Danke jetzt weiß ich was es mit dem "feedback" auf sich hat. Wünsche ebenso ein ruhiges weekend.

fireodo

@p54 said in 2.5.2 entwickelt sich IMHO sehr gut:

Wünsche ebenso ein ruhiges weekend.

Danke!

JeGr

@p54 kommt aber hart drauf an, wie man das eben im Devel-Team organisiert hat und was damit gemeint ist. Wir nutzen selbst auch Redmine intern und der Feedback Status ist bei uns intern im Team. Sprich der Status symbolisiert, dass der Ticket-Eigentümer noch mit/von irgendwem Feedback einholt oder nachfragen muss und es deshalb nicht weiter geht. Also quasi ein Blocker. Da ich keinen Einblick habe, wie Netgate das nutzt kann @fireodo natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

fireodo

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

Ich bezog mich hauptsächlich auf diese von Jim (Pingle) getätigte Aussage auf redmine:
"Will hold open for now to wait for additional feedback, but can be closed if none is received before release." (11805)
als Antwort auf mehrere User Posts.

Schönes WoE,
fireodo

JeGr

@fireodo Ja klar, war auch keine direkte Kritik an dir. Man weiß nur nicht ob das generell so gehandhabt wird oder in dem Fall nur. Trotzdem gut erkannt :)

Was sich jetzt bei der 2.5.2RC im letzten Snapshot m.E. auch verbessert hat ist das OVPN reconnection handling. Ich hatte dazu schon nen Bugpost aufgemacht, da bei gesetzten "explicit exit notifiy" auf 1 oder 2 gerade Tunnel einem schön um die Ohren geflogen sind. Sprich: statt exit notify hat die entsprechende Seite den Tunnel beendet statt nur mitzubekommen, dass die Gegenstelle sich abgemeldet hat. Bei S2S Tunneln hatte das die Auswirkung, dass - sollte es gesetzt gewesen sein - sich bei einem Restart der Seite A die Seite B einfach den Service beendet hat. Seite A konnte nach Restart dann nicht mehr verbinden.

Gleiches Spiel gabs bei RAS Clients auch, dann war der ganze Server weg. Das habe ich zumindest in letzter Instanz jetzt bei RAS Clients (Tunnel noch keine Zeit) nicht mehr, statt dessen wird jetzt - extrem sauber und schnell! - erkannt, dass der Client sich disconnected hat und der Client steht nicht mehr elend lang in der Connection list bis er timeouted (wenn in der Client Conf explicit-exit-notify drin ist natürlich). Umgekehrt ist es beim Server dann so, dass Clients sofort(!) auf Stufe gelb wechseln und nach 5s die Verbindung neu aufbauen, wenn vom Server ein "Restarte" kommt. Sehr gut, weil man damit die Downtime bei Änderungen an der Config minimieren kann - nach 10s sind die Clients wieder da. (5s timeout, 5s beim User/Passwort Dialog)

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

p54

@jegr Ah sehr guter Hinweis mit dem timeout, danke. cya

JeGr

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

Mein erster Test zwischen 2.5.2RC und 2.6 war bei Tunnelsetup auf den ersten Blick wieder genau das beschriebene Problem. Hat man einen Tunnel und auf beiden Enden Retry Once ausgewählt wird bei Restart einer Seite der Tunnel auf der anderen Seite beendet (entsprechender Prozess stirbt).

Irgendwie kann ich nicht glauben, dass das Absicht sein soll.