Redundáns failover tűzfal készítése OpenBSD 4.0-val

OpenBSD

A mai menü: hibatűrő tűzfalrendszer OpenBSD 4.0 módra. A hozzávalók:

  • 2 darab Soekris net4801
  • OpenBSD 4.0
  • CARP
  • pfsync

A szakácskönyv idevágó oldala: Soekris net4801 OpenBSD 4.0 CARP

Gabu szimpla bunkó. Ami semmit sem mond arról, mit tud, egyszerűen segghülye. Képtelen disztingváltan kifejezni magát, kisebbrendűségi komplexusa túlnőtt már rajta. Ezért kompenzál. Idióta.
És persze gyerek. Infantilis szamár, neki még a beszólástól nagyobb a fütyije.

Jajistenem, még mindig vannak nincs elég tapasztalatod, hogy ne reagálj az arra nem érdemes beszólásaira? Egy kis olvasnivaló: http://en.wikipedia.org/wiki/Troll_%28internet%29

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nekem is van egy Linksys wrt54gl, de nem adja meg ugyanazt a szabadságot.....

egyéként a 3lan -os wrap 29e Ft, alu ház hozzá 2e , táp 2e = 33 e

Egy jobb USB-s AP router 25-30e, és ARM-es vagy MIPS-es ez most lehet hogy előny, de nekem hátrány.
A WRAP-on minden megy. Az ARM/MIPS alapú routerekkel meg lehet gányolni,( ennek is megvan a szépsége persze)

Üdv
Godot

Régi useless driverek és workaround kódok ki, systrace és egyéb security hole ki, nullfs újraírása (köszönhetően, hogy a 3. security bugreportom után Theo inkább úgy döntött, hogy ők eltávolítják a teljes layerfs-t az OpenBSD forrásából, ahelyett, hogy javítanák), raidframe bizonyos részeinek átírása (néha csinált olyat, hogy mkdir bla után nem látszódott egyből a könyvtár, stb.), ata/wdc átírása (mivel katasztrófális sebességet hozott bizonyos szervereken és az OpenBSD csapat szokás szerint nem segített), FreeBSD jail portolása, a PaX ötlete alapján mmap() és mprotect() korlátozások (mivel OpenBSD egoja nagyobb volt, mint hogy a PaXTeam véleményét elfogadják és tőle ötletet vegyenek), egyéb memóriakezeléssel kapcsolatos változtatás és még sok más, amelyekre vagy nem emlékszem már, vagy nem akarom leírni (pl. jónéhány 0day sechole fix ;).

A hibák jórésze akkor jön elő, amikor már nyakig benne van az ember a munkában és nincs ideje/kedve már váltani. De tévedés ne essék, más oprendszereknél sem jobb a helyzet, csak max. más problémák jönnek elő. Tudnék mesélni Digital Unix, Linux, FreeBSD és Windows témakörben is, csak nem akarok. :)

Khm. Éppenséggel BSD kernelekről jelent meg könyv, nem is akármilyen, és nem is egy.
Jobb helyeken device driver íráshoz is szokott lenni doksi, de kernelhacker kézikönyveket, kernel debug leírásokat, útmutatót, hogy hol érdemes kezdeni, stb. is lehet találni, ha valaki veszi a fáradtságot, és kicsit körülnéz a választottja házatáján. (NetBSD-t ismerem ilyen szempontból)
Ráadásul BSD-nél ugye teljes oprendszer fejlesztés van, nem csak a kernellel lehet foglalkozni - nagyon fontos a userland, az installer és a doksiírás is.

Persze az "alap" fogalmakkal tisztában kell lenni (operációs rendszer elmélet), és képbe lehet jönni a választott rendszer kernelében aktuális fejlesztésekről a fejlesztői levlisták (+arhívumának) szorgalmas olvasgatásától. Kicsit meg lehet ismerni, hogy kik a meghatározó arcok, és (kellemesebb helyeken) nem is hajtanak el, ha kérdezel - csak ne legyel teljesen zöld. :)

Milyen érdekes dolgok. :) Mintha nem először olvasnék ilyenről. :)) Rémlik pl. egy olyan dolog is valahonnét, hogy amikor valaki egy MySQL szerverről panaszkodott, hogy az bedarálja maga alá az OBSD-t (értsd: fagy), akkor elküldték a francba. Ahelyett, hogy elgondolkodtak volna azon, hogy egy nem root jogokkal futó userland program hogyan tud ilyet tenni. :/

