Bewertung der pfsense Aktivitäten

[ristridin]

MVC hat Franco ja bereits erwähnt, insofern gute Aussichten an der gui Front denke ich :)

Ansonsten:
m0n0wall und pfsense haben sich untereinander wenig befruchtet, genau deswegen ist opnsense innerhalb so kurzer Zeit so erfolgreich. Und dies m.E. nach vollkommen zu Recht!
Ein open source Projekt mit einer engen kommerziellen Bindung in Sachen Support Optionen und Hardware durch Deciso gepaart mit einer modernen gui und einem insgesamt guten branding, abgerundet durch ein extrem ambitioniertes und richtig eingestelltes Team von Entwicklern! Freut mich ungemein.

[chol]

Wie in der erwähnten pfSense roadmap addressiert und im BSDnow Interview angedeutet, ist denn nicht PHP (2nd generation web framework) an sich die mögliche Schawchstelle!

Es geht doch wohl eher-grundsätzlich-um das MVC-wie-umgesetzt und um Sicherheitsarchitektur,  denn um GUI-design - oder irre ich? Die pfSense Beiträge hierzu sind einschlägig und eben neu durch die roadmap bestätigt.

[ristridin]

natürlich ist im Kern dieses Produktes die Sicherheitsarchitektur das A und O.
Allerdings bin ich aufgrund der bisherigen OPNsense Roadmap und einem langen Gespräch mit franco davon überzeugt, dass das Thema Sicherheit und Architektur allgemein hier in den besten Händen liegt, so dass wir unbeschwert ein großes Augenmerk auf die usability legen können   ;D

[franco]

Hallo chol,

Ich sehe es aber durchaus als Reaktion auf das OPNsense Project. Und das ist gut so.

Das sehen wir auch so. Wir sind diese Woche alle am gleichen Tisch hier im schönen Holland und haben den letzten Monat besprochen und für den nächsten geplant. Unser Fazit ist: wir haben viel bewegt, uns definiert und werden damit (u.a. mit dem heutigen 15.1.8 ) auch weiter fahren unbeirrt im Kurs. :)

#2 was hat es mit der Ubuntu Namensmimikri auf sich?

Die Namen gibt es noch immer, aber diese sind lange nicht so präsent wie wir gedacht haben. Ob sie bleiben oder nicht werden wir sehen. Zufrieden sind wir allerdings mit der numerischen Versionierung, auch wenn wir hier noch experimentieren und machmal die Versionen zu lang werden. ;)

Ob sich das alles noch ändert bleibt offen. Wir haben jedenfalls keine Angst davor etabliertes einzureißen, gerade um Dinge einfacher oder deutlicher für unsere Nutzer zu gestalten.

#3 FreeBSD 10.0 Problem: Unterstützung bis 02/2015

Das war ein guter Sprint. Ich sag jetzt einfach mal dreist, dass wir das selbe auch ganz schnell mit 10.2 machen können, damit man dann auch sieht, dass das kein "PR Stunt" oder Hinterherlaufen ist. Leider ist 10.2 erst im Herbst verfügbar soweit ich hörte? Schauen wir mal...

#1 gibt es Planungen, OPNsense von Phalcom/PHP wegzuführen?

zu #1 ist zu sagen, dass dies gerade von pfSense angestrebt wird. Wird sich zeigen ob Franco, Ad und Jos , neben dem OPNsense Python backend auch auf ein sichereres MVC webframework der 3. Generation wie etwa das 3.0 Python basierte Django (http://en.wikipedia.org/wiki/Django_%28web_framework%29) umsteigen werden?

Moment, Phalcon ist neu und genau wie Django 3.Generation um bei der Terminologie zu bleiben. Es ist unserer Meinung nach unmöglich den PHP Code komplett einzureißen und ein neues Framework mit neuer Sprache zu bauen. Das kostet Jahre. Jahre die nicht überbrückt werden können mit Zwischenlösungen. Was also mit anderen Projekten passieren könnte ist, dass eine "richtige" Version parallel ewig entwickelt wird aber niemals korrekt getestet wird, weil den Nutzern zu viele Features fehlen und dann "nebenbei" eine Legacy-Version gepflegt wird die weiterhin von allen genutzt wird. Man sieht deutlich, dass es auf 2 parallele Projekte hinausläuft. Wenn man dann noch annimmt, dass die Legacy-Version sehr viel Pflege und Modernisierung braucht könnte man zu dem Schluss kommen, dass das nur bedingt machbar ist auf die Jahre gesehen.

