PF raus aus FreeBSD

Hi

Seit Monaten Eiern die zum Beispiel beim Virtualisationsprojekt an PF herum
http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-May/000698.html
Und kommen deswegen nicht weiter.
Die Codebase von PF ist doch nie das was OpenBSD aktuell ausliefert.
Ein harter Cut löst ab und an mal den Knoten.

In der Cloud brauche ich Platformen wie ich die Qualität und Güte der Leistung bestimmen kann.

Ohne PF wäre man da schon viel weiter.

Mit funktionierendem virtuellem Netzwerkstack würde es sich lohnen ein Entwicklerteam einzustellen das dann darauf aufbauend Produkte Entwickelt. Natürlich auch in der Hoffnung das diese in FreeBSD aufgenommen werden. Das wäre am Ende billiger.

Cloud ist anscheinend für viele hier ein Buzzword. Für mich ist es die Zukunft weil logische Fortsetzung der bestehenden Enwicklung. Wenn Privatanwender oder Mitarbeiter in Firmen Ihre Daten komplett in der Wolke gespeichert haben, machen die das zum Einen weil weil es später alle so machen. Zum anderen haben die auch einen Mehrwert. Der Preis ist dann ein noch höheres Analphabetentum bei IT Produkten. Aber in immer komplexer werdenen Gesellschaften ist halt nichts umsonst. Systeme wie Google ChromeOS werden in der Zukunft eine breite Anwenderschaft finden.

Sollte FreeBSD bis dahin nicht in dieser Liga als Platform verfügbar sein wird es als OS sich mit der Zeit in die absolute Bedeutungslosigkeit verabschieden. Allerdings die Zeit drängt. Jeder verpasste Tag ohne diese Features ist eine verpasste Gelegenheit.

Anhand den Kommentaren in diesem Thread scheine ich meine Meinung nicht mit anderen zu Teilen. Beziehungsweise andere meinen vielleicht auch in 10 bis 20 Jahren wird der Desktop so wie wir ihn jetzt nutzen, weiterhin von einer breiten Masse an Bestand haben wird.

Bitte entschuldigt diese kurze Zusammenfassung meiner Meinung. Aber wenn ich Zeit in etwas investiere möchte ich wie jeder auch eine Rendite haben. Derzeit halte ich es für unlogisch mehr Zeit in diesem Thread zu investieren. Ich bin überzeugt das bei FreeBSD hier mehrere mehr an knowledge als ich aufweisen. Aber mit den vielen Jahren vielleicht doch in unzeitgemäse Denkstrukturen verfallen sind. Das ist nicht als Beleidigung gemeint, sondern nur als nüchterne Wahrnehmung meinerseits.
 
Zuletzt bearbeitet:
Amen.
Es geht hier nicht um Vor oder Nachteile der verschiedenen Firewalls oder deren Bedienbarkeit, sondern die Forderung mittels 'Beschwerde' etwas aus dem System BSD zu entfernen.

BTW, irgendwo hab ich was von Invest without return gelesen, geschrieben von Minimike als Erwartung an andere Investoren.

Aber mal Spass beiseite, die Menge der Worte und akademischer Plattphrasen kann nicht über den Inhalt hinwegtäuschen.
Wenn jemand genug Geld hat, mag er Entwickler dafür bezahlen, ihm seinem Projekt zufgeschnittene Plattformen und was weiß ich zu liefern.
Niemand zwingt ambitionierte Unternehmer, ein freies System wie FreeBSD zu verwenden.
Oracle z.B wird sicher gerne etwas entsprechendes liefern, mit Support und hochprofessionell. Schon mal bei IBM probiert ?
Mit Sicherheit lassen sich auch Kernelentwickler der BSD's gerne entsprechend entlohnen.

Von dem freien Opensourceprojekt FreeBSD zu erwarten, dass aufgrund etwas zweifelhaften Genuschels einer weltweit eher irrelevanten Verkaufsveranstaltung in Berlin (wusste gar nicht, dass es sowas hier gibt) und den ominösen Interessen einzelner und deren Prognosen für die Zukunft sein Konzept zu ändern, ist vorsichtig gesagt, anmaßend und realitätsfern.
Gab's da auch einen M$ - Stand auf der Messe ? Hört sich so an.

