OpenBSD-vel tényleg nem lehet megoldani a QoS-t?

OpenBSD-all

Azt olvastam, hogy mióta kivették az ALTQ-t az OpenBSD-ből, azóta nem megoldható a QoS vele, szemben a FreeBSD-vel, és az arra épülő pfsense-el vagy opnsense-el. Na most azt is olvastam, hogy ha az ember tényleg érteni szeretné, hogy mit csinál, akkor jobb CLI-ből csesztetni a tűzfalat ahelyett, hogy GUI-n összekattintgatjuk, hogy mi akarunk, mint pl pfsense-nél. Páran az OpenBSD-t ajánlották, de a fenti elbizonytalanított. Nekem kéne a QoS, ha már tényleg erre cseszem el az időmet, és ha tényleg ennyire nem tud semmit az OpenBSD, akkor inkább a FreeBSD vonalon mennék tovább...

  • 309 megtekintés

Akkor már a FreeBSD jobb, mert ott van ALTQ az ipf mellé, vagy a pf a saját queue megoldásával, vagy épp az ipfw a dummynet-tel párosítva ;-)

De a lényeg- megérteni jól akkor lehet, ha CLI-ből már tudod csinálni; no akkor át lehet térni a grafikus felületű dolgokra.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az ALTQ-t pont azért dobták mert az OpenBSD fejlesztők szerint egy kalap x*r volt. Legalábbis az OpenBSD-ben.

2020-ban van aki még ipf-et használ?

Amúgy a pf a FreeBSD-ben megrekedt valahol a 10 évvel ezelőtti verziónál tudtommal. Szóval nagy eséllyel FreeBSD-n pf-el is az ALTQ-t tudod tekerni.

Szóval marad a dummynet+ALTQ a FreeBSD-n.

Egyébként nem reklámozzák,de a jelenlegi OpenBSD-ben a queueing az HFSC+FQ_CODEL más diszciplinát nem is lehet választani. De ez sehol sincs leírva. :) Csak a forrásból derül ki, meg egy-két konferencia slideból.

De kiderül, én láttam a release logjukban, hogy "FQ-CoDel algorithm has been implemented for use with pf(4) queueing" a 6.2-es verziónál. https://www.openbsd.org/62.html A dokumentációban persze nincs benne. Ez elég hasznos cikk a témában: https://www.pauladamsmith.com/blog/2018/07/fixing-bufferbloat-on-your-h… Én inkább az OpenBSD felé hajlok a FreeBSD helyett, mert állítólag biztonságosabb az alapbeállításokkal, annyira nagyon meg még nem értek hozzá. Nekem azért tetszene, ha mást is lehetne választani, mert akkor legalább utánaolvasnék, hogy még milyen lehetőségek vannak. De ha ez a legjobb minden szempontból, akkor végülis mindegy.

Ez egy jól kitalált marketing bullshit. Ráadásul helyesen úgy szól, hogy 10+ év alatt csak 1 távolról kihasználható sebezhetőség volt benne a DEFAULT rendszerben. Azaz abban a rendszerben, ami telepítés után gyakorlatilag semmilyen távolról elérhető szolgaltatást nem futtat. Úgy könnyű biztonságot adni, ha nincsenek nyújtott szolgáltatások. Amint kezdesz felpakolni távolról is elérhető dolgokat, onnantól kb. pont annyira lesz biztonságos, mint bármelyik másik unix v. linux. Felesleges erre rástresszelni, a javított up-to-date csomagokat kell frissíteni rendszeresen, és akkor megtettél mindent ami reálisan elvárható. A biztonságot pedig lehet a használhatatlanságig fokozni, csak akkor mit értél el vele?

Jó, de ha így nézzük más rendszereknél meg alapból tele van szórva az egész olyan szolgáltatásokkal, amik teljesen feleslegesek. Nekem valami olyan kell, ami a minimumot adja, aztán majd én eldöntöm, hogy mit teszek fel rá. Ha tehetném L4 mikrokernerről indulnék, és úgy válogatnám össze a dolgokat, csak sajna ahhoz meg nincsen kb. semmi.

Aktuális örjöngés a témában:

https://marc.info/?l=openbsd-misc&m=160401644732418&w=2

Ettől függetlenül szeretjük az OpenBSD-t, mert tényleg konzisztens és ék egyszerű, mondjuk productionban elég kevés helyen látom. :)

Egyébként volt egy előadásuk a témában ahol a "Secure by Default"-ot körbemagyarázták, és ott hoztak olyan dolgokat amik végülis érthetők.

Pl. nem raknak "knob"-okat  mindenhová amivel ki/be lehet kapcsolni sec feature-kat, pl a Meltdown v Specrre mitigációt. Ha egyszer be le lett fejlesztve be van kapcsolva.

Talán ebben is van róla szó: https://www.openbsd.org/papers/bsdtw.pdf