Unser zweigleisiger Plan sieht so aus:

* PHP bleibt, aber der alte statische Code wird Schritt für Schritt ins MVC migriert. Das Config-System ist schon umgeschrieben und vereint und erscheint heute mit 15.1.8. Das heißt die Basis für alte und neuen Code ist nun gegeben. Was als nächstes passiert ist eine Portierung des statischen Codes in eine modularisierte Variante. Das bringt weniger Code der gleichzeitig besser strukturiert ist und daher wird es einfacher für andere mitzuarbeiten. Das hat noch nichts mit Sicherheit zu tun, sondern ist eine vernünftige Grundlage. Ganz nebenbei ist PHP/Phalcon sehr schnell und im Vergleich mit z.b. Python/Django ähnlich schnell und umfassend: http://vschart.com/compare/django/vs/phalconphp

* Python ersetzt den alten check_reload_status Daemon, der für Hintergrundaktivität genutzt wurde. Daraus wurde kürzlich "configd", der nun weiter ausgebaut wird um mehr Systemkonfiguration zu übernehmen. Das führt Schritt für Schritt zu einer Situation in der das "schwache" PHP weniger privilegierten Code für die Systemkonfiguration ausführen muss. Der Frontend-PHP-Code bleibt aber erhalten. Wenn dies ausreichend vorangeschritten ist können wir PHP die Root-Rechte entziehen, weil es diese dann nicht mehr braucht. Sicherheitsproblem gelöst! Na, ja, zumindest eins davon. ;)

Diese Schritte ermöglichen es uns jede Woche Releases herauszubringen, die etwas besser sind als die Woche zuvor und gegen Ende des Jahres haben wir dann den Löwenanteil erreicht, vielleicht sogar eine REST API und weitere Security-relevante Dinge wie LibreSSL oder aber ein neues modularisiertes Package-System als Nebenprodukte eingearbeitet.

Andere OPNsense pace-marks:

pkg(ng)
opnsense-update
LibreSSL

.. thank you and go on guys!  :)

Auf die bin ich besonders stolz. :) Vielen Dank auch im Namen von Jos, Ad und Robert.

@ristridin  Danke! :D

[Σουπεργιούζερ]

Hi Franco!

#2 was hat es mit der Ubuntu Namensmimikri auf sich?

Die Namen gibt es noch immer, aber diese sind lange nicht so präsent wie wir gedacht haben. Ob sie bleiben oder nicht werden wir sehen. Zufrieden sind wir allerdings mit der numerischen Versionierung, auch wenn wir hier noch experimentieren und machmal die Versionen zu lang werden. ;)

Ob sich das alles noch ändert bleibt offen. Wir haben jedenfalls keine Angst davor etabliertes einzureißen, gerade um Dinge einfacher oder deutlicher für unsere Nutzer zu gestalten.

Also meiner Meinung nach sind solche prosaischen Namensgebungen, wie sie leider auch z. B. Debian oder Opensuse verwenden, nachteilig und behindern mich nicht unerheblich in meiner täglichen Arbeit.

Ich benutze eine Vielzahl von Freier (oder zumindest Open Source)-Software und bin nicht automatisch in jedem dieser Projekte täglich intensiv involviert. So kommt es immer wieder vor, dass ich zu etwas recherchieren muss, aber die "locals" eines Projektes, also die stark Involvierten Projektmitglieder, sich in den Foren, Mailinglisten, etc. immer nur auf diese albernen Namen beziehen, anstatt auf die Selbsterklärenden und eindeutigen Versionsnummern.