Szeretném a témában Thug véleményét is olvasni. :))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Aha, valóban. :))) A lényeg, hogy emlékeztem rá. :)

Én amúgy szeretem az OpenBSD-t, érdekes rendszer. :) Itthon fölraktam egy Ultra5-ösre a 3.9-est, néha használom NFS szervernek, ehhez elég stabil. :)))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Én pedig úgy veszem észre , hogy a driver fejlesztés mostanában az Openbsd-ben pörög leginkább.

Az egy más kérdés, hogy a kernel-en lenne mit fejleszteni, hogy mást ne mondjak 2006(7) -ben nem ártana már normális SMP és kernel threading támogatás, mivel lassan már a PDA-k ban is dual core cpu van. Nem tudom, hogy Theo-ék hogy állnak a Világmegváltással (akarnak?) , de mondjuk egy jobb telepítő se ártana, én elvagyok vele , de az nem számít :)

Az álom (BSD) rendszer számomra egy DflyBSD+OpenBSD vegyes lenne, ez már elég innovatív szvsz.

Az, hogy nagyon experimental, még mindig, pedig 2003 óta gyúrják...
(Ami nem baj különben ,valahol olvastam, hogy Mattew a 2.0 -át igérte Production Ready-nek.)

Az SMP (és hozzá tartozó egyéb ) és ACPI kódot nyomják nagyon a srácok, de még nem stabil szvsz.

Egy SUN V40z-n (8core) és egy x4100 (4core)- on is csonttá fagy az 1.6 komolyabb threades teljesítménynél. (Mysql, Postgres)

A Netbsd is kiakadt nekem (3.0.1)
OpenBSD-t ki sem próbáltam SMP -vel nem javasolt :)

Ezért még mindig FreeBSD-t használunk (vagy RedHat-ot :) )

Üdv

Reportoltam már néhány dolgot a FreeBsd-seknek... (mind driver bug volt)
Normális bugreporthoz idő kell...

A baj az , hogy ezeknél a szervereknél nálunk nagyon kevés idő van a "játszásra" (meg egyébként is amúgy) mennek élesbe, néha cska éppeg hogy be lehet bootoni rajtuk a "kedvenc" "kisérleti" "rendszeremet", csak hogy lássam hol tart a tudomány.

Üdv
Godot

Én több gépen is használtam 3.8/i386-ot (K6, Athlon, Duron, PIII, PII - egy up és egy mp gépen) anno, az ment (igen, terhelés alatt is).

szerk.: egyébként most fontoljuk a redundant firewall-t, majd blogolok. :-)
--
Gentoo motto: It's worth spending eight hours trying to make something load 20ns faster.

Én egy ócskavas cyrixból akarok majd valami tűzfalszerűséget összehozni, de mivel egy rt2400 kártyával kell kapcsolódni a szolgáltatóhoz, ezért azt hiszem obsd-kilőve (legalább is úgy tudom nem támogatja). Linux(ndiswrapper és natív) és FreeBSD(ndiscvt) alatt sikerült beüzemelnem, más alatt nem tudom lehetséges-e...

--
TheReplaced - С Кем Ты?

Röhögni fogsz, de anno csináltam teszteket ilyen kártyákkal (ráadásul pont OpenBSD alatt) és a Realtek jobb eredményeket hozott, mint egy SiS 900. (Mielőtt még valaki elsüti, hogy ezen nem SiS 900 van, hanem a NS DP83815, annak elmondanám, hogy meglehetősen azonos mindkettő felépítése, ezért is hajtják meg ugyanazzal a driverrel...)

Ez valóban meglepő. :) Mondjuk ha nem a teljesítmény az elsődleges szempont, akkor nincs bajom az Realtekekkel. Az utolsó, gagyi, sz*r switchekkel, kábelmodemekkel stb. is képesek kommunikálni, amitől nem egy jobb kártyát (Intel e100, 3C905) már láttam megnémulni.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Ez így van. Keresgélj a hozzászólásaim után itt a HUP-on, egy naplóbejegyzéshez írtam hozzá, hogy az UPC Motorola kábelmodemjével képtelen volt emiatt kommunikálni.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.