Scheinbar ist aber der völlig verblödete Rest der Gemeinde, obwohl teilweise eher im professionellen Bereich angesiedelt, nicht in der Lage, der Tragweite der Zukunftsvisionen zu folgen.

Bitte entschuldigt meine kurze Zusammenfassung, aber mir wird's sonst zu wolkig.

Aber im Großen und Ganzen, gut getrollt.
 
minimike schrieb:
Hi

Seit Monaten Eiern die zum Beispiel beim Virtualisationsprojekt an PF herum
http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-May/000698.html
Und kommen deswegen nicht weiter.
Die Codebase von PF ist doch nie das was OpenBSD aktuell ausliefert.
Ein harter Cut löst ab und an mal den Knoten.

In der Cloud brauche ich Platformen wie ich die Qualität und Güte der Leistung bestimmen kann.

Ohne PF wäre man da schon viel weiter.

Mit funktionierendem virtuellem Netzwerkstack würde es sich lohnen ein Entwicklerteam einzustellen das dann darauf aufbauend Produkte Entwickelt. Natürlich auch in der Hoffnung das diese in FreeBSD aufgenommen werden. Das wäre am Ende billiger.

Cloud ist anscheinend für viele hier ein Buzzword. Für mich ist es die Zukunft weil logische Fortsetzung der bestehenden Enwicklung. Wenn Privatanwender oder Mitarbeiter in Firmen Ihre Daten komplett in der Wolke gespeichert haben, machen die das zum Einen weil weil es später alle so machen. Zum anderen haben die auch einen Mehrwert. Der Preis ist dann ein noch höheres Analphabetentum bei IT Produkten. Aber in immer komplexer werdenen Gesellschaften ist halt nichts umsonst. Systeme wie Google ChromeOS werden in der Zukunft eine breite Anwenderschaft finden.

Sollte FreeBSD bis dahin nicht in dieser Liga als Platform verfügbar sein wird es als OS sich mit der Zeit in die absolute Bedeutungslosigkeit verabschieden. Allerdings die Zeit drängt. Jeder verpasste Tag ohne diese Features ist eine verpasste Gelegenheit.

Anhand den Kommentaren in diesem Thread scheine ich meine Meinung nicht mit anderen zu Teilen. Beziehungsweise andere meinen vielleicht auch in 10 bis 20 Jahren wird der Desktop so wie wir ihn jetzt nutzen, weiterhin von einer breiten Masse an Bestand haben wird.

Bitte entschuldigt diese kurze Zusammenfassung meiner Meinung. Aber wenn ich Zeit in etwas investiere möchte ich wie jeder auch eine Rendite haben. Derzeit halte ich es für unlogisch mehr Zeit in diesem Thread zu investieren. Ich bin überzeugt das bei FreeBSD hier mehrere mehr an knowledge als ich aufweisen. Aber mit den vielen Jahren vielleicht doch in unzeitgemäse Denkstrukturen verfallen sind. Das ist nicht als Beleidigung gemeint, sondern nur als nüchterne Wahrnehmung meinerseits.
Zum Vergrößern anklicken....


Sei mir nicht böse...
Aber wenn ich CLOUD will... dann ruf ich den Dealer meines Vertrauens hin und stell mir Exadata, oder Exalogic hin.

Will ich Virtulisierung ruf ich bei EMC an und lass mir den Vmware Verkaufsdroiden kommen.


Ja Cloud ist für mich ein Buzzword, genau wie es Web 2.0 war.
Oder aktuell der DevOPS Quatsch.

Panikmache ist übrigens wie ich finde unproduktiv, seit Jahren höre ich schon BSD stirbt.

Solaris ist angeblich auch schon längst tot... HP-UX und AIX auch.

Abgesehen von HP-UX erfreuen sich alle bester Gesundheit. Gerüchteweise, werden sogar noch Unix Maschinen verkauft, ich habe allein 60 Stück gezählt die letzten zwölf Monate in meiner Klitsche und das waren keine x86.

Ok back to topic. Die Cloud ist im Moment alles und nichts... ich hab so viel widersprüchliches über die Cloud insbesondere von Salesleuten gehört, das ich das Wort schon gar nicht mehr hören kann.