So kommt es dann immer wieder vor, dass ich erst mal nachsehen muss ob ich jetzt eigentlich Clounesque Coyote oder doch schon Silly Snake verwende, oder mir bei Wikipedia die (hoffentlich vorhandene) Versionshistorie vorholen muss, um zu sehen ob Feature X in meinem Painintheass Penguin schon vorhanden ist, weil ich nicht auswendig weiß, wann es released wurde, und ob es jetzt vor oder doch nach Bullshit Buffalo released worden ist, weil ich die Reihenfolge dieser sinnlosen Namen nicht für jedes dieser Projekte auswendig aufsagen kann, etc. :-)

Deshalb plädiere ich dafür, ausschließlich aufsteigende Nummerierungen zu verwenden und nicht durch zweigleisige Bezeichnungspfade Verwirrung zu schaffen, zumal die zusätzliche prosaische Benennung einer Version keinerlei Mehrwert schafft. Wenn dann die Nummerierung auch noch zusätzlich Informationen beinhaltet, wie z. B. Jahr und Monat des Releases (also genau so, wie ihr es macht mit 16.1 für Januar 2016, etc.) dann finde ich es perfekt!

Sogar M$ hat irgendwann eingesehen, dass SE, ME, NT, XP und Vista als Versionsbezeichnungen ihre Kunden eher verwirren und knüpft seit 7 wieder an seine seit 3.11 schmerzlich vermisste Numerierung an, wobei ich die zwischenzeitliche Jahreszahlennummerierung von 95, 98 und 2000 aus oben erwähnten Zusatzinformationsgehalt-Nutzen besser fand.

Moment, Phalcon ist neu und genau wie Django 3.Generation um bei der Terminologie zu bleiben. Es ist unserer Meinung nach unmöglich den PHP Code komplett einzureißen und ein neues Framework mit neuer Sprache zu bauen. Das kostet Jahre. Jahre die nicht überbrückt werden können mit Zwischenlösungen. Was also mit anderen Projekten passieren könnte ist, dass eine "richtige" Version parallel ewig entwickelt wird aber niemals korrekt getestet wird, weil den Nutzern zu viele Features fehlen und dann "nebenbei" eine Legacy-Version gepflegt wird die weiterhin von allen genutzt wird. Man sieht deutlich, dass es auf 2 parallele Projekte hinausläuft. Wenn man dann noch annimmt, dass die Legacy-Version sehr viel Pflege und Modernisierung braucht könnte man zu dem Schluss kommen, dass das nur bedingt machbar ist auf die Jahre gesehen.

Wer von Euch den Projektverlauf des CMS "TYPO3" kennt, kann bestätigen, dass Du mit Deiner Einschätzung goldrichtig liegst! TYPO3 wollte sich komplett neu erfinden und ein neues Framework schaffen ("Flow") auf dem dann eine komplett neue Version ("Neos") laufen sollte. Ganze 6 Jahre (!) liefen drei Projekte gleichzeitig, das Legacy-Projekt "TYPO3 CMS" sowie die Zukunfts-Projekte zu Flow und, darauf aufbauend, Neos.

Ende der Geschichte: Flow und Neos wurden abgespalten und sind nunmehr nur noch experimentelle Projekte einer kleinen, unabhängigen und eigenständigen Gruppe, und TYPO3 CMS ist nicht mehr "legacy" sondern wieder das Hauptprodukt des TYPO3-Projekts. Der Großteil der Community ist bei TYPO3 geblieben, da keiner im Produktionbetrieb ein erprobtes, full featured und stabiles Sytem gegen ein experimentelles, funktionseingeschränktes System ersetzen konnte und wollte...
Allerdings hinkt TYPO3 durch die jahrelang eher halbherzige weiterentwicklung als "legacy version" jetzt entwicklungstechnisch anderen CMS fast ein Jahrzehnt hinterher, so dass im Grunde jetzt alles den Bach runtergegangen ist, TYPO3, Flow und Neos.

Unser zweigleisiger Plan sieht so aus:

