PuffyTron ajánlja az OpenBSD 4.5-öt

OpenBSD

Federico Biancuzzi jó szokása, hogy kiadásról kiadásra - azaz évente kétszer - meginterjúvolja az OpenBSD fejlesztőket és arról faggatja őket, hogy az éppen aktuális, legfrissebb, legjobb OpenBSD kiadás mitől lehet vonzó az régi és új OpenBSD felhasználók számára. Ugyan az OpenBSD 4.5 már másfél hónapja elérhető a szélesebb felhasználóközönség számára, az ehhez kapcsolódó interjú csak most, néhány napja jelent meg. Benne információk találhatók az OpenBSD 4.5 hang alrendszer, a ports és csomagolórendszer, az OpenBSD/sparc64 port, a Xenocara, a szenzor keretrendszer, a disklabel, az OpenSSH, a malloc, stb. állapotával kapcsolatban. Az érdeklődők elolvashatják a szokásosnál rövidebb az interjút itt.

( lgb | 2009. 06. 18., cs – 16:37 )

Valaki: az amd64 build mennyire ajanlott eles uzemre? Vagy jobb inkabb az i386-nal maradni most meg? Plusz hasonlo kerdes az smp kernellel kapcsolatban :)

Változó, lehet felsorolni pro és kontra elég sok érvet mellette és ellene. Security szempontból jobb az amd64 platform, mert van normális(abb) NX támogatás és azok a dolgok, amik egyébként is 64 bitesek már (pl. ffs blokk-címzés), azok jobban futnak rajta, mint i386-on.

Ugyanakkor vannak alkalmazások, amelyek még mindig nem futnak rendesen 64 bites környezetben, ezekkel lehetnek problémák. Továbbá, ha olyan third-party alkalmazásokat akarsz használni, amelyek csak 32 bites binárissal elérhetők, akkor az amd64 platform tárgytalan, mert nincsen i386 bináris kompatibilitása.

MP kernel működőképes, acpi/apic problémák miatt néha lehet vele szívás, de ez nem feltétlenül az OpenBSD bűne. Ettől függetlenül nyilván hatalmas teljesítményt azért nem kell várni tőle... :) Ha nem a performancia az elsődleges szempont, akkor érdemes lehet vele kísérletezni.

Hat errefele fw-t szoktunk epiteni belole (pf), szoval nem hiszem, hogy az alkalmazasokkal gond lenne :) Mondjuk persze akkor jo kerdes, miert kell mp kernel, lehet csak idegesit, hogy ket cpu/ket mag van, es nincs kihasznalva ;) Amugy performanciat hogy erted, hogy egy ket cpu-s rendszer mp kernellel nem hoz 2-es teljesitmeny up-hez kepest (skalazhatosagi problema), vagy azt, hogy neha egy cpu-val up kernel nagyobb performaciat nyujt atlagos hasznalat mellett (most epp nem fw-rol van szo, hanem ahol alkalmazas is fut, jo par mondjuk) mint mp kernel ket cpu-val?

Hmm, jó felvetés, érdemes lenne kimérni. Ahol javarészt csak a kernel teker, ott az MP se lesz valószínűleg gyorsabb, sőt, mivel több kód kell hogy fusson (#ifdef MULTIPROCESSOR :) és lockolnia agyba-főbe, ezért könnyen lehet, hogy lassabb. Attól függ igazából, hogy mennyi userland fut mégis, amelyet valamennyire lehet még szétosztani a processzorok között (pl. pflogd, pfsync, stb.).

Ilyen szintű méréseket nem végeztem, de lehet érdemes lenne. Mondjuk nálam nem fut sehol se "generic" OpenBSD, mert egy erősen átírt saját verziót használok és nem csak tűzfal funkcióra vannak használva, hanem mindenféle speciális feladatra, ahol nem a sebesség a legfőbb szempont, hanem a minél nagyobb biztonság.

mindig azert van

mondjuk ha % rendekezesreallast kell neznem akkor bizony a linux mogott kullog valahol gettyhatul

ellenben linuxon iptables van es amig ez igy is marad addig alkalmatlan tuzfalnak

freebsd broadcom driverben van egy olyan anomalia h az hs21en bizonyos packetmeretnel egyszeruen megall a kommunikacio

igazabol ez a FOSS heaven, tudod h mit mire nem lehet hasznalni :D

--
.

Csinalj meg par dolgot pf ben es iptablesben es te is ra fogsz jonni a kulonbsegre. Ami mondjuk pf.conf -ban 1 sor es 50 karakter az iptablessel 3 kulon parancs 60+ karakter/sor. De tenyleg nezd meg mi a kulonbseg. En bele se merek kezdeni a magyarazasba mert remalmaim lesznek az iptablestol.

Na meg alkalmazásszűrés szempontjából is rosszul áll a pf... lásd iptables+layer7filter.
Bár van már olyan projekt hogy a pf is képes legyen erre, de ehhez még sok idő kell...

--------------------
Tegnap beállított hozzám egy Tyrannosaurus Rex és Hamlet. Volt nagy dinóm-dánom...

Pf-el lehet már nat mögül több címről pptp-zni?

ha nagyon muszáj :)