Mag sein, das wir in alten Denkstrukturen gefangen sind, aber ich kenne keine Firma, die ihren Kram in der Cloud ablegen will.

Abgesehen davon, da wo ich tätig bin, wir sichern unter anderem die Clients und Datenbanken von Drittfirmen, also extern. Aber da geht nichts übers "Internet" und als Cloud Klitsche verkaufen wir uns auch nicht, obwohl das heute ja fast schon unter dieses nichtdefinierte Wort fällt. Nennen wir es eher mal ein großes VPN.

Was Google mit seinem Linuxfork ChromeOS macht, werden wir noch sehen, ich bin da nicht so optimistisch wie Du, das die Leute ihren ganzen Kram $Dienstleister überlassen. Nicht jeder hat sein Gehirn abgegeben.

Speichermedien sind im Commodity Markt heute derart billig, das es sich gar nicht lohnt den Mist extern zu lagern, zumindest als Privatkunde.

Als Dienstleister jedoch im professionellen Markt bist Du der gekniffene, Storage kostet richtig Geld, insebsondere wenn der performant sein soll.

Da kommt man im Moment, um FC Platten immer noch nicht rum. Für Testsysteme verschleudert man unter Umständen SATA Platten.

Oder wer wirklich auf Schmerzen steht, kombiniert dann SATA Storedge mit SSD's zum cachen. Oder man geht auf Scale Out, wie IBM das mit der XiV und HP mit seinem Neueinkauf 3PAR.

Bevor Du hier von der Cloud fabulierst, solltest Du dich auch mal mit den Kosten auseinander setzen, es ist eben nicht so wie Google und Facebook das gern propagieren, das Datacenter mal schnell so mit Commodity Hardware aus dem Boden gestampft werden können.

Das mag für deren Zwecke vielleicht reichen und selbst da bin ich sehr sehr skeptisch, ich würde mit Dir wetten, das die nicht nur ihre Billigkisten in den RZ's stehen haben.

Es gibt Szenarien wo Du Daten 10 Jahre Aufbewahren musst, schon aus Gesetzes Gründen und der Datenschutz extrem hoch gehängt wird, das Du das ganze intern machen musst, kannst Du Dir vorstellen was für ein Aufwand da betrieben wird, oder was für Infrastruktur da benötigt wird?

Ja möglicherweise kann man das was wir da machen als Firmencloud bezeichnen, aber bei uns käme keiner auf die Idee die vier RZ's als Cloud zu benennen, obwohl Dir dort von der Terminalfarm, über Storedge bis zum Unix und z/OS Backend alles angeboten wird und so mancher Kunde das auch komplett bucht.

Jedes System hat seine Berechtigung ich glaube auch nicht, das FreeBSD an der Cloud eingehen wird, im Gegenteil, es hat seine Nische, darin ist es gut, genau wie Windows seine Nische auf dem Desktop und bei internen Mailserverfarmen hat. z/OS lebt auch immer noch, obwohl es nichts teureres gibt. VMS existiert auch noch bei gut betuchten Kunden, auch die Sun Reste werden noch Jahrelang existieren weil sie ihre Nische und Berechtigung haben.


Wer glaubt das in Zukunft alles in der "Wolke" abfackeln zu können, ist naiv.


Sorry das war jetzt etwas lange und auch etwas Off Topic.
 
FreeBSD lebt auch von Spenden und brauch sie auch, Spenden gibts aber auch nur von Unternehmern die von FreeBSD etwas erwarten. Zum Thema nochmal, es wirklich so, das bestimmte Sachen in den Sourcen außer die Nummer der Release zu ändern trotz Fehler garnicht mehr oder nur sehr halbherzig gepflegt werden und wenn man mit Entwicklermangel oder zu viel andere Sachen um die Ohren hat eben auf die Kernsachen beschränken und auch Pakete entfernen. Es ist eben nicht so das ein OS alles können oder haben muß.
 
Ich kann auch nur PF, aber es gibt schon Mankos. Neben der alten Version, skaliert PF wohl schlecht auf mehrere CPUs, was nicht verwunderlich ist, da OpenBSD dies auch nicht kann und der Code von da kommt.