* PHP bleibt, aber der alte statische Code wird Schritt für Schritt ins MVC migriert. Das Config-System ist schon umgeschrieben und vereint und erscheint heute mit 15.1.8. Das heißt die Basis für alte und neuen Code ist nun gegeben. Was als nächstes passiert ist eine Portierung des statischen Codes in eine modularisierte Variante. Das bringt weniger Code der gleichzeitig besser strukturiert ist und daher wird es einfacher für andere mitzuarbeiten. Das hat noch nichts mit Sicherheit zu tun, sondern ist eine vernünftige Grundlage. Ganz nebenbei ist PHP/Phalcon sehr schnell und im Vergleich mit z.b. Python/Django ähnlich schnell und umfassend: http://vschart.com/compare/django/vs/phalconphp

* Python ersetzt den alten check_reload_status Daemon, der für Hintergrundaktivität genutzt wurde. Daraus wurde kürzlich "configd", der nun weiter ausgebaut wird um mehr Systemkonfiguration zu übernehmen. Das führt Schritt für Schritt zu einer Situation in der das "schwache" PHP weniger privilegierten Code für die Systemkonfiguration ausführen muss. Der Frontend-PHP-Code bleibt aber erhalten. Wenn dies ausreichend vorangeschritten ist können wir PHP die Root-Rechte entziehen, weil es diese dann nicht mehr braucht. Sicherheitsproblem gelöst! Na, ja, zumindest eins davon. ;)

Diese Schritte ermöglichen es uns jede Woche Releases herauszubringen, die etwas besser sind als die Woche zuvor und gegen Ende des Jahres haben wir dann den Löwenanteil erreicht, vielleicht sogar eine REST API und weitere Security-relevante Dinge wie LibreSSL oder aber ein neues modularisiertes Package-System als Nebenprodukte eingearbeitet.

Das klingt vernünftig! Revolution klingt zwar immer sexyer, als Evolution, aber wie oben am Beispel TYPO3 gezeigt, krepieren solche Revolutionsansätze meist und führen nur zu Frust und Problemen.

Viel Erfolg
Σουπεργιούζερ

[franco]

Hallo Σουπεργιούζερ,

Also meiner Meinung nach sind solche prosaischen Namensgebungen, wie sie leider auch z. B. Debian oder Opensuse verwenden, nachteilig und behindern mich nicht unerheblich in meiner täglichen Arbeit.

Wir sehen es mehr als Spaß an der Freude. Ich glaube "Crafty Coyote" taucht fast nirgendwo auf außer in Texten und dem Bootlogo. In der GUI direkt ist es z.B. nicht zu finden (nur in der Package-Install-Message.. wie gesagt, der Spaß eben). Sonst immer nur "16 - 1", "16 - 7", "17 - 1", ...

Das klingt vernünftig! Revolution klingt zwar immer sexyer, als Evolution, aber wie oben am Beispel TYPO3 gezeigt, krepieren solche Revolutionsansätze meist und führen nur zu Frust und Problemen.

Das ist so. Eindeutiges Vorbild sind hier die alteingesessenen BSDs, als auch der Linux Kernel selbst. Aufpassen sollte man dennoch mit Altlasten. Selbst eigenen Code muss man immer kritisch beäugen und auswechseln.

Wenn ich die alte Liste so sehe ein kleines Fazit:

* Plugin-System: erledigt
* LibreSSL: erledigt
* MVC/API: für neue Komponenten komplett (z.B. Proxy+IPS), für alte Features nur vereinzelt umgesetzt (z.B. Firmware+Traffic Shaper)
* Privilege-Separation: etwas besser als GUI Umstellung, aber auch noch nicht so weit wie wir erhofft haben
* Hardening: neuer Fokus
* Modularisierung: neuer Fokus

Viel Code, viel Refactoring. Mit 16.1.8 sind wir zumindest durch die alten Features durch und haben diese unter der Haube aufgeräumt, aber eben noch nicht die MVC/API Migration vervollständigt. Das Team umfasst derzeit 2 aktive Programmierer und ein duzend Mitwirkende, die aushelfen wie Zeit ist. Dafür sind wir zumindest weiter als wir uns erhofft hätten. ;)

Der nächste große Schritt wird die Modularisierung der Schnittstellen und Regelgenerierung, damit neue Features ohne zentrale Stelle eingeführt werden können. Der Fokus verschiebt sich mit seinen Lerngelegenheiten. Und der Spaß ist immer dabei.


Danke und Gruß,
Franco