Slysel sem o freeBSD, ze je to dobrej OS. A kdysi sem uvazoval, ze bych to s nim zkusil. Prednedavnem tady na root vysel clanek, kterej porovnava linux a freeBSD(4.9-5.2)z hlediska siti. Po serii testu vyslo najevo, ze linux s 2.6 kernelem je na tom daleko lepe nez tolik opevovane freeBSD(rychlost vyrizeni pozadavku atd.) Takze se ptam proc instalovat freeBSD, ktery je podle testu na sitove zalezitosti horsi nez linux? Bezpecnost? Mozna...ale kdo si umi nastavit linux tak problem s bezpecnosti nema. Rad bych, aby nekdo uvedl nejaky zavazny argument proc bych mel prejit z linux na freeBSD. Docela me to zajima. Chapu, ze to ma jinou filozofii
a znam par lidi co to pouzivaj, aby se odlisili atd.
Ale me spise zajimaj prakticke duvody. Nerad bych ztracel furu casu rypanim se v dalsim unix aniz by to pro me melo naky zasadni prinos. Takze freeBSD profici jen do me :)...ale prosim padne a logicke argumenty...na flamewar nemam cas ani chut.
3BSD se mi dnes také zdá trochu lenivější než Linux. Hlavně 5.x řada. Kdysi ovšem verze 4.2, kterou jsem používal i na desktopu, měla znatelně lepší odezvu. 3BSD má spoustu věcí lépe a mnohem jednodušeji vyřešených (sysctl, šablony pro make, ...). Radost je také kompilace a vývoj jádra. Taktéž má 3BSD velmi dobrou dokumentaci. Škoda jen slabší podpory a pro mne nejasného trendu ve vývoji. Proto dnes používám Gentoo, které se alespoň trochu 3BSD podobá.
Autorovi děkuji za velmi pěkný článek.
protoze nema chyby :)
jsou 3 vyvojive vetve:
RELEASE => prvni pouzitelna verze s minimem znamych lehkych chyb a 0 znamych bezpecnostnich chyb
STABLE => opravene chyby. zedne zasahy do kosmetiky a funkci
CURENT => tady se bastli stejne jako v linuxu a jednoho dne z toho vzejde dalsi RELEASE ktery sice nebude IN, ale nebude treba ho opatchovavat.
proste BSD (obecne, ne jen FreeBSD) odevzdava hotove produkty, nikoliv polotovary.
Jasna odpoved je niekde vo FreeBSD FAQs: Pokial mate vybrany svoj free unix-like operacny system a ste s nim spokojni, nie je dovod prechadzat na iny. Ak zatial nemate svoj free unix-like operacny system vybrany, tak moze byt FreeBSD dobrou volbou.
Neexistuje ziadny vseobecne akceptovany dovod, preco prejst z GNU/Linuxu na FreeBSD, rovnako ako neexistuje ziadny vseobecne akceptovany dovod, preco prejst z FreeBSD na GNU/Linux. Rozdiely sa najdu v mnohych aspektoch, ale signifikantne zacnu byt az v hranicnych situaciach (t.j. hranicnych poziadavkach na spravu virtualnej pamate, hranicnych poziadavkach na I/O subsystem, hranicnych poziadavkach na sietove vlastnosti, hranicnych poziadavkach na XYZ).
Ak pouzivate GNU/Linux a vyhovuje vam, tak ho v zdravi pouzivajte na uzitocnu pracu (lebo na to su pocitace urcene) a vykaslite sa na experimentovanie z nejakym FreeBSD. Ja pouzivam FreeBSD a vyhovuje mi, tak ho pouzivam na uzitocnu pracu a nebudem experimentovat z nejakym GNU/Linux-om, pokial k tomu nebudem donuteny okolnostami. Ak pouzivate GNU/Linux a vyhovuje vam, ale ste zvedavy na nejake FreeBSD, tak experimentujte, ale pripravte sa na zistenie, ze niekde inde mozu veci fungovat aj inak. Samozrejme, vsetky znalosti z Linuxu vam budu uzitocne aj vo FreeBSD a naopak.
Nechtel jste rict "vice ci mene" spokojeny uzivatel?
Tak napriklad zkusil jste nekdy pracovat s USB pod stable FreeBSD? Z uzivatelskeho hlediska to citim jako jeden z mnoha nejvetsich problemu soucasnosti. Vzdy se klepu, zda mi opet nesleti system. Jiste, nekdo USB nemusi pouzivat, ale je cela rada dalsich oblasti, kde je hodne co zlepsovat.
Prave kvuli temto ruznym problemum, posledni dobou uvazuji o Mac OS X. Jen to dostat na mesic pod ruku... Ale kde?
<OT> minimalne jsem vice spokojeny, nez mene nespokojeny uzivatel. :)) </OT>
jako uzivatel sitoveho OS jsem nadmiru spokojen.
vyzaduji sitove sluzby (ssh, ftp, mail, firewall a mnoho dalsiho) && nevyzaduju uzivatelsky luxus s podobe multimedii, USB, BlueToth, webcam, GUI atp.
jako uzivatel workstation jsem velmi spokojen.
vyzaduji GUI, alespon trochu multimedii, CD/CDRW/DVD atp. && nevyzaduju automaticke loupani bananu, stojanek na kafe, USB lampicku, USB vetracek, USB automat na Yuke.
s problemy se stabilitou USB pod FreeBSD4 jsem se nesetkal ( USB2 flash disk , fotak )
ad MacOSX , pred pul rokem jsem presel z FreeBSD na MacOSX (Powerbook ) hlavne kvuli zpracovani videa a zatim jsem s nim zcela spokojen . A ani odlisnosti od OS , na ktere jsem zvykly ( {Free|Net}BSD, Solaris ) nebyly tak velke , jak jsem se obaval .
Pokud si z Prahy tak se na nejake kratke ukazce muzeme domluvit .
No s tim MacOsX bych taky nebyl tak prehnany optimista. Ja si s nim uz nejakej ten rok hraju a je pravda ze system jako takovy mi za celou tu dobu nespadl ani jednou. Nicmene na druhou stranu problemu je s timto OS take mnoho a to hlavne s ovladaci k ruznemu hw. (prevazne od vyrobcu kteri nepusobi na americkem trhu). Jinak na zkousku na intelu doporucuji Pear.
Diky cronin za tento prispevek. <b>
Hluboce verim, ze je to spravny pohled na vec - uzivatele, kteri pouzivaji vase DNS, MAIL, WWW, DHCP atd atp maji na haku jestli pouzivate *BSD, Linux nebo nejaky jiny OS. Proste potrebuji, aby TO fungovalo - tj. aby to bylo dostatecne bezpecne a vy jako admin chcete, abyste administraci dostatecne rozumeli. Vyzkousel jsem [Free|Net|Open]BSD na ruznych strojich a nakonec se vratil k Debian Linux - PROTOZE mu rozumim. Nepochybuju o tom, ze kdybych byval zacal na FreeBSD, vykaslu se na Linuxik. Mam tu vyhodu, ze jsem nezacal na Windows -- ale jestli jsem tomu rozumel dobre - kdybych zacal na Win a dostatecne bych Win rozumel, pak bych asi nemel duvod jen tak prechazet na Linux/BSD. Respektuju volbu nabozenstvi ;-)
Jo, GNU GPL je samozřejmě lepší -- když nemohu přejímat proprietární kód, nevím, proč by to mělo jít naopak.
BSD už prostě svou licenční kauzu mělo -- s AT&T --, u Linuxu právě probíhá -- se SCO. Ostatně SCO vypadá, že si snad nárokuje i ten kód, co je v BSD pod BSD licencí, takže kdyby měli pravdu... ;-)
Pokud chcete zdarma pracovat pro MS, asi už vám není pomoci.
Myslím, že vůbec nechápete, o co tu jde -- tedy o reciprocitu. Dáváte svobodu někomu, kdo kašle na *vaši* svobodu. Tak si to pěkně užijte. K lidem, kteří se nechovají dobře k vám, se můžete chovat dobře jen do určité míry; za tímto bodem se dostáváte do jejich područí a vaše svoboda končí a dobré úmysly obracejí proti vám.
Právě naopak. BSD licence je věc, která mě od jakýchkoli vážných úmyslů s *BSD odrazuje.
GNU GPL == rovnost; a v rámci GPL naprostá svoboda; ostatní kód je prostě mimo a neinteraguje ani tak, ani onak.
BSD licence == feudalismus; vlastníci proprietárního kódu mají nárok používat vaši práci, ale chtít od nich zpět nic nemůžete.
Kromě toho GPL je (stejně jako proprietární licence) atraktor systému, takže boj proti ní je z pozice licence, jež není atraktor, marný a předem prohraný :o)
GNU GPL = rovnost?
To je tedy dost iluzorni. GNU GPL naprosto jednoznacne zadnou rovnost nezarucuje jak jiz praxe nekolikrat ukazala (RedHat, Crossbeam a mnoho dalsich)
Pokud pred nulovou vymahatelnosti prav a v praxi jejich velmi castym porusovanim zavirate oci, je to sice vas problem, ale vypada to smesne.
Ja jsem netvrdil, ze BSD licence je reseni.
Jen mi jednoduse pripada naivni ohanet se, pri prosazovani GPL, argumenty na tema ochrany pred komercnim zneuzitim. Z tohoto pohledu vychazi BSD i GPL prakticky stejne.
A jeste jedna nepresnost ve vasi citaci:
BSD licence == feudalismus; vlastníci proprietárního kódu mají nárok používat vaši práci, ale chtít od nich zpět nic nemůžete.
Jestli nekomu schvalim pouziti meho dila ve smyslu BSD licence, neznamena to, ze jsem jinou moznost nemel. Tzn. jako autor mohu chtit po druhe strane cokoli v mezich zakona. Pak to pochopitelne nemusi byt v souladu s BSD licenci, ale jako autora me to nijak neomezuje, jak se snazite naznacit.
Naopak u GPL jinou moznost nemam.
Ale to prece neni pravda, pokud budu stavet na GPL ale nebudu to distribuovat (tj. vysledek budu budto pouzivat pouze interne ve firme anebo to budu pouzivat pres inet, kde kod pobezi pouze na mych serverech) tak komunite nemusim vubec nic a licenci neporusim. Jediny kdy musim pod GPL zmeny uvolnit je pokud vysledek distribuuju.
Ja som to o nich tiez pocul, ale uz par rokov eksistuje sudne rozhodnutie, ze vsetok kod v BSD (konkretne 4.4BSD-Lite2 tusim) je originalny. Samozrejme SCO moze argumentovat, ze tam bol zaneseny novy kod alebo ze zistili nove skutocnosti a na ich zaklade chcu revidovat povodne rozhodnutie, ale myslim si, ze to bude mat tazke.
Pekna odpoved.
Kazdy nech pouziva to co mu vyhovuje, ale nech sa nestane otrokom toho/ktoreho systemu.
Pouzivame vo firme (aj pre klientov) freebsd od 4.4 a sme/su s tym spokojny.
Problemy na ktore som narazil a nevedel som ich vyriesit (zatial) pod fbsd a pod linuxum ano:
- apcupsd - soft na spravu apc ups nepodporuje pod freebsd novsie usb modely, len seriove....
- onboard raid v serveroch IBM Netfinity 5500 (obsahuje PPC601) nema driver pre fbsd ale pre linux ano
- podpora ACPI je v linuxe dalej...
Celkovo by som rad upozornil na to, ze v tejto diskusii povazuju diskutujuci za vyhodu linuxu to, ze pre neho existuju niektore closed source produkty (java, nvidia, flash) a pre fbsd nie. To je sice pravda, ale nie je to sposobene lepsou/horsou kvalitou linuxu/fbsd ale komercnymi ambiciami dodavatelov tychto produktov. Uz zajtra to moze byt inac...
No, z meho e-mailu je jasne co pouzivam a je to asi hlavne o tom, ze vykon pro me neni to nejdulezitejsi (a myslim, ze pro spoustu lidi). S dnesnim vykonem procesoru mi prijde, ze pokud je neco o nejake drobky pomalejsi (no tak ten mail dojde o ms pozdeji, firewall pro 100 MB udela v pohode PII 200 MHz...), tak to neni duvod proc to zavrhovat. *BSD maji jiny pristup k vyvoji, akceptovani ruznych non-free veci( ruzne takovety ovladace grafickych karet, tusim treba nVidia), ktere nemaji zrojaky, aly my to do toho jadra dame, cimz se paradoxne podporuje cokoliv, jenom ne GNU...
Ale jinak mam stejny nazor - pokud nekomu to jeho vyhovuje, nema s tim problemy, tak proc prechazet na neco jineho. Obcas nekam juknout, zjistit, jak to ci ono delaji jinde apod.
Kdysi jsem taky linux pouzival a duvod, proc jsem presel na OpenBSD nebyl rozhodne vykon, ale to, ze jsem potreboval IPSec (bez ruzneho patchovani, doinstalovavani apod.). No a pak jsem zjistil, ze ty dalsi veci v systemu jsou taky fajn, ze se mi vlastne ten jejich pristup libi mnohem vic, ze ten firewall se s iptables neda srovnat a a a...a pak uz nebylo navratu :o]
A kde je k dispozici dokumentace, podle ktere se da napsat driver ? Neni, takze existuje jen hotovy driver od vyrobce. To, ze se akceptuje a pouziva znamena, ze proste tu svobodu v Linuxu asi tolik nepotrebujeme.
Stejny pripad je cca. rok stary, s novym procesorem od Sunu (UltraSPARC III), nikdo kdo nepodepsal NDA (resp. u Sunu Confidential Disclosure Agreement)proste tu dokumentaci nedostal, takze kdyz je k dispozici podpora tohodle procesoru pro Linux tak to znamena co ? Ze David Miller, ktery tu podporu pro Linux napsal, asi to CDA podepsal nebo se pletu ? A jak se to slucuje se svobodou, kterou hlasa GNU ?
Tak to jsou ale bludy. Jak vite, ze "svobodu nepotrebujeme"? Ja jsem si koupil grafarnu od ATI prave proto, ze k ni jsou open-source drivery. Co se tyce UltraSparc III, neni to tak tragicke soude podle toho ze NetBSD sparc64 mailinglistem probehla zprava ze dokumentace je a kdo chce pomoct s portovanim na UltraSparc III necht se ozve.
Co se Linuxu tyce, proc by melo nekomu vadit, jestli nejaky vyvojar podepsal se Sunem NDA? (A vite vubec ze podepsal?) Dulezite je, ze vysledek je opensource. Pokud vim, i OpenBSD pouziva XFree86, jehoz vyvojari podepisuji NDA s vyrobci grafaren. Stejne tak dokumentace k nejakemu HW (mozna Intel sitovky, uz si nevzpominam) byla vyvojarum NetBSD poskytnuta pod NDA. Jste si jisti ze jste ten driver s NetBSD nikdy nesynchronizovali? Pokud ne, nevadi Vam moznost, ze se do OpenBSD takovy kod dostal?
Jeste k UltraSparc III - nemohlo to nahodou byt tak, ze Theo de Raadt nedokazal o tu dokumentaci pozadat dostatecne diplomatickym zpusobem, tak ho poslali nekam? Podle toho co jsem o nem slysel bych se vubec nedivil.
Vazeny pane, muj dotaz neni arogantni, mozna spise strohy, za coz se omlouvam ... aby nedoslo k omylu, ja uznavam *bsd systemy, jen me zajimalo co opravdu ma ten firewall nebo spise packed filter tak super, ze je lepsi nez iptables ...
Podle meho nazoru je iptables docela dobre vymyslene i vcetne ovladani - me to lepe sedne nez ovladani pf z openbsd, ale to je asi opravdu jen otazka zvyku. Musim uznat, ze nektere features z pf se me libi a pokud vim, tak v iptables nejsou ... ale na druhou stranu je dobre se podivat na stranky netfilteru a mrknou na patche od tretich stran - docela jsem se divil a myslim, ze nektere jsou opravdu "cool".
Myslim, ze nepr. ohledne QOS je na tom linux o trochu lepe, i kdyz ovladani bude asi lepsi v *bsd.
...tak tady si musim na FreeBSD opravdu postezovat. Co se tyka napr. deleni toku dat na lince, tak FreeBSD umi jenom CBQ (nikoli HTB) a to se tam jeste musi patchovat, pokud si dobre pamatuju. Navic je to implementovane do ovladace sitove karty, takze na nekterych sitovkach to jde a na nekterych proste ne. (Toto je stav z verze 5.0, mozna uz je to lepsi.)
Pro sitovy operacni system mi to prijde jako velky nedostatek.
FreeBSD dokaze nielen CBQ, napriklad HFSC, co zasa myslim nezvlada Linux. (Myslim, ze aj nejake ine, ale ja pouzivam takmer vyhradne HFSC, zriedka CBQ, PriQ alebo WFQ, ine nie.) Na druhej strane vsak mate pravdu s HTB, vo verzii 5.2 aj s patchovanim a ovladacmi sietovych kariet. (Sice som este nenarazil na sietovku, co by nebola zahrnuta, ale to nic neznamena.)
Tolko k altq. FreeBSD ma na shaping/QoS (zakladny) aj dummynet, ale tento u nas vo firme sa pri rychlosti radovo desiatky Mb (agregovanej) zacinal spravat velmi cudne, cize by som ho prilis neodporucal. Navyse altq ponuka viac moznosti.
Co sa tyka samotneho patchovania, stale pocuvam o samych patchoch na Linux pre tu a tu vlastnost, tak by som to nevidel az tak cierne. Ale detailne porovnavat nemozem, pretoze s Linuxom moc nerobim.
neco umi navic a neco ne. me se napriklad vice libi syntaxe IPWF/IPF/PF, ktera se podle me vice podoba klasicke anglictine nez zmeti prepinacu, ale je to vec nazoru. OpenBSD ma zase velice zajimavou ficurku - CARP - coz je protokol pro predavani si "stavovych" dat mezi firewally, coz je velmi vyhodne, pokud mate rekneme 2 firewally a potrebujete jeden z nich updateovat a nechcete zpusobit vypadek site(nebo jednotlivych spojeni). v pripade vypadku to totiz jeden firewall prevezme za druhy. vyhodou IPF (v OBSD nahrazen z licencnich duvodu PF) je jeho prenositelnost viz. http://coombs.anu.edu.au/~avalon/ slysel jsem cosi dokonce o zamerech autora portovat IPF na Linux, coz by bylo zajimave porovnani;-) .. nevite o tom nekdo neco?
Add CARP - neni to jenom na firewaly, CARP je Common Address Redundancy Protocol, muze se jednat treba o cluster web serveru,mail serveru nebo tak neco, proste sdili jednu IP adresu a ruzne se monitoruji. Stroju muze byt 2+, teoreticky az 255 a mohou to byt ruzne platformy treba. U tech fw treba 4 stroje 2 SPARC, jeden AMD a jeden i386 budou tvorit cluster.
CARP vznikl jako odezva na VRRP. Na VRRP, resp. HSRP ma patent Cisco, takze to se implementovat nemohlo, takze vymysleli trochu jiny mechanizmus HA a nazvali ho CARP.
Jo a je fakt, ze pad/upgrade toho jednoho fw se siti nic neudela, firewally si synchronizuji tabulku navazanych spojeni.
Add portovatelnost IPF - o tom nevim, ale vim, ze jak NetBSD tak i FreeBSD na ruznych urovnich importuji pf jako dalsi jejich dalsi firewall.
Precti si tohle http://www.openbsd.org/lyrics.html sloupec vlevo. Pokud nenkdy nekdo z Kiska bude mit pocit, ze jim nekde utekly penizky nebo ze je zrrovna taohle ohrozuje, pekne pockaji par let a pak se treba budou soudit. Nejde o to, ze by to neslo naprogramovat, ale o to, ze pokud je to kryte patentem, tak neni dobre to udelat, prave diky vyse uvedenym duvodum.
K tej portovatelnosti len tolkoto:
- PF je sucastou OpenBSD od (tusim) 3.0, FreeBSD-CURRENT (v 5.x funguje ako port), asi sa robi aj port na NetBSD, ale detily neviem,
- IPF je sucastou Free- a NetBSD (uz dost dlho), funguje vraj aj na Solarise, OpenBSD, HP-UXe, Tru64 a tusim je aj alpha verzia pre Linux.
Takze je asi jasne, ktory momentalne podporuje viac platform. Na druhej strane, PF ma o dost viac vlastnosti ako IPF 3.x, neviete niekto, ako je na tom novy IPF 4?
A zacina flamewar...
Tak kdyz o tom vsude slysite, tak proc si o tom neco neprecist nebo to nezkusit ?
Podivejte se sem http://www.openbsd.org/faq/pf/index.html, to jak to vypada a co to umi.
Velmi zkratka a rychle - syntax mi prijde mnohem snazsi ke cteni, kontroluje i platny rozsah sequence numbers (iptables asi taky s tusim tcp-window-tracking-patch ale nejsem si jisty) vyborna vychytavka jsou tables (pro ukladani velkeho mnozstvi adres s rychlem lookupem, mam spam tabulku s 4000+ adresami), makra, seznamy, logovani v pcap formatu, load-balancing pro odchozi/prichozi spojeni (mezi vice web servery, resp. mezi vice ISP), vyborne navrzena useland utilita pro ovladani, queueing, od verze 3.5 failover mezi vice firewaly, dobre moznosti pro accounting atp.
Mne to vyhovuje lip, abych nekoho presvedcoval, z toho uz jsem vyrostl...
Prijdte na tu konferenci Unix-Linux Security, mam tam o pf prednasku, tak musem dat rec.
Jak jsem psal na jinem miste, me se spise libi ovladani iptables - je totiz pomerne logicke a i prepinace jsou lehce k zapamatovani (--sport, --dport, apod.). Nektere chybejici vlastnosti iptables lze zaplacnout patchema ... jak tady nekdo jiz rikal patch&go, treba takovy scrub v pf se me docela libi a nevidel jsem zadny podobny patch pro iptables, ale co neni muze byt. Routovani na bazi pravidel ve firewallu lze take {ale asi sloziteji) ... no abych to shrnul, pokud iptables bude mit v budoucnu scrub, tak myslim, ze neni moc velky rozdil oproti pf. A abych si i trochu rejpnul, tak si myslim, ze podpora QOSu je lepsi na linuxu.
:o] rejpat klido muzes. Me zase prijde srozumitelnejsi pf konfigurace, ale jak sam rikas, je to otazka zvyku.
S tim patchovanim - ok, proc ne, ale proc ? Proc to neni v defaultnim netfilteru ? Nekdo tomu neveri ? Neni to odzkousene ? Ja si takhle nic modifikovat nechci, pf nijak zaplatovat nemusim, aby umel to co chci.
hmm., no patchovat se proste musi :-) Porad neco patchuju, tak jsem na to zvykly ... MPPE, pppd, sitovy drivery, vlastne ani nevim proc se na ten linux nevykaslu, ale asi to bude tim, ze jsem na nej zvykly. Prece neprejdu hned ke konkurenci, kdyz neco nejde. Vlastne i GPL je sympaticka, no. Jinak trochu zavidim *bsd ucelenost "distribuce" a konfiguracnich utilit. Linux je zase silnejsi v SMP, FS, apod. Zda-se, ze se posledni dobou Linus a spol. trochu pochlapili, takze nas cekaji svetle zitrky ... :-)
" ... momentální poslední stabilní verze je 4.9 ..."
"Date: Thu, 27 May 2004 01:35:03 -0400
From: Ken Smith <kensmith@FreeBSD.org>
To: freebsd-announce@FreeBSD.org
Subject: FreeBSD 4.10-RELEASE is now available
I am happy to announce the availability of FreeBSD 4.10-RELEASE, the latest release of the FreeBSD -STABLE development branch. ...."
;-)
mno pokud se nekdy java ocitne jako open ,tak zkonci. Vyhoda javy je dneska jeji jednotny tvar ,kdy se v zasade muzete spolehnout na to jak dane veci fuguji. Nedobrym prikladem je trebas Mono ve kterem se dneska neda psat. Budete chtit psat projektik pod C# a neustale se musite ohlizet jake omezeni mono ma.....
No hovorite tu o Jave, ale podme na praktickejsiu vec. Skuste si niekto porovnat vykon Mysql so zakompilovanymi linux threads a bez nich a uvidite ten rozdiel. Samozrejme pisem o 4.9 ktora je momentalne st
abilna a nie o 5.x verziach FreeBSD. Cize dalsia vec kde treba mat nainstalovanu tu takzvanu emulaciu linuxu. :-)
jj to ale uz bude neco o jadru :) jinak v 5.x se to jmenuje uz jinak.
ohledne te javy, zkuste toto: http://www.freebsdfoundation.org/downloads/java.shtml
emulace linuxu? no bsd systemy maji proste v sobe podporu emulace jinych os, napr. linux, system v atd. zadny vmware nepotrebujete :)
www.freebsd.cz nebylo v lincich? :)
vmware je o niecom inom, ABI je AFAIK len urcita medzivrstva, ktora preklada syscally, signaly a podobne veci medzi jadrom a procesom z Linuxovych standardov do (Free|Net|Open)BSDckovych. V principe by mali Linuxove binarky bezat (aj bezia) viac-menej rovnakov rychlostou ako nativne, bohuzial vsak niektore vlastnosti Linuxu nie su celkom dopracovane, napr. linprocfs. (Na ten som narazil pri pokuse spustit NODa.)
Samozrejme, ABI eksistuju aj pre programy pre ine OS ako Linux, napr. SunOS, Ultrix... (Zavisi od HW platformy.)
mnoo.. AFAIK ;}.. to neni zadne prekladani syscallu, signalu apod do standardov BSD, ale primo provadeni tech syscallu jako ten onen system.. pozna se to podle magic zacatku souboru, kt si oznacim treba -> toto spust s linux.ABI (brandelf -t Linux /pro/gram), toto treba se foo.ABI... ten preklad, to by byla spise emulace, ale tohle emulace neni.. je to oznacovano zpusobem jako 'linuxovy rezim (mode)', protoze se proto nehodi zadne jine pojmenovani.. zkratka jako by byl v jadre dalsi OS.. btw. u odlisnych HW platforem (treba 32bit vs 64bit) se to samozrejme musi emulovat..
Tyhle dve vety jsou moc hezke: "Stojíte sami proti různým druhům útočníků. Rozhodně se vyplatí být obezřetný." :-)
Ale k veci: (1) Jak pomuze bezpecnosti to, ze behem instalace nevytvorim uzivatele? (samozrejme ze ne s prazdnym heslem a podobne)
(2) kdyz je "range: -1..3", jak muzu nastavit -2? (navic -1 je "most insecure" tak proc -2 je Extreme secure?)
(3) bezpecnost fyzickeho pristupu nema co spolecneho s OS a je tu nastinena tak hrube ze by mozna bylo lepsi neuvadet vubec
(4) /etc/ttys a rust problemu jsem bohuzel nepochopil, vysvetli mi to nekdo? Zda se mi to dost divne napsane a taky ten prechod k zavadeci...
(5) nutnost prihlasovani uzivatel->superuzivatel na systemove konzoli (fyzicky pristup) resi co?
(6) "kompletne sifrovany system" ? asi sifrovany souborovy system, ne?
(7) omezenim platnosti hesla na 90 dnu se bezpecnost zrejme nezvysi, pokud mate opacny nazor, muzete ho podlozit? (vemte v potaz zname argumenty meho nazoru)
(8) misto "urcime jim" ohledne limitu uzivatelu patri spise "je mozno jim urcit", protoze ne vsechny uzivatele je radno omezovat (v zavislosti na tom co/koho predstavuji, zamereni stroje atd.) (btw. pokud chci vzdalene pristupny paketovy filter tak tam moc uzivatelu asi nebude:-)
(9) prijde mi to moc hrr, hrr, asi bych dal prednost rozebrani kdy co a proc je treba udelat a jake to ma dopady na bezpecnost a ostatni veci, holt jsem asi moc narocny
narocny asi jsi :)
1) muzes samozrejme, ale v ramci dalsich veci jsem chtel nejdrive udelat "sablony" pomoci login.conf - samozrejme ze to jde i potom
2) bud prudis naschval nebo ti to uniklo. ano -2 JE PREKLEP v textu ale v prikladu je to spravne.
3) pruda
4) viz single-user-rezim
5) prudis?
6) presne
7) muze to byt diskutabilni
8) proc? treba nekdo nebude mit doma dalsi oddeleny fw...
9) prijde ti to hrrr? tak navstiv odkazy nahore nebo si kup jen na toto tema knihu... neni to o postupem proti crackingu
cest. mam fakt debilni naladu :( smrt :)
(1) ptal jsem se jak to pomuze bezpecnosti ne jestli ho muzu vytvorit, precti si tu otazku jeste jednou
(2) proc tu chybu neopravis kdyz o ni vis? Nebyla to pruda, je to chaos kdyz je to tam i tam jinak.
(3) upozorneni na chybu (klidne to nazyvej pruda)
(4) sorry, porad nechapu co to ma spolecne s "narustem" rizika a tech nekolik odstavcu mi moc smyslu nedava. "viz single-user" mi nepomohlo
(5) ptam se, co jsi vyresil tim, ze na systemove konzoli (pri fyzickem pristupu) je nutno hlasit se prvne na uzivatele a az potom na superuzivatele. Pokud sam vidis ze jsi napsal blbost tak to prepis/omluv se a nenazyvej to pruda.
(6) tak bud te lasky a sprav to
(7) a to je podlozeni nazoru? ("muze to byt diskuktabilni")
(8) "...nebude mit doma dalsi oddeleny fw" ... ten clanek byl o tom jak vyresit domaci sit? A proc je cilem _zabezpeceny_ paketovy filter? A co kdyz treba bude? A co kdyz to ctou lidi co to nechteji udelat doma? A co kdyz...
(9) no comment
Jinak se svym stylem bavis? Ja na tebe neutocim, jenom mluvim o vecech ktere se mi zdaly nepresne nebo spatne aby o tom vedeli i ostatni.
Popripade, jestli to chapu spatne tak mi to vysvetli, ale rozumne protoze jinak >/dev/null
Myslite tim heslo ve formatu blowfish, dobu zmeny 90 a case? (umask se da asi uzivatelsky zmenit v rc souborech, delka hesla byla takova jakou chtel superuzivatel (uzivatele tvoril a heslo zadaval on), definice trid a omezeni zrejme nemusi byt hotova pred pridanim uzivatele protoze se zmeny musi projevovat i na existujicich uzivatelich a navic viz nize).
Je to s vysokou pravdepodobnosti uzivatel ktery bude pouzivan superuzivatelem k delani beznych veci v systemu. Superuzivatel zrejme musi zmenit jiz svoje heslo do formatu blowfish, takze tak udela krome sebe i u uzivatele pridaneho pri instalaci. Dobu zmeny hesla neuvazuji, nebot se zrejme jedna o uzivatele pouzivaneho superuzivatelem (pokud chce, muze si to nastavit) a case senzitive bude menit i sobe (jako superuzivateli), takze to zmeni i sobe jako uzivateli.
Omlouvam se za spatne formulovanou otazku, melo to znit: "Jak pomuze bezpecnosti nepridani uzivatele ktery bude pouzivam superuzivatelem pro beznou praci v systemu?"
Myslim si ze bezpenosti nepomuze nepridavani jakehokoliv uzivatele, muze to jen pridat adminovi par radku navic pri zmenach na tom danem uzivateli. Ani me nenapadlo ze by takto nejaky admin pridaval klasickeho uzivatele (pro bezne uzivatele bude mit pravdepodobne nejaky centralni system spravy a na fw jim pristup stejne asi neda). To uz ale motam dohromady nekolik ruznych veci, takze radsi stop.
omlouvam se spatne jsem to formuloval. nepomuzeto, primo, bezpecnosti, ale pomuze to adminovi, protoze nebude muset zpetne opravovat master.passwd.
myslim si ze clanek nemel v umyslu nekomu vnucovat autorovi vzite metody, ale pouze nastinit mozna reseni a pouzil k tomu postupy ktere sam pouziva. ja sam nektere veci resim jinak (a nehodlam to menit, jen proto ze sem si to ted precetl), ale clanek me celkem obohatil.
7, pokud budu pouzivat cely zivot jedno heslo (presto ze bude super), tak:
....a, zestarne - brute force attack ho casem rozlouskne. jako admin bych si toho mel vsimnout, ze se nekdo casto marne pokousi prihlasit, ale u >200 usivatelu se to ztrati.
....b, okouka se
....c, proflakne se jinym zpusobem - uzivatel ho pouzije na stroji se zberacem hesel, sam byl infikovan trojanem, atp.
8-9, myslim ze je zcela na autorovi clanku, jakym zpusobem clanek pojme. a pochopitelne je na 'citateli' jak clanek /ne/pochopi. me osobne se clanek velmi libil a tesim se na dalsi pokracovani.
Jedno heslo cely zivot -- to asi ne, bavime se o vynucovani zmeny hesla na (vsech) uzivatelich co 90 dnu (nebo drive).
brute force attack --> samozrejme se bere v uvahu jenze -- protiargument: vynucovanym stridanim hesel se docili:
(a) uzivatele jsou nachylnejsi (casem) k volbe "jednoduchych" hesel, protoze si musi kazdou periodu pamatovat jine. Nekteri jsou takovi samozrejme "od prirody", ty nezmeni nic.
(b) uzivatel ma sklon si heslo zapsat na papir, protoze si musi kazdou periodu pamatovat heslo jine ==> jina moznost utoku
(1) Meneni hesla != bezpecnost pred brute-force utokem. Kdo zaruci ze nove heslo bude v utokem jiz prozkoumanem prostoru hesel
(2) Brute-force utok primo na prihlasovani je ve vetsine systemu nemozny (diky vynucene prodleve mezi prihlasenimi) a da se velice jednoduse detekovat -- nesouhlasim s tim ze "se to ztrati" -- samozrejme predpokladam automaticke monitorovani neuspesnych pokusu a upozornovani admina, ne s tim ze by na to prisel sam uzivatel
(3) Brute-force utok pri znalosti zakryptovane podoby hesla je efektivnejsi, jenze tuto podobu hesla je nejdrive treba ziskat a toto je asi jediny typ utoku ktery je "realizovatelnejsi" pri stejnem hesle nez pri meneni hesel
- okouka se? (jako ze se uzivateli nekdo pravidelne diva pres rameno?) To je samozrejme mozne (u bezneho uzivatele), ovsem pokud je nekdo schopen okoukat heslo za rok, je toho s vysokou pravdepodobnosti schopen i za 3 mesice.
- proflakne se? Jaky je rozdil mezi tim kdyz se proflakne stale (rozumej: uzivatel si ho zmeni kdy chce) heslo a heslo na periodu (90 dni)? Kdyz se opravdu "proflakne" (sberac hesel, trojan), tak je prece zneuzito temer okamzite nebo ne?
Argumentem (klasickym) ktery beru je zestarnuti, ale pouze pri prozrazeni zakryptovane podoby hesla. Toto riziko lze celkem minimalizovat a myslim ze je akceptovatelnejsi nez rizika spojena s vynucenou zmenou hesla.
jak napsal autor clanku, je to diskutabilni. ja sam nejsem zastancem vynucovani zmeny hesel (vetsi duraz kladu na generovani kvalitnich hesel, nepodlehajicim slovnikovym utokum). pouze jsem uvedl par prikladu, ktere me okamzite napadli, ktere mluvi ve prospech vynucovani zmeny hesla.
1, souhlasim ze caste vynucovani vede k slabnuti nejen hesla jako takoveho, ale i obezretnosti uzivatele.
2, brute force attack jsem pochopitelne uvazoval i v pripade ukradeneho master.passwd. kde vynuceni opravdu muze pomoci.
3, trojan sebere hesla, ale sam nemusi vedet co s nimi, bud je preda tvurci, ktery se za pul roku dostane k zajimavemu pristupu a nebo jej prida do slovniku ( a jsme zpet u starnuti :))
4, nesouhlasim s tim ze neni rozdil mezi 1/4 a celym rokem. kdyz budu cely rok poslouchat dynamiku uderu na klavesnici + sem tam zahlidnu rozlozeni prstu na klavesnici, tak mam temer vyhrano. s castou zmenou hesla bude uzivatel stale tapat a dynamika uderu bude chaoticka a nepruhldna
(1) Neni mi jasne jak vede vynucovani zmeny hesla k obezretnosti uzivatele.
(2) Jenze to mate predpoklad ze se jiz povedlo prekonat jeden bezpecnostni mechanismus (nepristupnost zasifrovanych hesel). Pokud se tento mechanismus neprekona tak je naopak jednodussi brute-force utok pri vynucovane zmene hesla! (hesla jsou tak vetsinou slabsi a urcite vite ze brute-force se ze zacatku pokusi uhadnout "pravdepodobnejsi" (jednoducha) hesla a ne ze generuje hned vsechny moznosti.)
Cili: Za normalnich okolnosti (hesla jsou skryta) je (vetsinou, zalezi samozrejme jak na koho) utok na menena hesla jednodussi. Pri ziskani sifrovane podoby hesla je jednodussi zjistit heslo pri prilezitostne menenem hesle nez pri pravidelnem. Jednou na jednu stranu, podruhe (pri selhani bezpecnostniho mechanismu!) na druhou. Nevyplyva mi z toho, ze brute-force utok je jednodussi na "stala" hesla.
(3) pri takovemto pristupu ano, ale to neni jediny pristup a pokud mam podezdreni ze doslo k vyzrazeni hesla tak si ho zmenim. Samotnemu vyzrazeni hesla nedokaze vynucovani zmeny hesla zabranit, pouze nekdy jeho nasledkum. Navic nezapomente, ze u hesel ktera se casto meni je nebezpeci vyzrazeni vyssi (uzivatelum se hesla neustale meni, musi si porad pamatovat neco jineho, takze si je napisi na papir...)
(4) mluvite o jednom jedinem scenari a nezapomente ze neuspesne pokusy je velice jednoduche sledovat (jak ze strany uzivatele ktery vidi kdy mel posledni neuspesny pokus o prihlaseni a jednak ze strany automatickeho dohledu ktery tyto neuspesne pokusy muze porovnavat s pritomnosti pracovnika v budove/na pracovisti (pokud mluvite o dynamice uderu na klavesnici je treba si uvedomit ze se to tyka jedne klavesnice -- osobniho pristupu atd.)) Nezavrhuji to, jen upozornuji ze se jedna o velice uzky okraj pripadu a v drtive vetsine pripadu se tomu da jeste predejit nebo to odhalit pri neuspesnem pokusu (pokusech) nebo alespon dodatecne.
(4b) s castou zmenou hesel bude vetsina uzivatelu nove heslo psat ze zacatku pomaleji coz je na odkoukani/odposlechnuti mnohem jednodussi.
Navic vam staci ziskat _stara_ uzivatelova hesla (nekam si je pise a vzdy si to aktualni hlida ale ty stare vyhazuje do kose) a uz muzete odhadovat jake heslo si dal tentokrat. Rekl bych ze tim vyznamne snizite prohledavany prostor a tim zvysite sance uhodnuti nebo treba brute-force utoku :-)
je velmi tezke obajovat nazor, ktery sam nezdilim :)
1, sam si na to v dalsich bodech odpovidate :)) (pisou si heslo na papirky, bezskrupuli ho prozradi kolegovi, kdyz se ten potrebuje prihlasit na jeho pocitac, nemaji potrebu zmenit heslo, kdyz maji podezreni z jeho vyzrazeni... proste si pockaji az je system sam vyzve...)
2, to ze by se master.passwd "nemel" dostat do cizich rukou, neznamena ze se tam nedostane... bez adminova vedomi.
3, tady opet podporujete muj proti argument (1).
nadruhou stranu jsou uzivatele kteri si heslo sami nezmeni, ani kdyz se dozvedi o jeho prozrazeni, natoz pak pri pohem podezreni.
4, nemam v umyslu Vam vnucovat tuto metodu ani ji sam nasazovat, pouze jsem chtel podporit myslenku autora clanku, ze se jedna o diskutabilni tema. nikoli o axiom (vynuceni zmeny hesla == spatny || dobry)
4a, dynamika uderu je patrna prave pri perfektni znalosti hesla, protze v tom okamziku je chyba (zavahani) zanedbatelna a jedna se ciste o mechanicky limitovane zpezdeni mezi jednotlivymi udery... je jasneji "slyset" kdy byl zmacknuty shift a jak daleko od sebe jsou jednotlive klavesy. pokud uzivatel pise obema rukama da se z dynamicky usoudit jestli po sobe jsouci klavesy jsou ze stejne strany klavesnice, atd, atd...
(1) To ze si uziv. pise heslo na papirek a prozradi ho kolegovi je obezretnost? To je uplny opak obezretnosti! Krasne jste to podporil, dekuji :-)
(2) Samozrejme ze ne, ale o nemoznosti jsem se vubec nevyjadroval, porovnaval jsem moznosti.
(3) Nepodporuji, konstatuji. "...u hesel ktera se casto meni je nebezpeci vyzrazeni vyssi" mi nepripada jako podpora vasich argumentu.
(4) Netvrdim ze to je axiom, ostatne prave k debate jsem vyzval (a misto argumentu jsem videl "je to diskutabilni")
(4a) o tom diskutovat nebudu, protoze se mi jeste zadne heslo "odposlechnout" nepodarilo :-) (nekladte mi ale prosim do "ust" ze to vylucuji)
Uz mi to neprijde moc prinosne, bavit se o tom co kdo rekl nebo nerekl a z arumentu delat protiargumenty je celkem k nicemu, mozna bychom si meli pred kazdym dalsim prispevkem precist vzdy cely thread, vzdyt je to tady napsane.
zda se ze me spatne chapete.
1, ano bod jedna je temer od zacatku v NEPROSPECH CastychZmenHesla. psal jsem:
>>1, souhlasim ze caste vynucovani
>> vede k slabnuti nejen hesla jako
>> takoveho, ale i obezretnosti
>> uzivatele.
tz. rikam ze CZH vede k slabnuti hesla/obezretnosti, na to jste se me ptal proc obezretnosti... odpovedel jsem a mam znova na taliri ze ZCH je blbost a at si to po sobe prectu... znovu opakuji ze nejsem pro CZH, ale pouze chapu cizi pohnutky... uvadim argumenty pro i proti, zatimco Vy pouze ty proti... ktere respektuji.
2, pouze jsem uvadel jednu z moznych cest kde by CZH byla prospesna.
3, podporil jste muj argument (proti CZH) a to ze CZH oslabuje obezretnost uzivatele.
4, nejsem autor clanku ani nezastavam nazor ze CZH je vselek... ale vzhledem k tomu ze diskutujeme, tak se zda ze jeho tvrzeni bylo pravdive :)
4a, ok
mam nainstalovane FreeBSD 4.9 RELEASE a chcem vediet ako na bezpecnostne updaty systemu a jadra. zaujima ma najrychlejsi a co najmenej rizikovy sposob, povedzme ze sa jedna o produkcne nasadenie. v handbooku som nic konkretne k tomu nenasiel, mozno som nieco prehliadol. zatial si to predstavujem nasledovne (podla prekladu knihy Absolute FreeBSD...):
1) skopirujem a editujem standart-supfile, riadok
*default release=cvs tag=RELENG_4_9
+ dalsie potrebne veci (server, zoznam src-*, povedzme ze chcem src-all)
2) stiahnem/updatujem zdrojaky:
# cvsup supfile
3) necham zostavit:
# cd /usr/src
# make buildworld
4) obdobne zostavenie a nainstalovanie jadra:
# make buildkernel
# make installkernel
5) v jednouzivatelskom rezime nainstalujem zostaveny system:
# cd /usr/src
# make installworld
6) zmeny v /etc a /dev ...
ale teraz zistujem, ze by som asi upgradoval cely system. akym sposobom zazaplatujem bezpecnostne diery (povedzme chybu v sshd) a bugy bez kompilacie celeho systemu?
momentalne mam na serveroch Slackware, upozornenia na bezpecnostne updaty su posielane s linkami na stiahnutie opravenych balickov, staci ich stiahnut a prikazom "upgradepkg balik.tgz" updatovat, bez potreby kompilacie inych casti, alebo dokonca celeho systemu.
mozete prosim uviest aspon nejaku linku, kde by bola tato problematika rozobrana, aby som mohol slack a freebsd porovnat z tohto pohladu?
clanok sa mi velmi pacil a tesim sa na pokracovanie.
make buildworld && make installworld zajisti instalalci vsech binarek ktere jsou soucasti systemu (/bin /sbin /usr/bin /usr/sbin ...), ze zdrojovych kodu umystenych v /usr/src/... takze pokud tam mate cerstve zdrojaky, napriklad po `make update`, tak mate "zaplatovane" napriklad i /usr/sbin/sshd
bez nutnosti kompilace celeho systemu, je cesta sice delsi ale zato mene pohodlna:
1, najit si nekde (nebo si sam vytvorit distribuci stable binarek)
2, odtud stahnout vsechny soubory z adresare bin, vsechny soubory z adresare crypto, mateli zajem o aktualni man, tak vsechny soubory z adresare manpages a konecne pokud se nespokojite s generickym kernelem, take src/ssys* a src/install.sh. doporucuji stahnout do oddelenych adresaru, protoze kazdy obsahuje soubory se stejnym jmenem (minimalne install.sh a CHECKSUM.MD5).
3, spustit prislusny install.sh pro kazdou skupinu.
4, obnovit ze zalohy /usr/src/sys/i386/conf/MYKERNEL, zkompilovat kernel
5, obnovit ze zalohy /etc/*...
6, restartovat.
body 4 az 6 musite pochopitelne delat i pri make installworld.
upgrade /z vlastni zkusenosti/ jde delat i na dalku, jen je treba si dat vetsi pozor. doporucuji pred restartem restartovat sshd a zkusit si prihlasit. nede mezi verzi 4.6 a 4.8 je pridan do master.passwd uzivatel sshd a bez nej sshcko nenabehne, je pak celkem obtizne, nekomu v zahranici vysvetlovat jak se prihlasi v jednouzivatelskym modu a jak pomoci vi neco jineho zedituje... o mount -w / ani nemluve
A kde presne muzu nastavit minimalni vek hesla a jak dlouha bude historie? Protoze pokud tyhle dve veci nemuzu nastavit tak mi je prd platny ze dam uzivatelum maximalni zivotnost hesla kdyz jim nic nebude branit si to zmenit na neco novyho a ihned zpatky na to heslo co meli predtim. Proto kazdy slusny bezpecny system umoznuje nastavit i minimalni dobu po kterou heslo uzivatel menit nemuze a kolik hesel si system bude pamatovat aby uzivatel nestridal dve nebo tri hesla porad dokola.
Zdravim vsechny pritomne...
vim ze to sem asi urcite nepatri...
Potrebuji sehnat nejakeho dobrodince, ktery by byl ochoten (treba za uplatu) nainstalovat router pro sit. (pozadavky: proxy, mail, ftp, web, QoS, omezovani rychlosti, pocitani dat a statistiky ovladane prez web...)
piste na icq: 167160292...
predem moc dekuju a omlouvam se ze tu otravuju