Továbbá van-e full transzparens ftp proxy, ami nem a tűzfal forráscímével kapcsolódik tovább?

Nem próbáltam ilyesmit, de mi ezzel a baj? Szerintem ftpsesame is tudhatja, meg ftp-proxy is a -a opcióval.

Connection tracking helper szempontjából elég rosszul áll a pf

Viszont viszonylag könnyű hozzá írni.

igen ezt ertem de melyik ceg az ahol ez kell akkor inkabb igy kerdem

ftprol le lett szoktatva mindenki es van helyette sftp ami egyreszt halozati szempontbol is sokkal jobb masreszt a teljes kontent titkositva megy nem csak a command ugye

evek ota ez van es eddig egyetlen ugyfel se panaszkodott amikor elmagyaraztuk neki h miert kell ez sima ftp helyett.

Nalunk is terv, hogy a FTP-t kidobjuk, es helyette kulcsos auth-tal sftp, csak ez eddig meg nem mindenkinek jott be. Mondjuk mar egy ideje csokken a FTP userek szama, de sok helyen ez nem megoldhato (foleg, ha a usernel nincs kiengedve a tcp:22).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A 21 eleg sok helyen ki szokott lenni engedve azert.
A 1024 feletti portok tekinteteben meg google://conntrack ftp . Jo lenne, ha neha gondolkodnal, mielott ontod magadbol a hulyeseget, mar regen nem vagy vicces.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

HAHAHAH

ne bazmeg

erted a vilagon mindenhol linuxos iptables tuzfal van, hala a joistennek

fogalom nelkul irkalsz mar megint baromsagot. eloszor nezd meg hogy mukodik a ftp aztan nezd meg h miaza stateful tuzfal aztan esetleg meg utannanezhetnel hogy milyen _nem_ stateful megoldasok vannak

--
.

Aztan te meg olvass utana, mely tuzfalak tamogatjak meg a connection trackinget a iptablesen kivul.

Kulonben ftp-t inkabb stateful tuzfalakkal erdemes megoldani, mert kulonben tenyleg a fel gepet kinyithatod a nagyvilag ele. De majd mindjart jon valami tuzfalas emberke, es elmondja neked a tutit.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nekem az iptables amugy jobban tetszenne mint a pf, vannak itt netfilteres fw-k tobb ezer szaballyal sajat webes admin felulettel stb. A baj az, hogy ahogy nezegetem, netfilter eseten az igazi HA tuzfal nehezkes (ami atallas eseten pl kapcsolatokat is megtartja), a netfilter.org-on is olyasmikat irogatnak, hogy "haaaat nem igazan, de van XYZ patch, de ...". Mig OpenBSD/pf-el ez eleg egyszeruen osszehozhato jatek.

Hemm, nezem, de nekem eleg gyanus hogy linux distro-kban nem nagyon talalom, ha meg forditanek, akkor a dependency-ben olyan verziok kellenek libekbol, ami szinten nincs, es csak git repo-bol lehet osszevadaszni a weboldal szerint, nem kotozkodeskeppen, de ez nem kelt bennem jo erzest, hogy ez egy igazan kiprobalt, sokak szamara mar bevalt megoldas lenne. Azert jatszok vele egyet :)

Debian SID-ben minden együtt van hozzá én onnan backportoltam :) lenny-re. (Ami kb annyit jelent, hogy feltettem a sid-es csomagokat)

Egyébként Netfilter core fejlesztő írja.

Lenny-ben is vannak csomagok belőle, de az régi bugos ne használd.

Elég új még ez, hogy benne legyen minden disztróban. Ráadásul ha jól emlékszem 2.6.26+ -os kernel kell minden ficsörjének kihasználásához.