Deswegen hat NetBSD sich ja auch an eine neue gemacht [1]. Vielleicht sollte man diese erstmal portieren und dann weiter sehen. Sachen rausschmeißen macht zwar auch Sinn (4 Firewalla sind mindestens 2 zu viel), aber nur wenn das neue wirklich besser ist. Und bevor man OpenBSDs Firewall rauswirft, sollte man wirklich sicher sein, dass die neue sicher ist ;)


[1] http://mail-index.netbsd.org/netbsd-announce/2010/09/13/msg000110.html
 
Für NetBSD wäre nichts einfacher wie iptables in NetBSD zu integrieren, iptables ist ja der Nachfolger bzw. Fork von ipfilter. Bei ipfilter passiert doch seit Ewigkeiten auch nichts mehr.
 
Ich glaube mit der Lizenz hast du mich jetzt erwischt.

Crest

wegen dem Crash, war rule antispoof gesetzt
 
Flex6: Nein ich hatte kein antispoof drin. In meiner Produktivumgebung sind asymertrische Routen normal. Das Ruleset habe bis zu diesem reduziert. Allerdings sind die Links über die ich OSPF spreche üper OpenVPN bzw. IPsec gesichert.
Code: 
# Damit die kaputten Packets mit ungültigen Optionheaders aus ipfw raus gelassen werden.
sysctl net.inet6.ip6.fw.deny_unknown_exthdrs=0

ipfw pipe 1 config bw 1Mbit/s
ipfw add 100 pipe 1 ip6 from $UNICAST/64 to $UNICAST/64
ipfw add 200 allow ip from any to any
 
Flex6 schrieb:
FreeBSD lebt auch von Spenden und brauch sie auch, Spenden gibts aber auch nur von Unternehmern die von FreeBSD etwas erwarten. Zum Thema nochmal, es wirklich so, das bestimmte Sachen in den Sourcen außer die Nummer der Release zu ändern trotz Fehler garnicht mehr oder nur sehr halbherzig gepflegt werden und wenn man mit Entwicklermangel oder zu viel andere Sachen um die Ohren hat eben auf die Kernsachen beschränken und auch Pakete entfernen. Es ist eben nicht so das ein OS alles können oder haben muß.
Zum Vergrößern anklicken....

OP: 'Forderung ...Beschwerde ...PF raus.. weil mein $Projekt' .

wobei $Projekt=`zukünftig unverzichtbarer Bestandteil der weltweiten Entwicklung, weil , wenn erfolgreich, dann gibts Geld; und ausserdem kann sowieso nichts und niemand auf diese meine spezielle Beglückung verzichten`

So geht das nicht, und nicht nur bei FBSD, sondern auch nicht bei meinem Bäcker.

Du kannst einem kommerziellen Unternehmen gegen entsprechende Bezahlung, die in der Regel sehr, sehr zeitnah stattzufinden hat, einen Auftrag geben, den die dann erfüllen, wenn sie es wollen.

Du kannst ein freies, hier wie Freibier, OS/System nutzen, und hast gleichzeitig die Freiheit, es zu lassen.
Wenn kommerziell eingesetzt, steht es wiederum frei, dieses OS/Projekt wegen des dem eigenen Unternehmen entstandenen Mehrwertes finanziell zu unterstützen.
Gleichfalls steht es frei, Änderungen und Verbesserungen, die aufgrund spezifischer Bedürfnisse dieses Unternehmens auf eigene Kosten und damit auch Risiko entwickelt wurden, zurückzugeben.
Allerdings steht es dem OS/Projekt auch frei, auf diese Änderungen zu verzichten.

Wenn das akzeptieren derartiger geschäftlicher Parameter ( siehe $Projekt oben ) tatsächlich Bestandteil der Handlungsmuster eines Unternehmens ist, hat dieses zumindest für kurze Zeit eine Menge Freunde. Oder Altruismus (bei den anderen wohlgemerkt) ist oberstes ethisches Prinzip im Geschäftsleben geworden.
Das ist mir allerdings bisher entgangen.

