OPNsense Forum
International Forums => German - Deutsch => Topic started by: cibomato on February 26, 2015, 06:18:34 pm
-
Hallo zusammen,
wie bewertet Ihr diese Ankündigungen von pfsense:
https://blog.pfsense.org/?p=1588 (https://blog.pfsense.org/?p=1588)
Ist das (nur) blinder Aktionismus als Reaktion auf den opnsense-Fork?
Stehen auf opnsense-Seite ähnliche Dinge auf der Roadmap? Könnt Ihr da von evtl. Weiterentwicklungen auf pfsense-Seite profitieren?
Danke und Gruß,
cibomato
-
Wir freuen uns darauf. :)
Es zeigt doch, dass wir in einigen Dingen den Nerv des Fortschritts getroffen haben so wie Manuel es auch schon gesagt hat. Profitieren werden wir von diesen Änderungen kaum, da weder die pfSense Lizenz das Kopieren "einfach" macht, sowie FreeBSD Patches und Buildinfrastruktur hinter verschlossenen Türen gehandhabt werden.
Wir freuen uns für die Nutzer die weiterhin gern bei pfSense bleiben, weil sie nun eine echte Perspektive aufgezeigt bekommen. Und wir machen weiter: 2 Monate vorbei, viel geschafft, aber noch viel, viel mehr vor uns.
Ähnliche Dinge? Wir haben nativen pkgng Support, Meta-Packages und opnsense-update eingeführt und schon seit unserem Start eine Bootstrap GUI und PHP 5.6. Wir schreiben die GUI neu in MVC, arbeiten an einem Python-Backend-Service inklusive API und haben *immer* die neusten FreeBSD Pakete in unseren Releases, die übrigens alle 1-2 Wochen kommen. Das macht mit dem morgigen 8 Releases in nur 2 Monaten.
Nur bei DPDK müssen wir passen. Das ist sehr, sehr viel Arbeit die da versprochen wird.
Unsere Roadmap findest du hier: https://opnsense.org/about/road-map/
Grüße Franco
-
Finde ich toll. Die Konkurrenz belebt hier anscheinend den Markt, zumindest habe ich bisher noch nie eine solch detallierte Roadmap zu pfSense gefunden. ;)
Interessant sind die vielen Gemeinsamkeiten. Viele der Dinge auf der neuen Roadmap hatte ich in der Form so schon auf der OPNsense Roadmap bzw. vorher hier im Forum als Ankündigungen für OPNsense gefunden.
Wo wir gerade bei der Roadmap sind, toll wäre, wenn OPNsense vorm Upgrade jeweils ein Backup der bestehenden Installation erlauben würde, das ist ein Feature von pfSense, was einem beim Upgrade immer ein wohliges Gefühl in der Magengegend beschert.
Und ganz hervorragend wäre eine Beta vom OpenVPN Client Exporter, dann könnte ich OPNsense auch mal bei mir in "Produktion" nehmen.
Und vielleicht sollte dies Topic in den passenden Bereich verschoben werden?
-
Verschoben. :)
Der OpenVPN Client-Exporter wurde schon oft genug genannt um ihn als wichtiges Feature zu betrachten und wir hoffen dies bis spätestens 15.7 hinzufügen zu können, aber können hier keine definitive Aussage machen. Derzeit Arbeiten wir am neuen MVC, welches später als Grundlage für Packages genutzt werden soll. Jegliche Hilfe und Vorarbeit für den Exporter ist sehr willkommen.
Bei den Backups bin ich mir nicht so sicher. Die Configs sind das Herzstück der Software und dafür braucht man kein Plattenimage. Eine kaputte Installation lässt sich mit unserem Config Importer + Quick/Easy Install leicht bereinigen. Einzig und allein manuelle Modifikationen am System wären für ein Backup interessant, aber hier ist die Frage ob wir wirklich absichern wollen (oder auch: können), was nicht in unseren Händen liegt?
Grüße Franco
-
Naja, die Backupfunktion hat den Vorteil, dass man i.d.R. einfach schneller wieder ein laufendes System hat. Dies ist auch in dem Fall interessant, wenn man vor Ort kein Fachpersonal sitzen hat. Da geht es halt bedeutend einfacher, einen einzigen Befehl ausführen zu lassen, statt jemanden durch eine Neuinstallation zu führen.
Klar, das sind alles Sachen, die man auch durch vernünftige Redundanzen und gute Planung lösen kann. Aber falls es keine Redundanzen gibt - kommt leider oft genug vor - dann würde ein eventuelles Problem mit einem defekten Upgrade immer mit einer längeren Downtime einhergehen.
-
Wir arbeiten daran ein System wieder in einen Grundzustand zu versetzen. Sofern die Config nicht das System lahm legt, lässt sich so das System bereinigen. Ich mag das In-Place Backup nicht, weil es Modifikationen aufnimmt, die in erster Linie nicht im System sein sollten, es sei denn man kann sie administrieren (und das schließt ein eigenes Backup mit ein).
Ist das eine Option ein Factory-Reset anzubieten, dass nicht nur Config sondern auch das System zurücksetzen kann mit einem einzigen Befehl?
-
Bin für die Variante eines " Factory-Reset anzubieten, dass nicht nur Config sondern auch das System zurücksetzen kann mit einem einzigen Befehl"
Jakob
-
Ist das eine Option ein Factory-Reset anzubieten, dass nicht nur Config sondern auch das System zurücksetzen kann mit einem einzigen Befehl?
Eine super Option wäre, wenn dabei das System in einen funktionierenden Zustand (vor dem letzten Patch oder vor allen Patches) zurückgesetzt würde und man die Möglichkeit hätte, die aktuell laufende Config weiter einzusetzen.
Sowas deckt halt Fälle ab, wie wenn z.B. der IPSec Tunnel vor dem Update noch prima lief, nach dem Update aber (z.B. wegen eines Strongswan Patches) einfach nicht mehr hochkommen will. So könnte man dann einfach den "Zurück Knopf" drücken lassen, rebooten und danach in Ruhe recherchieren, woran es wohl lag.
Was mir bei pfSense nie so recht gefallen hat (weiss aber nicht, ob das mal gefixt wurde), wenn man ein Backup wieder eingespielt hat, gab es keine Rückmeldung wann man Rebooten soll. Man musste halt mit top nachsehen, ob tar/gzip noch lief. Die NanoBSD Slices hingegen sind natürlich unschlagbar, da hat man das System ja einfach doppelt auf der CF Karte ;)
Die Teuren haben sowas ja auch an Bord, bei ner ASA kann man i.d.R. einfach mit dem vorherigen Image wieder booten, ggf. muss man noch ein paar Befehle wieder anpassen. Checkpoint GAiA bietet LVM Snapshots an, auf die man in der GUI oder im Bootloader wieder zurück kann.
Alles in allem hat eine solche Funktion schon eine gewisse Daseinsberechtigung, finde ich ;)
-
Jau, die nano-slices werde ich bei Vollinstallation schwer vermissen...
Aber da meine Boxen 32-bit sind, werde ich die ja auf pfSense lassen müssen. So schnell gibt's nicht wieder Hardware und die würde auch nicht mehr Performance bringen, bei meinen Anwendungen.
-
Hmm, also zumindest bei den LibreSSL Builds gibts auch i386:
https://pkg.opnsense.org/snapshots/
-
Uiii, gar nicht gemerkt, ich hatte nur 64bit im Kopf ;-)
Aber ich müsste mich erstmal mit einer Vollinstallation auf den nano-Böxchen beschäftigen, Vollinstallationen hab ich bisher nur auf Workstations gemacht :-)
EDIT: äääh, sehe gerade, da ist ja ein serial .img, das sollte dann direkt auf die CF-Karte gehen, oder---
Irgendwelche Hinweise zu Problemen mit OpenVPN (site-to site tunnels zu pfsense) bei den LibreSSL builts?
Bedankt vorab!
:-D
-
Bisher hab ich nur IPSec (IKEv2) getestet, das funktioniert gegen eine Cisco ASA, aber hilft Dir nicht :)
Ich sehe gerade, normale i386 gibt's jetzt auch. Ich würde aber trotzdem mal LibreSSL testen, da soll die Reise ja hingehen, je mehr es probieren, desto besser...
Die Normalen findest Du hier:
http://sourceforge.net/projects/opnsense/files/15.1.7/
-
IPsec... könnte ich auch wieder zurückgehen... wenn ich die ganze Konfiguration sowieso neu aufsetzen muss ;-) (waren bei pfsense zeitweise nicht so stabil, besser mit openvpn)
Sorry for thread-hijacking, aber eine Frage noch: Ich sehe gerade, das .img hat "nur" ca. 0.5 GB nach entpacken, muss ich nachher irgendwie das Filesystem auf die volle Größe der CF-Karte erweitern? Bin nur pfSense gewohnt, .img drauf und fertig und halt leider kein Fachmann...
Nochmals bedankt! :-)
PS: Um auch mal etwas OT gesagt zu haben: Meine Meinung zu pfSense hatte ich ja dort im Forum (selber Name ;-) ) ziemlich direkt gesagt. Daraufhin mag keiner mehr mit mir im Sandkasten spielen, dort ...
-
Eine super Option wäre, wenn dabei das System in einen funktionierenden Zustand (vor dem letzten Patch oder vor allen Patches) zurückgesetzt würde und man die Möglichkeit hätte, die aktuell laufende Config weiter einzusetzen.
Da haben wir die allseits gefragte Variante mit "alles". :)
Mit boot environments auf ZFS geht das. Mit nano boot slices auch. Mit einer einzigen Partition leider nicht. Warum? Weil man sich auch alle Dateien merken müsste die neu waren. Du kannst zwar mit einem "backup" alles zurückspielen, aber gerade Downgrades machen hier enorme Probleme weil neuere Libraries dem alten Backup ja nie bekannt waren. Die bleiben dann im System und der Linker will dann diese Nutzen und dann ist das Verhalten der Box eher undefiniert. Erschwerend hier sind auch die schon angesprochenen Nutzer-Additionen, die sich nicht zurückrollen lassen, außer mit den eingangs genannten beiden Möglichkeiten. Und wenn diese Nutzer-Additionen das Ursprungsproblem sind geht auch nach dem Rollback nichts. Ich würde einfach gern vermeiden eine falsche Sicherheit vorzutäuschen.
i386 Images haben wir seit 15.1.1, also schon länger. So weit sind damit alle glücklich? :)
Auch mit LibreSSL sind wir bis jetzt sehr zufrieden was Stabilität und Bugs betrifft. Wir hatten zwei, beide waren aber nicht von LibreSSl verursacht sondern befanden sich auch auf den anderen Images.
Wir haben noch keine Direkt Disk Images; alle Images sind Installationsmedien. Das wird sich aber ganz bald ändern. Wir werden ein SD Image anbieten (Größe 1GB) mit spätestens dem übernächsten Release.
Grüße,
Franco
-
Hallo!
Ich denke das ist kein blinder Aktionismus.
Die pfSense-Fraktion gab sich vor diesem konstruktiven, elaborierten Plan bzw. roadmap ein bisschen negativ irritiert durch den <opnsense fork. Teilweise wurde ein ätzender Bugreport-Kommentar abgesetzt. Einige pfSensler scheinen verärgert über diesen völlig legitimen, erwartbaren und notwendigen EU-fork (eigentlich NL ;) )
Ich sehe es aber durchaus als Reaktion auf das OPNsense Project. Und das ist gut so.
Mir bleiben aber 3 Dinge hängen, aus dem BSD-Now Interview (http://www.bsdnow.tv/episodes/2015_01_14-common_sense_approach (http://www.bsdnow.tv/episodes/2015_01_14-common_sense_approach)), die Alan Jude ansprach und die Bezug zu diesem Post haben:
#1 gibt es Planungen, OPNsense von Phalcom/PHP wegzuführen?
#2 was hat es mit der Ubuntu Namensmimikri auf sich?
#3 FreeBSD 10.0 Problem: Unterstützung bis 02/2015
zu #2 und #3 haben sich Ad, Jos und Franco anscheinend schon entschieden: gegen eine Namenskonventions-kopie von Canonocal entschieden ("silly names": Albion Albatros, Black Bird, Colourful Colibri...), nur die Versionsnummern bleiben Ubuntu ähnlich und mit dem schnellen, d.h. vor 15.7 geschafften FreeBSD 10.1 Uprade haben sie (wie auch pfSense) Frühjahr 2015 ordentlich was vorgelegt, ein herzliches Danke und Gratulation an dieser Stelle!
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 (http://en.wikipedia.org/wiki/Django_%28web_framework%29)) umsteigen werden?
Andere OPNsense pace-marks:
pkg(ng)
opnsense-update
LibreSSL
.. thank you and go on guys! :)
-
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.
-
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.
-
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
-
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 (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
Σουπεργιούζερ
-
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