Und wie du schon sagst:
Es ist eben nicht so das ein OS alles können oder haben muß
Zum Vergrößern anklicken....
Genau !
 
minimike schrieb:
Seit Monaten Eiern die zum Beispiel beim Virtualisationsprojekt an PF herum
http://lists.freebsd.org/pipermail/f...ay/000698.html
Und kommen deswegen nicht weiter.
Zum Vergrößern anklicken....

Ich möchte einmal wissen, wie du darauf kommst, dass pf in Sachen vnet irgendwas blockieren würde. pf läuft derzeit nicht in vnet-Containern, klar. Aber das ist doch kein Problem, dann nutzt man es eben nicht. Zudem gibt es - wie ich oben schrieb - bereits seit Monaten Patches die pf auf eine deutlich aktuellere Version bringen und zugleich virtualisieren. Außerdem, wieso sollte FreeBSD ein viel genutztes und bei einem großen teil der Nutzerbasis sehr beliebtes Feature einfach entfernen, nur weil es dir im Weg steht? Deine ganze Argumentation bricht spätestens an dem Punkt zusammen, an dem ipfilter ins Spiel kommt. ipfilter ist wesentlich älterer Code als pf, wird inzwischen kaum noch genutzt und ist ebenso wenig virtualisiert. Wieso willst du das also nicht gleich mitentfernen? Siehe zu dem Thema auch die Folien von DevSummit 05/2011 über die Zukunft des Netzwerkstacks, speziell "Future of Firewalls". Dort wurde u.a. auch über pf diskutiert und das Ding zu entfernen wurde nicht einmal als Option genannt...

Außerdem wirst du mir irgendwelchen Anträgen und "Beschwerden" nicht weit kommen. Das einzige, was du erreichst ist ein weiterer, endloser Bikeshed, der Ressourcen und Manpower verschwendet. Wenn du pf wirklich loswerden möchtest, müsstest du schon den üblichen Weg gehen:
1. Schreibe Patches, engagieren dich und bekomme irgendwann vielleicht ein Commit-Bit.
2. Beteilige dich an der Entwicklung der Firewalls, des Netzwerkstacks und so weiter. Gewinne Respekt, werde als kompetente Person auf dem Gebiet akzeptiert.
3. Schreibe eine Eingabe an die nicht-öffentliche Entwicklerliste, in der du dalegst wieso pf sterben muss. Diskutieren das aus, werbe für deine Idee.
4. Kämpfe den zwingenden Bikeshed auf den öffentlichen Listen aus.
5. Hole dir das Einverständnis von core@ - ohne wird es bei einer solch massiven Änderung kaum gehen - und entferne pf.
6. Wenn die Scheiße denn den Ventilator getroffen hat, rechne damit ordentlich was ins Gesicht zu bekommen.

Da es technisch gesehen nicht viele Gründe gegen pf gibt - wenn du es nicht willst, baue halt einen Kernel ohne oder lade pf.ko nicht - ist das ganze hier eine fruchtlose und sinnlose Diskussion. Das große Problem an vnet ist übrigens mangelnde Manpower. Da sitzt kaum jemand (niemand?) mehr so wirklich dran, da alle zwar wunderschön schnacken können und immer wieder tolle Vorschläge bringen, aber wenn es darum geht den Code zu auditen, ihn zu testen, Patches zu schreiben und den Merge der Perforce-Branches in -CURRENT vorranzutreiben, ist immer gähnende Stille die Antwort. Siehe z.B. die RFC und vorgeschlagenen Patches auf virtualization@. Das reale Interesse an vnet abseits gewisser Randgruppen scheint eher gering zu sein.
 
h^2 schrieb:
Ich kann auch nur PF, aber es gibt schon Mankos. Neben der alten Version, skaliert PF wohl schlecht auf mehrere CPUs, was nicht verwunderlich ist, da OpenBSD dies auch nicht kann und der Code von da kommt.
Zum Vergrößern anklicken....

Das ist auch nicht unbedingt wichtig. Du kannst auch mehre Systeme mit einer CPU nehmen und diese mit CARP betreiben. So hast du zusätzlich auch noch eine höhere Ausfallsicherheit.
 
Yamagi schrieb:
Ich möchte einmal wissen, wie du darauf kommst, dass pf in Sachen vnet irgendwas blockieren würde.
Zum Vergrößern anklicken....

Das fragt sich hier glaub ich jeder, vor allem kam die Aussage doch extrem schwammig rüber.


Yamagi schrieb:
. Das große Problem an vnet ist übrigens mangelnde Manpower. Da sitzt kaum jemand (niemand?) mehr so wirklich dran, da alle zwar wunderschön schnacken können und immer wieder tolle Vorschläge bringen, aber wenn es darum geht den Code zu auditen, ihn zu testen, Patches zu schreiben und den Merge der Perforce-Branches in -CURRENT vorranzutreiben, ist immer gähnende Stille die Antwort. Siehe z.B. die RFC und vorgeschlagenen Patches auf virtualization@. Das reale Interesse an vnet abseits gewisser Randgruppen scheint eher gering zu sein.
Zum Vergrößern anklicken....

Amen!
 
h^2 schrieb:
Ich kann auch nur PF, aber es gibt schon Mankos. Neben der alten Version, skaliert PF wohl schlecht auf mehrere CPUs, was nicht verwunderlich ist, da OpenBSD dies auch nicht kann und der Code von da kommt.
Zum Vergrößern anklicken....


hi

pf unter openbsd braucht nicht scalieren weil es ein irrglaube ist das ein packetfilter multicore braucht.

wichtiger ist hohe taktrate.

henning und ryan wuerden sich kaputt lachen wenn sie das hier lesen.

und wer der meinung ist eine firewall in einer cloud oder virtuellen box
einzurichten , hat das thema firewall nicht verstanden.


holger
 
FreeBSD ohne pf? Also ich werde das garantiert auch nicht unterstützen. Mit ipfw kann ich mich nicht anfreunden. Die ipfw Konfiguration erinnert mich immer an die negativen Aspekte von iptables. ipfilter hatte ich vor ein paar Jahren im Einsatz aber pf finde ich einfach besser zu konfigurieren.
 
Dass pf in einer Jail nicht geht, ist nicht schlimm. Es wäre ein interessantes Feature, aber viel mehr nicht. Man braucht pf eigentlich nur auf dem Master Host. So habe ich das zur Zeit. Wenn man pf virtualisiert auf VIMAGE, dann ist das schon eine Leistung, über die sich sogar OpenBSD freuen würde. Das würde das Konzept auf einem abstrakten Niveau beweisen.

Meiner Meinung könntest Du genauso verlangen, dass man rum(4) entfernt (anhand Deiner Liste da), weil es mit VIMAGE panict.

Erinnert mich irgendwie an Simpsons: "Lasst uns das Observatorium niederbrennen, damit so etwas nie wieder passieren kann!".
 
Ich breche auch eine Lanze für pf. Ich mag die Syntax von pf, sie ist einfach und verständlich. Mir reicht es auch aus, pf nur auf dem Hostsystem zuhaben. Da ich auch zwei OpenBSD-Firewalls unter meinen Fittichen habe, möchte ich nicht auch noch eine andere Syntax lernen müssen. Und wenn es heißt, ipfw ist performanter, dann ist mir das egal. Kommt ne fettere CPU und mehr RAM rein und fertig ist der Lack.
 
crotchmaster: Zeig mir bitte die 19,2GHz CPU mit der ich einen 3,2GHz Hexacore ersetzen kann. OpenBSD skaliert halt nicht. Es ist schon traurig, wenn $n VMs mit CARP als Loadbalancer performanter sind als eine native Installation.
 
Ich wollte mit meinem Post nur ausdrücken, das mir die etwas bessere Performance von ipfw gegenüber pf soetwas von am Allerwertesten vorbeigeht. Das pf und OpenBSD nicht skalieren ist mir auch klar.
 
Dann sollen aber bitte auch die Soundtreiber rausfallen, "the power to serve" braucht keine Audioausgabe ;-)

Rob
 
KobRheTilla: Die braucht man für Stimmung im RZ. Sobald man mal wieder direkt vor der lärmenden Hardware steht kann man sich ne USB Soundkarte von vorne stecken und den musicpd anwerfen ;-).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben