diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index cdc2bc4348..e5135af596 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -1,4571 +1,4558 @@ Joseph J. Barbish Írta: Brad Davis SGML formátumúra alakította és aktualizálta: Tûzfalak tûzfalak biztonság tûzfalak Bevezetés A tûzfalakkal a rendszerünkön keresztülfolyó bejövõ és kimenõ forgalmat tudjuk szûrni. A tûzfalak egy vagy több szabályrendszer alapján vizsgálják az éppen érkezõ vagy távozó hálózati csomagokat, és vagy továbbengedik ezeket vagy megállítják. A tûzfalak szabályai a csomagok egy vagy több jellemzõjét veszik szemügyre, amelyek lehetnek például a protokoll típusa, a forrás vagy cél hálózati címe, esetleg a forrás- vagy a célport. A tûzfalak jelentõs mértékben képesek gyarapítani egy gép vagy egy hálózat védelmét. Leginkább a következõkre tudjuk felhasználni: A belsõ hálózatunkban futó alkalmazások, szolgáltatások, gépek megvédésére és elszigetelésére az internetrõl érkezõ nem kívánt forgalom ellen A belsõ hálózatban levõ gépek elérését tudjuk korlátozni vagy letiltani az interneten elérhetõ szolgáltatások felé A hálózati címfordítás (Network Address Translation, NAT) beállításához, ahol a belsõ hálózatunk privát IP-címeket használnak és egy közös kapcsolaton keresztül érik el az internetet (egyetlen IP-címmel, vagy pedig automatikusan kiosztott publikus címekkel). A fejezet elolvasása során megismerjük: hogyan adjuk meg helyesen a csomagok szûrését leíró szabályokat; a &os;-be épített tûzfalak közti különbségeket; hogyan állítsuk be és használjuk az OpenBSD PF tûzfalát; hogyan állítsuk be és használjuk az IPFILTER tûzfalat; hogyan állítsuk be és használjuk az IPFW tûzfalat. A fejezet elolvasása elõtt ajánlott: a &os;-hez és az internethez kötõdõ alapvetõ fogalmak ismerete. Röviden a tûzfalakról tûzfalak szabályrendszerei A tûzfalak szabályrendszereit alapvetõen kétféleképpen tudjuk összeállítani: inkluzív, vagyis megengedõ, illetve exkluzív vagyis kizáró módon. Az exkluzív tûzfalak minden forgalmat átengednek, amirõl nem rendelkeznek a tûzfal szabályai. Az inkluzív tûzfalak ennek pontosan az ellenkezõjét teszik. Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. - Az inkluzív tûzfalak általában - biztonságosabbak az exkluzív - társaiknál, mivel esetükben jelentõs - mértékben visszaszorul a nem kívánatos - átfolyó forgalom. + Az inkluzív tûzfalak alkalmazásával + sokkal jobban kezünkbentudjuk tartani a + hálózatunk kimenõ forgalmát, + ezért leginkább az internetes + szolgáltatásokat futtató rendszerek + esetében bizonyulhat jobb választásnak. + Emellett az internetrõl a hálózatunk + felé irányuló forgalmat is képes + szabályozni. Ekkor az egyetlen szabályra sem + illeszkedõ csomagokat egyszerûen eldobjuk és + naplózzuk. Az inkluzív tûzfalak + általában biztonságosabbak az exkluzív + típusú társaiknál, mivel + esetükben jelentõs mértékben visszaszorul + a nem kívánatos átfolyó + forgalom. + + + Hacsak nem emeljük ki külön, a fejezet + további részében minden + példaként megadott szabályrendszer + inkluzív tûzfalat hoz létre. + Ez a típusú védelem még - tovább fokozható az állapottartó - tûzfalak (stateful firewall) - használatával. Ilyenkor a tûzfal szemmel - tartja a rajta keresztül megnyitott kapcsolatokat, és - vagy csak a már meglevõ kapcsolathoz tartozó - forgalmat engedi át, vagy nyit egy újat. Az + tovább fokozható az + állapottartó tûzfalak (stateful + firewall) használatával. Az ilyen + típusú tûzfalak szemmel tartják a rajtuk + keresztül megnyitott kapcsolatokat, és vagy csak a + már meglevõ kapcsolathoz tartozó forgalmat + engedik át vagy nyitnak egy újat. Az állapottartó tûzfalak hátránya, hogy a Denial of Service (DoS) típusú támadásokkal szemben sokkal sérülékenyebbek olyan helyzetekben, amikor az új kapcsolatok nagyon gyorsan jönnek létre. A legtöbb tûzfal esetében azonban tudjuk vegyíteni az állapottartó és nem állapottartó viselkedést, és ezzel egy ideális beállítást kialakítani. Tûzfalak A &os; alaprendszerébe három különbözõ tûzfalat építettek be, melyek a következõk: az IPFILTER (másik nevén IPF), az IPFIREWALL (más néven IPFW) és az OpenBSD csomagszûrõje (Packet Filter, azaz PF). A forgalom szabályozására (vagyis alapvetõen a sávszélesség kihasználtságának vezérlésére) a &os; két beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ - a PF partnere. Az IPFILTER - esetében maga az IPFILTER végzi a - címfordítást és a szûrést, - a sávszélességet pedig az + a PF partnere. Az IPFILTER esetében + maga az IPFILTER végzi a címfordítást + és a szûrést, a + sávszélességet pedig az IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az IPFW és a PF szabályokkal rendelkezik a rendszerünkbe érkezõ vagy onnan távozó csomagokról, habár megoldásaik teljesen máshogy mûködnek és a szabályok megadási módja is eltér. A &os; azért tartalmaz egyszerre ennyiféle tûzfalat, mert az emberek elvárásai és igényei eltérnek. Egyikük sem tekinthetõ a legjobbnak. A szerzõ egyébként az IPFILTER megoldását részesíti elõnyben, mivel egy hálózati címfordítást alkalmazó környezetben sokkal könnyebb vele megfogalmazni az állapottartó szabályokat, valamint tartalmaz egy beépített FTP proxyt is, amivel így a kimenõ FTP kapcsolatok beállítása még tovább egyszerûsödik. Mivel az összes tûzfal a csomagok fejlécének bizonyos mezõinek alapján dolgozik, ezért a tûzfal szabályrendszerét megalkotó egyénnek - teljesen tisztában kell lennie a - TCP/IP + teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják egy átlagos kapcsolat alatt. Ebben a témában a címen találhatunk egy remek ismertetõt (angolul). John Ferrell Átnézte és aktualizálta: Az OpenBSD csomagszûrõje (PF) és az <acronym>ALTQ</acronym> tûzfalak PF 2003 júliusában az OpenBSD PF néven ismert csomagszûrõjét átírták &os;-re és elérhetõvé tették a &os; Portgyûjteményének részeként. A PF programot beépítetten tartalmazó elsõ kiadás pedig 2004 novemberében a &os; 5.3 volt. A PF egy teljes, mindentudó tûzfal, amely támogatja az ún. ALTQ (Alternate Queuing, vagyis a váltóbesorolás) megoldást. Az ALTQ lehetõvé teszi a sávszélesség korlátozását a szolgáltatás minõsége (Quality of Service, QoS) alapján. Az OpenBSD Projekt kiváló munkát végez a PF felhasználói útmutatójának karbantartásával. A kézikönyv ezen szakasza ezért elsõsorban azzal foglalkozik, hogyan kell a PF-et &os; alatt használni, miközben igyekszik egy általános összefoglalást adni a témáról. A részletesebb információkkal kapcsolatban azonban feltétlenül nézzük meg a felhasználói útmutatót. A címen olvashatunk többet arról (angolul), hogy a PF-et hogyan használjunk &os;-n. A PF rendszermagmodul használata A &os; 5.3 megjelenése óta a PF az alaprendszer része mint futás közben betölthetõ rendszermagmodul. A rendszer induláskor tehát képes automatikusan betölteni, ha az &man.rc.conf.5; állományban megadjuk a pf_enable="YES" sort. A PF modul azonban csak akkor fog mûködésbe lépni, ha talál hozzátartozó szabályrendszert, amely alapértelmezés szerint az /etc/pf.conf állományban található. Amennyiben a PF szabályrendszere a mi esetünkben máshol található, akkor az rc.conf állományban ne felejtsük megadni a pf_rules="/elérési/útvonal/pf.szabályok" sor használatával. A &os; 7.0 kiadással a minta pf.conf állomány az /etc könyvtárból átkerült a /usr/share/examples/pf könyvtárba. A &os; 7.0 elõtti kiadásokban alapértelmezés szerint található egy pf.conf állomány az /etc könyvtárban. A PF modul parancssorból akár kézzel is betölthetõ: &prompt.root; kldload pf.ko A betölthetõ modul tartalmazza a &man.pflog.4; támogatását, amely segítségével naplózni is tudunk. Amennyiben a PF további szolgáltatásaira is szükségünk lenne, akkor a PF támogatását be kell építenünk a rendszermagba. A PF rendszermagbeli beállításai a rendszermag beállításai device pf a rendszermag beállításai device pflog a rendszermag beállításai device pfsync Noha egyáltalán nem szükséges beépítenünk a PF támogatását a rendszermagba, abban az esetben mégis szükségünk lehet rá, amikor a PF olyan komolyabb lehetõségeit szeretnénk kiaknázni, amelyek már nem részei a modulnak. Ilyen például a &man.pfsync.4;, amely a PF által használt állapottáblázatok bizonyos változásainak megjelenítésére alkalmas pszeudoeszköz. A &man.carp.4; megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A - CARP-ról bõvebb - ismertetést a kézikönyv e ad. + CARP megoldásáról a + kézikönyvben bõvebb ismertetést a ad. A PF rendszermag konfigurációs beállításai a /usr/src/sys/conf/NOTES állományban találhatóak: device pf device pflog device pfsync A device pf beállítás engedélyezi a csomagszûrõ tûzfalat (&man.pf.4;). A device pflog megadásával keletkezik egy &man.pflog.4; pszeudo hálózati eszköz, amellyel egy &man.bpf.4; eszközre érkezõ forgalmat tudunk naplózni. Ezután a &man.pflogd.8; démon használható tõle származó naplózott adatok rögzítésére. A device pfsync engedélyezi a &man.pfsync.4; pszeudo hálózati eszköz létrejöttét, amely az ún. állapotváltások megfigyelésére alkalmas. Az <filename>rc.conf</filename> állományban elérhetõ beállítások A következõ &man.rc.conf.5; beállítások aktiválják a rendszerindítás során a PF és a &man.pflog.4; használatát: pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell) pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány pf_flags="" # a pfctl indításához szükséges további paraméterek pflog_enable="YES" # a pflogd(8) elindítása pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit pflog_flags="" # a pflogd indításához szükséges paraméterek Ha a tûzfalunk mögött egy helyi hálózat is meghúzódik, akkor az ott levõ gépek számára valamilyen módon tudnunk kell továbbítani a csomagokat vagy címfordítást kell végezni, így ez is mindenképpen kelleni fog: gateway_enable="YES" # az átjáró funkciók engedélyezése A szûrési szabályok megfogalmazása A PF a beállításait a &man.pf.conf.5; állomány tárolja (amely alapértelmezés szerint az /etc/pf.conf helyen található), és az ebben található szabályok alapján módosítja, dobja el vagy éppen engedi át a csomagokat. A &os; rendszerünkben ehhez találhatunk néhány példát a /usr/share/examples/pf/ könyvtárban. A PF által használt szabályokról minden részletre kiterjedõen a PF felhasználói útmutatójában olvashatunk. A PF felhasználói útmutatójának olvasásakor ne feledkezzünk meg róla, hogy a különbözõ &os; verziók különbözõ PF verziókat tartalmaznak: &os; 5.X — OpenBSD 3.5 PF &os; 6.X — OpenBSD 3.7 PF &os; 7.X — OpenBSD 4.1 PF A &a.pf; remek hely a PF tûzfal beállításával és futtatásával kapcsolatos kérdésekre. A kérdezés elõtt azonban ne felejtsük el alaposan átnézni az archívumot! A PF használata A PF a &man.pfctl.8; segítségével vezérelhetõ. Az alábbiakban ezzel kapcsolatban most összefoglalunk néhány hasznos parancsot (de ne felejtsük el megnézni a &man.pfctl.8; man oldalon található többi lehetõséget sem): Parancs Leírás pfctl A PF engedélyezése pfctl A PF tiltása pfctl all /etc/pf.conf Az összes (címfordítási, szûrési, állapottartási stb.) szabály törlése, és az /etc/pf.conf állomány újratöltése pfctl [ rules | nat | state ] A szûrési (rules), címfordítási (nat) és állapottartási (state) információk lekérdezése pfctl /etc/pf.conf Az /etc/pf.conf állomány ellenõrzése a benne levõ szabályok betöltése nélkül Az <acronym>ALTQ</acronym> engedélyezése Az ALTQ kizárólag csak úgy használható, ha a konfigurációs beállításokon keresztül beépítjük a &os; rendszermagjába. Az ALTQ alkalmazását nem minden hálózati kártya meghajtója támogatja, ezért ezt a &man.altq.4; man oldalon ellenõrizzük. A következõ rendszermag konfigurációs beállításokkal engedélyezhetjük az ALTQ használatát és bõvíthetjük azt további lehetõségekkel: options ALTQ options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ) options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED) options ALTQ_RIO # RED befele/kifele options ALTQ_HFSC # hiearchikus csomagütemezõ (Hierarchical Packet Scheduler, HFSC) options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ) options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ az ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a - osztályozás alapú besorolást (Class - Based Queuing, CBQ). A - CBQ használatával a - kapcsolatunkhoz tartozó + osztályozás alapú besorolást + (Class Based Queuing, + CBQ). A CBQ + használatával a kapcsolatunkhoz tartozó sávszélességet különbözõ osztályokra vagy sorokra tudjuk bontani és a szûrési szabályoknak megfelelõen osztályozni segítségükkel a forgalmat. Az options ALTQ_RED a véletlen - korai észlelés (Random Early Detection, - RED) használatát - engedélyezi. A RED a - hálózati forgalomban keletkezõ - torlódások elkerülésére - alkalmas. A RED ezt a - problémát úgy oldja meg, hogy méri a - sorok hosszát és összeveti a - hozzátartozó minimális és - maximális küszöbértékekkel. Ha a - sor hossza meghaladja a számára elõírt + korai észlelés (Random Early + Detection, RED) + használatát engedélyezi. A + RED a hálózati forgalomban + keletkezõ torlódások + elkerülésére alkalmas. A + RED ezt a problémát úgy + oldja meg, hogy méri a sorok hosszát és + összeveti a hozzátartozó minimális + és maximális + küszöbértékekkel. Ha a sor hossza + meghaladja a számára elõírt maximális értéket, akkor az új csomagokat eldobja. Nevéhez hûen a RED az eldobásra ítélt csomagokat véletlenszerûen választja ki. Az options ALTQ_RIO engedélyezi a RED használatát mind a két irányba, tehát be- és kifelé. Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú - csomagütemezõt (Hierarchical Fair Service Curve Packet - Scheduler, HFSC) engedélyezi. Vele - kapcsolatban a + csomagütemezõt (Hierarchical Fair Service + Curve Packet Scheduler, HFSC) + engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos - besorolást (Priority Queuing, PRIQ) - teszi elérhetõvé. A PRIQ - mindig elsõként a nagyobb értékû - sorban levõ forgalmat továbbítja. + besorolást (Priority Queuing, + PRIQ) teszi elérhetõvé. A + PRIQ mindig elsõként a nagyobb + értékû sorban levõ forgalmat + továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis többprocesszoros támogatását adja meg. Ilyen típusú rendszerekben ez kötelezõ. Az IPFILTER (IPF) tûzfal tûzfalak IPFILTER - - Ez a szakasz fejlesztés alatt áll. Ennek - megfelelõen a tartalma nem minden esetben pontos. - - Az IPFILTER szerzõje Darren Reed. Az IPFILTER nem kötõdik egyik rendszerhez sem: ez egy olyan nyílt forráskódú alkalmazás, amelyet átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX és &solaris; operációs rendszerekre. Az IPFILTER karbantartása és támogatása pillanatnyilag is aktív, folyamatosan jelennek meg újabb változatai. Az IPFILTER egy rendszermag oldalán mûködõ tûzfalazási és egy címfordítási mechanizmusra alapszik, amelyet felhasználói programokkal tudunk felügyelni és vezérelni. A tûzfal szabályai az &man.ipf.8; segédprogrammal állíthatóak be vagy törölhetõek. A hálózati címfordításra vonatkozó szabályokat az &man.ipnat.1; segédprogrammal állíthatjuk be vagy törölhetjük. Az &man.ipfstat.8; segédprogram képes futás közben statisztikákat készíteni az IPFILTER rendszermagban elhelyezkedõ részeinek viselkedésérõl. Az &man.ipmon.8; program pedig az IPFILTER cselekvéseit képes a rendszernaplókba feljegyezni. Az IPF eredetileg olyan szabályfeldolgozási módszer szerint készült, amelyben az utolsó egyezõ szabály nyer és csak állapotnélküli szabályokat ismert. Az idõ múlásával az IPF részévé vált a quick opció és a keep state opción keresztül az állapottartás is, melyek drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos - dokumentációja tartalmazza a régi - szabályok létrehozását és azok - feldolgozásának leírását. A - korszerûsített funkciók csak + dokumentációja csak a régi szabályok + létrehozását és azok + feldolgozásának leírását + tartalmazza. A korszerûsített funkciók csak kiegészítésképpen jelennek meg, és az általuk felkínált elõnyök megértése egy sokkal magasabb szintû és biztonságosabb tûzfal megépítését teszik lehetõvé. A szakaszban szereplõ utasításokban olyan szabályok szerepelnek, amelyek kihasználják a quick és keep state opciókat. Ezek az inkluzív tûzfalszabályok létrehozásának alapjai. - Az inkluzív tûzfalak csak olyan csomagokat - engednek keresztül, amelyek megfelelnek a - szabályoknak. Ezen módon képesek vagyunk - megmondani, hogy a tûzfal mögül milyen - szolgáltatások érhetõek el az interneten - és segítségével azt is megadhatjuk, - hogy az internetrõl a belsõ hálózatunkon - milyen szolgáltatásokat érhetnek el. A - tûzfal alapból minden mást visszautasít - és naplóz. Az inkluzív tûzfalak sokkal, - de sokkal megbízhatóbbak az exkluzív - tûzfalaknál, ezért itt most csak ilyenekkel - foglalkozunk. - A régi típusú szabályokról a + url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"> és + url="http://coombs.anu.edu.au/~avalon/ip-filter.html"> címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen + url="http://www.phildev.net/ipf/index.html"> címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a + url="http://marc.theaimsgroup.com/?l=ipfilter"> címen találjuk (angolul). Az IPF engedélyezése IPFILTER engedélyezés Az IPF megtalálható a &os; alaptelepítésében mint menet közben külön betölthetõ modul. Ha az rc.conf állományba beírjuk a ipfilter_enable="YES" sort, akkor ez a modul dinamikusan betöltõdik. A betölthetõ modul alapból naplóz és a default pass all beállítást tartalmazza. Ha helyette a block all szabályt akarjuk használni, akkor emiatt még nem kell feltétlenül újrafordítanunk a &os; rendszermagját, elég ha egyszerûen csak a szabályrendszerünk végére beszúrjuk. A rendszermag beállításai a rendszermag beállításai IPFILTER a rendszermag beállításai IPFILTER_LOG a rendszermag beállításai IPFILTER_DEFAULT_BLOCK IPFILTER a rendszermag beállításai Az IPF használatához nem kötelezõ a következõ beállításokkal újrafordítani a &os; rendszermagját, itt csupán háttérinformációként szerepel. Amikor az IPF a rendszermagba kerül, a betölhetõ modulra nem lesz szükség. Az IPF a rendszermag forrásai között található /usr/src/sys/conf/NOTES állományban megadott beállításai a következõ módon foglalhatóak össze: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Az options IPFILTER engedélyezi az IPFILTER tûzfal támogatását. Az options IPFILTER_LOG hatására az IPF az ipl csomagnaplózó pszeudo eszközre jegyzi fel a forgalmat — minden olyan szabály esetén, ahol megjelenik a log kulcsszó. Az options IPFILTER_DEFAULT_BLOCK megváltoztatja az alapértelmezett viselkedést, tehát minden olyan csomag, amely nem illeszkedik a tûzfal valamelyik pass típusú (átengedõ) szabályára, blokkolásra kerül. Ezek a beállítások csak azt követõen érvényesülnek, ha fordítottunk és telepítettünk velük egy új rendszermagot. Az <filename>rc.conf</filename> állomány beállításai Az /etc/rc.conf állományban a következõ utasításokra lesz szükségünk az IPF mûködésbe hozására a rendszer indítása során: ipfilter_enable="YES" # az ipf tûzfal indítása ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt ipmon_enable="YES" # elindítja az IP monitor naplózását ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok feloldása Ha olyan helyi hálózat áll meg a tûzfal mögött, amely egy fenntartott privát IP-címtartományt használ, akkor még a következõ utasításokra is szükségünk lesz a címfordítás bekapcsolásához: gateway_enable="YES" # a helyi hálózat átjárója ipnat_enable="YES" # az ipnat funkció elindítása ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez szükséges definíciók IPF ipf - Az ipf parancs használható - a szabályokat tartalmazó állomány + Az &man.ipf.8; parancs használható a + szabályokat tartalmazó állomány betöltésére. Általában egy állományba írjuk össze a tûzfal szabályait és ezzel a paranccsal cseréljük le egyszerre a tûzfalban levõ jelenlegi szabályokat: &prompt.root; ipf -Fa -f /etc/ipf.rules Az az összes belsõ szabály törlését jelenti. Az jelzi, hogy egy állományból kell beolvasni a betöltendõ szabályokat. Ezzel mintegy lehetõségünk van változtatni a korábban összeállított szabályainkon, futtatni a fenti IPF parancsot és ezen keresztül úgy frissíteni a szabályok friss másolatával a már mûködõ tûzfalat, hogy nem is kell újraindítanunk a rendszert. Ez a módszer igen kényelmes az új szabályok kipróbálásához, mivel bármikor tetszõlegesen végrehajtható. Az &man.ipf.8; man oldala tartalmazza a parancsnak megadható további beállításokat. Az &man.ipf.8; parancs a szabályokat tároló állományt egy szabványos szöveges állománynak tekinti, semmilyen szimbolikus helyettesítést alkalmazó szkriptet nem fogad el. Lehetõségünk van azonban olyan IPF szabályokat készíteni, amelyek kiaknázzák a szkriptek szimbolikus helyettesítésének lehetõségeit. Errõl bõvebben lásd . Az IPFSTAT ipfstat IPFILTER statisztika Az &man.ipfstat.8; alapértelmezés szerint a arra használatos, hogy le tudjuk kérdezni és megjeleníteni a tûzfalhoz tartozó számlálók értékeit, amelyek a legutóbbi indítás vagy az ipf -Z parancs által kiadott lenullázásuk óta a bejövõ vagy kimenõ forgalomból a megadott szabályoknak megfelelõ csomagok alapján gyûjtenek össze statisztikákat. A parancs mûködésének részleteit az &man.ipfstat.8; man oldalon olvashatjuk. Az &man.ipfstat.8; meghívása alapból így néz ki: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Az mint bejövõ (inbound), vagy az mint kimenõ (outbound) forgalomra vonatkozó paraméterek megadásával a rendszermagban az adott oldalon jelenleg telepített és alkalmazott szabályokat kérhetjük le és jeleníthetjük meg. Az ipfstat -in parancs így a bejövõ forgalomra vonatkozó belsõ szabályokat mutatja a szabályok számával. Az ipfstat -on parancs a kimenõ forgalmat érintõ belsõ szabályokat mutatja a szabályok számával. Az eredmény körülbelül ilyen lesz: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat -ih a bejövõ forgalomhoz tartozó belsõ szabályokat mutatja és mindegyik elé odaírja, hogy eddig mennyi csomag illeszkedett rájuk. Az ipfstat -oh ugyanígy a kimentõ forgalom esetén mutatja a belsõ szabályokat és mindegyik elõtt feltünteti, hogy az adott pillanatig mennyi csomag illeszkedett rájuk. A kimenete nagyjából ilyen lesz: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat parancs talán egyik legfontosabb funkciója a kapcsolóval csalható elõ, melynek hatására a rendszerben aktív állapotok táblázatát mutatja meg ugyanúgy, ahogy a &man.top.1; a &os; rendszerben futó programokat. Amikor a tûzfalunk támadás alatt áll, ezzel a funkcióval tudjuk a problémát beazonosítani, leásni a mélyébe és látni a támadótól érkezõ csomagokat. A kiegészítésképpen megadható alkapcsolók megadásával kiválaszthatjuk azt a cél vagy forrás IP-címet, portot vagy protokollt, amelyet valós idõben meg akarunk figyelni. Ennek részleteit az &man.ipfstat.8; man oldalán láthatjuk. Az IPMON ipmon IPFILTER naplózás Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a - rendszermag IPFILTER_LOG + rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a opció nélkül gépeljük be, akkor ezek közül alapból a natív módot kapjuk meg. A démon mód abban az esetben hasznos, ha folyamatosan naplózni akarjuk a rendszerben zajló eseményeket, majd késõbb ezeket átnézni. Így képes egymással együttmûködni a &os; és az IPFILTER. A &os; beépítve tartalmaz olyan lehetõséget, aminek révén magától cseréli a rendszernaplókat. - Ezért ha átküldjük a syslogd + Ezért ha átküldjük a &man.syslogd.8; démonnak a naplózandó üzeneteket, akkor sokkal jobban járunk, mintha egyszerûen csak mezei állományba naplóznánk. Az rc.conf alapértelmezései között az ipmon_flags beállítás a kapcsolókat rögzíti: ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok nevének feloldása Ennek a viselkedésnek az elõnyei minden bizonnyal egyértelmûek. Segítségével képesek vagyunk az esetek megtörténte után átnézni, hogyan milyen csomagokat dobott el a rendszer, azok milyen címekrõl érkeztek és hova szánták. Ez egy komoly fegyver a támadók lenyomozásában. Hiába engedélyezzük a naplózást, az IPF önszántából semmilyen naplózási szabályt nem fog gyártani. A tûzfal gazdájának kell eldöntenie, hogy a szabályokat közül melyiket akarja naplózni, és így neki kell megadnia a log kulcsszót ezekben az esetekben. Normális esetben csak a deny szabályokat naplózzák. Egyáltalán nem ritka, hogy a szabályrendszer végén egy alapértelmezés szerint mindent eldobó szabály áll, amely naplóz. Ezzel lehetõségünk nyílik rögzíteni azokat a csomagokat, amelyek egyetlen szabályra sem illeszkedtek. Naplózás az IPMON használatával A syslogd egy saját módszert alkalmaz a naplózott adatok elkülönítésére. Egy funkciók (facility) és szintek (level) segítségével kialakított speciális csoportosítást alkalmaz. Az IPMON módja a security (biztonság) funkciót használja. Tehát az IPMON által naplózott összes adat a security csoportjába kerül. Ezen túl a következõ szinteken különíthetjük el igényeinknek megfelelõen a naplózott adatokat: LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok LOG_NOTICE - az át is engedett csomagok LOG_WARNING - a blokkolt csomagok LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük) Az IPFILTER csak akkor tud naplózni a /var/log/ipfilter.log állományba, ha elõtte létrehozzuk. Az alábbi parancs erre tökéletesen megfelelõ: &prompt.root; touch /var/log/ipfilter.log - A syslog mûködését az + A &man.syslogd.8; mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes - meghatározni azt, ahogy a syslog az IPF és a + meghatározni azt, ahogy a + syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. Az /etc/syslog.conf állományba az alábbi sor kell felvennünk: security.* /var/log/ipfilter.log A security.* megadásával az összes ilyen típusú üzenet egy elõre rögzített helyre kerül. Az /etc/syslog.conf állományban elvégzett módosításokat úgy léptethetjük érvénybe, ha újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal - megkérjük a syslog programot, hogy olvassa - újra az /etc/syslog.conf + megkérjük a &man.syslogd.8; démont, hogy + olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne felejtsük el megadni az /etc/newsyslog.conf állományban sem, és akkor ezzel a cseréjét is megoldjuk. A naplózott üzenetek formátuma Az ipmon által létrehozott üzenetek whitespace karakterekkel elválasztott adatmezõkbõl állnak. A következõ mezõk az összes üzenet esetében megjelennek: A csomag megérkezésének dátuma A csomag megérkezésének idõpontja. ÓÓ:PP:MM.E alakban jelennek meg az órák, percek, másodpercek és ezredmásodpercek (ez több számjegy hosszú is lehet) szerint - Annak a felületnek a neve, ahol a csomag + Azon interfész a neve, ahol a csomag feldolgozásra került, például dc0 A szabályhoz tartozó csoport és sorszám, például @0:17 Ezek az ipfstat -in paranccsal nézhetõek meg. Cselekvés: a p mint átment (passed), b mint blokkolt (blocked), S mint rövid csomag (short packet), n mint egyik szabályra sem illeszkedett (not match), L mint naplózás (log). A módosítók megjelenítésének sorrendje: S, p, b, n, L. A nagybetûs P és B azt jelzi, hogy a csomagot egy felsõbb szintû beállítás miatt naplózták, nem egy szabály hatására. Címek: ez tulajdonképpen három mezõt takar: a forrás címet és portot (melyet egy vesszõ választ el), a -> jelet és cél címet és portot. Például: 209.53.17.22,80 -> 198.73.220.17,1722. A PR után a protokoll neve vagy száma olvasható, például PR tcp. A len csomaghoz tartozó fejléc és törzsének teljes hosszát jelöli, például len 20 40. Amennyiben a csomag TCP, egy kötõjellel kezdõdõen további mezõk is megjelenhetnek a beállított opcióknak megfelelõ betûk képében. A betûket és beállításaikat az &man.ipmon.8; man oldalán olvashatjuk. Amennyiben a csomag ICMP, a sort két mezõ zárja, melyek közül az elsõ tartalma mindig ICMP, és ezt egy perjellel elválasztva az ICMP üzenet típusa és altípusa követi. Tehát például az ICMP 3/3 a nem elérhetõ port üzenetet hordozza. A szabályok felírása szimbolikus helyettesítéssel Az IPF használatában gyakorlott felhasználók közül néhányan képesek olyan stílusú szabályrendszert készíteni, ahol szimbolikus helyettesítést használnak. Ennek az egyik legnagyobb elõnye az, hogy ilyenkor elég csak a szimbolikus névhez tartozó értéket megváltoztatni és amikor a szkript lefut, akkor az összes rá hivatkozó szabályba ez kerül be. Szkript lévén a szimbolikus helyettesítéssel ki tudjuk emelni a gyakran használt értékeket és behelyettesíteni ezeket több helyre. Ezt a most következõ példában láthatjuk. - Az itt alkalmazott felírás kompatibilis az sh, - csh és tcsh parancsértelmezõkkel. + Az itt alkalmazott felírás kompatibilis az + &man.sh.1;, &man.csh.1; és &man.tcsh.1; + parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: $. A szimbolikus mezõkben nem szerepel a $ jelölés. A szimbolikus mezõ tartalmát kettõs idézõjelbe (") tesszük. Kezdjük így el a szabályok írását: ######### Az IPF szabályait tartalmazó szkript eleje ########### -oif="dc0" # a kimenõ felület neve +oif="dc0" # a kimenõ interfész neve odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk ks="keep state" fks="flags S keep state" # Választhatunk, hogy az /etc/ipf.rules állományt ebbõl a szkriptbõl # hozzuk létre vagy futtathatjuk "magát" a szkriptet. # # Egyszerre csak az egyik sort használjuk. # # 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt: #cat > /etc/ipf.rules << EOF # # 2) Ezzel futtathajuk "magát" a szkriptet: /sbin/ipf -Fa -f - << EOF # Engedélyezzük a szolgáltató névszerverének elérését. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Engedélyezzük kifelé a titkosítatlan www funkciót. pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Engedélyezzük kifelé a TLS SSL felett üzemelõ titkosított www funkciót. pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Itt az IPF szkript vége ######################## Ennyi lenne. A példában szereplõ szabályok most nem annyira lényegesek, a hangsúly most igazából a szimbolikus helyettesítésen és annak használatán van. Ha a fenti példát az /etc/ipf.rules.script állományba mentjük, akkor ezeket a szabályokat a következõ paranccsal újra tudjuk tölteni: &prompt.root; sh /etc/ipf.rules.script Egyetlen aprócska gond van a beágyazott szimbólumokat tartalmazó állományokkal: az IPF maga nem képes megérteni a helyettesítéseket, azért közvetlenül nem olvassa a szkriptet. Ez a szkript két módon hasznosítható: Vegyük ki megjegyzésbõl a cat paranccsal kezdõdõ sort, és tegyük megjegyzésbe az /sbin/ipf kezdetût. A megszokottak szerint tegyük az ipfilter_enable="YES" sort az /etc/rc.conf állományba, majd minden egyes módosítása után futtassuk le a szkriptet az /etc/ipf.rules állomány létrehozásához vagy frissítéséhez. Tiltsuk le az IPFILTER aktiválását a rendszerindításkor, tehát írjuk bele az ipfilter_enable="NO" sort (ami mellesleg az alapértelmezett értéke) az /etc/rc.conf állományba. Tegyünk egy, az alábbi szkripthez - hasonlót az /usr/local/etc/rc.d/ + hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az .sh kiterjesztés használata kötelezõ. #!/bin/sh sh /etc/ipf.rules.script A szkript engedélyeit állítsuk be úgy, hogy a root tulajdonában legyen és képes legyen olvasni, írni valamint végrehajtani. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Most miután a rendszer elindult, az IPF szabályai be fognak töltõdni. Szabályrendszerek az IPF-ben - Az ipf esetében a szabályrendszer olyan + Az IPF esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást - képeznek. A tûzfal szabályrendszere minden - csomagot kétszer dolgoz fel: egyszer, amikor befut az - internetrõl, illetve még egyszer, amikor - visszatér az internetre. Mindegyik TCP/IP - szolgáltatást (például telnet, www, - levelezés stb.) elõre meghatározza a - hozzátartozó protokoll, cél és - forrás IP-cím vagy port. Ez az alapja a - szolgáltatások - engedélyezésérõl vagy - tiltásáról szóló - szabályok megfogalmazásának. + képeznek. A tûzfalhoz tartozó + szabályrendszer egyaránt feldolgozza a + internetrõl a hálózatunk felé + igyekvõ csomagokat, illetve a hálózatunk + ezekre adott válaszait. Az egyes + TCP/IP szolgáltatásokat (mint + például telnet, www, levelezés stb.) a + hozzájuk tartozó protokol és + szabványos (fogadó) portszám írja + le. Ezekre a forrásról általában + valamilyen nem szabványos (magasabb + értékû) portról érkeznek + csomagok. Ekkor a kommunikáció összes + paramétere (vagyis a portok és címek) + bármelyike alapján definiálhatunk + blokkolást vagy továbbengedést + leíró szabályokat. IPFILTER a szabályok feldolgozásának sorrendje Az IPF eredetileg úgy íródott, hogy a szabályokat az utolsó illeszkedõ szabály nyer stílusban dolgozza fel és csak állapot nélküli szabályokat ismert. Az idõk folyamán az IPF szabályai kiegészültek a quick és az állapottartásra vonatkozó keep state opciókkal, amelynek köszönhetõen óriási mértékben korszerûsödött a szabályok feldolgozása. A szakaszban szereplõ utasítások olyan szabályokat alkalmaznak, amelyekben egyaránt szerepel a quick és az állapottartásért felelõs keep state beállítás. Ez az inkluzív tûzfalak létrehozásának egyik alapeszköze. - Az inkluzív tûzfalak csak olyan - szolgáltatásokat engednek át, amelyek - megfelelnek valamelyik szabálynak. Ezzel - lényegében meg tudjuk adni, hogy milyen - szolgáltatások érhetõek el a - tûzfal mögül az internet felé, valamint az - internetrõl a magánhálózatunkon. A - tûzfal minden mást elutasít és - alapértelmezés szerint naplóz. Az - inkluzív tûzfalak sokkal, de sokkal - biztonságosabbak az exkluzív - tûzfalaknál, ezért itt most csak ezzel az - egyetlen típussal foglalkozunk. - A tûzfal szabályainak összeállítása során nagyon óvatosnak kell lennünk! Bizonyos beállítások hatására akár ki is zárhatjuk magunkat a szerverünkrõl. Az ebbõl fakadó esetleges kellemetlenségek elkerülése érdekében javasoljuk, hogy a tûzfal alapjait elõször helyi konzolról építsük fel, ne pedig távolról, például ssh segítségével. A szabályok felépítése IPFILTER a szabályok felépítése A szabályok felépítésének bemutatását itt most leszûkítjük a modern állapottartó szabályokra és az elsõ illeszkedõ szabály nyer típusú feldolgozásra. A szabályok felírásának régebbi módjai az &man.ipf.8; man oldalon találhatóak. A # karakterrel egy megjegyzés kezdetét jelezzük, és általában a sor végén vagy egy külön sorban bukkan fel. Az üres sorokat a rendszer nem veszi figyelembe. A szabályok kulcsszavakat tartalmaznak. Ezeknek a kulcsszavaknak balról jobbra haladva adott sorrendben kell szerepelniük. A kulcsszavakat kiemeltük. Egyes kulcsszavakhoz további beállítások is tartozhatnak, amelyek maguk is kulcsszavak lehetnek, és még további opciókkal rendelkezhetnek. Az alábbi nyelvtan mindegyik elemét kiemeltük és az alábbiakban egyenként kifejtjük a részleteiket. CSELEKVÉS BE-KI OPCIÓK SZÛRÉS ÁLLAPOTTARTÓ PROTOKOLL FORRÁS_CÍM,CÉL_CÍM OBJEKTUM PORTSZÁM TCP_BEÁLLÍTÁS ÁLLAPOTTARTÓ CSELEKVÉS = block | pass BE-KI = in | out OPCIÓK = log | quick | on - felületnév + interfész SZÛRÉS = proto érték | forrás/cél IP | port = szám | flags beállítás PROTOKOLL = tcp/udp | udp | tcp | icmp FORRÁS_CÍM,CÉL_CÍM = all | from objektum to objektum OBJEKTUM = IP-cím | any PORTSZÁM = portszám TCP_BEÁLLÍTÁS = S ÁLLAPOTTARTÓ = keep state CSELEKVÉS A cselekvés határozza meg, hogy mit kell tenni azokkal a csomagokkal, amelyek illeszkednek a szabály többi részére. Minden szabályhoz tartoznia kell egy cselekvésnek. A következõ cselekvések közül választhatunk: A block megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot eldobjuk. A pass megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot átengedjük a tûzfalon. BE-KI Az összes szûrési szabály esetében kötelezõ egyértelmûen nyilatkozunk arról, hogy a bemenõ vagy a kimenõ forgalomra vonatkozik. Ezért a - következõ kulcsszó vagy az in - vagy pedig az out, de közülük - egyszerre csak az egyiket szabad használni, - máskülönben a szabály hibásnak - minõsül. + következõ kulcsszó vagy az + in vagy pedig az out, de + közülük egyszerre csak az egyiket szabad + használni, máskülönben a + szabály hibásnak minõsül. Az in jelenti, hogy a szabályt - az internet felõl az adott felületen + az internet felõl az adott interfészen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt - az internet felé az adott felületen + az internet felé az adott interfészen kiküldött csomagokra kell alkalmazni. - OPCIÓK Ezek az opciók csak a lentebb bemutatott sorrendben használhatók. A log jelzi, hogy illeszkedés esetén a csomag fejlécét az ipl eszközön keresztül naplózni kell (lásd a naplózásról szóló szakaszt). A quickjelzi, hogy illeszkedés esetén ez lesz a legutolsónak ellenõrzött szabály és így egy olyan rövidzárat tudunk képezni a feldolgozásban, amellyel elkerüljük a csomagra egyébként vonatkozó többi szabály illesztését. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához elengedhetetlen. Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati - felületet. Itt a felületek az &man.ifconfig.8; - által megjelenített formában - adhatóak meg. Az opció - megadásával csak az adott felületen az + interfészt. Itt az interfészek az + &man.ifconfig.8; által megjelenített + formában adhatóak meg. Az opció + megadásával csak az adott interfészen az adott irányba (befelé/kifelé) közlekedõ csomagokra fog illeszkedni a szabály. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a - hozzátartozó fejléc az IPL - csomagnaplózó pszeudo eszközhöz - kerül. A log kulcsszó után - közvetlenül a következõ - minõsítõk szerepelhetnek (a - következõ sorrendben): + hozzátartozó fejléc az + IPL csomagnaplózó pszeudo + eszközhöz kerül. A log + kulcsszó után közvetlenül a + következõ minõsítõk szerepelhetnek + (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még jegyezzük fel a fejléc mellé. A first minõsítõt akkor érdemes használnunk, amikor a - log kulcsszót a keep - state opcióval együtt alkalmazzuk, mivel + log kulcsszót a keep + state opcióval együtt alkalmazzuk, mivel ilyenkor csak a szabályt kialakító csomag kerül naplózásra és nem minden olyan, ami illeszkedik az állapottartási feltételekre. - SZÛRÉS Ebben a szakaszban olyan kulcsszavak jelenhetnek meg, amelyekkel a csomagok különféle tulajdonságai alapján ítélkezhetünk azok illeszkedésérõl. Itt adott egy kiinduló kulcsszó, amelyhez további kulcsszavak is tartoznak, és amelyek közül csak egyet választhatunk. Az alábbi általános tulajdonságok alapján tudjuk szûrni a csomagokat, ebben a sorrendben: PROTOKOLL A proto egy olyan kulcsszó, amelyhez hozzá kell rendelnünk még valamelyik opcióját is. Ez az opció segít az adott protokolloknak megfelelõen válogatni a csomagok között. A korszerûsített szabályfeldolgozás lehetõségeinek kihasználásához nélkülözhetetlen. Opcióként a tcp/udp | udp | tcp | icmp, vagy bármelyik, az /etc/protocols állományban megtalálható kulcsszó felhasználható. A tcp/udp ebbõl a szempontból speciálisnak tekinthetõ, mivel hatására egyszerre illeszthetõek a szabályra a TCP és UDP csomagok, és így a protokolltól eltekintve azonos szabályok felesleges többszörözését kerülhetjük el. FORRÁS_CÍM/CÉL_CÍM Az all kulcsszó gyakorlatilag a from any to any (bárhonnan bárhova) szinonímája és nem tartozik hozzá paraméter. A from forrás to cél felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. - Ilyenkor a szabályokban a forrás ÉS a - cél paramétereknek is szerepelniük kell. - Az any egy olyan speciális + Ilyenkor a szabályokban a forrás + és a cél + paramétereknek is szerepelniük kell. Az + any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az - alkalmazására: from any to any - vagy from 0.0.0.0/0 to any, from any to - 0.0.0.0/0, from 0.0.0.0/0 to any vagy - from any to 0.0.0.0. + alkalmazására: from any to + any vagy from 0.0.0.0/0 to any, + from any to 0.0.0.0/0, from + 0.0.0.0/0 to any vagy from any to + 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben mért hosszával együtt, vagy akár egyetlen pontozott numerikus IP-címként. Nincs lehetõség olyan IP-címtartományok illesztésére, - amelyek nem adhatóak meg kényelmesen a maszk - hosszával. A hálózati maszkok - hosszának megállapításban - segíthet a következõ (angol nyelvû) - honlap: . - + amelyek nem adhatóak meg kényelmesen ponttal + elválasztott számok és maszk + hosszával. A net-mgmt/ipcalc port az ilyen + számításokat könnyíti meg. A + hálózati maszkok hosszának + megállapításban segíthet az + említett segédprogram (angol nyelvû) + honlapja: . PORT Amikor portra vonatkozó illeszkedést írunk elõ, megadhatjuk a forrásra és célra, amit aztán vagy csak TCP vagy pedig csak UDP csomagokra alkalmazunk. A portok feltételeinek megfogalmazásánál használhatjuk a portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy - from típusú objektum + from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a - to objektum leírásában + to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. - Példa: from any to any port = 80. + Példa: from any to any port = + 80. - A portokat különbözõ mûveletek - segítségével, numerikusan + Az egyes portokat különbözõ + mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". A porttartományok megadásához használjuk a port "<>" | "><" felírási módot. A forrásra és célra vonatkozó paraméterek után szereplõ másik két paraméter nélkülözhetetlen a korszerûsített szabályfeldolgozás mûködéséhez. - <acronym>TCP</acronym>_BEÁLLÍTÁS A beállítások csak a TCP forgalom szûrésénél érvényesülnek. A betûk jelölik azokat a lehetséges beállításokat, amelyek a TCP csomagok fejlécében megvizsgálhatóak. A korszerûsített szabályfeldolgozás a flags S paraméter segítségével ismeri fel a TCP munkameneteket kezdeményezõ kéréseket. ÁLLAPOTTARTÓ A keep state jelzi, hogy a szabály paramétereinek megfelelõ bármely csomag aktiválja az állapottartó szûrés használatát. Ez a beállítás feltétlenül szükséges a korszerûsített szabályfeldolgozás megfelelõ kihasználásához. Állapottartó csomagszûrés IPFILTER állapottartó szûrés Az állapottartó szûrés a csomagok kétirányú áramlását egy létrejött kapcsolatba sorolja be. Amikor aktiválódik, az állapottartó szabály elõre dinamikusan létrehozza a kétirányú kommunikációban megforduló csomagokhoz a megfelelõ belsõ szabályokat. Olyan vizsgálatokat végez, amelyek segítségével ki tudja deríteni, hogy a csomag küldõje és címzettje között fennálló kétirányú kapcsolat érvényes szabályok szerint zajlik-e. Minden olyan csomagot, amely nem illeszkedik megfelelõen a kapcsolatra vonatkozó sémára, csalásnak tekintjük és automatikusan eldobjuk. Az állapottartás révén lehetõségünk van a TCP vagy UDP kapcsolatokhoz tartozó ICMP csomagokat is átengedni a tûzfalon. Tehát ha kapunk egy 3-as típusú, 4-es kódú ICMP választ valamilyen böngészésre használt állapottartó szabályon keresztül kiküldött kérésre, akkor az automatikusan bejöhet. Amelyik csomagot az IPF egyértelmûen képes besorolni az aktív kapcsolatba, még ha az eltérõ protokollt is használ, beengedi. Ami ilyenkor történik: - Az internethez csatlakozó felületen + Az internethez csatlakozó interfészen keresztül kifelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat - állapota, a fennmaradó csomagok pedig a - kimenõ szabályrendszer szerint kerülnek + állapota. Az aktív munkameneten kívül + csomagok pedig egyszerûen a kimenõ + szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez - csatlakozó felületen keresztül befelé - haladó csomagokat elõször egy dinamikus - állapottábla alapján illesztjük, - és ha a csomag illeszkedik az aktív kapcsolatban - következõként várt csomagra, akkor - átmegy a tûzfalon és a dinamikus - állapottáblában frissül a kapcsolat - állapota, a fennmaradó csomagok pedig a - bejövõ szabályrendszer szerint kerülnek + csatlakozó interfészen keresztül + befelé haladó csomagokat elõször egy + dinamikus állapottábla alapján + illesztjük, és ha a csomag illeszkedik az + aktív kapcsolatban következõként + várt csomagra, akkor átmegy a tûzfalon + és a dinamikus állapottáblában + frissül a kapcsolat állapota. Az aktív + munkamenethez nem tartozó csomagok pedig egyszerûen + a bejövõ szabályrendszer szerint kerülnek ellenõrzésre. Amikor egy kapcsolat befejezõdik, automatikusan törlõdik a dinamikus állapottáblából. Az állapottartó csomagszûrés használatával az újonnan keletkezõ kapcsolatok elutasítására vagy engedélyezésére tudunk koncentrálni. Ha engedélyeztük egy új kapcsolat létrejöttét, akkor a rákövetkezõ összes többi csomag automatikusan átmegy a tûzfalon és minden más hamis csomag eldobódik. Ha tiltjuk az új kapcsolatot, akkor egyetlen rákövetkezõ csomag sem juthat át. Az állapottartó szûrés által felkínált fejlett elemzési lehetõségek képesek védelmet nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. - Példa inkluzív szabályrendszerre A most következõ szabályrendszer arra mutat példát, hogyan programozzunk le egy nagyon biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint - minden mást blokkolnak. Minden tûzfal - legalább két felülettel dolgozik, melyek - mindegyikéhez írnunk kell szabályokat a - tûzfal megfelelõ - mûködéséhez. + minden mást blokkolnak. Egy hálózat + gépeit védõ tûzfalnak, amelyet gyakran + hálózati tûzfalnak (network + firewall) is neveznek, legalább két + hálózati interfésszel kell rendelkeznie. + Ezeket az interfészeket általában + úgy állítják be, hogy + tökéletesen megbíznak az egyik oldalban (a + helyi hálózatban), a másikban (az + internetben) pedig egyáltalán nem. A + tûzfalat egyébként úgy is + beállíthatjuk, hogy csak a tûzfalat + mûködtetõ gépet védje — ezt + egyrendszeres tûzfalnak (host based + firewall) nevezik. Az ilyen típusú + megoldásokat nem biztonságos + hálózaton keresztül kommunikáló + szervereknél alkalmaznak. Mindegyik &unix;-típusú rendszert, köztük a &os;-t is úgy alakították ki, hogy az operációs rendszeren belüli kommunikáció az - lo0 felületen és a 127.0.0.1 IP-címen keresztül - történik. A tûzfal szabályai - között feltétlenül szerepelniük kell - olyanoknak, amelyek lehetõvé teszik ezen a - speciális felületen a csomagok zavartalan - mozgását. - - Az internetre csatlakozó felülethez kell - rendelni a kifelé haladó forgalom - hitelesítését és az internetrõl - befelé irányuló - hozzáférés vezérlését. - Ez lehet a felhasználói PPP által - létrehozott tun0 felület - vagy a DSL-, illetve kábelmodemhez csatlakozó + lo0 interfészen és a + 127.0.0.1 IP-címen + keresztül történik. A tûzfal + szabályai között feltétlenül + szerepelniük kell olyanoknak, amelyek lehetõvé + teszik ezen a speciális intefészen a csomagok + zavartalan mozgását. + + Az internetre csatlakozó interfészhez kell + rendelni a kifelé és befelé haladó + forgalom hitelesítését é a + hozzáférésének + vezérlését. Ez lehet a + felhasználói PPP által létrehozott + tun0 interfész vagy a DSL-, + illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya - is csatlakozik a tûzfal mögött elhelyezkedõ - helyi magánhálózathoz, ott ezeket a - felületeket úgy kell felvenni a tûzfal - szabályai közé, hogy a helyi - hálózaton zajló forgalmat ne - akadályozzuk. + is csatlakozik több különbözõ helyi + hálózathoz, úgy kell + beállítani a hozzájuk tartozó + interfészeket, hogy egymás felé és + az internet felé képesek legyenek küldeni + és fogadni. A szabályokat elõször három nagy - csoportba kell szerveznünk: az összes szabadon - forgalmazó felület, az internet felé - haladó kimenõ forgalom és az internet - felõl befelé haladó forgalom. + csoportba kell szerveznünk: elõször jönnek a + megbízható interfészek, ezeket követik + az internet felé mutató interfészek, + végül internet felõl jövõ, nem + megbízható interfészeke. Az egyes csoportokban szereplõ szabályokat úgy kell megadni, hogy közülük elõre kerüljenek a leggyakrabban alkalmazottak, és a csoport utolsó szabálya blokkoljon és - naplózzon minden csomagot az adott felületen + naplózzon minden csomagot az adott interfészen és irányban. A kimenõ forgalomat vezérlõ - szabályrendszer csak pass (tehát - átengedõ) szabályokat tartalmazhat, amelyek - bentrõl az interneten elérhetõ - szolgáltatásokat azonosítják - egyértelmûen. Az összes ilyen - szabályban meg kell jelenni a quick, - on, proto, port - és keep state - beállításoknak. A proto tcp - szabályok esetében meg kell adni a - flag opciót is, amivel fel tudjuk + szabályrendszer csak pass + (tehát átengedõ) szabályokat + tartalmazhat, amelyek bentrõl az interneten + elérhetõ szolgáltatásokat + azonosítják egyértelmûen. Az + összes ilyen szabályban meg kell jelenni a + quick, on, + proto, port és + keep state + beállításoknak. A proto + tcp szabályok esetében meg kell adni a + flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két - eltérõ oka van. Elõször is a blokkolt - elemek lehetnek egy egyébként szabályos - csomag részei, amit a késõbbiekben a - hitelesített szolgáltatások alapján - beengedünk. Másodszor ezzel az olyan - rendszertelenül érkezõ csomagokat tudjuk - blokkolni, amelyeket nem akarunk a naplóban látni, - mivel ilyenkor a csoport utolsójaként megadott - blokkoló és naplózó - szabályhoz már nem jut el. A csoport - utolsó tagjaként megadott szabály blokkolja - és naplózza az illétektelen - hozzáféréseket, amit akár jogi - bizonyítékként is felhasználhatunk a - rendszerünket megtámadók ellen. + eltérõ oka van. Elõször is + elõfordulhat, hogy a veszélyes csomagok + részleges illeszkedés miatt szabályosnak + tûnnek. Az ilyen csomagokat értelemszerûen nem + lenne szabad beengedni a szabályok részleges + megfelelése alapján. A másodszor az eleve + ismerten problémás és értelmetlen + csomagokat csendben el kellene vetni, mielõtt a szakaszhoz + tartozó utolsó szabály fogná meg + és naplózná. Ez az utolsó + szabály egyébként szükség + esetén felhasználható a + támadók elleni bizonyítékok + begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz - nem keletkezik, egyszerûen csak eltûnnek. Így - a támadó nem fogja tudni, hogy a csomagjai vajon - elérték-e a rendszerünket. Minél - kevesebb információt tudnak + nem keletkezzen, egyszerûen csak tûnjenek el. + Így a támadó nem fogja tudni, hogy a + csomagjai vajon elérték-e a rendszerünket. + Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál több idõt kell szánniuk csínytevéseik - kieszelésére. Javasolt a beérkezõ - OS fingerprint jellegû - kéréseket az elsõ alkalmommal - naplózni, mert ez az elsõ jele annak, amikor valaki - meg akar támadni minket. - - Amikor a log first szabály - alapján keletkezõ üzeneteket akarjuk - látni, hívjuk meg a ipfstat - -hio parancsot, ahol megjelenik, hogy melyik - szabályra mennyi csomag illeszkedett. Ennek - alapján el tudjuk dönteni, hogy éppen - elárasztanak-e bennünket, tehát meg akarnak-e - támadni. - - Ha ismeretlen porthoz tartozó csomagokat - naplózunk, akkor az /etc/services - állományban vagy a - (angol nyelvû) honlap segítségével - tudjuk kideríteni, hogy pontosan melyik portról - van szó. + kieszelésére. A log first + opciót tartalmazó szabályok csak az + illeszkedésnél fogják naplózni a + hozzájuk tartozó eseményt. Erre + láthatunk példát az nmap OS + fingerprint szabálynál. Az security/nmap segédprogramot + a támadók gyakran alkalmazzák a + megtámadni kívánt szerver + operációs rendszerének + felderítésére. + + Minden log first opcióval megadott + szabály illeszkedésénél a + ipfstat -hio parancs + meghatározódik az eddigi illeszkedések + aktuális száma. Nagyobb értékek + esetében következtethetünk arra, hogy a + rendszerünket megtámadták (vagyis csomagokkal + árasztják éppen el). + + Az ismeretlen portszámok + felderítésére az + /etc/services állomány, + esetleg a + (angol nyelvû) honlap használható. Érdemes továbbá megnézni a trójai programok által használt portokat a címen (angolul). A következõ szabályrendszer egy olyan biztonságos inkluzív - típusú tûzfal, amelyet maga a szerzõ is - használ. Ha ezt átvesszük egy az egyben, - akkor abból semmilyen bajunk nem származhat. - Egyszerûen csak vegyük ki azokat a szabályokat, - amelyek olyan szolgáltatásokra vonatkoznak, amiket - nem akarunk hitelesíteni. - - Ha nem akarunk látni bizonyos üzeneteket a - naplóban, akkor vegyünk fel hozzájuk egy - block típusú szabályt a - befelé irányuló forgalomhoz tartozó + típusú tûzfal, amelyet éles rendszeren + is használnak. Ezt a rendszerünkön nem + használt szolgáltatásokra vonatkozó + pass szabályok + törlésével könnyedén a + saját igényeink szerint + alakíthatjuk. + + Ha nem akarunk látni bizonyos üzeneteket, akkor + vegyünk fel hozzájuk egy block + típusú szabályt a befelé + irányuló forgalomhoz tartozó szabályok közé. - Ne felejtsük el minden szabályban - átírni a dc0 felület - nevét annak a hálózati - kártyának a felületére, amelyen - keresztül csatlakozunk az internethez. A - felhasználói PPP esetében ez a - tun0 lesz. + A szabályokban írjuk át a + dc0 interfész nevét annak + a hálózati kártyának az + interfészére, amelyen keresztül csatlakozunk + az internethez. A felhasználói PPP + esetében ez a tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules állományba: ################################################################# # A helyi hálózatunkon zajló forgalmat ne korlátozzuk. # Csak akkor kell, ha helyi hálózathoz is csatlakozunk. ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# -# A belsõ felületen szintén ne korlátozzunk semmit. +# A belsõ interfészen szintén ne korlátozzunk semmit. ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# -# Az internet felé forgalmazó felület (kimenõ kapcsolatok) +# Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Engedélyezzük az internet szolgáltatók névszerverének elérését, # az "xxx" helyett a névszervet IP-címét kell megadni. # Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több # névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf # állományban találjuk. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # DSL vagy kábeles hálózatoknál engedélyezzük a # szolgáltatónk DHCP szerverének elérését. # Ez a szabály nem kell, ha "felhasználói PPP"-vel # kapcsolódunk az internethez, ilyenkor tehát az egész # csoport törölhetõ. # Használjuk az alábbi szabályt és keressük meg a naplóban az # IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben # szereplõ szabályba és töröljük az elsõ szabályt. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL # protokollal. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Kifelé engedélyezzük az e-mailek küldését és fogadását. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Kifelé engedélyezzük az idõ szolgáltatást. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Kifelé engedélyezzük az nntp híreket. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem # biztonságos FTP használatát (passzív és akív módokban is). Ez a # funkció a mûködéséhez a nat szabályokat tartalmazó állományban # hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal # csomagokat akarunk telepíteni az átjáróra, erre a szabályra # mindenképpen szükségünk lesz. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Kifelé engedélyezzük a biztonságos FTP, telnet és SCP szolgáltatások -# elérését az SSH (secure shell) használatával. +# Kifelé engedélyezzük az ssh/sftp/scp # (biztonságos telnet/rlogin/FTP) +# szolgáltatások # elérését az SSH (secure shell) használatával. pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Kifelé engedélyezzük a nem biztonságos telnet elérését. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Kifelé engedélyezzük FreeBSD CVSUP funkcióját. +# Kifelé engedélyezzük FreeBSD CVSUp funkcióját. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Kifelé engedélyezzük a pinget. pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Kifelé engedélyezzük a helyi hálózatról érkezõ whois kéréseket. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Minden mást eldobunk és naplózzuk az elsõ elõfordulásukat. -# Ezzel a szabállyal állítjuk be, hogy alapértelmezés szerint minden -# blokkolva legyen. +# Ez a szabály blokkol alapértelmezés szerint mindent. block out log first quick on dc0 all ################################################################# -# Az internet felõli felület (bejövõ kapcsolatok) +# Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Eldobjuk az összes olyan bejövõ forgalmat, amit hivatalosan nem # lehetne továbbítani vagy fenntartott címterülethez tartozik. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP block in quick on dc0 from 127.0.0.0/8 to any #helyi block in quick on dc0 from 0.0.0.0/8 to any #helyi block in quick on dc0 from 169.254.0.0/16 to any #DHCP block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast ##### Itt eldobunk egy rakás csúf dolgot ############ # Ezeket nem akarjuk a naplóban látni: # Eldobjuk a töredékcsomagokat. block in quick on dc0 all with frags # Eldobjuk a túlságosan rövid TCP csomagokat. block in quick on dc0 proto tcp all with short # Eldobjuk a forrás által közvetített (source routed) csomagokat. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Elutasítjuk az "OS fingerprint" kéréseket. # Naplózzuk az elsõ elõfordulást, így nálunk lesz a kíváncsiskodó # egyén IP-címe. block in log first quick on dc0 proto tcp from any to any flags FUP # Eldobunk mindent, aminek speciális beállításai vannak. block in quick on dc0 all with ipopts # Elutasítjuk a publikus pinget. block in quick on dc0 proto icmp all icmp-type 8 # Elutasítjuk az ident kéréseket. block in quick on dc0 proto tcp from any to any port = 113 # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Engedélyezzük a szolgáltatónk DHCP szerverétõl érkezõ forgalmat. # Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének # IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat. # Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a # "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím # megegyezik a kimenõ kapcsolatoknál megadott címmel. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk # van. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és # jelszavakat titkosítatlan formában közli az interneten keresztül. # Töröljük ezt a szabályt, ha nem használunk telnet szervert. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Befelé engedélyezzük az internetrõl érkezõ biztonságos FTP, telnet és SCP -# kapcsolatokat az SSH (secure shell) használatával. +# Befelé engedélyezzük az internetrõl # érkezõ ssh/sftp/scp (biztonságos +# telnet/rlogin/FTP) # kapcsolatokat az SSH (secure shell) használatával. pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Minden mást dobjuk el és naplózzuk az elsõ elõfordulásukat. # Az elsõ alkalom naplózásával elejét tudjuk venni a "Denial of # Service" típusú támadásoknak, amivel egyébként lehetséges lenne a # napló elárasztása. -# Ez a szabály gondoskodik arról, hogy a rendszer alapértelmezés -# szerint mindent eldobjon. +# Ez a szabály blokkol alapértelmezés szerint mindent. block in log first quick on dc0 all ################### Itt van a szabályok vége ############################## - <acronym>NAT</acronym> NAT IP maszkolás NAT hálózati címfordítás NAT - A NAT jelentése Network - Address Translation, vagyis hálózati + A NAT jelentése Network + Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati címfordítás és az IP maszkolás lényegben ugyanazt takarja. Az IPF címfordításért felelõs funkciójának köszönhetõen képesek vagyunk a tûzfal mögött elhelyezkedõ helyi hálózat számára megosztani az internet-szolgáltatól kapott publikus IP-címet. Sokakban felmerülhet a kérdés, hogy erre vajon mi szükségünk lehet. Az internet-szolgáltatók a magánszemélyeknek általában dinamikus IP-címeket osztanak ki. A dinamikus itt arra utal, hogy a címünk minden alkalommal változik, amikor betárcsázunk a szolgáltatóhoz vagy amikor ki- és - bekapcsoljuk a modemünket. Ez az IP-cím lesz az, - ami alapján az interneten elérhetõek - leszünk. + bekapcsoljuk a modemünket. Ez a dinamikus IP-cím + fog azonosítani minket az interneten. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel rendelkezünk. Ebben az esetben öt telefonvonalat kellene használnunk és mindegyik géphez elõfizetni az internetre. A hálózati címfordítás alkalmazásával azonban mindössze egyetlen elõfizetés kell. A gépek közül négyet hozzákötünk egy switch-hez és a switch-et pedig a fennmaradó géphez, amelyen &os; fut. Ez utóbbi lesz az így kialakított helyi hálózatunk átjárója. A tûzfalban mûködõ címfordítás segítségével a helyi hálózaton található gépek IP-címeit észrevétlenül át tudjuk fordítani a hálózatunk publikus IP-címére, ahogy a csomagok elhagyják az átjárót. A beérkezõ csomagok esetében mindez visszafelé történik meg. - A hálózati címfordítás - gyakran a szolgáltató engedélye vagy - éppen tudta nélkül történik, - és ha a szolgáltató rájön, - akkor a legtöbb esetben ez az elõfizetés - megszûntetésével jár. Az üzleti - felhasználók jóval többet fizetnek az - internet kapcsolatért és általában - egy olyan statikus IP-címblokkot kapnak, amely sosem - változik. A szolgáltatók az üzleti - célú felhasználás esetében - gyakran ajánlják és - támogatják a hálózati - címfordítást a belsõ - hálózatok számára. - Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok részére tartanak fenn. Az RFC 1918 szerint az alábbi IP-címtartományok használhatók a helyi hálózatban, mivel ezeken keresztül közvetlenül sosem lehet kijutni az internetre: Kezdõ IP: 10.0.0.0 - Záró IP: 10.255.255.255 Kezdõ IP: 172.16.0.0 - Záró IP: 172.31.255.255 Kezdõ IP: 192.168.0.0 - Záró IP: 192.168.255.255 IP<acronym>NAT</acronym> NAT IPFILTER ipnat A címfordításra vonatkozó szabályokat az ipnat paranccsal tudjuk betölteni. Az ilyen típusú szabályokat általában az /etc/ipnat.rules állományban találjuk. A részleteket lásd az &man.ipnat.1; man oldalán. Amikor a címfordítás üzembe helyezése után meg akarjuk változtatni a címfordítás szabályait, elõször a címfordítás szabályait tartalmazó állományt módosítsuk, majd a belsõ címfordítási szabályok és a címfordítási táblázatban szereplõ aktív bejegyzések törléséhez futassuk le az ipnat parancsot a beállítással. A címfordítási szabályok újratöltését egy ehhez hasonló paranccsal tudjuk elvégezni: &prompt.root; ipnat -CF -f /etc/ipnat.szabályok A címfordításhoz tartozó statisztikákat ezzel a paranccsal tudjuk lekérdezni: &prompt.root; ipnat -s A címfordítási táblázatban pillanatnyilag szereplõ összerendeléseket a következõ paranccsal tudjuk listázni: &prompt.root; ipnat -l A szabályok feldolgozásával és az aktív szabályokkal/bejegyzésekkel kapcsolatos információk részletezését így engedélyezhetjük: &prompt.root; ipnat -v A címfordítási szabályok A címfordítási szabályok nagyon rugalmasak és rengeteg olyan funkciót meg tudunk velük valósítani, ami az üzleti és otthoni felhasználók számára egyaránt hasznos. Itt most a szabályok felépítését csak egyszerûsítve mutatjuk be, leginkább a nem üzleti környezetek tekintetében. A szabályok komplett formai leírását az &man.ipnat.5; man oldalán találjuk. Egy címfordítási szabály tehát valahogy így néz ki: - map FELÜLET HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM + map INTERFÉSZ HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. - A FELÜLET helyére az - internet felé mutató külsõ felület - nevét írjuk be. + A INTERFÉSZ helyére + az internet felé mutató külsõ + interfész nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez például a 192.168.1.0/24. A PUBLIKUS_CÍM lehet egy külsõ IP-cím vagy a 0/32 speciális kulcsszó, amellyel a FELÜLET-hez rendelt IP-címre hivatkozunk. Hogyan mûködik a hálózati címfordítás A publikus cél felé haladó csomag megérkezik a helyi hálózatról. Miután a kimenõ kapcsolatokra vonatkozó szabályok átengedik, a címfordítás kapja meg a szerepet és fentrõl lefelé haladva nekilát alkalmazni a saját szabályait, ahol az elsõ egyezõ szerint cselekszik. A címfordítás a - szabályokat a csomaghoz tartozó felületre + szabályokat a csomaghoz tartozó interfészre és a forrás IP-címére illeszti. - Amikor a csomag felületének neve illeszkedik egy + Amikor a csomag interfészének neve illeszkedik egy címfordítási szabályra, akkor ezután a csomag forrás (vagyis a helyi hálózaton belüli) IP-címérõl igyekszik eldönteni, hogy a szabály nyilának bal oldalán szereplõ tartományba esik-e. Ha erre is illeszkedik, akkor a forrás IP-címét átírjuk a 0/32 kulcsszó alapján felderített publikus IP-címre. A címfordító rutin ezt feljegyzi a saját belsõ táblázatába, így amikor a csomag visszatér az internetrõl, akkor képes lesz visszafordítani az eredeti belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. - A címfordítás engedélyezése A címfordítás életre keltéséhez a következõket kell beállítanunk az /etc/rc.conf állományban. Elõször engedélyezzük a - gépünknek, hogy közvetítsen forgalmat a - felületek között: + gépünknek, hogy közvetítsen forgalmat az + interfészek között: gateway_enable="YES" Minden alkalommal indítsuk el a címfordításért felelõs IPNAT programot: ipnat_enable="YES" Adjuk meg az IPNAT számára a betöltendõ szabályokat: ipnat_rules="/etc/ipnat.rules" Hálózati címfordítás nagyon nagy helyi hálózatok esetében Az olyan helyi hálózatokban, ahol rengeteg PC található vagy több alhálózatot is tartalmaz, az összes privát IP-cím egyetlen publikus IP-címbe tömörítése igen komoly problémává tud dagadni és az azonos portok gyakori használata a helyi hálózatra kötött számítógépek között ütközéseket okoz. Két módon tudunk megoldást nyújtani erre a problémára. A használható portok kiosztása Egy normális címfordítási szabály valahogy így nézne ki: map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag - forrásportját az IPNAT változatlanul a - feldolgozás után hagyja. Ha ehhez még - hozzátesszük a portmap - kulcsszót, akkor ezzel utasítani tudjuk az - IPNAT-ot, hogy csak az adott tartományban - képezze le a forrásportokat. - Például a következõ szabály - hatására az IPNAT a forrásportokat egy - adott tartományon belül fogja + forrásportját az IPNAT + változatlanul a feldolgozás után hagyja. + Ha ehhez még hozzátesszük a + portmap kulcsszót, akkor ezzel + utasítani tudjuk az IPNAT-ot, hogy + csak az adott tartományban képezze le a + forrásportokat. Például a + következõ szabály hatására az + IPNAT a forrásportokat egy adott + tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, - amellyel az IPNAT önmagától - megállapítja, hogy milyen portokat tud - használni: + amellyel az IPNAT + önmagától megállapítja, hogy + milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Több publikus cím használata Minden nagyobb helyi hálózat esetében elérkezünk ahhoz a ponthoz, ahol már egyetlen publikus cím nem elég. Ha több publikus IP-címmel is rendelkezünk, akkor ezekbõl a címekbõl egy közös készletet hozhatunk létre, amibõl majd az IPNAT válogathat miközben a csomagok címeit átírja kifelé menetben. Például ahelyett, hogy a csomagokat egyetlen publikus IP-címre képeznénk le, ahogy itt tesszük: map dc0 192.168.1.0/24 -> 204.134.75.1 A hálózati maszk segítségével meg tudjuk adni IP-címek egy tartományát is: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 - A portok átirányítása Gyakran elõfordul, hogy van webszerverünk, levelezõ szerverünk, adatbázis szerverünk és névszerverünk, melyek a helyi hálózat különbözõ gépein futnak. Ebben az esetben a szerverekhez tartozó forgalmat is fordítanunk kell, illetve valamilyen módon a bejövõ forgalmat is át kell irányítanunk a helyi - hálózat megfelelõ gépeihez. Az IPNAT - ezt a gondot a hálózati + hálózat megfelelõ gépeihez. Az + IPNAT ezt a gondot a hálózati címfordítás átirányítást támogató funkcióival szünteti meg. Tegyük fel, hogy a 10.0.10.25 belsõ címen van egy webszerverünk, amelyhez a 20.20.20.5 publikus IP tartozik. Ilyenkor a következõ szabályt adjuk meg: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 vagy: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 Így tudjuk beállítani a 10.0.10.33 címmel rendelkezõ névszervert a kintrõl érkezõ névfeloldási kérések fogadására: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp Az FTP és a címfordítás Az FTP egy olyan õskövület, amely még az internet egy régi korszakából maradt fenn, amikor az egyetemek között még bérelt vonal létezett és az FTP szolgált a kutatók közt az állományok megosztására. Ez még abban az idõben történt, amikor a biztonság egyáltalán nem volt lényeges szempont. Az évek elõrehaladtával az FTP protokoll beleivódott a feltörekvõ internet gerincébe és a titkosítatlanul küldött azonosítóival és jelszavaival továbbra is ugyanolyan védtelen maradt. Az FTP két változatban, aktív és passzív módban képes mûködni. Az eltérés kettejük között az adatcsatorna megállapításában van. A passzív mód sokkal biztonságosabb, mivel ilyenkor az adatcsatornát az FTP kapcsolatot kezdeményezõ állítja be. Az FTP különbözõ módjainak magyarázatát és a köztük levõ különbséget a címen ismerhetjük meg részleteiben (angolul). Az IPNAT szabályai Az IPNAT egy speciális beépített FTP proxyval rendelkezik, amelyre a hálózati címfordítás leképezései között hivatkozhatunk. Képes figyelni az összes aktív vagy passzív FTP kapcsolathoz tartozó kimenõ kérést és ezekhez dinamikusan létrehozni olyan ideiglenes szûrési szabályokat, amelyek valóban csak az adatcsatornához felhasznált portokat tartalmazzák. Ezzel ki tudjuk küszöbölni az FTP azon káros hatását a tûzfalra nézve, hogy egyszerre túlságosan sok magasabb tartománybeli port legyen nyitva. Ez a szabály a belsõ hálózat összes FTP forgalmát lekezeli: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp Ez a szabály pedig az átjáróról érkezõ FTP forgalommal bírkózik meg: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Ez a szabály kezeli a belsõ hálózatról érkezõ összes nem FTP típusú forgalmat: map dc0 10.0.10.0/29 -> 0/32 Az FTP leképzésére vonatkozó szabály a szokásos leképzési szabály elé kerül. Az összes csomag fentrõl haladva az elsõ illeszkedõ szabály alapján kerül feldolgozásra. - Elõször a felület nevét + Elõször az interfész nevét vizsgáljuk, majd a belsõ hálózatbeli forrás IP-t, végül azt, hogy a csomag egy FTP kapcsolat része. Ha minden paraméterében megfelel, akkor az FTP proxy készít egy ideiglenes szûrési szabályt hozzá, amellyel az FTP kapcsolathoz tartozó csomagok mind a két irányba képesek lesznek vándorolni, természetesen a címfordítással együtt. Az összes többi bentrõl érkezõ csomag átlép ezen a szabályon és - megáll a harmadiknál, ahol a felületnek - és forrás IP-nek megfelelõen - átfordítjuk a címét. - + megáll a harmadiknál, ahol az + interfésznek és forrás IP-nek + megfelelõen átfordítjuk a + címét. Az IPNAT szûrési szabályai FTP-re Az FTP esetében csak egyetlen szûrési szabályra van szükségünk a hálózati címfordításba épített FTP proxy használatához. FTP proxy nélkül az alábbi három szabály kellene: # Kifelé engedélyezzük a belsõ gépek FTP elérést az internet irányába, # aktív és passzív módokban. pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli # adatcsatornákat. pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Aktív módban beengedjük az FTP szervertõl érkezõ adatcsatornát. pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state - IPFW tûzfalak IPFW - Az IPFIREWALL (IPFW) a &os; által támogatott - tûzfalazó alkalmazás, melyet a &os; Projektben - résztvevõ önkéntesek fejlesztettek ki - és tartanak karban. Régi típusú, - állapottartás nélküli szabályokat - használ, és az itt használatos - szabályírási technikát - egyszerû állapottartó + Az IPFIREWALL (IPFW) a &os; által + támogatott tûzfalazó alkalmazás, melyet a + &os; Projektben résztvevõ önkéntesek + fejlesztettek ki és tartanak karban. Régi + típusú, állapottartás + nélküli szabályokat használ, és + az itt használatos szabályírási + technikát egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként szolgáló szabályrendszere (ez az /etc/rc.firewall és /etc/rc.firewall6 állományokban található meg) annyira egyszerû, hogy komolyabb módosítások nélkül nem ajánlatos használni. Ez a példa nem tartalmaz állapottartó szûrést, ami viszont a legtöbb esetben kívánatos lenne, ezért ezt a szakaszt nem erre alapozzuk. Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tûzfalépítõk tudását. Az IPFW elsõsorban olyan szakemberek vagy szakmailag elõrehaladott felhasználók számára készült, akiknek speciális csomagszûrési igényeik vannak. A különbözõ protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedõ ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein. Az IPFW hét komponensbõl épül fel, melyek közül az elsõdleges a rendszermag tûzfalazásért felelõs szabályfeldolgozó és a hozzátartozó csomagnyilvántartás, majd ezt követi a naplózás, a hálózati címfordítást aktiváló - divert szabály, valamint a komolyabb + divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, - a továbbküldésre alkalmas fwd - szabály, a hálózati hidak + a továbbküldésre alkalmas fwd + rule szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW egyaránt használható IPv4 és IPv6 esetén. Az IPFW engedélyezése IPFW engedélyezése Az IPFW az alap &os; telepítésben külön, futás idõben betölthetõ modulként érhetõ el. Ha az rc.conf állományban megadjuk a firewall_enable="YES" beállítást, akkor a rendszer indulásakor ezt a modult dinamikusan betölti. Az IPFW-t csak akkor kell a &os; rendszermagjába beépítenünk, ha szükségünk van a címfordítási funkciójára is. Ha tehát az rc.conf állományban megadtuk a firewall_enable="YES" sort és újraindítottuk a számítógépünket, akkor a következõ fehérrel kiemelt üzenet fog megjelenni a rendszerindítás során: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled A logging disabled üzenetbõl kiderül, hogy a modul nem végez naplózást. A naplózást és a hozzátartozó részletesség szintjét úgy tudjuk beállítani, ha az /etc/sysctl.conf állományba felvesszük a következõ sorokat, amivel a következõ indításkor már mûködni fog: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 A rendszermag beállításai a rendszermag beállításai IPFIREWALL a rendszermag beállításai IPFIREWALL_VERBOSE a rendszermag beállításai IPFIREWALL_VERBOSE_LIMIT IPFW a rendszermag beállításai Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetõségeket, akkor egyáltalán nem szükséges a &os; rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítõ információként tüntettük fel. options IPFIREWALL Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként. options IPFIREWALL_VERBOSE Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni. options IPFIREWALL_VERBOSE_LIMIT=5 Ez az érték korlátozza a &man.syslogd.8; segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket. a rendszermag beállításai IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Ezen beállítás hatására a tûzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet - jól, amikor még csak ismerkedünk a - tûzfallal. + jól, amikor elõször beállítjuk a + tûzfalat. a rendszermag beállításai IPDIVERT options IPDIVERT Ezzel a beállítással engedélyezzük a címfordítás használatát. Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövõ csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni. Az <filename>/etc/rc.conf</filename> beállításai Így tudjuk engedélyezni a tûzfalat: firewall_enable="YES" A &os;-hez mellékelt alapértelmezett tûzfaltípusok közül az /etc/rc.firewall állomány átolvasásával tudunk választani, és megadni az alábbi helyett: firewall_type="open" A következõ értékek állnak rendelkezésünkre: open — átengedi az összes forgalmat client — csak ezt a gépet védi simple — az egész hálózatot védi - closed — a helyi felület - kivételével minden IP alapú forgalmat - tilt + closed — a helyi + interfész kivételével minden IP + alapú forgalmat tilt UNKNOWN — tiltja a tûzfal szabályainak betöltését állománynév — a tûzfal szabályait tartalmazó állomány abszolút elérési útvonala Két különbözõ módon lehet betölteni a saját ipfw szabályainkat. Az egyik közülük, ha a firewall_type változóban megadjuk a tûzfal szabályait tartalmazó állomány abszolút elérési útvonalát, az &man.ipfw.8; parancssori beállításai nélkül. Egy egyszerû szabályrendszer lehet például a következõ: add block in all add block out all Másrészrõl az firewall_script változóban is megadhatjuk azt a szkriptet, amelyben a rendszerindítás során meghívjuk ipfw parancsot. Az iménti szabályrendszert az alábbi szkripttel tudjuk kiváltani: #!/bin/sh ipfw -q flush ipfw add block in all ipfw add block out all Ha a firewall_type változó client vagy simple értékét használjuk, akkor az /etc/rc.firewall állományban található alapértelmezett szabályokat érdemes átvizsgálnunk, hogy kellõen illeszkednek-e az adott géphez. Hozzátennénk, hogy a fejezetben szereplõ példák azt feltételezik, hogy a firewall_script értéke az /etc/ipfw.rules állomány. A naplózás így engedélyezhetõ: firewall_logging="YES" A firewall_logging változó egyedül csak annyit tesz, hogy beállítja a net.inet.ip.fw.verbose sysctl változónak az 1 értéket (lásd ). A napló korlátozására nincs külön változó az rc.conf állományon belül, de az /etc/sysctl.conf állomány segítségével és manuálisan be tudjuk állítani a hozzátartozó változót: net.inet.ip.fw.verbose_limit=5 Amennyiben a gépünk átjáróként viselkedik, tehát a &man.natd.8; segítségével címfordítást végez, a ban olvashatunk utána, hogy ehhez az /etc/rc.conf állományban milyen beállításokat kell megadnunk. Az IPFW parancs ipfw Normál esetben az ipfw parancs használatos arra, hogy a tûzfal mûködése közben az aktív belsõ szabályai közé vegyünk fel vagy töröljünk közülük manuálisan bejegyzéseket. Ennek a módszernek az egyedüli hátránya, hogy az így végrehajtott módosítások el fognak veszni a rendszer leállításával. Itt inkább azt a megoldást javasoljuk, hogy az összes szabályt tegyük bele egy állományba és a rendszerindítás során ezt töltsük be, majd ha változtatni akarunk a tûzfalon, akkor ezt az állományt módosítsuk és a régiek törlésével töltsük be újra az egész szabályrendszert. Az ipfw parancs mellesleg remekül használható a jelenleg futó tûzfalszabályok megjelenítésére a konzolon. Az IPFW nyilvántartásában az egyes szabályokhoz dinamikusan jönnek létre számlálók, amelyek a rá illeszkedõ csomagokat számolják. A tûzfal tesztelése folyamán a szabályok és hozzátartozó számlálók lekérdezése a megfelelõ mûködés ellenõrzésének egyik lehetséges módja. A szabályokat így tudjuk egymás után felsoroltatni: &prompt.root; ipfw list A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni: &prompt.root; ipfw -t list - A nyilvántartás lekérdezésekor a - szabályok mellett az illeszkedõ csomagok - száma is láthatóvá válik. Az - elsõ sorban a szabály száma szerepel, majd - ezt követi rendre az illeszkedõ kimenõ és + A következõ példában a + nyilvántartási információkat + kérdezzük le, ekkor a szabályok mellett az + illeszkedõ csomagok száma is + láthatóvá válik. Az elsõ + sorban a szabály száma szerepel, majd ezt + követi rendre az illeszkedõ kimenõ és bejövõ csomagok mennyisége, valamint végül maga a szabály. &prompt.root; ipfw -a list A statikus szabályok mellett a dinamikusakat így lehet kilistázni: &prompt.root; ipfw -d list A lejárt dinamikus szabályokat is meg tudjuk nézni: &prompt.root; ipfw -d -e list A számlálók nullázása: &prompt.root; ipfw zero Csak a SZÁM sorszámú szabályhoz tartozó számlálók nullázása: &prompt.root; ipfw zero SZÁM Szabályrendszerek az IPFW-ben - Egy szabályrendszer lényegében nem - több, mint ipfw szabályok egy - csoportja, amelyekben a csomagokat tartalmuktól - függõen továbbengedjük vagy eldobjuk. A - gépek közti kétirányú - csomagváltás egy kapcsolat - létrejöttének számít. A - tûzfalszabályok a csomagokat kétszer - dolgozzák fel: elõször amikor az - internetrõl megérkeznek, másodjára - pedig akkor, amikor visszatérnek az internetre. Minden - egyes TCP/IP szolgáltatást - (vagyis a telnet, www, levelezés stb.) meghatároz - a saját protokollja és a - hozzátartozó port száma. Ez az az - alapvetõ szûrési feltétel, ami - alapján a szolgáltatásokhoz - engedélyezését vagy tiltását - megvalósító szabályokat - megalkotjuk. + Az IPFW esetében a szabályrendszer olyan + szabályokból áll, amelyek a + csomagokról tartalmuk alapján eldöntik, hogy + át kell engedni vagy vissza kell tartani. A gépek + közt két irányban áramló + csomagok egy munkamenet alapú társalgást + képeznek. A tûzfalhoz tartozó + szabályrendszer egyaránt feldolgozza a + internetrõl a hálózatunk felé + igyekvõ csomagokat, illetve a hálózatunk + ezekre adott válaszait. Az egyes + TCP/IP szolgáltatásokat (mint + például telnet, www, levelezés stb.) a + hozzájuk tartozó protokol és + szabványos (fogadó) portszám írja + le. Ezekre a forrásról általában + valamilyen nem szabványos (magasabb + értékû) portról érkeznek + csomagok. Ekkor a kommunikáció összes + paramétere (vagyis a portok és címek) + bármelyike alapján definiálhatunk + blokkolást vagy továbbengedést + leíró szabályokat. IPFW a szabályok feldolgozásának sorrendje Amikor egy csomag eléri a tûzfalat, a szabályrendszer elsõ szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentrõl lefelé egyesével, a sorszámuknak megfelelõ növekvõ sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejezõdik. Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen - szabályra sem illeszkedik, akkor az - ipfw 65535-ös sorszámú - állandó szabálya fogja elcsípni, - amely feladata szerint eldobja az összes hozzá - beérkezõ csomagot anélkül, hogy - bármit is válaszolna a csomag - feladójának. + szabályra sem illeszkedik, akkor az IPFW 65535-ös + sorszámú állandó szabálya + fogja elcsípni, amely feladata szerint eldobja az + összes hozzá beérkezõ csomagot + anélkül, hogy bármit is válaszolna a + csomag feladójának. A keresés a count, skipto és tee szabályok után még folytatódik. - Az itt szereplõ utasítások az - állapottartó keep state, a - limit, - in/out és - via szabályokra - építkeznek. Ezek szolgálnak az - inkluzív tûzfalak - megvalósításának alapvetõ - eszközeiként. - - Az inkluzív tûzfal csak a szabályoknak - megfelelõ szolgáltatásokat engedélyez. - Segítségével meg tudjuk határozni, - hogy a tûzfal mögül milyen - szolgáltatásokat érhetünk el az - interneten, valamint azt is megadhatjuk vele, hogy az - internetrõl melyik szolgáltatásokhoz - férhetnek hozzá a saját belsõ - hálózatunkban. Felépítése - szerint minden mást tilt. Az inkluzív - jellegû tûzfalak sokkal bizontságosabbak az - exkluzív tûzfalaknál, ezért itt most - csak ilyen típusú szabályrendszerekkel - foglalkozunk. + Az itt szereplõ utasítások + különbözõ állapottartásra + vonatkozó opciókat, például a + keep state, limit, + in, out és + via kulcsszavakat tartalmazó + szabályokon alapulnak. Lényegében ezt + tekinthetjük az inkluzív típusú + tûzfalak kiindulási alapjaként. A tûzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkrõl. A szabályok felépítése IPFW a szabályok felépítése Az itt bemutatásra kerülõ szabályok felépítését csak olyan mértékig részletezzük, ami elengedõ a szabványos inkluzív típusú tûzfalak kialakításához. A szabályok felépítésének pontos leírását az &man.ipfw.8; man oldalán találhatjuk meg. A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy elõre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak. A # egy megjegyzés kezdetét jelzi, mely egyaránt megjelenhet egy külön sorban, vagy egy szabályt tartalmazó sor végén. Az üres sorok nem vesznek részt a feldolgozásban. PARANCS SZABÁLY_SZÁM CSELEKVÉS NAPLÓZÁS SZÛRÉS ÁLLAPOTTARTÁS PARANCS Minden új szabály elõttt az add (mint hozzáadás) parancsnak kell szerepelni, amellyel a belsõ táblázatba tudjuk felvenni. SZABÁLY_SZÁM A szabályokhoz mindig tartozik egy sorszám is. CSELEKVÉS A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzátartozó szûrési feltételeknek. allow | accept | pass | permit A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedõ csomag kilép a tûzfalból. Ez a szabály megállítja a keresést. check-state A csomagot a dinamikus szabályokat tároló táblázattal veti össze. Ha itt egyezést talál, akkor végrehajtja az egyezõ dinamikus szabályhoz tartozó cselekvést, minden más esetben továbblép a következõ szabályra. Ennek a szabálynak nincs illeszthetõ paramétere. Ha a szabályrendszerben nem szerepel ilyen, akkor a dinamikus szabályok vizsgálatát az elsõ keep-state vagy limit használatánál vonja be a rendszer. deny | drop Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedõ csomagokat el kell dobni. Ebben az esetben a keresés befejezõdik. NAPLÓZÁS log vagy logamount Amikor egy csomag egy log kulcsszót tartalmazó szabályra illeszkedik, akkor a rendszernaplóban egy üzenet keletkezik a security (biztonság) funkción keresztül. A naplóba ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó - logamount paraméter + logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl változóból fog származni. A nulla érték mind a két esetben megszünteti ezt a korlátozást. Ha elértük a korlátot, akkor a naplózást úgy tudjuk újra engedélyezni, ha töröljük a naplózáshoz tartozó számláló értékét, lásd az ipfw reset log parancsot. A naplózás mindig az összes paraméter illeszkedésének ellenõrzése után történik, de még a cselekvés (accept, deny) elvégzése elõtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk. SZÛRÉS Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különbözõ tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következõ általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben: udp | tcp | icmp Bármilyen más olyan protokoll is megadható, amely megtalálható az /etc/protocols állományban. Ezzel adjuk a csomaghoz tartozó protokollt. Használata kötelezõ. from forrás to cél Mind a from és to kulcsszavak IP-címek illesztésére alkalmasak. A szabályoknak tartalmazniuk kell a forrás ÉS a cél paramétereket is. Az any egy olyan kulcsszó, amely tetszõleges IP-címre illeszkedik. A me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez - a gép) adott felülethez tartozó - IP-címét jelöli, mint ahogy a from - me to any, from any to me, - from 0.0.0.0/0 to any, from any to - 0.0.0.0/0, from 0.0.0.0 to any, - from any to 0.0.0.0 vagy from me to - 0.0.0.0 paraméterekben. Az IP-címek - numerikus pontozott formában a hálózati - maszk hosszával együtt, vagy egyszerûen - csak pontozott formában adhatóak meg. A - hálózati maszkok - megállapításában a címen - található honlap nyújthat - segítséget (angolul). + a gép) adott interfészhez tartozó + IP-címét jelöli, mint ahogy a + from me to any, from any to + me, from 0.0.0.0/0 to any, + from any to 0.0.0.0/0, from + 0.0.0.0 to any, from any to + 0.0.0.0 vagy from me to 0.0.0.0 + paraméterekben. Az IP-címek numerikus + pontozott formában a hálózati maszk + hosszával együtt (CIDR-jelöléssel), + vagy egyszerûen csak pontozott formában + adhatóak meg. A hálózati maszkok + megállapításában a net-mgmt/ipcalc port lehet + segítségünkre. Errõl bõvebb + információkat a segédprogram + honlapján, a címen + találhatunk (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a - TCP vagy UDP) adhatjuk meg. Fontos, hogy - itt annak a szolgáltatásnak a - portszámát adjuk meg, amelyre a szabály - vonatkozik. A szolgáltatás (az + TCP vagy UDP) adhatjuk + meg. Fontos, hogy itt annak a szolgáltatásnak + a portszámát adjuk meg, amelyre a + szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma helyett. in | out A beérkezõ valamint a kimenõ csomagokat adhatjuk meg ezen a módon. Itt az in és out kulcsszavak, melyeket kötelezõ megadni a szabály részeként. via - felület + interfész - Név szerint az adott felületen + Név szerint az adott interfészen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó - hatására a használt felület is + hatására a használt interfész is számítani fog a csomag feldolgozása során. setup Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani. keep-state Ez egy kötelezõ kulcsszó. Feldolgozásakor a tûzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni. limit {forráscím | forrásport | célcím | célport} A tûzfal csak N darab, a szabálynak megfelelõ azonos paraméterû kapcsolatot fog átengedi. Itt egy vagy több forrás- és célcím valamint forrás- és célport adható meg. A limit és a keep-state egy szabályon belül nem használható. A limit ugyanazokat az állapottartó funkciókat képviseli, mint a keep-state, csak a saját kiegészítéseivel megtoldva. ÁLLAPOTTARTÁS IPFW állapottartó szûrés Az állapottartó szûrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldõje és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérõ összes csomag hamisnak minõsül és automatikusan eldobásra kerül. A check-state segítségével ellenõrizhetjük, hogy az adott csomag a IPFW szerint megfelel-e valamelyik dinamikusan leképzett szabálynak. Ha egyezik valamelyikõjükkel, akkor a csomag a tûzfalból kilépve folytatja útját és a kommunikációban soron következõ csomag számára létrejön egy másik dinamikus szabály. Ha nincs egyezés, akkor csomag feldolgozása a szabályrendszer következõ szabályánál folytatódik. A dinamikus szabályokat kezelõ rutin sebezhetõ, mivel ha egyszerre nagy mennyiségû SYN csomagot küldünk, akkor olyan sok dinamikus bejegyzés keletkezik, hogy egyszerûen kifogyunk a rendelkezésre álló erõforrásokból. A &os; fejlesztõi azonban az ilyen természetû támadások kivédésére is felkészítették, és kialakították belõle a limit opciót. Alkalmazásával le tudjuk korlátozni az egyszerre folyó párhuzamos kapcsolatok számát a forrás vagy a cél a limit paraméternél megadott mezõinek és a csomag IP-címe alapján. Így az adott szabályhoz és IP-címhez csak elõre rögzített mennyiségû nyitott állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. - A tûzfal üzeneteinek naplózása IPFW naplózás A naplózás elõnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben. Azonban hiába engedélyezzünk önmagában a naplózást, attól az IPFW még saját magától nem fog naplózást elõíró szabályokat gyártani. A tûzfal karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a - log kulcsszót. + log kulcsszót. Általában csak az eldobással - járó deny + járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy oldják meg ezt, hogy a szabályrendszer utolsó szabályaként lemásolják az ipfw alapértelmezett mindent eldobunk szabályát és a naplózást adják meg benne. Ezen a módon fény derül azokra a csomagokra, amelyek a szabályrendszerben semmire sem illeszkedtek. A naplózás azonban egy kétélû fegyver, mivel ha nem vagyunk elég körültekintõek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legõsibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsõdleges konzol képernyõjére is kiíródnak, ami egy idõ után idegesítõ tud lenni. A rendszermag IPFIREWALL_VERBOSE_LIMIT=5 beállításával azonban képesek vagyunk korlátozni azokat a rendszernapló felé küldött egymás után következõ üzeneteket, amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt a beállítást megadjuk a rendszermag fordításánál, akkor az egyes szabályokhoz az általa meghatározott értéken felül nem jön létre több hasonló üzenet. Hiszen semmi sem derül ki 200 teljesen azonos naplóüzenetbõl. Például, ha az egyes szabályokhoz legfeljebb öt egymást követõ üzenetet engedélyezünk, akkor a többi fennmaradó azonos üzenetet összeszámolja a rendszer és a következõ módon közvetíti a rendszernaplózó szolgáltatás felé: last message repeated 45 times Ami magyarul így hangzik: az utolsó üzenet 45 alkalommal ismétlõdött meg Az összes csomagokkal kapcsolatos naplózás alapértelmezés szerint a /var/log/security állományba kerül, amelyet az /etc/syslog.conf állomány definiál. Szabályokat tartalmazó szkript készítése A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb elõnye, hogy a tûzfal szabályai így egyszerre cserélhetõek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszõleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetõségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következõkben fogunk egy konkrét példát látni. A szkript felépítése kompatibilis a - sh, csh és - tcsh parancsértelmezõkkel. A - szimbolikus mezõk helyettesítését a - $ vagyis dollárjel vezeti be. Maguk a - szimbolikus mezõk nem tartalmazzák a $ - elõtagot. A szimbolikus mezõk - értékeit "kettõs idézõjelek" - között kell megadni. + &man.sh.1;, &man.csh.1; és &man.tcsh.1; + parancsértelmezõkkel. A szimbolikus mezõk + helyettesítését a $ vagyis + dollárjel vezeti be. Maguk a szimbolikus mezõk + nem tartalmazzák a $ elõtagot. A + szimbolikus mezõk értékeit "kettõs + idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: ####### itt kezdõdik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults -oif="tun0" # a kimenõ felület +oif="tun0" # a kimenõ interfész odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejezõdik be az ipfw szabályait tartalmazó szkript ###### Ezzel készen is vagyunk. Most ne törõdjünk a példában szereplõ szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni. Ha az iménti példát az /etc/ipfw.rules állományba mentettük el, akkor az alábbi parancs kiadásával tudjuk újratölteni a benne szereplõ szabályokat: &prompt.root; sh /etc/ipfw.rules Az /etc/ipfw.rules állományt egyébként tetszõleges néven hívhatjuk és bárhová rakhatjuk. Ugyanez természetesen elérhetõ a következõ parancsok egymás utáni begépelésével is: &prompt.root; ipfw -q -f flush &prompt.root; ipfw -q add check-state &prompt.root; ipfw -q add deny all from any to any frag &prompt.root; ipfw -q add deny tcp from any to any established &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - Állapottartó szabályrendszerek A most következõ címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés - szerint tiltanak. Minden tûzfalhoz legalább - két felület tartozik, és a - mûködéséhez ezek mindegyikéhez - meg kell adnunk szabályokat. + szerint tiltanak. A komplett hálózati + szegmensek védelmére + összeállított tûzfalaknak + legalább két interfészük van, + amelyek mindegyikéhez tartoznia kell + szabályoknak a megfelelõ + mûködéshez. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a - lo0 nevû felületen + lo0 nevû interfészen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan szabályoknak, amelyek gondoskodnak ezen speciális belsõ csomagok zavartalan közlekedésérõl. - Az internet felé csatlakozó felület + Az internet felé csatlakozó interfész lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ - kéréseket. Ez lehet a PPP esetében a - tun0 eszköz, vagy a DSL-, - illetve kábelmodemhez csatlakozó + kéréseket. Ez lehet a PPP + esetében a tun0 eszköz, + vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tûzfal mögött található belsõ helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról. A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes - szabadon forgalmazó felület, a publikus - kimenõ és a publikus bejövõ felület - csoportjába. - - A publikus felületekhez tartozó csoportokban - úgy kell rendeznünk a szabályokat, hogy - elõre kerüljenek a gyakrabban használtak - és hátra a kevésbé - használtak, valamint a csoportok utolsó - szabálya blokkoljon és naplózzon minden - csomagot az adott felületen és - irányban. + szabadon forgalmazó interfész, a publikus + kimenõ és a publikus bejövõ + interfész csoportjába. + + A publikus interfészekhez tartozó + csoportokban úgy kell rendeznünk a + szabályokat, hogy elõre kerüljenek a + gyakrabban használtak és hátra a + kevésbé használtak, valamint a csoportok + utolsó szabálya blokkoljon és + naplózzon minden csomagot az adott interfészen + és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó csoport csak olyan allow típusú szabályokat tartalmaz, amelyek szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes - szabályban megjelennek a proto, - port, - in/out, - via és keep - state opciók. A proto + szabályban megjelennek a proto, + port, + in/out, + via és keep + state opciók. A proto tcp szabályokban emellett szerepel még - egy setup opció is, amellyel a + egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. - A bejövõ felülettel foglalkozó - csoport elsõsorban a kéretlen csomagokat igyekszik - blokkolni, aminek két oka is van. Elõször is - a blokkolt csomagról elképzelhetõ, hogy - egyébként érvényes és - valamelyik késõbbi szabály fogja - hitelesíteni. Másodszor ezekkel a - szabályokkal olyan szabálytalan - idõközönként érkezõ - csomagokat tudunk eldobni, amelyeket nem akarunk a - naplóban feljegyezni, és ennek - segítségével távoltartjuk az - utolsó, mindent blokkoló és - naplózó szabálytól. A csoport - utolsó szabálya dobja el és - naplózza a hozzá befutó összes - csomagot, illetve ezen keresztül - rögzíthetünk olyan jogi - bizonyítékot, amellyel hivatalosan fel tudunk - lépni a rendszerünket támadó emberek - ellen. - - Amit még nem szabad elfelejtenünk: a - tûzfal az eldobott csomagokra egyáltalán - nem válaszol, egyszerûen csak eltûnnek, - mintha sosem lettek volna. Ennek köszönhetõen - a támadóknak fogalma sem lesz arról, hogy - a csomagjaik elérték-e a rendszerünket. - Minél kevesebbet tudnak a támadók a - rendszerünkrõl, annál biztonságosabb. + A bejövõ forgalmat vezérlõ + szabályrendszerben elõször az eldobni + kívánt csomagokat kell megadni, aminek + két eltérõ oka van. Elõször is + elõfordulhat, hogy a veszélyes csomagok + részleges illeszkedés miatt szabályosnak + tûnnek. Az ilyen csomagokat értelemszerûen + nem lenne szabad beengedni a szabályok részleges + megfelelése alapján. A másodszor az + eleve ismerten problémás és + értelmetlen csomagokat csendben el kellene vetni, + mielõtt a szakaszhoz tartozó utolsó + szabály fogná meg és + naplózná. Ez az utolsó szabály + egyébként szükség esetén + felhasználható a támadók elleni + bizonyítékok + begyûjtésére. + + A másik, amire még oda kell figyelnünk, + hogy a blokkolt csomagok esetében semmilyen + válasz nem keletkezzen, egyszerûen csak + tûnjenek el. Így a támadó nem fogja + tudni, hogy a csomagjai vajon elérték-e a + rendszerünket. Minél kevesebb + információt tudnak összegyûjteni a + rendszerünkrõl a támadók, annál + biztonságosabbnak tekinthetõ. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy + url="http://www.securitystats.com/tools/portsearch.php"> címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . - + url="http://www.simovits.com/trojans/trojans.html">. Példa egy inkluzív szabályrendszerre A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív - típusú. Ha ezt használjuk, nem - járunk rosszul. Egyszerûen csak annyit kell + típusú. Éles rendszereken is nyugodtan + alkalmazhatjuk. Egyszerûen csak annyit kell tennünk, hogy megjegyzésbe tesszük az olyan szolgáltatásokra vonatkozó szabályokat, amelyeket nem akarunk engedélyezni. Amikor pedig olyan üzenetek jelennek meg a naplóban, amelyeket nem akarunk tovább látni, a bejövõ kapcsolatokhoz vegyünk fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 - felületet arra a hálózati + interfészt arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A - felhasználói PPP esetében ez a - tun0. + felhasználói PPP + esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta rendszerszerûséget: Mindegyik sorban, ahol az internet felé nyitunk - meg egy kapcsolatot, a + meg egy kapcsolatot, a keep-state opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése - tartalmazza a opciót az + tartalmazza a limit opciót az elárasztások kivédése miatt. Az összes szabályban az - vagy az + in vagy az out paraméterrel megadjuk szûrni kívánt forgalom irányát. Az összes szabályban szerepel a - paraméterrel a csomagokat - továbbító felület neve. + via paraméterrel a csomagokat + továbbító interfész + neve. Az alábbi szabályokat tegyük az /etc/ipfw.rules állományba. ############## Itt kezdõdnek az IPFW szabályai ########################## # Kezdés elõtt töröljük az összes aktív szabályt. ipfw -q -f flush # Állítsuk be a parancsok további szükséges opciót. cmd="ipfw -q add" pif="dc0" # az internethez csatlakozó - # felület neve + # interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó -# felület nevére. +# interfész nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ -# A rendszer belsõ felületét se szûrjük. +# A rendszer belsõ interfészét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 ################################################################ # A csomagot engedjük át a tûzfalon, ha korábban már felvettünk # hozzá egy dinamikus szabályt a keep-state opcióval. ################################################################ $cmd 00015 check-state ################################################################ -# Az internet felé forgalmazó felület (kimenõ kapcsolatok) +# Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################ # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe # legyen. Ha a szolgáltatónak több névszervere is van, akkor # másoljuk le ezeket a sorokat és az /etc/resolv.conf # állományban található IP-címeket helyettesítsük be. $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Kábel/DSL konfigurációk esetében kifelé engedélyezzük a # szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói # PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész # csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a # beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük # ki az elsõ szabályt, a másodikba írjuk bele a címet és # engedélyezzük. $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW # funkció elérését. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkció # elérését TLS SSL használatával. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük a e-mailek küldését és fogadását. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP) # funkcióit. Ezzel lényegében a rendszeradminisztrátornak # ,,ISTENI'' jogokat adunk. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 00250 allow icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást # (vagyis a hírcsoportokat) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # elérését az SSH (secure shell) használatával. $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük a whois szolgáltatást. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # Dobjuk el és naplózzunk mindent, ami megpróbál kijutni. # Ez a szabály gondoskodik róla, hogy alapértelmezés szerint # mindent blokkoljunk. $cmd 00299 deny log all from any to any out via $pif ################################################################ -# Az internet felõli felület (bejövõ kapcsolatok) +# Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################ # Blokkoljunk minden olyan bejövõ forgalmat, amely a fenntartott # címtartományok felé tart. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # A nyilvános pingek tiltása. $cmd 00310 deny icmp from any to any in via $pif # Az ident szolgáltatás tiltása. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Eldobjuk az összes késõn érkezõ csomagot. $cmd 00330 deny all from any to any frag in via $pif # Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus # szabálynak sem felelnek meg. $cmd 00332 deny tcp from any to any established in via $pif # Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben # a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az # egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet. # Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges. # Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem # kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a # kimenõ kapcsolatoknál is. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk # is van. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # típusú kapcsolatokat az internetrõl. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az # azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak. # Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes többi kintrõl érkezõ csomagot. $cmd 00499 deny log all from any to any in via $pif # Alapértelmezés szerint dobjuk el mindent. Az ide érkezõ # csomagokat is naplózzuk, amibõl többet is ki tudunk majd # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### - Példa hálózati címfordításra és állapottartásra címfordítás és az IPFW Az IPFW címfordító funkciójának kihasználásához további konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell - adnunk az option IPDIVERT sort a többi + adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. Emellett még az /etc/rc.conf állományban is engedélyezni kell az IPFW alapvetõ funkcióit. natd_enable="YES" # engedélyezzük a címfordításért felelõs démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok - használata a divert natd + használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. A check-state és divert natd szabályok helye kritikus a megfelelõ mûködés tekintetében. Az eddig megszokott egyszerû viselkedés itt már nem érvényesül. Bevezetünk egy új cselekvést is, amelynek a neve skipto. A skipto parancs használatához elengedhetetlen a szabályok sorszámozása, mivel pontosan tudnunk kell, hogy a skipto hatására hova kell ugrania a vezérlésnek. A következõ példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk. A feldolgozás a szabályokat tartalmazó állomány tetején található elsõ szabállyal kezdõdik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szûrési feltételek valamelyikének eleget nem tesz és távozik a tûzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenõ és bejövõ csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen - bejövõ) és az érintett felület - megnevezése. Emellett azt is vegyük észre, - hogy az összes kifelé irányuló - kapcsolatlétrehozási kérés az - 500-as sorszámú szabályhoz fog ugrani a + bejövõ) és az érintett + interfészt megnevezése. Emellett azt is + vegyük észre, hogy az összes kifelé + irányuló kapcsolatlétrehozási + kérés az 500-as sorszámú + szabályhoz fog ugrani a címfordítás elvégzéséhez. Tegyük fel, hogy a helyi hálózatunkon levõ felhasználók szeretnek honlapokat nézgetni az interneten. A honlapok a 80-as porton keresztül kommunikálnak. Tehát amikor egy ilyen csomag eléri a tûzfalat, nem fog illeszkedni a 100-as szabályra, mert a fejléce szerint kifelé halad és nem befelé. A 101-es szabályon is átlép, mivel ez az elsõ csomag, így a dinamikus állapottartó táblázatban sem szerepel még. A csomag végül a 125-ös szabályra fog illeszkedni: kifelé halad az internetre csatlakozó hálózati kártyán. A csomagban azonban még mindig az eredeti forrás IP-címe található, amely a helyi hálózat egyik gépére hivatkozik. A szabály illeszkedésekor két cselekvés is - végbemegy. A opció + végbemegy. A keep-state opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített - bejegyzésnek, ami ebben az esetben a skipto - 500 (ugorjunk az 500-as + bejegyzésnek, ami ebben az esetben a skipto + 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne felejtsük el, nagyon fontos! A csomag ezután eljut a céljához, és visszatérve ismét belép a szabályrendszer tetején. Ezúttal illeszkedni fog a 100-as szabályra és a cél IP-címét visszafordítjuk a helyi hálózatunk megfelelõ gépének címére. Ezután a check-state szabályhoz kerül, amely megtalálja a dinamikus szabályok között és továbbengedi a belsõ hálózatra. Ezzel visszakerül a küldõ géphez, amely egy újabb csomagot küld egy újabb adatszeletet kérve a távoli szervertõl. Ekkor már a check-state szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a - korábban letárolt skipto 500 + korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. Az bejövõ oldalon minden, ami egy korábban kialakult kapcsolat részeként érkezik, automatikusan a check-state és a megfelelõ helyre rakott divert natd szabályok által dolgozódik fel. Itt mindössze a rossz csomagok eldobásával és a hitelesített szolgáltatások elérésének biztosításával kell foglalkoznunk. Például a tûzfalon egy webszerver fut, és azt szeretnénk, hogy az internetrõl képesek legyenek elérni a rajta levõ oldalakat. Az újonnan beérkezõ kapcsolatépítési kérelem a 100-as szabályra fog illeszkedni, amelynek a cél IP-címét a tûzfal helyi hálózaton található címére fogjuk leképezni. A csomagot ezután még megvizsgáljuk, nem tartalmaz-e valamilyen huncutságot, majd végül a 425-ös szabálynál fog kikötni. Az egyezéskor két dolog történhet: a csomaghoz felveszünk egy dinamikus szabályt, de ezúttal az adott forrás IP-címrõl érkezõ kapcsolatkérések számát 2-re lekorlátozzuk. Ezzel az adott szolgáltatás portján meg tudjuk óvni a tûzfalat üzemeltetõ gépet a DoS típusú támadásoktól. A csomagot ezután hozzátartozó cselekvés szerint továbbengedjük a belsõ hálózat felé. Visszatéréskor a tûzfal felismeri, hogy a csomag egy már meglevõ kapcsolathoz tartozik, ezért közvetlenül az 500-as szabályhoz kerül címfordításra, majd a - kimenõ felületen keresztül + kimenõ interfészen keresztül továbbküldjük. Íme az elsõ példa egy ilyen szabályrendszerre: #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot -$cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi felületet +$cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi interfészt $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenõ csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkezõ csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenõ állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ################## A következõ példa teljesen megegyezik az elõzõvel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos mûködését. A második példa: #!/bin/sh ############# Az IPFW szabályai itt kezdõdnek ########################### # Kezdés elõtt töröljük az összes jelenleg aktív szabályt: ipfw -q -f flush # Beállítjuk a parancsok megfelelõ elõtagjait: cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó - # hálózati felület neve + # hálózati interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó -# felület nevére. +# interfész nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# -# A rendszer belsõ felületét se szûrjük. +# A rendszer belsõ interfészét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Ellenõrizzük, hogy ez egy beérkezõ csomag és ha igen, akkor # fordítsuk a címét. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Ha ehhez a csomaghoz korábban már vettük fel dinamikus # szabályt a keep-state opció révén, akkor engedjük tovább. ################################################################# $cmd 015 check-state ################################################################# -# Az internet felé forgalmazó felület (kimenõ kapcsolatok) +# Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe # lesz. Ha a szolgáltatónknak több névszervere is van, akkor # az /etc/resolv.conf állományból nézzük ki a címeiket és # másoljuk le az alábbi sor mindegyikükhöz. $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state # A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató # DHCP szerverének elérését. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL # használatával. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük az e-mailek küldését és fogadását. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit. # Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk. $cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 080 $skip icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást (tehát a # hírcsoportokat). $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # funkciókat az SSH (secure shell) használatával. $cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük ki a whois kéréseket. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Kifelé engedélyezzük az NTP idõszerver elérését. $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# -# Az internet felõli felület (bejövõ kapcsolatok) +# Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Tiltsuk a fenntartott címtartományok felé haladó összes beérkezõ # forgalmat. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az ident tiltása. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Dobjuk el a késõn érkezõ csomagokat. $cmd 330 deny all from any to any frag in via $pif # Dobjuk el azokat az ACK csomagokat, amelyekre nincs # dinamikus szabály. $cmd 332 deny tcp from any to any established in via $pif # Engedélyezzük a szolgáltató DHCP szerverétõl érkezõ forgalmat. Ennek # a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tõle # fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL # konfigurációk esetén használatos, a "felhasználói PPP" esetében # törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenõ kapcsolatoknál # megadtunk. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel van # webszerverünk. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # használatát az internetrõl. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a nem biztonságos telnet elérését az # internetrõl. Azért nem tekintjük biztonságosnak, mert az # azonosítókat és a jelszavakat az interneten titkosítatlanul # közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt # a csoportot. $cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes internetrõl érkezõ hitelesítetlen kapcsolatot. $cmd 400 deny log all from any to any in via $pif # Dobjuk el és naplózzuk az összes internetre menõ hitelesítetlen kapcsolatot. $cmd 450 deny log all from any to any out via $pif # Ez lesz a kimenõ szabályokhoz tartozó "skipto" célja. $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### - diff --git a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml index 43ce85c424..03df15b558 100644 --- a/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/kernelconfig/chapter.sgml @@ -1,2101 +1,2150 @@ Jim Mock Frissítette és átdolgozta: Jake Hamby Eredetileg írta: A &os; rendszermag testreszabása Áttekintés rendszermag saját rendszermag készítése A rendszermag a &os; operációs rendszer lelke. Felelõs a memória kezelésért, a biztonsági szabályozások betartatásáért, a hálózat mûködtetéséért, a lemezhozzáférésért és sok minden másért is. Miközben maga a &os; egyre jobban konfigurálható dinamikusan, addig alkalmanként elegedhetetlen, hogy újrakonfiguráljuk és újrafordítsuk a rendszermagot. A fejezet elolvasása során megismerjük: miért lehet szükségünk egy saját rendszermagra; hogyan készítsünk konfigurációs állományt a rendszermaghoz, vagy hogyan módosítsunk egy már létezõt; hogyan használjuk a rendszermag konfigurációs állományát egy új rendszermag lefordítására és létrehozására; hogyan telepítsük az új rendszermagot; hogyan orvosoljuk a felmerülõ problémákat. A fejezetben az összes példaként bemutatásra kerülõ parancsot root felhasználóként kell kiadni a sikeres végrehajtásukhoz. Miért készítsünk saját rendszermagot? A &os; eredetileg ún. monolitikus rendszermaggal rendelkezett. Ez azt jelenti, hogy a rendszermag egyetlen nagy program volt, ami elõre rögzített eszközöket ismert, és ha meg akartuk változtatni a rendszermag mûködését, akkor fordítanunk kellett új rendszermagot, majd újra kellett indítanunk vele a számítógépet. Manapság azonban a &os; már inkább afelé a megközelítés felé halad, ahol a rendszermag funkcionalitásának nagy részét mûködés közben az igények szerint betölthetõ és eltávolítható modulok adják. Ezzel lehetõvé válik, hogy a rendszermag gyorsan illeszkedjen az újonnan megjelenõ hardvereszközökhöz (mint például a laptopok PCMCIA-kártyáihoz), vagy olyan új funkciókat tegyünk a rendszermaghoz, amelyek a fordításánál nem voltak feltétlenül szükségesek. Ezt a modellt nevezik moduláris rendszermagnak. Ennek ellenére még mindig elkerülhetetlen, hogy esetenként ne legyen szükség a rendszermag statikus testreszabására. Ez a legtöbb esetben azzal magyarázható, hogy vannak olyan funkciók, amelyek túlságosan is mélyen helyezkednek el a rendszermagban, ezáltal nem tölthetõek be dinamikusan. Máskor viszont egyszerûen azért nem lehetséges, mert még senki sem szánt idõt az adott funkcióhoz tartozó, dinamikusan betölthetõ modul elkészítésére. Egy saját rendszermag készítése - azon legfontosabb próbatételek egyike, melyet - majdnem az összes BSD felhasználónak ki kell + azon legfontosabb próbatételek egyike, melyet egy + haladó BSD felhasználónak ki kell állnia. Ez a folyamat, habár némileg idõigényes, számos elõnyt tartogat &os; rendszerünk számára. Eltérõen egy GENERIC (általános) rendszermagtól, amely rengeteg hardvert támogat, egy saját rendszermag csak a saját PC-nk hardverét ismeri. Ennek több elõnye is van, például: A rendszerünk gyorsabban indul. Mivel a rendszermag csak azokat a hardvereket fogja keresni, melyek a rendszerünkben megtalálhatóak, jelentõs mértékben le tud csökkeni az induláshoz szükséges idõ. + Kisebb memóriahasználat. Egy saját - rendszermag gyakran kevesebb memóriát - emészt fel, mint a GENERIC - rendszermag, ami azért is fontos, mert a rendszermag - mindig benn van a memóriában. Emiatt egy + rendszermag a szükségtelen részek és + eszközmeghajtók elhagyása miatt gyakran + kevesebb memóriát emészt fel, mint a + GENERIC rendszermag. Ez azért is + fontos, mert a rendszermag mindig benn van a fizikai + memóriában, és ezzel az + alkalmazások elöl veszi a helyet. Emiatt egy saját rendszermag elkészítése különösen hasznos lehet egy kevés fizikai memóriával rendelkezõ rendszeren. + További hardverek támogatása. A saját rendszermagunkba olyan eszközök támogatását is beletehetjük, amelyek nem szerepelnek a GENERIC rendszermagban, mint például a hangkártyákét. - Tom Rhodes Írta: A rendszerünkben levõ hardverek összeszedése Mielõtt belevetnénk magunkat a rendszermag beállításába, érdemes egy leltárt készíteni a gépünkben található különbözõ eszközökrõl. Ahol a &os; nem elsõdlegesen használt operációs rendszer, ott ehhez elegendõ megnézni a jelenlegi rendszerben található elemeket. Például az µsoft; rendszerek Eszközkezelõjében (Device Manager) általában az összes eszköz fontosabb adatait megtaláljuk. Magát az Eszközkezelõt pedig a Vezérlõpultból (Control Panel) érhetjük el. A µsoft.windows; egyes verzióiban a Rendszer (System) ikonjára kattintva megkapjuk azt a képernyõt, ahonnan közvetlenül el tudjuk érni az Eszközkezelõt. Ha viszont nincs másik operációs rendszer a gépünkön, akkor magunknak kell mindezeknek utánanéznünk. Erre az egyik alkalmas módszer a &man.dmesg.8; és a &man.man.1; parancsok használata. A &os;-ben található legtöbb meghajtónak van saját man oldala, ami tartalmazza az általuk kezelt eszközök listáját, illetve így a rendszerindítás során észlelt hardvereket nézhetjük vissza. Például az alábbi sor arra utal, hogy a psm meghajtó megtalálta a gépünkhöz tartozó egeret: psm0: <PS/2 Mouse> irq 12 on atkdbc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 Ezután ezt a meghajtót vagy a rendszermagba kell beépítenünk, vagy pedig a &man.loader.conf.5; állományon keresztül betöltenünk. Bizonyos esetekben a dmesg az eszközök felkutatásának eredményei helyett csak a rendszer üzeneteit mutatja. Ilyen helyezetekben a teljes kimenet a /var/run/dmesg.boot állományban tekinthetõ meg. A hardverek manuális felderítésének módja a &man.pciconf.8; segédprogram kimenetének böngészése, ami egy valamivel részletesebb eredményt ad. Mint például: ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet A pciconf paranccsal kapott kimenet ezen része azt mutatja, hogy az ath meghajtó talált egy vezeték nélküli Ethernet eszközt. Innen a man ath paranccsal érhetjük el a &man.ath.4; man oldalát. A &man.man.1; a paraméter megadásával további hasznos információkkal is tud szolgálni. A fentiekbõl kiindulva például a következõ paranccsal: &prompt.root; man -k Atheros le tudjuk kérdezni azokat a man oldalakat, amelyek tartalmazzák az adott szót: ath(4) - Atheros IEEE 802.11 wireless network driver ath_hal(4) - Atheros Hardware Access Layer (HAL) A hardvereszközeink listájával felvértezve most már egy saját rendszermag létrehozása sem lesz annyira ijesztõ. Meghajtók, alrendszerek és modulok rendszermag meghajtók, modulok, alrendszerek Mielõtt új rendszermagot készítenénk, érdemes megfontolnunk, hogy egyáltalán szükségünk lesz-e rá. Ha például valamilyen eszköz támogatásához kell, akkor könnyen elõfordulhat, hogy azt modulként is be tudjuk tölteni. A rendszermaghoz tartozó modulok a /boot/kernel könyvtárban találhatóak, és a &man.kldload.8; segítségével a rendszer mûködése közben dinamikusan betölthetõek. Ha nem is az összes, de a legtöbb meghajtóhoz tartozik egy modul és egy man oldal. Például az elõzõ szakaszban az ath vezeték nélküli Ethernet meghajtóval foglalkoztunk. A következõ leírást találjuk a hozzátartozó man oldalon: Vagy ha modulként akarjuk betölteni ezt a meghajtót a rendszer indítása során, akkor a &man.loader.conf.5; állományba vegyük fel a következõ sort: if_ath_load="YES" A fentebb leírtak szerint tehát ha a if_ath_load="YES" sort hozzáadjuk a /boot/loader.conf állományhoz, akkor a rendszer indulásakor ez a modul mindig dinamikusan betöltõdik. Némely esetben azonban nem áll rendelkezésünkre ilyen modul. Ez különösen igaz bizonyos alrendszerekre és a fontosabb meghajtókra, például az FFS állományrendszerre vonatkozóan, mivel ezeknek kötelezõen a rendszermagban kell lenniük. Ugyanez elmondható a hálózati támogatásra is (INET). Csak úgy tudjuk megmondani, hogy valamelyik meghajtóra szükség van a rendszermagban, ha elõször megpróbáljuk megkeresni hozzá a megfelelõ modult. A beépített meghajtók figyelmetlen eltávolításával könnyen lefordíthatatlan állapotba kerülhet a rendszermag. Például, ha a &man.ata.4; meghajtót kivesszük a rendszermag konfigurációs állományából, az ATA alrendszert használó meghajtók csak abban az esetben fognak biztosan mûködni, ha egyúttal felvesszük a loader.conf állományba. Ha nem vagyunk benne biztosak, akkor elõször próbáljuk meg használni a modult és csak utána hagyjuk el a rendszermagba épített változatát. Saját rendszermag készítése és telepítése rendszermag készítése, telepítése Elõször is tegyünk egy rövidke sétát a rendszermag könyvtárában. A továbbiakban említendõ összes könyvtár a /usr/src/sys könyvtáron belül található, amely /sys néven is elérhetõ. Itt rengeteg alkönyvtár található, mindegyikük a rendszermag különbözõ részeit testesíti meg. Ezek közül most számunkra a legfontosabb az architektúra/conf lesz, ahol majd létrehozzuk a saját rendszermagunk konfigurációs állományát, valamint a compile, ahol majd a rendszermagunk fordítása történik. Itt az architektúra lehet i386, alpha, amd64, ia64, powerpc, sparc64 vagy pc98 (a PC-k egyik, leginkább Japánban elterjedt változata). Az adott architektúra könyvtárában található összes állomány csak arra az architektúrára vonatkozik, a kód többi része pedig gépfüggetlen és közös az összes többi létezõ és leendõ &os; platformon. Érdemes megfigyelni a könyvtárak logikai elrendezését: minden egyes ismert eszköz, állományrendszer és bõvítmény saját alkönyvtárral rendelkezik. A példák során ez a fejezet feltételezi, hogy az i386 architektúrát használjuk. Ha ez a mi esetünkben nem így lenne, ne felejtsük el átírni bennük az elérési útvonalakat a rendszerünk architektúrájának megfelelõen. Ha nem lenne /usr/src/sys könyvtár a rendszerünkben, valószínûleg még nem telepítettük a rendszermag forráskódját. Ezt a legkönnyebben úgy tudjuk megtenni, ha root felhasználóként elindítjuk a sysinstall programot és ott kiválasztjuk a Configure (Beállítások), azon belül Distributions (Terjesztések) menüpontot, amiben válasszuk ki a src, base és sys terjesztéseket. Ha nem szeretnénk erre a célra a sysinstall programot használni, de rendelkezésünkre áll a hivatalos &os; CD, akkor a forrásokat akár parancssorból is telepíthetjük: &prompt.root; mount /cdrom &prompt.root; mkdir -p /usr/src/sys &prompt.root; ln -s /usr/src/sys /sys &prompt.root; cat /cdrom/src/ssys.[a-d]* | tar -xzvf - &prompt.root; cat /cdrom/src/sbase.[a-d]* | tar -xzvf - Ezután lépjünk be az i386/conf könyvtárba és másoljuk le a GENERIC konfigurációs állományt a kedvünk szerinti nevûre. Például: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; cp GENERIC SAJÁT Általában a nevet végig nagybetûkkel írjuk, és ha több &os;-s gépet is üzemeltetünk különbözõ hardverekkel, hasznosnak bizonyulhat megemlíteni benne az adott gép rendszerének nevét is. Ebben a példában ez most a SAJÁT lesz. A rendszermagunk konfigurációs állományát nem éppen a legjobb ötlet a /usr/src könyvtárban tárolni. Ugyanis könnyen elõfordulhat, hogy egy rosszul sikerült fordítás után egyszerûen csak letöröljük az egész /usr/src könyvtárat és onnan kezdjük újra. Azonban csak ezután juthat eszünkbe, hogy vele együtt bizony letöröltük a saját rendszermagunk konfigurációs állományát is! Ehhez hasonlóan, közvetlenül a GENERIC konfigurációs állomány szerkesztése sem ajánlott, mivel a források egy esetleges frissítésénél könnyen felülíródhat és ezzel együtt elvesznek a módosításaink is. Tehát érdemes inkább valahol máshol tárolnunk a rendszermagunk konfigurációs állományát, majd létrehozni rá egy szimbolikus linket a i386 könyvtárban. Valahogy így: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; mkdir /root/kernel &prompt.root; cp GENERIC /root/kernel/SAJÁT &prompt.root; ln -s /root/kernel/SAJÁT Most pedig a kedvenc szövegszerkesztõnkkel lássunk neki a SAJÁT átírásának! Ha nemrég telepítettük csak a rendszerünket, az egyetlen elérhetõ szövegszerkesztõnk minden bizonnyal a vi lesz. Róla most túlságosan is bonyolult lenne leírást adnunk, de az Irodalomjegyzékben található könyvek közül sokban elég jól bemutatják. Ezen kívül a &os; ajánl egy könnyebben megtanulható szövegszerkesztõt is az ee személyében, amely a kezdõk számára az ideális választás. Nyugodtan átírhatjuk az elöl található megjegyzéseket a saját konfigurációnknak megfelelõen, vagy akár azt is rögzíthetjük, hogy miben tértünk el a GENERIC beállításaitól. SunOS Ha fordítottunk már rendszermagot &sunos; vagy más BSD operációs rendszer alatt, ez az állomány ismerõsnek tûnhet. Ha viszont más operációs rendszerek, mint például a DOS felõl érkezünk, a GENERIC konfigurációs állomány egy kissé terebélyesnek tûnhet számunkra, ezért A konfigurációs állomány címû részt figyelmesen és lassan olvassuk át. Amennyiben a forrásfánkat a &os; projekt legfrissebb forrásaival szinkronizáljuk, mindig olvassuk el a /usr/src/UPDATING állományt, mielõtt bármilyen frissítéshez is kezdenénk. Itt megtalálhatóak azok a fontos érintett kérdések és területek, amely külön figyelmet igényelnek a frissített forráskód esetén. A /usr/src/UPDATING mindig a &os; forrásának legfrissebb változatához igazodik, és ezért sokkal naprakészebb információkat tartalmaz, mint ez a kézikönyv. Most pedig le kell lefordítanunk a rendszermag forráskódját. A rendszermag lefordítása Lépjünk be a /usr/src könyvtárba: &prompt.root; cd /usr/src Fordítsuk le a rendszermagot: &prompt.root; make buildkernel KERNCONF=SAJÁT Telepítsük az új rendszermagot: &prompt.root; make installkernel KERNCONF=SAJÁT A &os; teljes forrásfájára szükség van a rendszermag lefordításához. Amikor egy saját rendszermagot alapértelmezés szerint fordítunk, vele együtt az összes modul is lefordításra kerül. Ha viszont idõt szeretnénk megtakarítani a rendszermag frissítése során vagy csak a saját moduljainkat akarjuk lefordítani, érdemes átírnunk az /etc/make.conf állományt a rendszermag fordításának megkezdése elõtt: MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs Ez a változó megadja a ténylegesen lefordítandó modulok listáját. WITHOUT_MODULES = linux acpi sound/sound sound/driver/ds1 ntfs Ez a változó a fordításból kihagyandó modulokat sorolja fel. A rendszermag fordításának folyamatában egyéb hasznosnak tekinthetõ változókról a &man.make.conf.5; man oldalán olvashatunk. /boot/kernel.old Ezután az új rendszermag a /boot/kernel könyvtárba kerül /boot/kernel/kernel néven és a korábbi rendszermag pedig /boot/kernel.old/kernel néven õrzõdik meg. Most állítsuk le a rendszert és indítsuk újra az új rendszermag aktiválásához. Ha közben valamilyen hiba történt volna, nézzük meg a fejezet végén található, hibakeresésre vonatkozó utasításokat. Mindenképpen olvassuk el azt a részt, amely leírja, hogyan állítsuk helyre a rendszerünket abban az esetben, ha az új rendszermaggal nem indul. A rendszerindítási folyamathoz tartozó további állományok, mint például a rendszerbetöltõ (&man.loader.8;) és annak konfigurációs állománya, a /boot könyvtárban találhatóak. A külsõ és saját modulok a /boot/kernel a könyvtárba kerülhetnek, azonban a felhasználóknak nagyon ügyelniük kell rá, hogy az itt található modulok szinkronban legyenek a lefordított rendszermaggal. Ellenkezõ esetben a rendszerben megbízhatatlanságot, hibákat észlelhetünk. Joel Dahl A &os; 6.X verziójához igazította: A konfigurációs állomány rendszermag NOTES NOTES rendszermag konfigurációs állomány A konfigurációs állomány általános formátuma igen egyszerû. Minden sor tartalmaz egy kulcsszót és egy vagy több paramétert. A további egyszerûsítés kedvéért a legtöbb sor csak egyetlen paramétert tartalmaz. Bármi, ami egy # (kettõskereszt) jelet követ, megjegyzésnek minõsül és nem számít konfigurációs elemnek. A most következõ részek bemutatják az egyes kulcsszavakat abban a sorrendben, ahogy azokat a GENERIC állományban is megtalálhatjuk. Az architektúrafüggõ opciók és eszközök teljes listáját a GENERIC állománnyal egy könyvtárban levõ NOTES állományban találhatjuk meg. Az architektúrától független opciókat a /usr/src/sys/conf/NOTES állományban találjuk. + A &os; 5.0 megjelenése óta a + konfigurációs állományokban + használható az include + direktíva. Ennek segítségével egy + másik konfigurációs állomány + tartalma logikailag beilleszthetõ az aktuálisba, + így könnyebbé válik egy már + meglevõ állományhoz tartozó kisebb + mennyiségû változtatás + karbantartása. Például ha csupán + pár egyszerû kiegészítést + szeretnénk hozzáadni a + GENERIC rendszermaghoz, akkor elegendõ + a hozzá vett eltéréseket + nyilvántartanunk egy külön + konfigurációs állományban: + + include GENERIC +ident SAJAT + +options IPFIREWALL +options DUMMYNET +options IPFIREWALL_DEFAULT_TO_ACCEPT +options IPDIVERT + + + Valószínûleg sok rendszergazda + számára jelentõs elõnyt jelent ez a + megoldás a konfigurációs + állományok korábbról már + megszokott újraírásával szemben: a + helyi konfigurációs állomány csak a + GENERIC rendszermag helyi rendszerre + vonatkozó eltéréseit tartalmazza. Így + amikor frissítjük a rendszerünket, a + GENERIC rendszermag összes + újítása elérhetõvé + válik, kivéve ha explicit módon le nem + tiltottuk ezeket a noptions vagy a + nodevice megadásával. A fejezet + további részében egy átlagos + konfigurációs állománnyal fogunk + foglalkozni, mind a beállítások, mind pedig + az eszközök tekintetében. + Ha olyan állományt akarunk készíteni, amely tartalmazza az összes lehetséges opciót, például teszteléshez, futtassuk le root felhasználóként az alábbi parancsot: &prompt.root; cd /usr/src/sys/i386/conf && make LINT rendszermag konfigurációs állomány Itt a GENERIC rendszermag-konfigurációs állomány ismertetése következik, az érthetõség kedvéért helyenként megjegyzésekkel kibõvítve. A bemutatott állománynak majdnem pontosan meg kell egyeznie a rendszerünkben található /usr/src/sys/i386/conf/GENERIC állománnyal. a rendszermag beállításai machine machine i386 A számítógépünk architektúráját adja meg. A következõk valamelyikének kell lennie: alpha, amd64, i386, ia64, pc98, powerpc, vagy sparc64. a rendszermag beállításai cpu cpu I486_CPU cpu I586_CPU cpu I686_CPU A fenti beállítás segítségével megadhatjuk, milyen típusú processzor található a számítógépünkben. Több ilyen sorunk is lehet (ha például nem lennénk biztosak benne, hogy a I586_CPU vagy I686_CPU értéket kellene megadnunk), de a saját rendszermagunk összeállításához érdemes csak egyet meghagynunk. Ha nem ismerjük pontosan a processzorunk típusát, vessünk egy pillantást a /var/run/dmesg.boot állományra és keressük ki belõle. a rendszermag beállításai ident ident GENERIC Ez a rendszermag azonosítója. Változtassuk meg rendszermagunk nevére, legyen például SAJAT, ha a korábbi utasításokat követtük. Az ident után írt sztring fog megjelenni a rendszermag neve mellett a rendszer indítása során, ezért fontos, hogy az új rendszermagunknak más nevet adjunk, ha meg akarjuk különböztetni az általában használttól (például egy tesztelésre szánt rendszermagot akarunk készíteni). # ha a /boot/device.hints használata helyett statikusan bele akarjuk fordítani #hints "GENERIC.hints" # itt szerepelnek a device hintek A &man.device.hints.5; használható az eszközmeghajtók beállítására. A &man.loader.8; a rendszer indítása során alapértelmezés szerint a /boot/device.hints állományt olvassa be erre a célra. A hints beállítás használatával ezeket a hinteket statikusan bele tudjuk építeni a rendszermagba. Ebben az esetben nincs szükségünk külön device.hints állomány létrehozására a /boot könyvtárban. makeoptions DEBUG=-g # a nyomkövetéshez szükséges gdb(1) szimbólumok beépítése A &os; hagyományos fordításának folyamata során a rendszermagot a használatával készítjük el, aminek köszönhetõen hibakeresési információkat tudunk átadni a &man.gcc.1; fordítónak. options SCHED_4BSD # 4BSD ütemezõ A &os; tradicionális és alapértelmezett rendszerütemezõje. Ne változtassuk meg! options PREEMPTION # a rendszerszálak megszakíthatóságának engedélyezése Ha engedélyezzük, a rendszermagban futó szálakat meg tujdák szakítani más, magasabb prioritású szálak. Ez segít növelni a rendszer válaszadási sebességét és csökkenti a megszakításokat kezelõ szálak várakozását. options INET # hálózatkezelés A hálózatkezelés támogatása. Ne töröljük ki, még akkor sem, ha nem tervezzük hálózatra kapcsolni a rendszert. Sok programnak szüksége van legalább az ún. loopback típusú hálózat támogatására (vagyis a számítógépünkön belüli hálózati kapcsolatokra), ezért ez feltétlenül kötelezõ! options INET6 # IPv6 kommunikációs prokotollok Engedélyezi az IPv6 kommunikációs protokollok használatát. options FFS # Berkeley Fast Filesystem Ez a legalapvetõbb merevlemezes állományrendszer. Hagyjuk meg, ha merevlemezrõl akarjuk indítani a rendszerünket. options SOFTUPDATES # az FFS Soft Updates támogatása Ez a beállítás engedélyezi a rendszermagban a Soft Updates használatát, amely segít felgyorsítani a lemez írási sebességét. Ha már a rendszermag ezt a funkcionalitást ismeri, akkor még külön az egyes lemezeken is engedélyezni kell. Nézzük meg a &man.mount.8; kimenetét, hogy lássuk, a rendszerünkben levõ lemezek közül melyiken van ténylegesen engedélyezve a Soft Updates használata. Ha nem látjuk benne sehol sem a soft-updates opciót, akkor azt (meglevõ állományrendszerek esetén) a &man.tunefs.8; vagy (új állományrendszerek esetén) a &man.newfs.8; parancsokkal tudjuk bekapcsolni. options UFS_ACL # a hozzáférés-vezérlési listák (ACL) támogatása Ezzel a beállítással engedélyezhetjük a rendszermagban a hozzáférés-vezérlési listák támogatását. Ez a kiterjesztett attribútumok és az UFS2 használatára támaszkodik. Ezt a lehetõséget részleteiben a ban tárgyaljuk. Az ACL alapértelmezés szerint támogatott, és korábban már használtuk, akkor semmiképpen se kapcsoljuk ki, mert ezzel az eddig létrehozott hozzáférés-vezérlési listáink érvénytelenné, az állományaink pedig védtelenné válnak. options UFS_DIRHASH # nagyobb könyvtárak esetén gyorsulást hoz Ezzel a beállítással némi memória feláldozása árán fel tudjuk gyorsítani a nagyobb könyvtárakon végzett lemezmûveletek sebességét, ezért ezt a beállítást érdemes nagyobb szerverekre vagy interaktívitást igénylõ munkaállomásokra tartogatni, és eltávolítani olyan esetekben, amikor a &os;-t egy olyan kisebb számítógépeken használjuk, ahol a memória kevés és a lemezmûveletek sebessége kevésbé fontos, például egy tûzfalon. options MD_ROOT # tudunk memórialemezrõl is rendszert indítani Ezzel az opcióval engedélyezni tudjuk a rendszer indítását memóriában tárolt virtuális lemezekrõl. a rendszermag beállításai NFS a rendszermag beállításai NFS_ROOT options NFSCLIENT # hálózati állományrendszer (NFS) kliens options NFSSERVER # NFS szerver options NFS_ROOT # NFS használható gyökérként is, kell hozzá az NFSCLIENT A hálózati állományrendszer támogatása. Hacsak nem akarunk TCP/IP-n keresztül állományrendszereket csatlakoztatni egy &unix; állományszerverrõl, kivethetjük. a rendszermag beállításai MSDOSFS options MSDOSFS # MS-DOS állományrendszer Az &ms-dos; állományrendszer. Hacsak nem akarunk DOS-ra formázott merevlemezes partíciót csatlakoztatni a rendszerindítás során, nyugodtan elhagyhatjuk. A fentebb leírtak szerint az elsõ olyan alkalommal automatikusan betöltõdik, amikor egy DOS partíciót csatlakoztatni akarunk. Sõt, a nagyszerû emulators/mtools szoftver segítségével külön csatlakoztatás és leválasztás nélkül tudunk DOS-os floppykat olvasni (és az MSDOSFS-re egyáltalán nincs is szüksége). options CD9660 # ISO 9660 állományrendszer Az ISO 9660 állományrendszert a CD-k használják. Vegyük ki, ha nincs a számítógépben CD-ROM meghajtó vagy csak ritkán fogunk CD-ket csatlakoztatni (mivel a hozzátartozó modul magától betöltõdik az elsõ adat CD csatlakoztatása során). Az audio CD-k nem használják ezt az állományrendszert. options PROCFS # a futó programok állományrendszere (szükséges hozzá a PSEUDOFS) A futó programok állományrendszere. Ez csak a /proc könyvtárra csatlakoztatott színlelt állományrendszer, amely segítségével a &man.ps.1; és hozzá hasonló programok képesek több információt adni a futó programokról. A PROCFS használata a legtöbb esetben nem indokolt, mivel a különféle nyomkövetõ és felügyeleti eszközök képesek a PROCFS használata nélkül is mûködni: alapértelmezés szerint a telepített rendszerek sem csatlakoztatják ezt az állományrendszer. options PSEUDOFS # pszeudo állományrendszerek támogatása A 6.X verziójú rendszermagokban a PROCFS használatához engedélyeznünk kell a PSEUDOFS használatát is. options GEOM_GPT # GUID típusú partíciós táblák használata Ezzel a beállítással engedélyezni tudjuk nagy mennyiségû partíció támogatását egyetlen lemezen. options COMPAT_43 # kompatibilitás fenntartása a 4.3 BSD-vel [NE TÖRÖLD!] Kompatibilitás a 4.3BSD-vel. Ne vegyük ki, mert bizonyos programok furcsán fognak viselkedni a hiánya esetén. options COMPAT_FREEBSD4 # kompatibilitás a &os;4-el Ez a beállítás szükséges a &os; 5.X &i386; és Alpha rendszerein a &os; korábbi verzióihoz fordított alkalmazások támogatásához, melyek régebbi rendszerhívásokat használnak. Az összes &i386; és Alpha típusú rendszeren ajánlott engedélyezni, mivel itt elõfordulhatnak régebbi alkalmazások. A többi platform, mint például az ia64 vagy a &sparc64;, támogatása csak az 5.X verzióban jelent meg, ezért ott nincs szükség erre. options COMPAT_FREEBSD5 # kompatibilitás a &os;5-el Ezt a beállítást a &os; 6.X és afeletti verziókban kell használni az olyan &os; 5.X verziókra fordított alkalmazások futtatásának támogatásához, melyek a &os; 5.X rendszerhívásait használják. options SCSI_DELAY=5000 # a SCSI eszközök keresése elõtt késleltetés (ezredmásodpercben) Ezzel a beállítással a rendszermag 5 másodpercig várakozni fog a SCSI eszközök keresése elõtt. Ha kizárolag csak IDE típusú merevlemezeink vannak, nyugodtan kihagyhatjuk, máskülönben érdemes a rendszerindítás gyorsítása érdekében próbáljuk meg csökkenteni ezt az értéket. Természetesen, ha így teszünk és a &os; nem tudja felismerni a SCSI eszközeinket, akkor növeljük meg valamennyivel. options KTRACE # a ktrace(1) támogatása Engedélyezi a rendszermagban futó rutinok nyomonkövetését, ami hasznos lehet a hibák keresése során. options SYSVSHM # SYSV-szerû osztott memória Ezzel a beállítással engedélyezni tudjuk a rendszerben a System V típusú osztott memória használatát. Leggyakrabban az X rendszer XSHM kiterjesztése használja, amelyen keresztül számos mûveletigényes grafikus program mûködését fel lehet gyorsítani. Ha X-et használunk, mindenképpen szükségünk lehet erre. options SYSVMSG # SYSV-szerû üzenetsorok A System V üzenetek támogatása. Ez a beállítás csupán néhány száz byte-tal növeli a rendszermagot. options SYSVSEM # SYSV-szerû szemaforok A System V szemaforok támogatása. Nem túl gyakran alkalmazzák ezeket, de ez csak néhány száz byte-ot tesz hozzá a rendszermaghoz. A &man.ipcs.1; parancs paraméterével ki tudjuk listáztatni azokat futó programokat, amelyek ezen System V eszközöket használják. options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B valósidejû kiterjesztések A &posix; 1993-as változatában megjelent valósidejû bõvítések. A Portgyûjteményben megjelenõ egyes alkalmazások használják ezeket (mint például a &staroffice;). options KBD_INSTALL_CDEV # CDEV bejegyzés létrehozása a /dev könyvtárban Ez a beállítás kell ahhoz, hogy /dev könyvtárban létre tudjunk hozni eszközleírókat a billentyûzethez. options ADAPTIVE_GIANT # adaptív Giant mutexek A Giant annak a kölcsönös kizárási mechanizmusnak (blokkolt mutexnek) a neve, amely a rendszermag erõforrásainak jelentõs részét védi. Manapság ez már egy elfogadhatatlanul szûk keresztmetszet képez a teljesítményben, ezért a fejlesztésben fokozatosan felváltják az egyes erõforrásokat külön-külön védõ zárolások. Az ADAPTIVE_GIANT beállítás hatására a Giant a helyzethez igazodóan forgó (spin) mutexek közé kerül. Ez azt jelenti, hogy amikor egy szál zárolni akarja a Giant mutexet, de ezt már megtette elõtte egy másik processzorról futó szál, a szál tovább fut és várakozni fog a zárolás feloldására. Normális esetben ugyanis egy szál továbbra is blokkolt állapotban marad, várakozva a futásra. Ha nem tudunk dönteni, hagyjuk változatlanul. Hozzátesszük, hogy a &os; 8.0-CURRENT és késõbbi változataiban az össszes mutex alapértelmezés szerint adaptív, hacsak meg nem adjuk a NO_ADAPTIVE_MUTEXES beállítást. Ennek eredményeképpen a Giant most már alapból adaptív, ezért esetükben az ADAPTIVE_GIANT nem szerepel a rendszermag beállításai között. a rendszermag beállításai SMP device apic # I/O APIC Az apic nevû eszköz engedélyezésével használhatjuk a hardveres APIC-ot a megszakítások vezérlésére. Az apic alkalmazható egy- és többprocesszoros rendszerek esetén is egyaránt, de az SMP rendszermagoknál szükséges. Több processzor támogatásánál mindenképpen tegyük hozzá az options SMP beállítást is. Az apic eszköz csak az i386 architektúrán létezik, ezért a többi architektúrán nem szabad használnunk ezt a beállítást. device eisa Abban az esetben engedélyezzük, ha EISA-s alaplapunk van, ezzel aktiváljuk az EISA buszra csatlakoztatott eszközök automatikus felismerését és beállíthatóságát. device pci Tegyük hozzá a konfigurációs állományhoz, ha PCI-os alaplapuk van. Ezzel engedélyezhetjük a PCI kártyák automatikus felismerését és a PCI és ISA buszok közti átirányítást. # Hajlékonylemezes meghajtók device fdc Ez a hajlékonylemezes meghajtó vezérlõje. # ATA és ATAPI eszközök device ata Ez az eszközmeghajtó felelõs az összes ATA és ATAPI eszközért. A modern számítógépeken csak egyszer kell megadnunk a device ata sort a beállítások között az összes PCI-os ATA/ATAPI eszköz felismeréséhez. device atadisk # ATA lemezmeghajtók Az ATA lemezmeghajtók támogatásához erre van még szükség a device ata mellett. device ataraid # ATA RAID-meghajtók Az ATA RAID-meghajtók kezeléséhez erre a sorra van szükség a device ata mellett. device atapicd # ATAPI CD-meghajtók Az ATAPI CD-meghajtók használatához ezt is tegyük a konfigurációba a device ata mellé. device atapifd # ATAPI floppy meghajtók A device ata használata mellett erre van még szükségünk az ATAPI floppy meghajtók kezeléséhez. device atapist # ATAPI szalagos meghajtók Az ATAPI szalagos egységek ezt a sort is tegyük a konfigurációba a device ata mellé. options ATA_STATIC_ID # statikus eszközszámozás Ezzel a beállítással a vezérlõk számozása állandó lesz. Nélküle az eszközszámok dinamikusan kerülnek kiosztásra. # SCSI vezérlõk device ahb # EISA AHA1742 család device ahc # AHA2940 és integrált AIC7xxx eszközök options AHC_REG_PRETTY_PRINT # a hibák kereséséhez kiíratja a regiszterek # bitmezõit. Kb. 128 KB-al növeli a méretét. device ahd # AHA39320/29320 és integrált AIC79xx eszközök options AHD_REG_PRETTY_PRINT # a hibák kereséséhez kiíratja a regiszterek # bitmezõit. Kb. 215 KB-al növeli a méretét. device amd # AMD 53C974 (Teckram DC-390(T)) device isp # Qlogic család #device ispfw # a QLogic HBA firmware-e, többnyire modul device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (újabb chipsetek, illetve az `ncr' típusúak) device trm # Tekram DC395U/UW/F DC315U csatolók device adv # Advansys SCSI-csatolók device adw # Advansys wide SCSI-csatolók device aha # Adaptec 154x SCSI-csatolók device aic # Adaptec 15[012]x SCSI-csatolók, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI-csatolók device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 SCSI-vezérlõk. Vegyük ki azokat, amelyekkel ténylegesen nem rendelkezünk. Ha csak IDE eszközeink vannak a rendszerünkben, az összeset eltávolíthatjuk. A _REG_PRETTY_PRINT végzõdésû sorok a megfelelõ meghajtók hibakerési beállításait takarják. # SCSI-perifériák device scbus # SCSI-busz (kell a SCSI-hoz) device ch # SCSI médiumváltók (media changer) device da # közvetlen hozzáférés (lemezek) device sa # soros hozzáférés (szalag stb.) device cd # CD device pass # áteresztõ eszköz (közvetlen SCSI hozzáférés) device ses # SCSI környezeti szolgáltatások (és SAF-TE) SCSI-perifériák. Itt is érvényes, hogy kivethetjük azokat az eszközöket, amelyekkel nem rendelkezünk. De ha csak IDE hardvereink vannak, teljesen eltávolíthatjuk ezeket. Annak ellenére, hogy valójában nem igazi SCSI-eszközök, az USB-s &man.umass.4; és még néhány más egyéb meghajtó is használja a SCSI alrendszert. Emiatt semmiképpen se távolítsuk el a SCSI támogatást a rendszerünkõl abban az esetben, ha ilyen meghajtókat is használni szándékozunk. # a SCSI alrendszerhez kapcsolódó RAID-vezérlõk device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI és Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - lásd a NOTES állományt device hptmv # Highpoint RocketRAID 182x device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID vezérlõk device aac # Adaptec FSA RAID device aacp # SCSI áteresztõ az aac-hez (kell hozzá a CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 család device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID Az ismert RAID-vezérlõk. Ha közülük egyikkel sem rendelkezünk, távolítsuk el ezeket a konfigurációból. # az atkbdc0 vezérli a billentyûzetet és a PS/2-es egeret device atkbdc # AT billentyûzet vezérlõ A billentyûzet vezérlõje (atkbdc) az AT-s billentyûzet és a PS/2 stílusú pozícionáló eszközök vezérléséhez szükséges I/O szolgáltatásokat biztosítja. Erre a vezérlõre a billentyûzet meghajtójának (atkbd) és a PS/2 pozícionáló eszközök eszközmeghajtójának (psm) is szüksége van. device atkbd # AT billentyûzet Az atkbd meghajtó, a atkbdc vezérlõvel együtt, adja a hozzáférést az AT billentyûzet vezérlõre csatlakoztatott AT 84 és a fejlettebb AT billentyûzetek felé. device psm # PS/2 egér Használjuk ezt az eszközt, ha az egerünk a PS/2 portra csatlakozik. device kbdmux # billentyûzet multiplexer A billentyûzet multiplexer alapszintû támogatása. Ha nem kívánunk a jövõben egynél több billentyûzetet csatlakoztatni a rendszerünkre, nyugodt szívvel kivehetjük ezt a sort. device vga # VGA videokártya meghajtó Videokártya meghajtó. device splash # üdvözlõképernyõk és képernyõkímélõk támogatása Nyissunk egy üdvözlõképernyõvel! A képernyõkímélõknek is szüksége van erre az eszközre. # a syscons az alapértelmezett konzolmeghajtó, hasonlít a SCO konzolra device sc Az sc az alapértelmezett meghajtó a konzolok számára, és sokban hasonlít a SCO konzolra. Mivel a legtöbb teljesképernyõs program a termcap termináladatbázis könyvtáron keresztül éri el a konzolt, nem igazán számít, hogy ezt vagy a VT220-kompatibilis vt konzolmeghajtót használjuk. Ha bármilyen gondunk lenne a teljesképernyõs programok futtatásával ezen a konzolon, a bejelentkezéskor állítsuk a TERM környezeti változónk a scoansi értékre. # ezzel tudjuk engedélyezni a pcvt (VT220-kompatibilis) konzolmeghajtót #device vt #options XSERVER # az X szerver támogatása vt konzolon #options FAT_CURSOR # telt kurzor használata Ez a VT220-kompatibilis konzolmeghajtó, amely visszafele kompatibilis a VT100/102-vel is. Remekül mûködik olyan laptopokon, ahol a hardver nem használható az sc konzollal. Itt ugyanúgy érdemes egyébként a vt100 értékre vagy a vt220 értékre állítani a TERM környezeti változónkat. Hasznosnak bizonyulhat abban az esetben is, amikor hálózaton keresztül nagy mennyiségû és eltérõ típusú számítógépekhez csatlakozunk, és ahol a termcap és terminfo adatbázisokban az sc bejegyzései gyakran nem is érhetõek el — a vt100 viszont virtuálisan az összes platformon elérhetõ. device agp Írjuk bele a konfigurációba, ha van AGP kártya a rendszerünkben. Ezzel engedélyezzük az AGP és az AGP GART támogatását az ezeket ismerõ kártyák számára. APM # energiagazdálkodás támogatása (bõvebben lásd: NOTES) #device apm A fejlett energiagazdálkodás támogatása. Laptopok esetén hasznos, habár ez alapértelmezés szerint nincs engedélyezve a GENERIC konfigurációban. # az i8254 készenléti módjának támogatása device pmtimer Az energiagazdálkodási események, mint például APM és ACPI idõzítõjének eszközmeghajtója. # PCCARD (PCMCIA) támogatás # PCMCIA és cardbus támogatás device cbb # cardbus (yenta) bridge device pccard # PC Card (16 bites) busz device cardbus # CardBus (32 bites) busz A PCMCIA támgotása. Mindenképpen szükségünk lesz rá, ha laptopunk van. # soros (COM) portok device sio # 8250, 16[45]50 alapú soros portok Ezek azok a soros portok, amelyek az &ms-dos;/&windows; világban csak COM portokként ismernek. Ha van egy belsõ modemünk a COM4-en és egy soros portunk a COM2-n, a modem IRQ-ját meg kell változtatnunk 2-re (valamilyen homályos mûszaki októl kifolyólag a COM2 = IRQ9), hogy hozzá tudjunk férni &os;-bõl. Ha többportos soros kártyánk lenne, lapozzuk fel a &man.sio.4; man oldalát, és ott hozzá megtaláljuk a /boot/device.hints állományba írandó megfelelõ értékeket. Egyes videokártyák (különösen az S3 chipekre épülõk) az I/O címeket 0x*2e8 alakban használják, és mivel rengeteg olcsó soros kártya nem kódolja vissza egészében a 16 bites I/O címteret, ütközni fognak ezekkel a kártyákkal, és ezáltal a COM4 port gyakorlatilag elérhetetlenné válik. Minden egyes soros portnak egyedi IRQ-ja kell legyen (hacsak nem használunk olyan többportos kártyát, amely támogatja a megosztott megszakításokat), ezért a COM3 és COM4 esetén alapértelmezett IRQ-k nem használhatóak. # párhuzamos port device ppc Ez az ISA busz párhuzamos portjának felülete. device ppbus # a párhuzamos port busza (kell) A párhuzamos porthoz tartozó busz támogatása. device lpt # nyomtató A párhuzamos portra csatlakozó nyomtatók támogatása. A fentiek közül mind a három szükséges a párhuzamos porton csatlakozó nyomtatók használatához. device plip # TCP/IP párhuzamos porton keresztül Ez a párhuzamos port hálózati felületének meghajtója. device ppi # a párhuzamos port felületének eszköze Általános célú (geek port) és IEEE1284 I/O. #device vpo # az scbus és a da kell a használatához zip meghajtó Ez az Iomega Zip meghajtóihoz tartozó eszköz. A mûködéséhez szükség van az scbus és da engedélyezésére. A legjobb teljesítményt EPP 1.9 módban mûködõ portokkal lehet kihozni belõle. #device puc Tegyük bele a konfigurációba ezt az eszközt, ha egy olyan buta soros vagy párhuzamos PCI kártyánk van, amelyet a &man.puc.4; segédmeghajtó ismer. # PCI Ethernet kártyák device de # DEC/Intel DC21x4x (Tulip) device em # Intel PRO/1000 Gigabit Ethernet kártya device ixgb # Intel PRO/10GbE Ethernet kártya device txp # 3Com 3cR990 (Typhoon) device vx # 3Com 3c590, 3c595 (Vortex) Különféle PCI hálózati kártyák meghajtói. Vegyük ki azokat, amelyek nem találhatóak meg a rendszerünkben. # PCI Ethernet kártyák, melyek az MII busz vezérlõkódját használják # FIGYELEM: Ne töröljük ki a 'device miibus' sort, ha ilyen kártyánk van! device miibus # az MII busz támogatása Az MII busz engedélyezése elengedhetetlen bizonyos 10/100-as PCI Ethernet kártyák használatához, konkrétan azokéhoz, amelyek az MII-vel együttmûködni képes adó-vevõt használnak vagy az MII-höz hasonló adó-vevõ vezérlõ felületet valósítanak meg. A device miibus hozzáadása a rendszermaghoz magával vonja az általános miibus API és az összes PHY meghajtó támogatását, beleértve azt az általános PHY eszközt is, amelyet az egyes eszközmeghajtók külön nem támogatnak. device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 és egyéb hasonlóak device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit ethernet device nve # nVidia nForce MCP integrált Ethernet hálózat device pcn # AMD Am79C97x PCI 10/100 (az 'lnc' elõtt) device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (Starfire) device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 EPIC) device vge # VIA VT612x gigabit ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (Boomerang, Cyclone) Meghajtók, melyek az MII busz vezérlõkódját használják. # ISA Ethernet és pccard hálózati kártyák. device cs # Crystal Semiconductor CS89x0 NIC # az 'device ed' eszközhöz kell a 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 és Pro/10+ device ep # Etherlink III alapú kártyák device fe # Fujitsu MB8696x alapú kártyák device ie # EtherExpress 8/16, 3C507, StarLAN 10 stb. device lnc # NE2100, NE32-VL Lance Ethernet kártyák device sn # az SMC 9000-res sorozatú Ethernet chipjei device xe # Xircom pccard Ethernet # ISA eszközök, melyek a régi ISA betétet használják #device le ISA Ethernet meghajtók. A konkrétan támogatott kártyák teljes felsorolását lásd a /usr/src/sys/i386/conf/NOTES állományban. # vezeték nélküli hálózati kártyák device wlan # 802.11 támogatás Általános 802.11 támogatás. Erre a sorra mindenképpen szükség van a vezeték nélküli hálózatok használatához. device wlan_wep # 802.11 WEP támogatás device wlan_ccmp # 802.11 CCMP támogatás device wlan_tkip # 802.11 TKIP támogatás A 802.11 eszközök esetén a titkosítás támogatása. Ezeket a sorokat akkor adjuk meg, ha titkosítást akarunk használni vagy a 802.11i biztonsági protokolljait. device an # Aironet 4500/4800 802.11 vezeték nélküli hálózati kártyák device ath # Atheros pci/cardbus hálózati kártyák device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # küldési mintavételi vezérlés az ath-hoz device awi # BayStack 660 és mások device ral # Ralink Technology RT2500 vezeték nélküli hálózati kártyák device wi # WaveLAN/Intersil/Symbol 802.11 vezeték nélküli hálózati kártyák #device wl # régebbi, nem 802.11 Wavelan vezeték nélküli hálózati kártyák A különbözõ vezeték nélküli kártyák támogatása. # Pszeudo eszközök device loop # hálózati loopback Ez a TCP/IP általános loopback eszköze. Ha telnettel vagy FTP-vel rácsatlakozunk a localhost címére (vagyis a 127.0.0.1-re), akkor rajta keresztül saját magunkhoz jutunk vissza. Ennek a megléte kötelezõ! device random # álvéletlenszám eszköz Kriptográfiai szempontból biztonságos álvéletlenszám generátor. device ether # Ethernet támogatás Az ether eszközre csak abban az esetben van szükség, ha Ethernet kártyán van. Ez magában foglalja az általános Ethernet protokoll kódját. device sl # belsõ SLIP Az sl a SLIP használatát engedélyezi. Ez egy régi protokoll, amelyet azóta már szinte teljesen kiszorított a PPP, mivel azt könnyebb beállítani és sokkal jobban is illik a modem-modem kapcsolatokhoz, illetve sokkal erõteljesebb. device ppp # belsõ PPP Ez a tárcsázós kapcsolatok rendszermagon belüli PPP támogatását adja meg. Van a PPP-nek egy külsõ, a felhasználói programként megvalósított változata is, amely a tun eszközt használja és sokkal nagyobb rugalmasságot kínál fel, illetve olyan lehetõségeket, mint például az igény szerinti tárcsázás. device tun # csomag alagút Ezt a felhasználói PPP szoftver használja. A könyv PPP-rõl szóló részében többet is megtudhatunk róla. device pty # Pszeudo terminálok (telnet stb.) Ezek a pszeudo terminálok vagy más néven szimulált bejelentkezési portok. A bejövõ telnet és rlogin munkamenetek használják, valamint az xterm és a hozzá hasonló alkalmazások, mint például az Emacs. device md # memórialemezek A memóriában levõ pszeudo lemezes meghajtók. device gif # IPv6 és IPv4 tunnelek használata Megvalósítja az IPv6 IPv4 feletti, az IPv4 IPv6 feletti, az IPv4 IPv4 feletti és az IPv6 IPv6 feletti közvetítését. A gif eszköz magától másolódik, vagyis szükség szerint hozza létre a megfelelõ eszközleírókat. device faith # IPv6-IPv4 közti továbbítás (fordítás) Ez a pszeudo eszköz elfogja a hozzá küldött csomagokat és átadja ezeket az IPv4/IPv6 fordítással foglalkozó démonnak. # a `bpf' eszköz használatával a Berkeley csomagszûrõt (Berkeley Packet Filter) engedélyezzük # Legyünk rá tekintettel, hogy ennek komoly következményei lehetnek # rendszeradminisztrációs szempontból! # A 'bpf'-re szükség van a DHCP-hez. device bpf # Berkeley csomagszûrõ A Berkeley csomagszûrõje. Ez egy olyan pszeudo eszköz, amely lehetõvé teszi, hogy a hálózati csatolók forgalmát megfigyeljük, mivel a (pl. Ethernet) hálózatunkon minden csomagot elkap. Ezek a csomagok lemezre is menthetõek vagy kielemezhetõek a &man.tcpdump.1; program segítségével. A &man.bpf.4; eszközt a &man.dhclient.8; is használja többek közt az alapértelmezett átjáró IP-címének megszerzéséhez. Ha DHCP-t akarunk használni, hagyjuk így. # USB támogatás device uhci # UHCI PCI->USB felület device ohci # OHCI PCI->USB felület device ehci # EHCI PCI->USB felület (USB 2.0) device usb # USB busz (kell) #device udbp # USB Double Bulk Pipe eszközök device ugen # általános device uhid # Human Interface Devices device ukbd # billentyûzet device ulpt # nyomtató device umass # lemez/háttértároló - kell hozzá az scbus és a da device ums # egér device ural # Ralink Technology RT2500USB vezeték nélküli hálózati kártyák device urio # Diamond Rio 500 MP3 lejátszó device uscanner # lapolvasók # USB Ethernet, kell hozzá az mii device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # általános USB, Etherneten keresztül device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet A különféle USB eszközök támogatása. # FireWire támogatás device firewire # FireWire buszkód device sbp # SCSI FireWire-ön keresztül (kell hozzá az scbus és a da) device fwe # Ethernet FireWire-ön keresztül (nem szabványos!) A különféle Firewire eszközök támogatása. A &os; által ismert további eszközökrõl a /usr/src/sys/i386/conf/NOTES állományból tájékozódhatunk. Sok memória kezelése (<acronym>PAE</acronym>) Fizikai címkiterjesztés (PAE) sok memória A sok memóriával rendelkezõ számítógépek esetén szükség lehet a felhasználói és rendszerszintû virtuális címek (Kernel Virtual Address, KVA) 4 gigabyte feletti használatára. Ennek a korlátozásnak a kiküszöbölésére az &intel; külön támogatást épített be a &pentium; Pro és az azt követõ processzorok 36 bites fizikai címzésének kialakításához. A Fizikai Címkiterjesztés (Physical Address Extension, PAE) az &intel; &pentium; Pro és késõbbi processzoraiban található meg, és lehetõvé teszi egészen 64 gigabyte-ig a memóriahasználatot. A &os; is támogatja ezt a tulajdonságot a rendszermag beállítás használatával, és megtalálható a &os; összes jelenlegi verziójában. Az &intel; architektúrájú processzorok memóriaszervezésének korlátai miatt nem különböztethetõ meg a 4 gigabyte alatti és feletti memória. A 4 gigabyte felett található memóriaterületek egyszerûen hozzáadódnak a rendelkezésre álló memóriához. A rendszermagban a PAE támogatását egyszerûen az alábbi sor segítségével hozzáadásával tudjuk engedélyezni: options PAE A &os;-ben a PAE támogatása csak az &intel; IA-32 architektúrájú processzoraihoz érhetõ el. Emellett meg kell említenünk, hogy a &os;-ben található PAE támogatás nem lett szélesebb körben próbára téve, ezért a &os; többi megbízható elemeihez képest csak béta állapotúnak tekinthetõ. A &os; PAE támogatásának van néhány hiányossága: Egy futó program a virtuális memóriában nem képes 4 gigabyte-nál többet elérni. A &man.bus.dma.9; felületet nem használó eszközmeghajtók adathibákat okozhatnak a PAE-t támogató rendszermagokban, és emiatt nem ajánljuk a használatukat. Ebbõl a megfontolásból készítettünk egy PAE nevû konfigurációs állományt a &os;-hez, amelyben nem szerepel egyetlen olyan meghajtó sem, amely ismereteink szerint nem mûködik együtt a PAE-t támogató rendszermagokkal. Bizonyos finomhangolási beállítások a memóriahasználatot a rendelkezésre álló fizikai memória mennyiségébõl számítják ki. A PAE támogatással mûködõ rendszerek esetében megjelenõ sok memória miatt azonban az ilyen eszközök szükségtelenül több területet foglalhatnak le. Erre példa lehet a sysctl változó, amely a rendszermag által maximálisan felhasználható virtuális csomópontok számát korlátozza. Ajánlott tehát az ilyen és ehhez hasonló beállítások értelmes értékre történõ visszaállítása. Szükséges lehet a rendszermag virtuális címterének (KVA) növelése vagy a rendszermag által túlságosan nagy méretûre foglalt címterû különféle erõforrások (lásd fentebb) csökkentése a KVA kifogyásának elkerülésére. A KVA területének növelését a beállításával tehetjük meg. Ha gondjaink lennének a teljesítménnyel vagy a megbízhatósággal, keressük fel a &man.tuning.7; man oldalt. A &man.pae.4; man oldalon pedig a &os; PAE támogatásáról találhatunk naprakész információkat. Ha valamilyen hiba történne Négyféle probléma jelentkezhet egy saját rendszermag készítése során. Ezek: A config hibát jelez: Amikor a &man.config.8; parancs hibát jelez vissza a rendszermagunk konfigurációs beállításainak feldolgozása során, akkor minden bizonnyal csak egy apró hibát vétettünk valahol. Szerencsére a &man.config.8; kiírja a hibás sor számát, ezért gyorsan fel tudjuk kutatni a hibát tartalmazó sort. Például, ha ezt látjuk: config: line 17: syntax error Akkor gyõzödjünk meg róla, hogy helyesen írtuk be az adott sorban szereplõ kulcsszót. Ebben segítségünkre lehet, ha összevetjük a GENERIC konfigurációs állománnyal vagy más hivatkozásokkal. A make hibát jelez: Ha a make jelez hibát, az általában arra utal, hogy az általunk korábban megadott rendszermag konfigurációs állományt a &man.config.8; nem értette meg rendesen. Megint azt tudjuk csak javasolni, hogy nézzük át a konfigurációs beállításainkat, és ha ezután sem sikerül megoldani a problémát, akkor mellékeljük egy levélben a rendszermagunk konfigurációs beállításait és küldjük el a &a.questions; címére, ahol a hozzáértõk gyorsan átnézik. A rendszermag nem indul: Ha az új rendszermagunk nem indul vagy nem képes felismerni az eszközeinket, ne essünk kétségbe! Szerencsére a &os; tökéletes megoldással tud szolgálni az összeférhetetlen rendszermagok esetére: a &os; rendszerbetöltõjében egyszerûen válasszuk ki az indítandó rendszermagot. Ezt akkor tudjuk elõhívni, amikor a rendszerindító menü megjelenik. Válasszuk ki a hatos, vagyis az Escape to a loader prompt (a betöltõ parancssorának elõhívása) menüpontot. Mikor megjelenik a parancssor, írjuk be, hogy unload kernel, majd adjuk ki a boot /boot/kernel.old/kernel, parancsot, amiben bármilyen más olyan rendszermagot is megnevezhetünk, ami korábban már mûködött. Ezért amikor beállítunk egy új rendszermagot, mindig érdemes a kezünk ügyében tartani legalább egy olyan rendszermagot, amely mûködik. Miután sikerült elindítanunk az egyik használható rendszermagot, nézzük át még egyszer a konfigurációs állományt és próbáljuk újra lefordítani a rendszermagot. A probléma megoldását segítheti a /var/log/messages állomány áttanulmányozása is, ami többek közt rögzíti a rendszermag sikeres indulása során keletkezõ üzeneteket. Ezenkívül a &man.dmesg.8; parancs is meg tudja jeleníteni az aktuális rendszerindítás üzeneteit. Ha gondok merülnének fel a rendszermag elkészítése során, mindenképpen tartsuk meg a GENERIC, vagy bármilyen másik olyan rendszermagot, amelyrõl tudjuk, hogy mûködik. Nevezzük át, így nem fog felülíródni a következõ fordítás és telepítés során. A kernel.old állományra ugyanis nem minden esetben számíthatunk, mivel az új rendszermagok telepítésénél a kernel.old mindig felülíródik a legutóbb telepített rendszermaggal, amely azonban nem feltétlenül lesz mûködõképes. Sõt, amint csak lehetséges, rakjuk a mûködõ rendszermagot a /boot/kernel könyvtárba vagy különben a &man.ps.1; és a hozzá hasonló parancsok nem fognak rendesen mûködni. Mindezek elvégzéséhez egyszerûen nevezzük át a jó rendszermagot tartalmazó könyvtárt: &prompt.root; mv /boot/kernel /boot/kernel.rossz &prompt.root; mv /boot/kernel.jó /boot/kernel A rendszermag mûködik, de a &man.ps.1; viszont nem: Ha olyan rendszermagot telepítettünk, aminek a verziója nem egyezik meg a hozzátartozó segédprogramokéval, tehát például -CURRENT rendszermagot raktunk egy -RELEASE rendszerhez, egyes rendszerállapotjelzõ parancsok, mint például a &man.ps.1; vagy a &man.vmstat.8; nem fognak mûködni. Ebben az esetben az egész rendszert újra kell fordítanunk és telepítenünk a rendszermagunkkal megegyezõ verziójú forrásból. Részben ezért sem különösen ajánlott, hogy az operációs rendszer többi részétõl eltérõ verziójú rendszermagot használjunk. diff --git a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml index e748acef00..c64fda2d0e 100644 --- a/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/mirrors/chapter.sgml @@ -1,3902 +1,3912 @@ A &os; beszerzése CD és DVD kiadók Kiskereskedelmi dobozos termékek A &os; beszerezhetõ számos kiskereskedõtõl dobozos termék formájában is (&os; CD-k, egyéb szoftverek és nyomtatott dokumentáció):
CompUSA WWW:
Frys Electronics WWW:
CD- és DVD-készletek &os; CD- és DVD-készletek rengeteg helyrõl rendelhetõek:
&os; Mall, Inc. 700 Harvest Park Ste F Brentwood, CA 94513 Egyesült Államok Telefon: +1 925 240-6652 Fax: +1 925 674-0821 e-mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Németország Telefon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Franciaország WWW:
JMC Software Írország Telefon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Egyesült Királyság Telefon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Lengyelország Telefon: +48 22 860 18 18 e-mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Ausztrália Telefon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Terjesztõk Ha viszonteladók vagyunk és szeretnénk CD-s &os; termékeket forgalmazni, akkor az alábbi terjesztõk valamelyikével vegyük fel a kapcsolatot:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Egyesült Államok Telefon: +1 650 694-4949 Fax: +1 650 694-4953 e-mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Egyesült Államok Telefon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Egyesült Államok Telefon: +1 952 947-0822 Fax: +1 952 947-0876 e-mail: sales@kudzuenterprises.com
LinuxCenter.Ru Galernaya utca, 55 Szentpétervár 190000 Oroszország Telefon: +7-812-3125208 e-mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Egyesült Államok Telefon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP oldalak A &os; hivatalos forrásai anonim FTP-n keresztül is elérhetõek különféle tükrözésekrõl. Az oldal ugyan jó minõségû kapcsolattal rendelkezik és rengeteg felhasználót is enged egyidejûleg kapcsolódni, azonban valószínûleg jobban járunk, ha egy hozzánk közelebbi tükrözést választunk (különösen abban az esetben, amikor mi magunk is egy tükrözést akarunk készíteni). A &os; tükrözések adatbázisában az itt megtalálhatónál sokkal pontosabb leltárt kaphatunk az elérhetõ tükrözésekrõl, mivel közvetlenül a névfeloldás segítségével állapítja meg a szükséges adatokat és nem egy rögzített listát tárol. Emellett az alábbi tükrözésekrõl a &os; elérhetõ anonim FTP-n keresztül is. Amennyiben az anonim FTP használata mellett döntenénk, igyekezzünk a hozzánk legközelebb levõ szervert használni. Az Elsõdleges tükrözésekként feltüntetett oldalak általában a teljes &os; archívumot tartalmazzák (az összes jelenleg elérhetõ változatot az összes architektúrára), de a környékünkön vagy országunkban elhelyezkedõ tükörszerverekrõl többnyire gyorsabban tudunk majd letölteni. A regionális oldalakon gyakorta csak a népszerûbb architektúrákon futó népszerûbb változatokat találjuk meg, nem a teljes &os; archívumot. Minden szerver elérhetõ anonim FTP-vel, de közülük néhány még további más módszereket is támogat. Az egyes oldalak által ismert konkrét módszereket a nevük után zárójelben közüljük. &chap.mirrors.ftp.inc; BitTorrent BitTorrent Az egyes kiadásokhoz tartozó alap CD-készletek BitTorrent segítségével is elérhetõek. A lemezek képeire hivatkozó torrent állományokat a címrõl tölthetjük le. A BitTorrent kliens telepíthetõ a net-p2p/py-bittorrent portból vagy csomagból. Miután sikeresen letöltöttük BitTorrenten keresztül a lemezképeket, a nyújthat segítséget abban, hogy kell ezeket lemezre írni. Anonim CVS <anchor id="anoncvs-intro">Bevezetés CVS anonim Az anonim CVS (vagy más néven anoncvs) a &os;-hez mellékelt CVS-es segédprogramok által nyújtott olyan lehetõség, amivel távoli CVS repositorykkal tudunk szinkronizálni. Több más dolog mellett lehetõvé teszi a &os; felhasználói számára, hogy kiemelt jogosultságok nélkül képesek legyenek olvasással kapcsolatos CVS mûveleteket végrehajtani a &os; Projekt hivatalos anoncvs szerverein. A használatához egyszerûen csak a kiválasztott anoncvs szervert kell beállítani a CVSROOT környezeti változó értékének, ahol aztán a cvs login parancsnak a szerver által ismert anoncvs jelszót kell megadni. Ezután a &man.cvs.1; paranccsal a többi CVS szerverhez hasonlóan lehetõségünk nyílik hozzáférni. A cvs login parancs a bejelentkezésekhez szükséges jelszavakat a HOME könyvtárunkban levõ .cvspass állományban tárolja. Ha ez az állomány nem létezik, akkor a cvs login elsõ használatakor hibát kapunk. Ilyenkor csak hozzunk létre egy üres .cvspass állományt, majd próbálkozzunk újra. Habár azt mondhatnánk, hogy a CVSup és az anoncvs lényegében egyazon feladatot oldják meg, mind a két esetben léteznek olyan kompromisszumok, amelyek befolyásolhatják a felhasználó választását a két szinkronizációs módszer között. Dióhéjban ezt úgy tudnánk összefoglalni, hogy a CVSup a hálózati erõforrásokat hatékonyabban kihasználja és kettejük közül ez a fejlettebb, azonban ennek meg kell fizetnünk az árát. A CVSup használatához elõször ugyanis telepítenünk kell és be kell állítanunk egy speciális klienst, illetve az adatokat a CVSup által gyûjteményeknek (collection) nevezett, viszonylag nagy méretû egyeségekben érhetjük el. Ezzel szemben az anoncvs használata során a megfelelõ CVS modul nevének felhasználásával tetszõlegesen megvizsgálhatunk önálló állományokat vagy akár programokat (mint az ls vagy a grep). Természetesen az anoncvs segítségével csupán az olvasást igénylõ CVS mûveleteket végezhetjük el, ezért ha a &os; Projekt keretein belül fejleszteni is szeretnénk, akkor inkább érdemes a CVSup alkalmazást választani. <anchor id="anoncvs-usage">Az anonim CVS használata A &man.cvs.1; parancsot nagyon könnyû beállítani az anonim CVS repositoryk használatához, hiszen mindössze annyit kell tennünk, hogy a CVSROOT környezeti változó értékének megadjuk a &os; Projekt valamelyik anoncvs szerverét. Ezen sorok írásának pillanatában a következõ szerverek érhetõek el: Franciaország: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (a jelszó anoncvs), ssh (nincs jelszó)) Japán: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (a cvs login használatánál a jelszó anoncvs.) Tajvan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (a cvs login használatával tetszõleges jelszó megadható), ssh (nincs jelszó)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub Egyesült Államok: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (csak ssh — nincs jelszó) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub Egyesült Államok: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (csak ssh2 — nincs jelszó) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Mivel a CVS használatával kikérhetjük (check out) tulajdonképpen a &os; forrásainak akármelyik eddigi (vagy majd ezután keletkezõ) változatát, érdemes megismerkednünk a &man.cvs.1; által alkalmazott revízió (revision) (az opcióval állítható) fogalmával és a &os; Projekt repositoryjain belül engedélyezett értékeivel. Címkéket (tag) két esetben használhatunk: a revíziók és az ágak esetén. A revíziós címkék mindig egy adott revízióra hivatkoznak, ami állandóan ugyanazt jelenti. Ezzel szemben az ágak címkéi a fejlesztés adott irányú menetének az adott pillanatban legfrissebb revízióját hivatkozzák. Mivel az ágak címkéi nem egy adott revízióra vonatkoznak, ezért elmondhatjuk róluk, hogy naponta változik a jelentésük. Az tartalmazza a felhasználók számára fontos revíziós címkéket. Ezek azonban nem igazak a Portgyûjteményre, mivel a Portgyûjteménynek nincs egyszerre több fejlesztési iránya. Egy ág címkéjének megadásával általában az adott irányhoz tartozó állományok legfrissebb változatát kapjuk meg. Ha viszont az állományok egy korábbi változatára lenne szükségünk, akkor a opció megadásával meg tudjuk adni annak idõpontját. Errõl részletesebben a &man.cvs.1; man oldalán olvashatunk. Példák Habár a továbbhaladáshoz mindenképpen javasoljuk a &man.cvs.1; man oldalának részletes áttanulmányozását, mutatunk néhány gyors példát az anonim CVS használatának tömör illusztrálására: Valami (az &man.ls.1;) kikérése a -CURRENT ágból &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Jelszóként ezután bármit megadhatunk. &prompt.user; cvs co ls Az <filename>src/</filename> fa kikérése SSH-n keresztül &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Az &man.ls.1; 6-STABLE ágban szereplõ változatának kikérése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Amikor kéri, jelszóként bármit megadhatunk. &prompt.user; cvs co -rRELENG_6 ls Az &man.ls.1; változásainak (Unified Diff formátumú) listázása &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Itt jelszóként bármit megadhatunk. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls A használható modulok nevének kiderítése &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Ezután jelszóként bármit megadhatunk. &prompt.user; cvs co modules &prompt.user; more modules/modules Egyéb helyek A következõ helyeken találhatunk még hasznos információkat a CVS használatáról: A CVS bemutatása (írta: Cal Poly). A CVS honlapja, a CVS fejlesztésével és alkalmazásával foglalkozó közösség oldala. A CVSweb a &os; Projekt által használt CVS rendszerének webes felülete. A CTM használata CTM A CTM használatáva a távoli könyvtárakat tudunk egy központi változattal szinkronban tartani. Eredetileg a &os; forrásaihoz fejlesztették ki, de idõvel mások más célokra is alkalmasnak találhatják majd. Az eltérések (delták) feldolgozásával kapcsolatban kevéske dokumentáció áll rendelkezésre, ezért a &a.ctm-users.name; levelezési listát érdemes felkeresni, ha többet szeretnénk megtudni a CTM egyéb célú alkalmazásairól. Miért használnánk a <application>CTM</application>-et? A CTM segítségével a &os; forrásainak helyi másolatát hozhatjuk létre. A források több különbözõ kivitelben is hozzáférhetõek. A CTM minden esetben képes eleget tenni az igényeinknek, akár az egész CVS fát, akár annak egy részét kívánjuk csak figyelemmel követni. Ha netalán &os; fejlesztõk lennénk, és híján vagyunk vagy éppen gyenge TCP/IP kapcsolattal rendelkezünk, esetleg egyszerûen csak automatikusan értesülni szeretnénk a változásokról, a CTM-et nekünk találták ki. A leggyorsabban fejlõdõ ágakból is naponta legfeljebb három deltát fogunk kapni, azonban érdemes megfontolni a változások automatikus elküldését levélben. A szükséges frissítések méretét mindig igyekszünk minimalizálni. Ez egyébként általában alig 5 KB, de néha (tízbõl egyszer) elõfordul, hogy 10 és 50 KB között van, és idõnként 100 KB vagy afeletti mennyiségû frissítés is érkezhet. Amikor a fejlesztõk által használt forrásokat töltjük le, magunknak kell gondoskodnunk a menet közben felmerülõ különbözõ problémák megoldásáról. Ez kiváltképp igaz abban az esetben, amikor az aktuális, vagy hivatalos nevén CURRENT ágat követjük. Mielõtt azonban egy ilyenbe belevágnánk, érdemes fellapozni a &os; legfrissebb változatának használatáról szóló fejezetet. Mire van szükségünk a <application>CTM</application> használatához? A mûködéshez két komponens szükségeltetik: a CTM kliensprogramja és hozzá a kezdeti delták (amivel majd letöltjük a CURRENT forrásait). A CTM program már a 2.0 kiadástól kezdve a &os; része, és a források között a /usr/src/usr.sbin/ctm könyvtárban találjuk meg (amennyiben felraktuk). A CTM mûködéséhez kellõ deltákat két módon, FTP-n vagy e-mailen keresztül szerezhetjük be. Ha el tudunk érni interneten levõ FTP oldalakat, akkor az alábbi FTP helyeken találunk a CTM-hez használható adatokat: valamint lásd a tükrözéseket. FTP-n keresztül lépjünk be a könyvtárba, töltsük le a README nevû állományt és kövessük a benne szereplõ utasításokat. Ha viszont e-mailen keresztül akarjuk megszerezni a deltákat: Iratkozzunk fel a CTM terjesztési listáinak egyikére. A &a.ctm-cvs-cur.name; lista az egész CVS-fát, míg a &a.ctm-src-cur.name; a fõ fejlesztési ágat teszi elérhetõvé. A &a.ctm-src-4.name; a 4.X kiadásaihoz ágakat tartalmazza, és így tovább. (Ha nem tudjuk, hogyan kell feliratkozni egy levelezési listára, akkor kattintsunk a lista nevére vagy kövessük a &a.mailman.lists.link; linket, majd kattintsunk arra a listára, ahova fel akarunk iratkozni. Ezen az oldalon az összes, a feliratkozáshoz nélkülözhetetlen információnak szerepelnie kell.) Miután elkezdenek megérkezni a CTM-frissítéseket tartalmazó levelek, a tartalmukat a ctm_rmail programmal tudjuk kicsomagolni és felhasználni. Az /etc/aliases állományba akár közvetlenül is beírhatjuk a ctm_rmail programot, és ezzel a önállósítani tudjuk a levélben érkezõ frissítések feldolgozását. A ctm_rmail man oldalán olvashatjuk ennek részleteit. Nem számít, milyen módon jutunk hozzá a CTM által használt deltákhoz, minden esetben fel kell iratkoznunk a &a.ctm-announce.name; levelezési listára. Az elkövetkezendõkben ez lesz az egyetlen hely, ahová a CTM rendszer mûködtetésével kapcsolatos bejelentések beküldésre kerülnek. A feliratkozáshoz kattinsunk a fenti lista nevére és kövessük a mellette szereplõ utasításokat. A <application>CTM</application> elsõ használata Mielõtt nekilátnánk a CTM-hez tartozó delták használatának, elõször el kell jutnunk egy kiindulási ponthoz, ahonnan majd létre tudjuk hozni a rákövetkezõ deltákat. Ehhez elsõként vegyük számba, pontosan mink is van. Általában mindenki egy üres könyvtárral kezd. Ilyenkor egy kezdeti Empty (mint üres) elnevezésû deltával tudjuk megkezdeni az CTM által ismert fa szinkronizálását. Erre a célra lesznek majd szintén alkalmasak a megkezdett delták is, amelyek valamikor a CD-re fognak felkerülni. Mivel a fák maguk több tíz megabyte-nyi méretûek, ezért érdemes inkább valami kéznél levõ eszközzel megkezdeni a folyamatot. Ha van -RELEASE verziójú CD-nk, akkor másoljuk le róla és bontsuk ki a kiindulásként használt forrásokat. Ezzel jelentõs mennyiségû adat átvitelét takaríthatjuk meg. A kezdõ deltákat könnyen megismerjük a szám után X karakterrel leválasztott nevükrõl (például src-cur.3210XEmpty.gz). Az X után szereplõ megnevezés a kezdeti kiindulás (seed) fokának felel meg. Az Empty egy üres könyvtárra utal. A szabályok szerint az Empty állapotból 100 deltánként jön létre újabb (kiindulásra alkalmas) alapváltozat. Ezek azonban nagyon nagyok is lehetnek. A 70 vagy 80 megabyte-os gzippel csomagolt adatok gyakoriak az XEmpty delták esetén. Miután kiválasztottuk a számunkra megfelelõ alapváltozatot, szükségünk lesz a tõle nagyobb sorszámú összes deltára is. A <application>CTM</application> használata a hétköznapokban A delták felhasználásához egyszerûen csak ennyit kell tennünk: &prompt.root; cd /ahol/tárolni/akarjuk/az/adatokat &prompt.root; ctm -v -v /ahol/tároljuk/a/deltákat/src-xxx.* A CTM képes értelmezni a gzip által csomagolt adatokat, ezért nincs szükség a delták elõzetes kitömörítésére, amivel tárhelyet tudunk spórolni. Hacsak nem tekinti tökéletesen biztonságosnak az egész folyamatot, akkor a CTM nem fog módosítani a fán. A deltákat a CTM kapcsolójával is ellenõrizhetjük, aminek során egyáltalán nem fog módosulni a forrásfa. Ekkor egyszerûen csak ellenõrzi a delták sértetlenségét és megnézi, hogy minden rendben zajlana-e az alkalmazásuk során. A CTM-nek vannak még további kapcsolói is, melyekrõl bõvebben a man oldalakból és a forráskódokból tájékozódhatunk. Most már minden megvan, ami kellhet. Amikor kapunk egy újabb deltát, a forrásaink frissítéséhez csak futtassuk át a CTM-en. Ne töröljük le azokat a deltákat, melyeket nehezen tudtunk letölteni. Helyette érdemes inkább megtartani ezeket arra az esetre, ha valami rossz történne. Még ha csak floppylemezek is állnak rendelkezésünkre, mindenképpen másoljuk le ezeket az fdwrite paranccsal. A saját változtatásaink megtartása Fejlesztõként biztosan szeretnénk kísérletezni és állományokat megváltoztatni a forrásfában. A CTM a helyben elkövetett változtatásokat csak korlátozottan támogatja: az ize nevû állomány meglétének vizsgálata elõtt az ize.ctm állományt fogja keresni. Ha létezik, akkor a CTM az ize helyett ezen fog dolgozni. Ezzel a viselkedéssel nyerjük a saját változtatásaink megtartásának egyszerû módját: csak másoljuk le .ctm kiterjesztéssel a módosítani tervezett állományokat. Ezután már szabadon módosíthatjuk a forrásokat, miközben a CTM a .ctm kiterjesztésû állományokat folyamatosan szinkronban tartja. A <application>CTM</application> egyéb érdekes beállításai Derítsük ki pontosan miket is fog érinteni a frissítés A CTM által a forrásokon elvégzendõ változtatások listáját az kapcsolóval kérdezhetjük le. Ez akkor esik kézre, ha szeretnénk feljegyezni a bekövetkezõ változásokat, vagy bármilyen módon elõ- vagy utófeldolgozni a módosított állományokat, esetleg szimplán elõvigyázatosak akarunk lenni. Biztonsági másolat készítése a frissítés elõtt Néha egyszerûen csak szeretnénk az összes érintett állományról biztonsági másolatot készíteni a CTM által elvégzett frissítés elõtt. A beállítás megadásával az adott CTM delta által módosítandó összes állomány tárolásra kerül a mentés-állomány nevû állományba. A frissíthetõ állományok korlátozása Egyes esetekben érdekünkben állhat leszûkíteni a CTM által eszközölt frissítések hatáskörét, vagy egyszerûen csak néhány állomány szinkronizálására van szükségünk. A CTM számára feldolgozható állományok listáját reguláris kifejezés formájában az és opciók mentén határozhatjuk meg. Például ha a lib/libc/Makefile állomány az összegyûjtött CTM delták szerinti legfrissebb verziójához kívánunk hozzájutni, akkor futtassuk az alábbi parancsot: &prompt.root; cd /akarhova/ahova/ki/akarjuk/bontani/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* A CTM deltákban megadott minden egyes állomány esetén az az opciók a parancssorban történt megadásuk sorrendjében kerülnek feldolgozásra. Egy állományt kizárólag csak akkor dolgoz fel a CTM, ha az az és opciók kiértékelése után is indokolt. További tervek a <application>CTM</application>-mel kapcsolatban Rengeteg van: Valamiféle hitelesítés bevezetése a CTM rendszerbe, amivel észlelhetõek a meghamisított CTM-frissítések. A CTM beállításainak letisztázása, mivel eléggé megtévesztõek és nehézkesen használhatóak. Egyebek Léteznek delták a portok gyûjteményéhez is, azonban még nem mutatkozott túlzottan nagy érdeklõdés irántuk. CTM tükrözések A CTM/FreeBSD anonim FTP-n keresztül elérhetõ az alábbi tüköroldalak valamelyikérõl. Amennyiben ezen a módon kívánjuk letölteni a CTM rendszerhez tartozó állományokat, elõször próbálkozzunk a hozzánk legközelebb levõ szerverrel. Ha bármilyen gond merülne fel, értesítsük a &a.ctm-users.name; levelezési listát. Kalifornia, Bay Area (hivatalos forrás) Dél-Afrika (a korábbi delták biztonsági másolatai) Tajvan/R.O.C. Ha nem találtunk volna hozzánk közel esõ tükrözést, vagy ha talált tükör nem elég friss, akkor próbálkozzunk egy olyan keresõmotor használatával, mint például az alltheweb. A CVSup használata Bevezetés A CVSup távoli szervereken található központi repositorykban levõ forrásfák terjesztésére és a rajtuk keresztüli frissítésre alkalmas programcsomag. A &os; forrásait egy CVS repositoryban tartják karban Kaliforniában egy fejlesztéseket tároló központi számítógépen. A CVSup segítségével a &os; felhasználói könnyen szinkronban tudják vele tartani a saját forrásaikat. A CVSup az ún. lehúzással frissít. Ilyenkor a kliensek csak akkor kérnek a szervertõl frissítéseket, amikor szükségük van rá, miközben a szerver passzívan várja a frissítési kérelmeket. Ennek megfelelõen tehát minden esetben a kliens kezdeményezi a frissítést, a szerver pedig önmagától sosem küld ilyeneket kéretlenül. A felhasználóknak így vagy maguknak kell meghívniuk a CVSup kliensét, vagy a frissítések rendszeres automatikus letöltéséhez be kell állítaniuk a cron rendszerprogramot. A CVSup kifejezés ebben az írásmódban az egész programcsomagra utal. Fõ alkotórészei a a felhasználó gépén futó cvsup nevû kliens, és a &os; tüköroldalain futó cvsupd nevû szerver. A &os; dokumentációjának és levelezési listáinak fürkészése során rengeteg hivatkozást találhatunk egy sup nevû alkalmazásra. A sup a CVSup elõdje volt, és hasonló célokat szolgált. A CVSup használat tekintetében nagyon hasonlít a sup-hoz, és ami azt illeti, a a sup konfigurációs állományaival visszafele kompatibilis formátumot használ. Mivel a CVSup sokkal gyorsabb és rugalmasabb, a supot már nem használja a &os; Projekt. A csup a CVSup C nyelven újraírt változata. Legnagyobb elõnye, hogy gyorsabb és nincs szüksége a Modula-3 nyelv futtató környezetére, ezért azt nem kell a használatához telepíteni. Ráadásul, ha a &os; 6.2 vagy annál késõbbi változatát használjuk, akkor minden további nélkül a rendelkezésünkre áll, hiszen az alaprendszer része. A &os; korábbi verzióinak alaprendszerei ugyan nem tartalmazzák a &man.csup.1; parancsot, viszont a net/csup port vagy csomag segítségével pillanatok alatt telepíteni tudjuk. Emellett a csup segédprogram nem támogatja a CVS módot sem. Teljes repositoryk tükrözéséhez ezért továbbra is a CVSup kell használnunk. Amennyiben a csup mellett tennénk le a voksunkat, a szakasz fennmaradó részében egyszerûen hagyjuk ki a CVSup telepítésérõl szóló lépéseket és a CVSup hivatkozásait helyettesítsük a csup programmal. Telepítés A CVSup telepítésének legegyszerûbb módja a &os; csomaggyûjteményében található elõrefordított net/cvsup csomag használata. Ha viszont inkább forrásból akarjuk telepíteni a CVSupot, akkor helyette használjuk a net/cvsup portot. De legyünk elõvigyázatosak: a net/cvsup portnak szüksége van a Modula-3 rendszerre, aminek letöltése és lefordítása pedig meglehetõsen sok idõt és tárhelyet igényel. Ha olyan gépen akarjuk használni a CVSupot, ahol nincs &xfree86;, &xorg; vagy bármilyen más ilyen szerver, akkor használjuk a net/cvsup-without-gui portot, ami nem tartalmazza a hozzátartozó grafikus felületet. Ha a &os; 6.1 vagy korábbi változatain szeretnénk telepíteni a csupot, használjuk a &os; csomaggyûjteményében megtalálható net/csup csomagot. Ha viszont forrásból kívánjuk telepíteni a csup programot, akkor helyette használjuk a net/csup portot. A CVSup beállítása A CVSup mûködését a supfile elnevezésû állomány vezérli. A /usr/share/examples/cvsup/ könyvárban találhatunk néhány példát a supfile állományokra. A supfile állományban szereplõ információk a CVSup használatával kapcsolatban a következõ kérdéseket válaszolják meg: Milyen állományokat akarunk letölteni? Milyen verzióikra van szükségünk? Honnan akarjuk ezeket beszerezni? Hova akarjuk rakni a számítógépünkön? Hova akarjuk rakni az állapotot tároló állományokat? Az imént feltett kérdésekre a következõ szakaszokban összeállítandó supfile segítségével fogunk válaszolni. Ehhez elõször bemutatjuk a supfile formátumú állományok általános szerkezetét. A supfile állományok szöveget tartalmaznak. A megjegyzések # karakterrel kezdõdnek és a sor végéig tartanak. A kizárólag csak megjegyzéseket tartalmazó vagy üres sorok nem kerülnek feldolgozásra. Az összes többi fennmaradó sorban pedig azokat az állományokat írjuk le, amelyeket a felhasználó le akar tölteni. Az ilyen fajtájú sorok egy gyûjtemény (collection) nevével kezdõdnek, ami állományok egy szerver által meghatározott logikai csoportjára utal. A gyûjtemény neve ennek megfelelõen elárulja a szervernek, hogy pontosan milyen állományokra van szükségünk. Ezután következik whitespace-szel elválasztva nulla vagy több mezõ, amelyek a korábban feltett kérdéseinket válaszolják meg rendre. Ezeknek a mezõknek két típusa létezik: a beállításokat és a konkrét értéket tároló mezõk. A beállításokat tároló mezõk különbözõ kulcsszavakat tartalmaznak, például a delete (törlés) vagy compress (tömörítés). Az értéket tároló mezõk is egy kulcsszóval kezdõdnek, azonban utána közvetlenül egy = (egyenlõségjel) jön, amelyet egy második szó követ szorosan. Így például a release=cvs pontosan egy ilyen értékmezõ lesz. Egy supfile általában egynél több gyûjtemény letöltését írja le. Ezért az ilyen állományok felépítésének egyik módja, ha az egyes gyûjteményhez explicite megadjuk a hozzátartozó mezõket. Azonban így a supfile állományok gyorsan megnövekednek és kényelmetlenné válnak, mivel a legtöbb gyûjtemény esetén szinte ugyanazokat a mezõket kellene megadnunk. A CVSup az ilyen típusú bonyodalmak elkerülésére egy alapértelmezési megoldást javasol. A *default nevû álgyûjteménnyel kezdõdõ sorok segítségével meg tudunk adni olyan beállításokat és értékeket, amelyek az utána következõ gyûjtemények számára alapértelmezésnek fognak számítani a supfile állományban. Az itt megadott alapértelmezések természetesen az egyes gyûjteményekben tetszõleges módon felülbírálhatóak, a mezõk magán a gyûjteményen belüli megadásával. Az állományban az alapértelmezések is megváltoztathatóak vagy bõvíthetõek további *default sorok hozzáadásával. Mindezek tudatában most már megkezdhetjük a FreeBSD-CURRENT ág tartalmának letöltésére és frissen tartására alkalmas supfile állomány összeállítását. Milyen állományokat akarunk letölteni? A CVSupon keresztül elérhetõ állományok gyûjteményeknek hívott nevesített csoportokra bontva érhetõek el. A hivatkozható gyûjtemények leírását a következõ szakaszban találjuk. Ebben a példában most szeretnénk letölteni az egész &os; rendszer forrását. Ezt a src-all nevû gyûjteményre hivatkozva érhetjük el. A supfile állományunk létrehozásának elsõ lépéseként soronként egyet megadva felsoroljuk a letölteni kívánt gyûjteményeket (jelen esetünkben csak egyetlen egyet): src-all Milyen verzióikra van szükségünk? A CVSup használatával tulajdonképpen a források összes valaha létezett verziójához hozzá tudunk férni. Ez annak köszönhetõ, hogy a cvsupd szerver közvetlenül a CVS repositoryból dolgozik, ami pedig az összes verziót tartalmazza. A tag= és date= értékmezõk segítségével adhatjuk meg az igényelt verziókat. Legyünk óvatosak azonban a tag= mezõk helyes megadásával. Egyes címkék ugyanis csak bizonyos állománygyûjtemények esetén élnek. Ha hibás vagy elírt címkét adunk meg, akkor a CVSup törölni fog olyan állományokat, amelyeket valószínûleg nem kellene. A ports-* gyûjtemények esetében pedig kifejezetten csak a tag=. mezõk használhatóak! A tag= mezõk a tárházban található szimbolikus címkéket nevezik meg. A címkéknek két típusa van: a revíziókhoz és az ágakhoz tartozó címkék. A revíziós címkék mindig egy adott revíziót hivatkoznak, jelentésük állandó. Ezzel szemben az ágak címkéi egy adott fejlesztési ág adott idõpontjában elérhetõ revíziót címkézi. Mivel az ágak címkéi nem egy konkrét revízióra vonatkoznak, ezért akár olyanra is utalhatnak, ami pillanatnyilag még nem is létezik. Az ban megtalálhatjuk a fontosabb ágak címkéit. A CVSup konfigurációs állományában a címkéket a tag= elõtaggal kell bevezetni (így tehát a RELENG_4 címke hivatkozása tag=RELENG_4 lesz). Ne felejtsük el, hogy a Portgyûjtemény esetében csak tag=. mezõ megadásának van értelme. Igyekezzünk pontosan lemásolni a címkék neveit, mivel a CVSup nem képes megkülönböztetni az érvényes és az érvénytelen címkéket. Ha véletlen elírjuk a címkét, akkor a CVSup úgy fog viselkedni, mintha olyan érvényes címkére hivatkozhatunk volna, amihez nem tartoznak állományok. Ennek következtében pedig egyszerûen letörli a már meglevõ forrásainkat. Egy ág címkéjének megadása során általában az adott fejlesztési vonal legfrissebb verzióját kapjuk meg. Ha viszont az adott ág valamelyik korábbi változatára lenne szükségünk, akkor a értékmezõ felhasználásával meg tudjuk adni a hozzátartozó dátumot. Ennek mûködésérõl a &man.cvsup.1; man oldala részletesebben értekezik. A példában mi most a &os;-CURRENT verziót akarjuk letölteni. Ezért a következõ sort tesszük a supfile állományunk elejére: *default tag=. Ha nem adunk meg sem tag=, sem pedig date= mezõket, akkor egy fontos eset következik be. Ilyenkor ugyanis egy konkrét verzió helyett közvetlenül a szerver CVS repositoryjából kapjuk meg az állományokat, az összes kiegészítõ információjukkal együtt. A fejlesztõk általában ezt a típusú megoldást kedvelik, mivel így a saját rendszerükön is könnyen karban tudnak tartani egy példányt, amiben tudnak keresni a revíziók között és ki tudják kérni akár az állományok korábbi változatait is. Természetesen ennek függvényében jóval több tárhelyre van szükségük. Honnan akarjuk ezeket beszerezni? A host= mezõ beállításával közöljük a cvsup klienssel, honnan töltse le a frissítéseket. A CVSup tükrözések közül bármelyik megfelel erre a célra, habár leginkább azt érdemes választani, ami a kibertérben a hozzánk legközelebb esik. A példában most egy kitalált &os; terjesztési oldalt választunk, a cvsup99.FreeBSD.org-ot: *default host=cvsup99.FreeBSD.org A CVSup futtatása elõtt tehát ne felejtsük el megváltoztatni ezt a létezõ számítógép hálózati nevére. A cvsup futtatásakor a opció megadásával lehetõségünk ennek felülbírálására. Hova akarjuk rakni a számítógépünkön? A prefix= mezõ adja meg a cvsup számára, hogy hova tegye a kapott állományokat. A példában a forrásokat közvetlenül a forrásokat tároló központi könyvtárba, a /usr/src könyvtárba tettük. Mivel a src könyvtár neve már hallgatólagosan benne foglaltatik a letöltésre kiválasztott gyûjtemény nevében, ezért itt csak ennyit kell megadnunk: *default prefix=/usr Hova akarjuk rakni az állapotot tároló állományokat? A CVSup kliens egy bázisnak (base) nevezett könyvtárban folyamatosan fenntart bizonyos állományokban állapotokat (status file). Ezek a már letöltött állományok nyilvántartásával segítik a CVSup hatékony munkavégzését. Mi most a szabványos bázist, a /var/db könyvtárat fogjuk használni: *default base=/var/db Amennyiben még nem létezne a bázisként használni kívánt könyvtár, ideje létrehoznunk. A cvsup ugyanis egy nem létezõ könyvtár esetén nem lesz hajlandó mûködni. További beállítások a supfile állományban: Általában még egy sor szokott szerepelni a supfile állományokban: *default release=cvs delete use-rel-suffix compress A release=cvs mezõ jelzi, hogy a szervernek a &os; fõ CVS repositoryból kell kikeresnie az információkat. Tulajdonképpen majdnem mindig errõl van szó, és az itt megadható többi lehetõség ismertetése most egyébként is meghaladná a szakasz határait. A delete hatására a CVSup képes lesz állományokat törölni. Mindig érdemes megadnunk, hiszen a CVSup csak így tudja teljes mértékben frissentartani a forrásokat. A CVSup természetesen csak azokat az állományokat igyekszik letörölni, amelyek miatt valóban felelõs. A kóbor állományokat nem fogja bántani. A use-rel-suffix hatása egy igazi... Rejtély. Ha tényleg érdekel minket a mûködése, lapozzuk fel bátran a &man.cvsup.1; man oldalát. Nyugodtan adjuk meg és különösebben ne törõdjünk vele. A compress beállítás segítségével a kommunikációs csatornán vándorló adatokat tudjuk gzip-szerû módon tömöríteni. Ha a hálózati kapcsolatunk sebessége meghaladja a 1,5 Mbitet másodpercenként (T1), akkor ezt már nem érdemes használni, viszont minden más esetben lényeges gyorsulást hozhat. Összegezzük az eddigieket: Íme a példaként összerakott supfile állományunk teljes tartalma: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all A <filename>refuse</filename> állomány Ahogy arról már korábban szó esett, a CVSup lehúzással frissít. Ez alapvetõen annyit jelent, hogy feltárcsázunk egy CVSup szervert, aki a következõt mondja nekünk: A következõket tudod tõlem letölteni..., amire a kliensünk ezt válaszolja: Rendben, akkor nekem kell ez, ez, ez meg ez. Alapértelmezés szerint a CVSup kliense azokat az állományokat fogja letölteni, amelyeket a konfigurációs állományban szereplõ gyûjtemények és címkék által megneveztünk. Ez azonban nem mindig felel meg az igényeinknek, különösen akkor, amikor a doc, ports vagy www fákat akarjuk letölteni — az emberek többsége ugyanis nem beszél négy vagy öt nyelven, ezért nincs is szükségük a nyelvfüggõ állományok letöltésére. A Portgyûjtemény letöltése során a ports-all helyett egyszerûen egyenként is felsorolhatjuk a számunkra érdekes kategóriákat (például ports-astrology, ports-biology stb). Azonban mivel a doc és a www fákhoz nincsenek nyelvfüggõ gyûjtemények, ezért elõ kell halásznunk a CVSup egyik remek funkcióját, a refuse állományt. A refuse állománnyal lényegében arra utasítjuk a CVSup alkalmazást, hogy a gyûjteményekbõl ne töltse le az összes állományt. Úgy is fogalmazhatnánk, hogy javaslatára a kliens visszautasít (refuse) bizonyos szervertõl érkezõ állományokat. Ezeket a visszautasításokat tároló refuse állományt a bázis/sup/ könyvtárban találhatjuk meg (illetve ha még nincsenek, akkor ide kell rakunk ezeket). Itt a bázis a supfile állományban megadott base= mezõre utal, ami a példánkban a /var/db könyvtár volt. Ennek megfelelõen tehát a refuse állomány a /var/db/sup/refuse lesz. A refuse állomány felépítése igen egyszerû: a letölteni nem kívánt állományok és könyvtárak neveit tartalmazza. Például ha az angolul mellett esetleg még beszélünk egy kevés németet is, de nincs szükségünk az angol dokumentáció német fordítására sem, akkor a következõket írjuk a refuse állományba: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* és így tovább a többi nyelvre is (melyeket a &os; CVS repository böngészésével deríthetjük ki). Ezzel az alkalmas funkcióval a lassú vagy drága internetes kapcsolattal rendelkezõ felhasználók nagyon jól tudnak gazdálkodni, mivel így nem kell letölteniük az egyáltalán nem használt állományokat. A refuse állományokról és a CVSup más hasonlóan elegáns funkcióiról a saját man oldaláról tudhatunk meg többet. A <application>CVSup</application> futtatása Most már készen állunk egy próba frissítés elvégzésére. A parancssorban nem sok mindent kell beírnunk ehhez: &prompt.root; cvsup supfile ahol a supfile a frissen létrehozott supfile állományunk neve lesz. Feltételezve, hogy a parancsot X11 alatt adtunk ki, az cvsup erre feldob egy grafikus ablakot néhány gombbal. Nyomjuk meg a go feliratú gombot és dõljünk hátra. Mivel a példában a /usr/src könyvtárunk frissítését állítottuk be, az állományok aktualizálásához szükséges jogosultságok biztosításához a cvsup programot root felhasználóként kell elindítanunk. Teljesen érthetõ, ha egy kicsit izgatottak vagyunk ezekben a pillanatokban, hiszen az elõbb hoztunk létre egy általunk eddig ismeretlen programhoz egy konfigurációs állományt. Ezért megemlítenénk, hogy ilyenkor elõször mindig próbáljuk ki a konfigurációkat, mielõtt azok bármilyen módosítást végeznének a fontos állományainkon. Ehhez hozzunk létre valahol egy üres könyvtárat, majd adjuk meg a parancssorban ennek a nevét: &prompt.root; mkdir /var/tmp/proba &prompt.root; cvsup supfile /var/tmp/proba Az így megadott könyvtárba kerülnek a frissítés eredményeképpen keletkezõ állományok. A CVSup elõször megvizsgálja a /usr/src könyvtárban található állományokat, viszont egyiküket sem módosítja vagy törli. A frissítések ehelyett a /var/tmp/proba/usr/src könyvtárba fognak kerülni. A CVSup emellett még a báziskönyvtárában tárolt állapotokat sem fogja megváltoztatni. A módosított állományok új változatai a megadott könyvtárba jönnek létre. Mivel a /usr/src könyvtárt ehhez csak olvasni fogjuk, a próba lefuttatásához még root felhasználónak sem kell lennünk. Ha nem használunk X11-et vagy egyszerûen csak nincs szükségünk a grafikus felületre, a parancssorban pár további opció megadásával így is kiadhatjuk a cvsup parancsot: &prompt.root; cvsup -g -L 2 supfile A hatására a CVSup nem hozza be a grafikus felületét. Ha nem talál X11-et, akkor ez természetesen automatikus, de ellenkezõ esetben ezt is meg kell adnunk. Az megadásával a CVSup az összes elvégzendõ frissítésrõl részletes értesítést ad. A részletességnek három foka van, -tól indulva egészen -ig. Itt az alapértelmezett érték a 0, amivel a hibaüzenetek kivételével egyetlen üzenetet sem kapunk. Rengeteg egyéb beállítás adható még meg, ezeket a cvsup -H kiadásával kérdezhetjük le. A beállítások pontosabb leírását a man oldalon találjuk meg. Miután elégedetten tapasztaltuk, hogy a frissítés remekül mûködik, a &man.cron.8; segítségével próbáljuk meg az egész folyamatot önmûködövé tenni a CVSup szabályos idõközönkénti futtatásával. Ekkor viszont magától értetõdik, hogy a CVSup számára ne engedjük használni a grafikus felületet. A <application>CVSup</application> állománygyûjteményei A CVSup révén elérhetõ állománygyûjtemények egy hierarchikus rendszert alkotnak. Van néhány nagyobb állománygyûjtemény, amelyek kisebb al-állománygyûjteményekre bonthatóak. A nagyobb gyûjtemények letöltése ezért a kisebb algyûjtemények letöltésével egyenlõ. A gyûjtemények közt fennálló hierarchikus rendszer a lentebb szereplõ lista behúzásaiban érhetõ tetten. A leggyakrabban használt gyûjtemények a src-all és a ports-all neveket viselik. A többi gyûjteményt általában csak kevesen és csak speciális célokra használják, ezért egyes tükrözéseken nem feltétlenül találjuk meg mindegyiküket. cvs-all release=cvs A &os; fõ CVS repositoryja, beleértve a titkosításhoz tartozó kódokat is. distrib release=cvs A &os; terjesztéséhez és tükrözéséhez kapcsolódó állományok. doc-all release=cvs A &os; kézikönyvének és a többi dokumentáció forrásai. Nem tartalmazza a &os; honlapjának forrásait. ports-all release=cvs A &os; portgyûjteménye. Ha nem akarjuk a ports-all egészét (vagyis a teljes portfát) frissíteni, csak a lentebb szereplõ egyes algyûjteményeket letölteni, akkor soha ne feledkezzünk meg a ports-base megadásáról! Amikor valami változik a portok mûködésében, akkor a ports-base által képviselt algyûjteményben szereplõ állományokat igen gyorsan elkezdik használni a valódi portok. Ezért ha csak a valódi portokat frissítjük, amelyek viszont igényt tartanak néhány újabb funkcióra is, akkor könnyen fordítási hibára vagy különbözõ rejtélyes hibaüzenetekbe futhatunk. Emiatt legeslegelõször mindig tegyünk róla, hogy a ports-base algyûjteményünk a lehetõ legfrissebb legyen. Ha a ports/INDEX állomány egy saját példányát kívánjuk létrehozni, akkor ahhoz a ports-all gyûjteményt (tehát a teljes portfát) le kell kérnünk. A ports/INDEX állományt a portfa egy része alapján nem készíthetjük el. Errõl bõvebben lásd a GYIK-ot. ports-accessibility release=cvs A fogyatékos felhasználókat segítõ szoftverek. ports-arabic release=cvs Arab nyelvi támogatás. ports-archivers release=cvs Archiváló eszközök. ports-astro release=cvs Csillagászathoz tartozó portok. ports-audio release=cvs Hangtámogatás. ports-base release=cvs A Portgyûjtemény saját infrastruktúrája — az Mk/, Tools/ és /usr/ports különféle alkönyvtáraiban elhelyezkedõ állományok. Ne hagyjuk figyelmen kívül a fenti fontos figyelmeztetést sem: ezt az algyûjteményt mindig a &os; Portgyûjteményével együtt frissítsük! ports-benchmarks release=cvs Teljesítménytesztek. ports-biology release=cvs Biológia. ports-cad release=cvs Számítógépes tervezõeszközök (CAD). ports-chinese release=cvs Kínai nyelvi támogatás. ports-comms release=cvs Kommunikációs szoftverek. ports-converters release=cvs Karakterkódolások közti átalakítók. ports-databases release=cvs Adatbázisok. ports-deskutils release=cvs A számítógép feltalálása elõtt is már létezõ eszközök. ports-devel release=cvs Fejlesztõeszközök. ports-dns release=cvs Névfeloldással kapcsolatos szoftverek. ports-editors release=cvs Szövegszerkesztõk. ports-emulators release=cvs Más operációs rendszerek emulátorai. ports-finance release=cvs Pénzügyi, gazdasági és hasonló alkalmazások. ports-ftp release=cvs FTP kliensek és szerverek. ports-games release=cvs Játékok. ports-german release=cvs Német nyelvi támogatás. ports-graphics release=cvs Grafikus segédeszközök. ports-hebrew release=cvs Héber nyelvi támogatás. ports-hungarian release=cvs Magyar nyelvi támogatás. ports-irc release=cvs IRC-vel kapcsolatos programok. ports-japanese release=cvs Japán nyelvi támogatás. ports-java release=cvs &java; segédeszközök. ports-korean release=cvs Koreai nyelvi támogatás. ports-lang release=cvs Programozási nyelvek. ports-mail release=cvs Levelezõ programok. ports-math release=cvs Numerikus számításokkal foglalkozó programok. ports-mbone release=cvs MBone alkalmazások. ports-misc release=cvs Egyéb segédprogramok. ports-multimedia release=cvs Multimediás szoftverek. ports-net release=cvs Hálózati szoftverek. ports-net-im release=cvs Üzenetküldõ (Instant Messaging, IM) szoftverek. ports-net-mgmt release=cvs Hálózati karbantartó szoftverek. ports-net-p2p release=cvs Egyenrangú (Peer to Peer, P2P) hálózatok. ports-news release=cvs USENET hírszoftverek. ports-palm release=cvs A Palm sorozat szoftveres támogatása. ports-polish release=cvs Lengyel nyelvi támogatás. ports-ports-mgmt release=cvs A portok és csomagok karbantartását végzõ segédeszközök. ports-portuguese release=cvs Portugál nyelvi támogatás. ports-print release=cvs Nyomdai programok. ports-russian release=cvs Orosz nyelvi támogatás. ports-science release=cvs Tudományos programok. ports-security release=cvs Biztonsági segédprogramok. ports-shells release=cvs Parancsértelmezõk. ports-sysutils release=cvs Rendszerprogramok. ports-textproc release=cvs Szövegfeldolgozást segítõ eszközök (kivéve az asztali kiadványszerkesztést). ports-ukrainian release=cvs Ukrán nyelvi támogatás. ports-vietnamese release=cvs Vietnámi nyelvi támogatás. ports-www release=cvs A világhálóhoz tartozó szoftverek. ports-x11 release=cvs Az X Window System mûködését segítõ portok. ports-x11-clocks release=cvs X11 órák. ports-x11-drivers release=cvs X11 meghajtók. ports-x11-fm release=cvs X11 állománykezelõk. ports-x11-fonts release=cvs X11 betûtípusok és a hozzájuk tartozó segédprogramok. ports-x11-toolkits release=cvs X11 eszközrendszerek. ports-x11-servers release=cvs X11 szerverek. ports-x11-themes release=cvs X11 témák. ports-x11-wm release=cvs X11 ablakkezelõk. projects-all release=cvs A &os; projektek forrásainak repositoryja. src-all release=cvs A &os; fontosabb forrásai, a titkosításhoz tartozó kódokkal együtt. src-base release=cvs A /usr/src könyvtárban levõ egyéb állományok. src-bin release=cvs Az egyfelhasználós módban használható segédeszközök (/usr/src/bin). src-cddl release=cvs A CDDL licenc szerint terjesztett segédprogramok és függvénykönyvtárak (/usr/src/cddl). src-contrib release=cvs A &os; Projekten kívül fejlesztett segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/contrib). src-crypto release=cvs A &os; Projekten kívül fejlesztett, titkosítással kapcsolatos segédprogramok és függvénykönyvtárak, viszonylag kevés módosítással (/usr/src/crypto). src-eBones release=cvs Kerberos és DES (/usr/src/eBones). A &os; jelenlegi változatai nem használják. src-etc release=cvs A rendszer beállításait tartalmazó állományok (/usr/src/etc). src-games release=cvs Játékok (/usr/src/games). src-gnu release=cvs A GPL licenc szerint terjesztett segédprogramok (/usr/src/gnu). src-include release=cvs (C nyelvi) Header állományok (/usr/src/include). src-kerberos5 release=cvs A Kerberos5 biztonsági csomag (/usr/src/kerberos5). src-kerberosIV release=cvs A KerberosIV biztonsági csomag (/usr/src/kerberosIV). src-lib release=cvs Függvénykönyvtárak (/usr/src/lib). src-libexec release=cvs Más programok által futtatott rendszerprogramok (/usr/src/libexec). src-release release=cvs A &os; kiadások elkészítéséhez szükséges állományok (/usr/src/release). src-rescue release=cvs Statikusan linkelt programok vészhelyzet esetére, lásd &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Egyfelhasználós módban használható rendszereszközök (/usr/src/sbin). src-secure release=cvs Titkosítással foglalkozó függvénykönyvtárak és parancsok (/usr/src/secure). src-share release=cvs Több rendszer között megosztható állományok (/usr/src/share). src-sys release=cvs A rendszermag (/usr/src/sys). src-sys-crypto release=cvs A rendszermagban levõ titkosítással foglalkozó kód (/usr/src/sys/crypto). src-tools release=cvs A &os; karbantartására való különbözõ segédprogramok (/usr/src/tools). src-usrbin release=cvs Felhasználói segédprogramok (/usr/src/usr.bin). src-usrsbin release=cvs Rendszerszintû segédprogramok (/usr/src/usr.sbin). www release=cvs A &os; Projekt honlapjának forráskódja. distrib release=self A CVSup szerver saját konfigurációs állományai. A CVSup tükrözései használják. gnats release=current A GNATS hibanyilvántartó adatbázis. mail-archive release=current A &os; levelezési listáinak archívuma. www release=current A &os; Projekt honlapjának generált állományai (de nem a forrásai). A WWW tükrözések használják. Bõvebb információk A CVSup részletesebb bemutatását és a hozzátartozó GYIK-ot A CVSup honlapján találjuk meg. A CVSup &os;-re vonatkozó tárgyalása a &a.hackers;n történik. Itt és az &a.announce;n jelentik be a szoftver újabb változatait. A CVSup alkalmazással kapcsolatos kérdéseket és hibajelentéseket illetõen a CVSup GYIK-ot érdemes megnéznünk. CVSup oldalak A &os; CVSup szerverei az alábbi oldalakon érhetõek el: &chap.mirrors.cvsup.inc; CVS címkék Meg kell adnunk egy revízió címkéjét, amikor a cvs vagy CVSup használatával letöltjük vagy frissítjük a forrásokat. A revíziós címkék a &os; egyik fejlesztési irányát vagy egy adott idõpontbeli állapotát hivatkozzák. Az elõbbi egy ág címkéje, míg az utóbbi pedig egy kiadás címkéje. Az ágak címkéi A HEAD kivételével (amely mindig egy érvényes címke) az összes címke csak a src/ fára vonatkozik. A ports/, doc/ és www/ fák nem tartalmaznak ágakat. HEAD A fõ fejlesztési ág, avagy a &os;-CURRENT szimbolikus neve. Ha nem adunk meg revíziót, ez lesz az alapértelmezés. A CVSup számára ezt . címke jelzi (itt most nem mondatvégi pontot jelöli, hanem a . karaktert). A CVS számára ez lesz az alapértelmezett érték, ha nem adunk meg konkrét revíziós címkét. Többnyire nem túlzottan jó ötlet egy STABLE változatot használó gépen a CURRENT verziójú források kikérése, kivéve hacsak nem ez a szándékunk. RELENG_7 A FreeBSD-7.X fejlesztési ága, más néven a FreeBSD 7-STABLE + + RELENG_7_2 + + + A FreeBSD-7.2 kiadás ága, ahová + csak a biztonsági frissítések és a + kritikus hibajavítások kerülnek. + + + RELENG_7_1 A FreeBSD-7.1 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_7_0 A FreeBSD-7.0 kiadás ága, ahová csak a biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6 A FreeBSD-6.X fejlesztési ága, más néven a FreeBSD 6-STABLE RELENG_6_4 A FreeBSD-6.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_3 A FreeBSD-6.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_2 A FreeBSD-6.2 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_1 A FreeBSD-6.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_6_0 A FreeBSD-6.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5 A FreeBSD-5.X fejlesztési ág, más néven a FreeBSD 5-STABLE. RELENG_5_5 A FreeBSD-5.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_4 A FreeBSD-5.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_3 A FreeBSD-5.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_2 A FreeBSD-5.2 és FreeBSD-5.2.1 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_1 A FreeBSD-5.1 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_5_0 A FreeBSD-5.0 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4 A FreeBSD-4.X fejlesztési ága, más néven a FreeBSD 4-STABLE. RELENG_4_11 A FreeBSD-4.11 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_10 A FreeBSD-4.10 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_9 A FreeBSD-4.9 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_8 A FreeBSD-4.8 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_7 A FreeBSD-4.7 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_6 A FreeBSD-4.6 és FreeBSD-4.6.2 kiadások ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_5 A FreeBSD-4.5 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_4 A FreeBSD-4.4 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_4_3 A FreeBSD-4.3 kiadás ága, ahová csak biztonsági frissítések és a kritikus hibajavítások kerülnek. RELENG_3 A FreeBSD-3.X fejlesztési ága, más néven a 3.X-STABLE. RELENG_2_2 A FreeBSD-2.2.X fejlesztési ága, más néven a 2.2-STABLE. Ez az ág manapság már elavult. A kiadások címkéi Ezek a címkék a &os; egyes kiadásainak dátumára hivatkoznak. Egy kiadás elõkészítésének és terjesztésének folyamatáról részleteiben a kiadásokat összefoglaló lapról és a kiadások építésérõl szóló cikkbõl tájékozódhatunk. Az src fában RELENG_ kezdetû címkéket találunk. A ports és doc fákban a címkék nevei a RELEASE elõtaggal kezdõdnek. Végezetül a www fában nincsenek kiadásokhoz tartozó címkék. RELENG_7_2_0_RELEASE FreeBSD 7.2 RELENG_7_1_0_RELEASE FreeBSD 7.1 RELENG_7_0_0_RELEASE FreeBSD 7.0 RELENG_6_4_0_RELEASE FreeBSD 6.4 RELENG_6_3_0_RELEASE FreeBSD 6.3 RELENG_6_2_0_RELEASE FreeBSD 6.2 RELENG_6_1_0_RELEASE FreeBSD 6.1 RELENG_6_0_0_RELEASE FreeBSD 6.0 RELENG_5_5_0_RELEASE FreeBSD 5.5 RELENG_5_4_0_RELEASE FreeBSD 5.4 RELENG_4_11_0_RELEASE FreeBSD 4.11 RELENG_5_3_0_RELEASE FreeBSD 5.3 RELENG_4_10_0_RELEASE FreeBSD 4.10 RELENG_5_2_1_RELEASE FreeBSD 5.2.1 RELENG_5_2_0_RELEASE FreeBSD 5.2 RELENG_4_9_0_RELEASE FreeBSD 4.9 RELENG_5_1_0_RELEASE FreeBSD 5.1 RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5 RELENG_4_4_0_RELEASE FreeBSD 4.4 RELENG_4_3_0_RELEASE FreeBSD 4.3 RELENG_4_2_0_RELEASE FreeBSD 4.2 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 RELENG_4_1_0_RELEASE FreeBSD 4.1 RELENG_4_0_0_RELEASE FreeBSD 4.0 RELENG_3_5_0_RELEASE FreeBSD-3.5 RELENG_3_4_0_RELEASE FreeBSD-3.4 RELENG_3_3_0_RELEASE FreeBSD-3.3 RELENG_3_2_0_RELEASE FreeBSD-3.2 RELENG_3_1_0_RELEASE FreeBSD-3.1 RELENG_3_0_0_RELEASE FreeBSD-3.0 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 AFS oldalak A &os; a következõ szerverein érhetõ el AFS: Svédország Az állományok a következõ helyen érhetõek el: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Svédország 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Karbantartó: ftp@stacken.kth.se Rsync oldalak A most következõ oldalakon a &os;-t érhetjük el az rsync protokollal. Az rsync segédprogram mûködésében leginkább a &man.rcp.1; parancshoz hasonlít, de sokkal több beállítással rendelkezik, és az rsync távoli frissítéseket kezelõ protokollja segítségével csak az állományok csoportjai között levõ eltéréseket küldi át, amivel a hálózaton keresztüli szinkronizáció rendkívül felgyorsítható. Ez olyankor jelent számunkra a legtöbbet, ha a &os; FTP szerverének vagy CVS repositoryjának egyik tükrözését tartjuk karban. Az rsync több operációs rendszerre is elérhetõ, és &os;-n a net/rsync port vagy csomag tartalmazza. Cseh Köztársaság rsync://ftp.cz.FreeBSD.org/ Elérhetõ gyûjtemények: ftp: a &os; FTP szerverének részleges tükrözése. FreeBSD: a &os; FTP szerverének teljes tükrözése. Hollandia rsync://ftp.nl.FreeBSD.org/ Elérhetõ gyûjtemények: - vol/4/freebsd-core: a &os; FTP szerverének - teljes tükrözése. + FreeBSD: a &os; FTP szerverének teljes + tükrözése. Oroszország rsync://cvsup4.ru.FreeBSD.org Elérhetõ gyûjtemények: FreeBSD-gnats: A GNATS hibanyilvántartó adatbázis. Tajvan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének teljes tükrözése. Egyesült Királyság - rsync://rsync.mirror.ac.uk/ + rsync://rsync.mirrorservice.org/ Elérhetõ gyûjtemények: - ftp.FreeBSD.org: a &os; FTP szerverének + sites/ftp.freebsd.org: a &os; FTP szerverének teljes tükrözése. Amerikai Egyesült Államok rsync://ftp-master.FreeBSD.org/ Ezt a szervert csak az elsõdleges &os; tükrözéseknek szabad használniuk. Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerverének központi archívuma. acl: a &os; központi ACL listája. rsync://ftp13.FreeBSD.org/ Elérhetõ gyûjtemények: FreeBSD: a &os; FTP szerver teljes tükrözése. diff --git a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml index 6f53d76e71..fd315a2798 100644 --- a/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/multimedia/chapter.sgml @@ -1,2447 +1,2452 @@ Ross Lippert Szerkesztette: Multimédia Áttekintés A &os; a hangkártyák széles választékát ismeri, ami által képesek vagyunk számítógépünkkel hi-fi minõségû hangzást létrehozni. Ennek részeként rögzíteni és visszajátszani tudunk többek közt MPEG Audio Layer 3 (MP3), WAV és Ogg Vorbis formátumokban. A &os; Portgyûjteménye ezenkívül tartalmaz még olyan alkalmazásokat is, amelyekkel szerkeszteni lehet a felvett hangokat, effekteket hozzátenni és vezérelni a hangkártyánkhoz csatlakoztatott MIDI eszközöket. Némi kísérletezéssel a &os; még videoállományok és DVD-k lejátszására is rávehetõ. A különféle videoanyagok kódolására, konvertálására és visszajátszására alkalmas programok száma azonban jóval kisebb, mint a hanganyagok esetén. Például az írás pillanatában nincs a &os; Portgyûjteményében a formátumok közti konvertálásra alkalmas, a videókat olyan jól újrakódolni tudó alkalmazás, amilyen az audio esetén az audio/sox. Azonban ezen a területen a szoftverek palettája gyorsan változik. Ebben a fejezetben bemutatjuk a hangkártyánk beállításához szükséges lépéseket. Az X11 telepítése és beállítása () során ugyan már foglalkoztunk a videokártyánkkal kapcsolatos hardveres problémákkal, azonban a jobb visszajátszás érdekében további cselfogásokat is be kell majd vetnünk. A fejezet elolvasása során megismerjük: hogyan állítsuk be úgy a rendszerünket, hogy felismerje a hangkártyánkat; hogyan bizonyosodjuk meg róla, hogy a kártyánk valóban mûködik; hogyan oldjuk meg a hangkártya beállítása során felmerülõ problémákat; hogyan játsszunk le és kódoljunk MP3-at vagy más egyéb hangformátumot; hogyan támogatja a videokat az X szerver; hogyan adnak az egyes lejátszók és kódolók még jobb eredményt hogyan játsszunk le DVD-ket, .mpg és .avi állományokat; hogyan mentsük a CD-k és DVD-k tartalmát állományokba; hogyan állítsuk be a TV kártyánkat hogyan állítsunk be egy scannert. A fejezet elolvasásához ajánlott: egy új rendszermag beállításának és telepítésének ismerete (). Ha zenei CD-ket próbálunk meg a &man.mount.8; paranccsal csatlakoztatni, akkor az hibával, vagy a legrosszabb esetben akár teljes rendszerösszeomlással is járhat. Az ilyen típusú lemezek az ISO szabványú állományrendszerekétõl eltérõ kódolással rendelkeznek. Moses Moore Írta: Marc Fonvieille A &os; 5.X verziójához igazította: A hangkártya beállítása A rendszer beállítása PCI ISA hangkártya A mûvelet megkezdése elõtt ki kell derítenünk, milyen típusú hangkártyánk van, milyen chip van rajta, PCI vagy ISA buszon csatlakozik-e. A &os; rengeteg PCI és ISA buszos kártyát ismer egyaránt. A sajátunk beazonosításához a támogatott hangeszközök listáját a Hardware Notes (Hardverjegyzék) oldalán találhatjuk meg. Ebbõl a jegyzékbõl mellesleg azt is megtudhatjuk, hogy melyik meghajtó kezeli a kártyánkat. rendszermag beállítás A hangeszközünk használatához be kell töltenünk a neki megfelelõ meghajtót. Ez két módon is megtehetõ. Ezek közül az a legkönnyebb, ha a &man.kldload.8; paranccsal egyszerûen betöltjük a rendszermag hangkártyánkhoz tartozó modulját. Ezt megtehetjük közvetlenül parancssorból: &prompt.root; kldload snd_emu10k1 vagy a /boot/loader.conf állományból az alábbihoz hasonló sor hozzáadásával: snd_emu10k1_load="YES" A fenti példák a Creative &soundblaster; Live! hangkártyára vonatkoznak. A többi betölthetõ hangkártya-modul felsorolása a /boot/defaults/loader.conf állományban található. Ha nem vagyunk benne biztosak, hogy melyik meghajtót is akarjuk pontosan használni, akkor próbálkozzunk az snd_driver modul betöltésével: &prompt.root; kldload snd_driver Ez egy olyan metameghajtó, ami egyszerre betölti az összes érintett eszközmeghajtót, és segítségével felgyorsíthatjuk a megfelelõ meghajtó megtalálását. A /boot/loader.conf használatával is be tudjuk ugyanígy tölteni az összes meghajtót. Az snd_driver metameghajtó betöltése után úgy kereshetjük meg a ténylegesen használatban levõ meghajtót, ha megnézzük a /dev/sndstat állományt a cat /dev/sndstat paranccsal. A második módszer szerint a hangkártyánk támogatását statikusan beépítjük a rendszermagba. A lentebb található szakaszban olvashatjuk mindazok az információkat, amikre szükségünk lehet ennek elvégzése közben. A rendszermag újrafordításával kapcsolatban forduljunk a hez. A hangkártya támogatásával rendelkezõ saját rendszermag összeállítása Elsõként hozzá kell adnunk a rendszermaghoz a hangeszközök alapmeghajtóját, a &man.sound.4; eszközt. Ezt a rendszermag beállításait tartalmazó állományban az alábbi sor felvételével tehetjük meg: device sound Ezután tegyük még hozzá a hangkártyánkhoz kapcsolódó támogatást is. Ehhez viszont pontosan tudunk kell, melyik meghajtó képes mûködtetni a kártyát. A hangkártyához tartozó meghajtót a Hardware Notes (Hardverjegyzék)-ben található eszközök listájából deríthetjük ki. Például a Creative &soundblaster; Live! hangkártyát a &man.snd.emu10k1.4; meghajtó kezeli. Ennek a hangkártyának a támogatását az alábbi sorral állíthatjuk be: device snd_emu10k1 Az itt használatos formátumot a meghajtó man oldalának átolvasásából tudhatjuk meg. Azonban az összes támogatott hangkártya meghajtó megadásának pontos formátuma megtalálható a /usr/src/sys/conf/NOTES állományban is. A PnP (Plug n Play)-t nem ismerõ ISA kártyák esetén az összes többi nem PnP-s ISA kártyához hasonlóan szükséges lehet a rendszermag számára megadnunk a kártya hardveres beállításait (IRQ, I/O port stb). Ezt a /boot/device.hints állományon keresztül tehetjük meg. A rendszerindítási folyamat során a &man.loader.8; beolvassa ezt az állományt, majd átadja a benne szereplõ információkat a rendszermagnak. Például a Creative &soundblaster; 16, nem PnP-s ISA kártya az snd_sb16 meghajtóval együtt az &man.snd.sbc.4; meghajtót használja. A kártya használatához a rendszermag beállításait tartalmazó állományba ezeket a sorokat kell megadni: device snd_sbc device snd_sb16 valamint a /boot/device.hints állományba ezeket: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" Ekkor a kártya a 0x220 I/O portot és 5 IRQ-t használja. A /boot/device.hints állományban alkalmazott felírási módról bõvebben a &man.sound.4;, valamint a kérdéses meghajtó man oldalán tájékozódhatunk. A fentiekben bemutatott beállítások alapértelmezettek, néhány esetben azonban a kártyánknak megfelelõen meg kell változtatnunk az IRQ és egyéb értékeket. Errõl a kártyáról konkrétan a &man.snd.sbc.4; man oldalon olvashatunk részletesebben. A hangkártya kipróbálása Miután újraindítottuk a számítógépünket a módosított rendszermaggal, vagy miután betöltöttük a szükséges modult, a hangkártyának valahogy így kell megjelennie a rendszerünk üzenetpufferében (&man.dmesg.8;): pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> A hangkártyánk állapota a /dev/sndstat állományon keresztül ellenõrizhetõ: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) Ez a kiírás rendszerünként eltérhet. Ha nem látunk semmilyen pcm0 eszközt, akkor menjünk vissza és nézzük át újra, pontosan mit is csináltunk. Vizsgáljuk át a rendszermagunk beállításait tartalmazó állományt és gyõzõdjünk meg róla, hogy a megfelelõ meghajtót adtuk meg. Az itt felmerülõ gyakori gondokkal a foglalkozik. Ha azonban minden remekül haladt, akkor most már van egy mûködõ hangkártyánk. Ha rendesen összekapcsoltuk hangkártyánkat a CD- vagy DVD-meghajtónk audio csatlakozásával, akkor tegyünk egy CD-t a meghajtóba és kezdjük el játszani a &man.cdcontrol.1; paranccsal: &prompt.user; cdcontrol -f /dev/acd0 play 1 Az olyan alkalmazások, mint például az audio/workman, ehhez egy sokkal barátságosabb felületet nyújtanak. Az MP3 formátumú állományok meghallgatásához pedig minden bizonnyal jól fog jönni egy olyan alkalmazás is, mint például az audio/mpg123. A kártyát úgy is tesztelhetjük, ha az alábbihoz hasonló módon adatokat küldünk a /dev/dsp állományba: &prompt.user; cat állománynév > /dev/dsp ahol az állománynév tetszõleges állomány neve lehet. A parancs hatására valamilyen zajt kell hallanunk, és ez egyben meg is erõsíti, hogy a hangkártyánk mûködik. A hangkártyánk csatornáinak jellemzõit a &man.mixer.8; paranccsal állíthatjuk. Errõl további részleteket a &man.mixer.8; man oldalon olvashatunk. Gyakori problémák eszközleíró I/O port IRQ DSP Hiba Megoldás sb_dspwr(XX) timed out Nem állítottuk be jól az I/O portot. bad irq XX Nem állítottuk be jól az IRQ értékét. Gondoskodjunk róla, hogy a beállított érték megegyezik a hangkártyánkéval. xxx: gus pcm not attached, out of memory Nincs elég memória az eszköz használatához. xxx: can't open /dev/dsp! A fstat | grep dsp parancs kiadásával ellenõrizzük, hogy valamelyik alkalmazás használja-e már az eszközt. Gyakori bajkeverõ az esound és a KDE hangtámogatása. Munish Chopra Írta: Több hangforrás kihasználása Gyakoran szükségünk lehet több hangforrás egyidejû használatára, fõleg olyankor, amikor az esound vagy az artsd bizonyos alkalmazásokkal nem hajlandó megosztani a hangeszközt. A &os; ezt a virtuális hangcsatornák használatával oldja meg, amit a &man.sysctl.8; eszközön keresztül tudunk engedélyezni. Amikor a rendszermagban virtuális csatornák használatával keverünk, akkor lényegében képesek vagyunk a hangkártyánk által egyszerre játszható hangok számát megtöbbszörözni. A virtuális csatornák számának beállításához a sysctl két változóját kell módosítanunk, amelyet root felhasználóként így tehetünk meg: - &prompt.root; sysctl hw.snd.pcm0.vchans=4 + &prompt.root; sysctl dev.pcm.0.play.vchans=4 +&prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 A fenti példa négy virtuális csatornát hoz létre, ami egészen jellemzõ a mindennapi használatban. A - hw.snd.pcm0.vchans - pcm0 virtuális - csatornáinak számát adja meg, amelyet az - eszköz csatlakoztatása után tudunk + dev.pcm.0.play.vchans és + dev.pcm.0.rec.vchans a + pcm0 eszköz + lejátszásra és felvételre + használt virtuális csatornáinak + számát adja meg, amelyet az eszköz + csatlakoztatása után tudunk beállítani. A hw.snd.maxautovchans az új eszközhöz tartozó virtuális csatornákat adja meg, ami akkor állítódik be, amikor a &man.kldload.8; paranccsal csatlakoztatjuk. Mivel a pcm modul a többi eszközmeghajtótól függetlenül töltõdik be, ezért a hw.snd.maxautovchans azt tárolja, hogy a késõbb hozzá csatlakozó eszközök mennyi virtuális csatornát - fognak majd kapni. + fognak majd kapni. Errõl részletesebben a + &man.pcm.4; man oldalon olvashatunk. A használatban levõ eszközöknél nem tudjuk megváltoztatni a virtuális csatornák számát. Ehhez elõször le kell állítanunk az eszközt használó összes programot, tehát a zenelejátszókat és hangdémonokat. Amennyiben nem használjuk ki a &man.devfs.5; által nyújtott lehetõségeket, az összes alkalmazásnak a /dev/dsp0.x eszközre kell mutatnia, ahol az x értéke 0-tól 3-ig terjedhet attól függõen, hogy a - hw.snd.pcm.0.vchans + dev.pcm.0.rec.vchans értékét a fenti példához hasonlóan 4-re állítottuk-e. A &man.devfs.5; megoldását használó rendszerek esetén ez a folyamat automatikusan lezajlik, tehát az összes /dev/dsp eszközre irányuló kérés magától átirányítódik. Josef El-Rayes Írta: A keverõ alapértelmezett értékeinek beállítása A keverõben megjelenõ különbözõ csatornák alapértékei a &man.pcm.4; meghajtó forráskódjában huzalozottan találhatóak meg. Számos alkalmazás és démon segít két hívás közt megõrizni a keverõben beállított értékeket, azonban ez nem teljesen egy tiszta megoldás. A meghajtó szintjén is be tudjuk állítani a keverõ alapértékeit — ezt a /boot/device.hints állomány megfelelõ módosításával érhetjük el, például: hint.pcm.0.vol="50" Ezzel a &man.pcm.4; modul betöltése során a hangerõ (volume) csatorna alapértelmezett értéket 50-re állítjuk. Chern Lee Írta: MP3 Az MP3 (MPEG Layer 3 Audio) használatával közel CD minõségû hangot lehet elérni, ezért a mi &os; munkaállomásunk sem maradhat ki elõnyeinek élvezetébõl. MP3 lejátszók Az XMMS (X Multimedia System) kiemelkedõen a legnépszerûbb X11-es MP3 lejátszó. Mivel az XMMS grafikus felhasználói felülete szinte teljesen megegyezik a Nullsoft Winampjának felületével, ezért még a Winamp skinjeit is használhatjuk vele. Az XMMS-ben ezenkívül még a natív pluginek támogatását is megtalálhatjuk. Az XMMS a multimedia/xmms portból vagy csomagból telepíthetõ. Az XMMS használatára könnyû ráérezni: megtaláljuk benne a lejátszandó számok listáját, egy grafikus hangszínszabályzót és még sok minden mást. Akik már ismerik a Winamp mûködését, azok az XMMS-t is egyszerûnek érzik majd. Mellette az audio/mpg123 port egy másik, parancssoros MP3 lejátszót kínál fel. Az mpg123 futtatásához paraméterként meg kell adnunk a hangeszközt és lejátszandó MP3 állományt, ahogy ez a példában is látható: &prompt.root; mpg123 -a /dev/dsp1.0 IzéMizé-Sláger.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from IzéMizé-Sláger.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo Itt a /dev/dsp1.0 nevet ne felejtsük el kicserélni a rendszerünkben található dsp eszköz nevével. Sávok lementése CD-rõl Mielõtt MP3 formátumba tömörítenénk egy CD-t vagy annak egy sávját, a CD-n található audio adatot valahogy le kell tudnunk szedni a merevlemezre. Ezt úgy tehetjük meg, ha a nyers CDDA (CD Digital Audio) adatot WAV formátumú állományokba mentjük. A sysutils/cdrtools csomag részeként elérhetõ cdda2wav segédprogrammal tudjuk a CD-ken levõ audio és a hozzájuk tartozó egyéb információkat leszedni. A meghajtóban levõ CD teljes tartalmát (root felhasználóként) a következõ parancs kiadásával lehet (sávonként) különálló WAV állományokba menteni: &prompt.root; cdda2wav -D 0,1,0 -B A cdda2wav ismeri az ATAPI (IDE) CD-meghajtókat, használatukhoz a SCSI egység sorszáma helyett az eszköz nevét kell megadni. Tehát például így szedjük le egy IDE-meghajtóról a 7. sávot: &prompt.root; cdda2wav -D /dev/acd0 -t 7 A a 0,1,0 sorszámú SCSI eszközre utal, ami megfelel cdrecord -scanbus parancs eredményének. Az egyes sávok lementéséhez a kapcsoló használható: &prompt.root; cdda2wav -D 0,1,0 -t 7 A példa szerint a zenei CD-rõl a hetedik sávot szedjük le. Egyszerre több sávot, például az elsõtõl a hetedikig, egy tartomány megadásával menthetünk le: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 A &man.dd.1; segédprogram is használható ATAPI eszközökön levõ hangsávok kimentéséhez. Ennek lehetõségérõl részletesebben a ban olvashatunk. MP3 állományok tömörítése Az MP3 állomány tömörítésére manapság a legtöbben a lame elnevezésû kódolót választják. A portfában a lame az audio/lame helyen található meg. Az elõbb kimentett WAV állományok felhasználásával az alábbi paranccsal tudjuk átalakítani a audio01.wav állományt audio01.mp3 állománnyá: &prompt.root; lame -h -b 128 \ --tt "Izé dal címe" \ --ta "Izé-mizé elõadó" \ --tl "Izé-mizé album" \ --ty "2001" \ --tc "Leszedte és tömörítette: Izé" \ --tg "Mûfaj" \ audio01.wav audio01.mp3 A 128 kbites tömörítés a gyakorlatban leginkább használt kódolási arány, sokan azonban a sokkal jobb minõségû 160 vagy 192 kbites tömörítést szeretik. Minél nagyobb a kódolási arány, annál több helyet fog foglalni a keletkezõ MP3 állomány — habár a minõsége is jobb lesz. A kapcsoló alkalmazásával tudjuk aktivizálni a jobb minõségû de valamivel lassabb módot. A kezdetû paraméterek ID3 tageket adnak meg, amelyek segítségével az MP3 állományokba rájuk vonatkozó információkat tudunk beágyazni. A tömörítés további beállításairól a lame man oldalán tájékozódhatunk. MP3 állományok kitömörítése Ha MP3 formátumú állományokat szeretnénk audio CD-re írni, akkor ehhez elõször tömörítetlen WAV formátumba kell ezeket alakítanunk. Az XMMS és az mpg123 is egyaránt lehetõséged ad az MP3 állományok kitömörítésére. Lemezre írás az XMMS-sel: Indítsuk el az XMMS alkalmazást. Az XMMS menüjének felhozásához kattinsunk jobb gombbal az ablakjára. Válasszuk az Options almenüben található Preference menüpontot. Változtassuk meg az Output Plugin beállítást a Disk Writer Plugin értékre. Nyomjunk a Configure gombra. Írjuk be (vagy válasszuk ki a Browse gombbal) a könyvtárat, ahová majd a kitömörített állományok kerülnek. Az eddig megszokottak szerint töltsük be az XMMS-be az MP3 állományt, állítsuk 100%-ra a hangerõt és kapcsoljuk ki a hangszínszabályzót (EQ, equalizer). Nyomjuk le a Play gombot — úgy fog tûnni, mintha az XMMS játszaná az MP3 állományt, de nem hallunk semmit. Ekkor a tartalmát állományba menti. Mikor befejeztük a kitömörítést, ne felejtsük el visszaállítani az Output Plugin értékét az alapértelmezettre. Írás a szabványos kimenetre az mpg123-mal: Futtassuk le a mpg123 -s audio01.mp3 > audio01.pcm parancsot. Az XMMS az állományokat WAV formátumban írja, miközben az mpg123 nyers PCM hangadatokat képez belõlük. A cdrecord használata során mind a két formátumból hozhatóak létre audio CD-k. A nyers PCM a &man.burncd.8; programmal használható. Amikor WAV állományokkal dolgozunk, minden egyes sáv elején egy apró kattanást hallhatunk: ez a WAV állomány fejléce lesz. A (audio/sox portból vagy csomagból telepíthetõ) SoX segédprogrammal a WAV formátumú állományok fejléce pillanatok alatt eltávolítható: &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw A CD-írók &os; alatti használatával kapcsolatban olvassuk el a t. Ross Lippert Írta: Videók lejátszása A videolejátszás egy nagyon friss és gyorsan fejlõdõ alkalmazási terület. Legyünk türelmesek, ez nem minden fog annyira könnyen menni, mint a hangok esetében. A kezdéshez nem árt tudnunk, hogy a videokártyánk milyen gyártmányú és milyen chipet használ. Míg az &xorg; és az &xfree86; számos különféle videokártyát ismer, csupán töredékükkel lehet jó lejátszási teljesítményt elõhozni. Az X11 futtatása közben az &man.xdpyinfo.1; parancs kiadásával kérdezhetjük le az X szervertõl a kártyánk használatával elérhetõ kiterjesztéseket. Érdemes a kezünk ügyében tartani egy rövidke MPEG formátumú állományt, amellyel majd ki tudjuk próbálni a különféle lejátszókat és azok beállításait. Mivel egyes DVD lejátszók alapértelmezés szerint a /dev/dvd helyen keresik a lejátszandó DVD eszközt, vagy egyszerûen csak így írták meg ezeket mindenképpen hasznos lehet, ha szimbolikus linkeket hozunk létre a megfelelõ eszközökre: &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd A &man.devfs.5; mûködése miatt azonban ezek a kézzel létrehozott linkek az újraindítás után már nem maradnak meg. A szimbolikus linkeket a rendszer minden egyes indulásakor úgy tudjuk automatikusan létrehozni, hogy ha az /etc/devfs.conf állományba felvesszük az alábbi sort: link acd0 dvd link acd0 rdvd Emellett a DVD-k titkosításának feloldása, mely a DVD-meghajtók speciális funkcióit igényli, a DVD eszközökön írási jogot is igényel. Az X11 osztott memóriát kezelõ felületének gyorsításához javasolt néhány &man.sysctl.8; változó értékének megnövelése is: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 A megjelenítõ képességeinek megállapítása XVideo SDL DGA Több különbözõ úton lehet X11 alatt videókat nézni, de ennek tényleges módját igazából a rendelkezésre álló hardver határozza meg. Az itt leírt módszerek által kihozható minõség hardverenkét eltérhet. Másodsorban a videók megjelenítése az X11-ben az utóbbi idõben igen nagy hangsúlyt kapott, ezért az &xorg; és az &xfree86; minden egyes változatával jelentõsen javulhat a helyzet ezen a téren. A videók megjelenítésére használt gyakori felületek: X11: az X11 normális kimenete osztott memórián keresztül XVideo: az X11 felületének kiterjesztése, ami tetszõleges X11 által kirajzolható objektum esetén támogat videót SDL: a Simple Directmedia Layer DGA: a Direct Graphics Access (közvetlen grafikus hozzáférés) SVGAlib: alacsonyszintû konzolos grafikus réteg XVideo Az &xorg; és az &xfree86; 4.X rendelkezik egy XVideo (avagy Xvideo, Xv, xv) elnevezésû kiterjesztéssel, amelyen keresztül egy speciális gyorsítás segítségével a kirajzolható objektumokban közvetlenül meg tudunk jeleníteni videókat. Ezzel a kiterjesztéssel még a gyengébb gépeken is nagyon jó minõségû lejátszást tudunk elérni. A kiterjesztés mûködésérõl az xvinfo parancs kiadásával gyõzõdhetünk meg: &prompt.user; xvinfo Ha a parancs eredménye ehhez hasonló, akkor a kártyánk támogatja az XVideót: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 Az XVideo nem mindegyik implementációjában vannak jelen a felsorolt formátumok (YUV2, YUV12 stb.), ami viszont néhány lejátszó számára akadályokat jelenthet. Amennyiben viszont ezt látjuk: X-Video Extension version 2.2 screen #0 no adaptors present Akkor a kártyánk nem rendelkezik XVideo támogatással. Ha az XVideo nem támogatott a kártyánk számára, akkor az csupán csak annyit jelent, hogy a gépünknek nehéz dolga lesz a videók megjelenítéséhez szükséges számítási kapacitás kiszolgálásában. Azonban a videokártyánktól és processzorunktól függõen még így is kielégítõ eredményt tudunk elõcsalni. Ekkor viszont minden bizonnyal érdemes lesz átolvasnunk ban, hogyan tudjuk növelni a teljesítményét. A Simple Directmedia Layer A Simple Directmedia Layer, vagy SDL, eredetileg a µsoft.windows;, BeOS és &unix; közti hordozhatóságot szándékozta megvalósítani, aminek segítségével a hangot és grafikát hatékonyan használni tudó alkalmazások hozhatóak létre. Az SDL által nyújtott réteg a hardver olyan alacsonyszintû absztrakcióját öleli fel, amely gyakran még az X11 felületénél is hatékonyabb. Az SDL a devel/sdl12 helyen található. Direct Graphics Access (Közvetlen grafikus hozzáférés) A közvetlen grafikus hozzáférés az X11 egy olyan kiterjesztése, ami lehetõvé teszi a programok számára az X szerver megkerülését és így közvetlenül a videokártya memóriáját képesek elérni. Mivel a megosztás hatékony megvalósításához ez nagyban építkezik alacsonyszintû leképzési mûveletekre, ezért az ilyet használó programokat root felhasználóként kell futtatni. A DGA kiterjesztés a &man.dga.1; segítségével tesztelhetõ és mérhetõ. A dga parancs kiadása után minden billentyû lenyomására megváltoztatja a képernyõn látható színeket. A kilépéshez a q billentyût kell lenyomni. A videókkal foglalkozó portok és csomagok videoportok videocsomagok Ebben a szakaszban a &os; Portgyûjteményébõl a videók lejátszására alkalmas programokat vesszük számba. A videolejátszás nagyon gyorsan fejlõdõ terület, ezért az itt említett különbözõ alkalmazások képességei az itt leírtaktól némileg eltérhetnek. Elõször is fontos tisztában lennünk azzal, hogy számos &os;-n futó videoalkalmazás eredetileg linuxos alkalmazásként indult, és közülük sokan még csak béta minõségûek. Íme a &os;-n is megtalálható videocsomagokkal kapcsolatos néhány olyan gond, amivel esetleg összefuthatunk: Az egyik alkalmazás nem képes visszajátszani olyan állományt, amit egy másik alkalmazás hozott létre. Az alkalmazás nem képes visszajátszani a saját maga által készített állományokat. Ugyanazon az alkalmazás két különbözõ gépen, amikor mind a kettõn az adott konfigurációra fordítjuk le, ugyanazt az állományt másképpen játssza vissza. Egy olyan látszólag egyértelmû szûrõ, mint például a kép átméretezése, a hibás átmértezõ rutin miatt nagyon csúnya eredményt produkál. Az alkalmazás gyakran elszáll. A porthoz nem találjuk a dokumentációt, egyedül csak az interneten vagy a port work könyvtárában van. Sok alkalmazás a linuxizmus jeleit is hordozza, vagyis gondok adódhatnak abból, hogy a szerzõk az alkalmazások mûködtetéséhez a Linux rendszermag és a különféle terjesztésekben megtalálható módosított szabványos könyvtárak különlegességeit használják ki. Ezeket a portok karbantartói nem mindig észlelik és javítják ki, ami miatt az alábbiak bármikor bekövetkezhetnek: A processzor jellemzõit a /proc/cpuinfo állományon keresztül állapítják meg. A szálak helytelen használatuk miatt a program befejezõdésekor összeakadnak. Az alkalmazással gyakran együtt használt egyéb alkalmazások még nem nincsenek benne a &os; Portgyûjteményében. Az ilyen alkalmazások fejlesztõi a hordozhatóság javításával és a problémák megoldásával kapcsolatban eddig mindig igyekeztek együttmûködni a portok karbantartóival. MPlayer Az MPlayer az utóbbi idõben felbukkant, gyorsan fejlõdõ videolejátszó. Fejlesztõinek célja a sebesség és rugalmasság a Linux, illetve más &unix; rendszereken. A kezdeményezés abból fakadt, hogy a fejlesztés mögött álló csapat alapítójának elege lett az akkoriban elérhetõ lejátszók teljesítményébõl. Mondhatnánk, hogy ez a program feláldozta a grafikus felületet az áramvonalas kialakításért, azonban ha hozzászokunk a parancssori beállításokhoz és a billentyûkön keresztüli vezérléshez, remekül mûködik. Az MPlayer lefordítása MPlayer fordítása Az MPlayer a multimedia/mplayer helyen található. A program a fordítási folyamat során elvégez számos hardverellenõrzést, aminek eredményeképpen az egyik rendszeren fordított program nem vihetõ a másikra. Ezért különösen fontos portból fordítani és nem pedig bináris csomagot használni. Mindezek mellett a Makefile állományban még számos, a make parancsnak a fordítás megkezdésekor átadható beállítást találhatunk: &prompt.root; cd /usr/ports/multimedia/mplayer &prompt.root; make N - O - T - E Take a careful look into the Makefile in order to learn how to tune mplayer towards you personal preferences! For example, make WITH_GTK1 builds MPlayer with GTK1-GUI support. If you want to use the GUI, you can either install /usr/ports/multimedia/mplayer-skins or download official skin collections from http://www.mplayerhq.hu/homepage/dload.html Az üzenet fordítása: F - I - G - Y - E - L - E - M Az mplayert személyes igényeinekhez úgy tudjuk igazítani, ha figyelmesen átnézzük a Makefile állományt! Például a WITH_GTK1 megadásával az MPlayer GTK1 alapú grafikus felülettel jön létre. A grafikus felület használatához telepítenünk kell a /usr/ports/multimedia/mplayer-skins portot is, vagy letölteni a hivatalos skingyûjteményt a http://www.mplayerhq.hu/homepage/dload.html oldalról. A port alapbeállításai a legtöbb felhasználó számára megfelelõek, habár az Xvid kódek használatához meg kell adnunk a WITH_XVID beállítást. Rajta kívül még az alapértelmezett DVD eszközt is érdemes megadni a WITH_DVD_DEVICE beállítással, amelynek alapértéke a /dev/acd0. A leírás elkészítésének idõpontjában az MPlayer portja létrehozza a HTML dokumentációt és a két végrehajtható állományt: az mplayer lejátszót és videók újrakódolásáért felelõs mencoder segédprogramot. Az MPlayer HTML dokumentációja nagyon közlékeny, és ha az olvasó nem találná valamelyik videohardver vagy felület leírását ebben a fejezetben, akkor ez a dokumentáció mindenképpen egy hasznos olvasnivalónak bizonyul. Ha a &unix;-ok alatt elérhetõ videotámogatás leírását keressük, határozottan megéri idõt szánni az MPlayer dokumentációjának alapos végigolvasására. Az MPlayer használata MPlayer használata Az MPlayer használatához a felhasználói könyvtárunkban rendelkeznünk kell egy .mplayer elnevezésû könyvtárral. Ezt a következõ paranccsal tudjuk létrehozni: &prompt.user; cd /usr/ports/multimedia/mplayer &prompt.user; make install-user Az mplayer parancssori paraméterei a hozzátartozó man oldalon találhatóak meg, valamint mindezek a HTML dokumentációban még részletesebben. Ebben a szakaszban csupán néhányukat mutatjuk be. Egy állomány, mint például a tesztvideo.avi, a beállításával játszható le a különbözõ felületeken: &prompt.user; mplayer -vo xv tesztvideo.avi &prompt.user; mplayer -vo sdl tesztvideo.avi &prompt.user; mplayer -vo x11 tesztvideo.avi &prompt.root; mplayer -vo dga tesztvideo.avi &prompt.root; mplayer -vo 'sdl:dga' tesztvideo.avi Érdemes az itt felsorolt konfigurációk mindegyikét kipróbálni, mivel az egymáshoz mért teljesítményük rengeteg tényezõn múlik, de közülük talán maga a hardver a legjelentõsebb. A DVD-k lejátszásához cseréljük ki a tesztvideo.avi paramétert a paraméterekkel, ahol az N a lejátszandó fejezet sorszáma, valamint az ESZKÖZ a DVD-hez tartozó eszközleíró. Például így tudjuk elkezdeni /dev/dvd eszközrõl a 3. fejezet lejátszását: &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd A port fordítása során a WITH_DVD_DEVICE paraméter segítségével megadható az alapértelmezett DVD eszköz, amely alapból a /dev/acd0. Errõl többet a port Makefile állományában találhatunk. A leállításhoz, szüneteltetéshez, továbblépéshez és többi hasonló funkcióhoz tartozó billentyûket a mplayer -h parancs kimenetébõl vagy a man oldal elolvasásából deríthetjük ki. A lejátszáshoz tartozó néhány viszonylag fontos beállítás: az teljesképernyõs módra vált, valamint a segít növeli a teljesítményt. A lejátszáskor kiadandó parancs túlburjánzását el tudjuk kerülni, ha létrehozunk egy .mplayer/config állományt és itt állítjuk be a gyakori opciókat: vo=xv fs=yes zoom=yes Végezetül megemlítjük, hogy az mplayer segítségével a DVD-n található fejezeteket ki tudjuk menteni .vob állományokba. A DVD második fejezetének kimentéséhez gépeljük be ezt: &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd A parancs eredményeképpen keletkezõ out.vob állomány formátuma MPEG lesz, amit a fejezetben bemutatott további csomagokkal tudunk feldolgozni. mencoder mencoder A mencoder használatának megkezdése elõtt javasolt alaposan beleásnunk magunkat a HTML dokumentációba és megismerkednünk az alapvetõ beállításaival. Van külön man oldala is, azonban a HTML leírás nélkül önmagában ez nem túl sokat ér. Megszámlálhatatlan úton és módon növelhetõ benne a minõség, csökkenthetõ a kódolási arány, változtatható a formátum, és ezen apró finomságok felelõsek a jó vagy éppen a rossz teljesítményért. A témába néhány példa bemutatásával igyekszünk beavatni az olvasót. Elõször vegyünk egy egyszerû másolást: &prompt.user; mencoder bemenõ.avi -oac copy -ovc copy -o eredmény.avi A parancssori paraméterek helytelen kombinációja olyan állományokat eredményezhet, amelyeket még maga az mplayer sem képes lejátszani. Ezért ha csak le akarunk szedni egy állományt, akkor maradjunk meg az mplayer opciójánál. A bemenõ.avi állományt MPEG4 video- és MPEG3 hangtömörítéssel (amihez kell majd a audio/lame) így tudjuk lekódolni: &prompt.user; mencoder bemenõ.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o eredmény.avi Ezzel az mplayer és xine programok számára is egyaránt lejátszható állomány jön létre. A DVD fejezeteit úgy tudjuk közvetlenül kódolni, ha a parancssorban kicseréljük a bemenõ.avi állományt az beállításra, illetve ha a programot root felhasználóként futtatjuk. De mivel elsõre általában ritkán vagyunk elégedettek a kódolással, érdemes elõször inkább lementeni az egész fejezetet egy állományba, majd azon dolgozni. A xine videolejátszó A xine lejátszó mögött projekt célja nem egy mindenható alkalmazás létrehozása, hanem inkább olyan újrahasznosítható függkönyvtárak és egy moduláris felépítésû program kifejlesztése, amelyeket pluginekkel tudunk kiegészíteni. A multimedia/xine helyen portként, valamint csomagként is elérhetõ. A xine itt-ott még valamelyest durva, de mindenképpen egy dicséretes kezdeményezés. A xine a gyakorlatban egyaránt egy erõs processzort és gyors videokártyát kíván, vagy az XVideo kiterjesztés támogatását. A grafikus felhasználói felülete ugyan használható, de még kicsit esetlen. Az írás pillanatában az xine mellé még nem kapunk olyan modult, amivel le tudnánk játszani a CSS kódolású DVD-ket. Léteznek azonban olyan külsõs modulok, amelyekkel meg lehet valósítani ezt a feladatot, azonban a &os; Portgyûjteményében ezeket még nem találhatjuk meg. A xine az MPlayerhez képes többet tesz a felhasználóért, azonban ezzel egyidõben el is veszi tõle a finomhangolás lehetõségét. A xine legjobban az XVideót ismerõ felületeken teljesít. A xine alapértelmezés szerint grafikus felülettel indul, ahol a menük segítségével tudunk megnyitni egy adott állományt: &prompt.user; xine Vagy a grafikus felület használata nélkül kiadhatjuk közvetlenül is az állomány lejátszását: &prompt.user; xine -g -p kedvencmozim.avi A transcode A transcode nem egy újabb lejátszó, hanem a video- és audio állományok újratömörítésére használható programok gyûjteménye. A transcode segítségével a szabványos be- és kimeneten keresztül parancssoros programokkal képesek vagyunk videoállományokat összefûzni, megjavítani. A multimedia/transcode port fordítása során temérdek beállítást adhatunk meg, amelyek közül az alábbi parancsban foglaljuk össze az általunk javasolandókat: &prompt.root; make WITH_OPTIMIZED_CFLAGS=yes WITH_LIBA52=yes WITH_LAME=yes WITH_OGG=yes \ WITH_MJPEG=yes -DWITH_XVID=yes Ezek a beállítások a legtöbb felhasználó számára elegendõek. A transcode képességeinek illusztrálásához lássunk egy példát, amiben megmutatjuk, hogyan kell egy DivX állományt PAL szabványú MPEG-1 formátumú (PAL VCD) állománnyá alakítani: &prompt.user; transcode -i bemenõ.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o eredmény_vcd.mpg eredmény_vcd.m1v eredmény_vcd.mpa Az eredményül keletkezõ eredmény_vcd.mpg MPEG állomány akár már játszható is MPlayerrel. Ha az állományt kiírjuk egy írható CD-re, akkor ezzel video CD-t is létre tudunk hozni, amihez viszont szükségünk van mind a multimedia/vcdimager és sysutils/cdrdao programokra. A transcode parancsnak van saját man oldala, azonban ehelyett a transcode wikiben érdemes inkább további információkat és példákat keresni. Ajánlott olvasmányok A &os;-hez tartozó videoszoftverek nagyon gyorsan fejlõdnek. Könnyen elképzelhetõ, hogy az imént tárgyalt problémák legtöbbje a közeljövõben hamarosan megoldódik. Addig viszont bárkinek, aki a legtöbbet szeretné kihozni a &os; audio- és video lehetõségeibõl, rengeteg leírás és dokumentáció elolvasása alapján kell összecsiszolnia a különbözõ beállításokat, és csak néhány alkalmazás mellett érdemes kitartania. Ebben a szakaszban igyekszünk segíteni az olvasónak megtalálni az ilyen jellegû információkat. Az MPlayer dokumentációja szakmai szempontból igen közlékeny. Ezt mindenkinek érdemes elolvasnia, aki a késõbbiekben magasabb szakmai szinten akar foglalkozni a &unix;-os videózással. Az MPlayer levelezési listája viszont alig tolerálja a dokumentációt rendesen el nem olvasó emberek kérdéseit, ezért minden egyes hiba bejelentése elõtt lehetõleg rendesen nézzük át a dokumentáció odavágó részeit. A xine HOGYAN egyik külön fejezetében az összes lejátszó esetén érvényesíthetõ teljesítménynövelési módszereket mutat be. Végül íme néhány ígéretes alkalmazás, amelyeket érdemes kipróbálnunk: Avifile, ami egyben a multimedia/avifile port Ogle, ami a multimedia/ogle port Xtheater multimedia/dvdauthor, egy nyílt forráskódú DVD-tartalom szerkesztõ Josef El-Rayes Eredetileg írta: Marc Fonvieille Kiegészítette, továbbfejlesztette: TV kártyák beállítása TV kártyák Bevezetés A TV kártyák segítségével kábeles vagy antennás televízióadásokat tudunk nézni a számítógépünkön. A legtöbbjük RCA vagy S-video bemenettel rendelkezik, valamint néhányukon még FM rádiókészülék is megtalálható. A &os; a &man.bktr.4; meghajtón keresztül a Brooktree Bt848/849/878/879, illetve a Conexant CN-878/Fusion 878a típusú, PCI-os videorögzító chipeket ismeri. Ügyelnünk kell arra, hogy a kártyánkon levõ vevõkészülék is használható legyen, amit pedig a &man.bktr.4; man oldalán megtalálható támogatott eszközök listájából ellenõrizhetünk. A meghajtó beállítása A kártyánk használatához be kell töltenünk a &man.bktr.4; meghajtót, ami csupán annyiból áll, hogy a /boot/loader.conf állományhoz hozzáadunk egy ilyen sort: bktr_load="YES" Másik lehetõségünk, ha a TV kártya támogatását statikusan beleépítjük a rendszermagba. Ha ezt a megoldást választjuk, a következõ sorokat kell elhelyeznünk a rendszermag beállításait tartalmazó állományba: device bktr device iicbus device iicbb device smbus A fentebb látható egyéb eszközök megadása azért szükséges, mert a kártya részegységei egy I2C buszon csatlakoznak egymáshoz. Miután beillesztettük a szükséges változtatásokat, fordítsuk le és telepítsük az új rendszermagot. A támogatás hozzáadása után újra kell indítanunk a számítógépünket. A rendszerindítási folyamat során meg kell jelennie a TV kártyánknak is, valahogy így: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. Természetesen a fenti üzenetek az aktuális hardvereszközünknek megfelelõen némileg eltérhetnek. Ellenõrizzük, hogy a vevõkészüléket helyesen ismerte-e fel a rendszer. Ha nem sikerült volna, akkor a &man.sysctl.8; és a rendszermag beállításai segítségével még mindig van lehetõségünk állítani rajta. Például, ha egy Philips SECAM vevõkészüléket akarunk beállítani, akkor a rendszermag beállításaihoz még hozzá kell adni a következõ sort: options OVERRIDE_TUNER=6 vagy erre közvetlenül használhatjuk a &man.sysctl.8; programot is: &prompt.root; sysctl hw.bt848.tuner=6 A &man.bktr.4; man oldalán és a /usr/src/sys/conf/NOTES állományban megtalálhatjuk a többi beállítás részletes leírását is. Hasznos alkalmazások A TV kártyánk tényleges használatához azonban még a következõ alkalmazások valamelyikét is telepítenünk kell: A multimedia/fxtv használatával ablakban tévézhetünk, valamint lehetõségünk van kép/audio/video kimentésére is. A multimedia/xawtv az fxtv-hez hasonló lehetõségekkel bíró tévénézõ alkalmazás. A misc/alevt dekódolja és megjeleníti a mûsorhoz kapcsolódó Videotex/Teletext üzeneteket. Az audio/xmradio segítségével az egyes TV kártyákon megtalálható FM rádiókészülékeket tudjuk használatba venni. Az audio/wmtune a rádióvevõkhöz használható hasznos grafikus alkalmazás. Ebben a témában a &os; Portgyûjteményében további érdekes alkalmazások találhatóak még. Hibakeresés Ha bármilyen gond adódna a TV kártyánkkal kapcsolatosan, akkor elõször mindenképpen érdemes megnézni, hogy a rajta levõ videorögzítõ chipet és vevõkészüléket a &man.bktr.4; meghajtó ténylegesen ismeri-e, illetve hogy jól állítottuk-e be. A TV kártyákra irányuló különféle egyéb kérdések és segítség tekintetében érdemes lehet még levelet küldeni a &a.multimedia.name; címére is. Marc Fonvieille Írta: Lapolvasók lapolvasók Bevezetés A &os; lapolvasókhoz a SANE (Scanner Access Now Easy) elnevezésû API (alkalmazásfejlesztõi felület) segítségével képes hozzáférni, amelyet a Portgyûjteményben találhatunk meg. A lapolvasást végzõ hardvereszközök használatához a &os; a SANE mellett még néhány eszközmeghajtóra is támaszkodik. A &os; egyaránt ismeri az SCSI és USB csatlakoztatású lapolvasókat is. Még mielõtt nekikezdenénk a lapolvasó beállításához, bizonyosodjuk meg róla, hogy a SANE támogatja. A SANE által ismert eszközök felsorolásában ellenõrizhetjük a lapolvasónk támogatottságának állapotát. Ezenkívül még a &man.uscanner.4; man oldalon is láthatjuk az ismert USB-s lapolvasók listáját. A rendszermag beállítása A korábbiak értelmében tehát mind a SCSI, mind pedig a USB felületen csatlakozó eszközök támogatottak. A lapolvasónknak megfelelõen eltérõ eszközmeghajtók szükségesek. Beállítás USB felületen A GENERIC rendszermag alapértelmezés szerint tartalmazza az USB-s lapolvasók használatához szükséges eszközmeghajtókat. Ha valamiért azonban mégis saját rendszermagot akarunk használni, akkor ne felejtsük el ellenõrizni, hogy a rendszermag beállításai között megtalálhatóak a következõ sorok: device usb device uhci device ohci device uscanner Az alaplapon levõ USB chipkészletnek megfelelõen a device uhci vagy device ohci sorok közül csak az egyikre lesz szükség, habár az sem okoz különösebben gondot, ha mind a kettõt benne hagyjuk. Ha nem GENERIC rendszermagunk van, de nem akarjuk újrafordítani, akkor a &man.kldload.8; parancs segítségével a &man.uscanner.4; eszközmeghajtó modulját akár közvetlenül is betöltethetjük: &prompt.root; kldload uscanner Ezt a modult a rendszerindítás során úgy tudjuk automatikusan betöltetni, ha a /boot/loader.conf állományhoz hozzávesszük a következõ sort: uscanner_load="YES" A megfelelõen felépített rendszermag elindítása vagy a szükséges modul betöltése után csatlakoztassuk az USB-s lapolvasónkat. Ez sor fog megjelenni a rendszer üzenetpufferében (&man.dmesg.8;): uscanner0: EPSON EPSON Scanner, rev 1.10/3.02, addr 2 Ez az üzenet elárulja nekünk, hogy a lapolvasóhoz mostantól a /dev/uscanner0 eszközleíró tartozik. Beállítás SCSI felületen Ha a lapolvasónk SCSI felületen csatlakozik, fontos tisztában lennünk azzal, hogy pontosan milyen SCSI-vezérlõn keresztül is érhetjük el, ugyanis a rajta található SCSI chipkészletnek megfelelõen kell majd hangolnunk a rendszermag beállításait. A GENERIC rendszermag alapból ismeri a leggyakrabban elõforduló SCSI-vezérlõket. Mindenképpen olvassuk át a NOTES nevû állományt és adjuk hozzá a rendszermag beállításaihoz a megfelelõ sort. A SCSI-kártya meghajtóján kívül még az alábbi beállításokat is meg kell adnunk a rendszermagunk számára: device scbus device pass Ahogy sikerült a rendszermagot sikeresen lefordítani és telepíteni, a rendszer indulása során az üzenetpufferben már láthatjuk is a felismert eszközt: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers Ha a rendszer indulásakor még nem kapcsoltuk volna be a lapolvasónkat, a &man.camcontrol.8; parancs segítségével késõbb külön kérhetjük a SCSI buszon található eszközök újbóli felderítését: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful Ekkor a lapolvasó megjelenik a SCSI eszközök felsorolásában: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) A SCSI eszközökrõl további leírásokat a &man.scsi.4; és &man.camcontrol.8; man oldalakon találhatunk. A SANE beállítása A SANE rendszere két részre oszlik: a backendekre (graphics/sane-backends) és a frontendekre (graphics/sane-frontends). Ezek közül maguk a backendek szolgáltatják a lapolvasó hozzáférhetõségét. A SANE által ismert eszközeinek listájából kifürkészhetjük, hogy lapolvasónkat melyik backenden keresztül érhetjük el. Az eszköz megfelelõ használatához döntõ fontosságú megállapítani a hozzátartozó backendet. A frontendek között találjuk meg a lapolvasást felügyelõ grafikus felületeket (mint például az xscanimage). Elsõként telepítsük a graphics/sane-backends portot vagy csomagot. Ezután ellenõrizzük, hogy a SANE felismeri a lapolvasót, és ehhez adjuk ki a sane-find-scanner parancsot: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 A kimenetében jelzi a felületet, amin a lapolvasó csatlakozik, valamint a hozzátartozó eszközleírót. A gyártó neve és a termék típusa nem minden esetben jelenik meg, de ez nem is annyira fontos. Némely USB-s lapolvasók esetén még egy firmware-t is be kell töltenünk, amirõl bõvebben a backendhez tartozó man oldalokon olvashatunk. Ajánlott még elolvasni a &man.sane-find-scanner.1; és &man.sane.7; man oldalakat is. Most pedig nézzük meg, hogy vajon a frontend is be tudja-e azonosítani a lapolvasónkat. Alapértelmezés szerint a SANE backendjéhez tartozik még egy &man.scanimage.1; nevû segédprogram is, aminek segítségével listázni tudjuk a használható eszközöket és képeket tudunk beolvasni parancssorból. Közülük a kapcsoló listáz: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner Ha ennek eredményeképpen semmi sem jelenik meg, vagy a &man.scanimage.1; látszólag nem talált semmilyen eszközt, akkor a lapolvasó azonosítása nem sikerült. Ilyen esetekben valószínûleg módosítanunk kell a backend beállításait tartalmazó állományt a használni kívánt lapolvasó eszköz szerint. A backendek beállításait a /usr/local/etc/sane.d/ könyvtárban találjuk. Ez a probléma bizonyos USB-s lapolvasók esetében jelentkezik. Például, ha ban használt USB-s lapolvasónkra a sane-find-scanner parancs a következõket adja vissza: &prompt.root; sane-find-scanner -q found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Akkor a lapolvasót sikerült megtalálni, és láthatjuk, hogy USB-n keresztül csatlakozik és a /dev/uscanner0 eszközleíró tartozik hozzá. Most már ellenõrizhetjük a lapolvasó helyes beazonosítását is: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Az üzenet fordítása: Nincs azonosítható lapolvasó. Ha nem erre számítottunk, akkor ellenõrizzük, hogy az eszközt tényleg bekapcsoltuk, csatlakoztattuk és észlelte a sane-find-scanner segédprogram (amennyiben szükséges). Kérjük, olvassa el a szoftverhez tartozó dokumentumtációt (README, FAQ, man oldalak)! Mivel a lapolvasót nem sikerült azonosítani, át kell írnunk a /usr/local/etc/sane.d/epson.conf állományt. A használt lapolvasó típusa &epson.perfection; 1650, ezért hozzá az epson backendet fogjuk használni. Ehhez feltétlenül olvassuk el a konfigurációs állományban található megjegyzéseket is. A sorokat igen könnyû átírni: tegyük megjegyzésbe az összes olyat, ahol a lapolvasónk számára nem megfelelõ felületek találhatóak (a mi esetünkben tehát megjegyzésbe fogjuk tenni az összes scsi szóval kezdõdõ sort, hiszen a nekünk USB-s eszközünk van), majd az állomány végére írjuk be a használni kívánt felületet és eszközleírót. Ez ebben a konkrét esetben ennyi lenne: usb /dev/uscanner0 A megfelelõ formátum és a további részletek leírásához ne felejtsük el azonban elolvasni a backend konfigurációs állományában felbukkanó megjegyzéseket és az ide tartozó man oldalt sem. Most már megpróbálkozhatunk újra a lapolvasó azonosításával: &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner Láthatjuk, hogy az USB-s lapolvasónkat sikerült azonosítani. Nem számít, ha esetleg nem egyezne a valósággal a gyártó vagy a típus megjelölése. Itt a valóban lényeges elem az `epson:/dev/uscanner0' mezõ lesz, melynek a backend és az eszközleíró nevét kell helyesen tartalmaznia. A beállítást akkor zárhatjuk le, miután a scanimage -L parancs képes észlelni a lapolvasót. A eszköz ekkor már készen áll a beolvasásra. Míg a &man.scanimage.1; parancssorból teszi lehetõvé számunkra a lapolvasást, addig érdemesebb a képek olvasását egy grafikus felületen keresztül végeznünk. A SANE egy egyszerû, ám hatékony grafikus felületet ajánl fel ehhez, ez az xscanimage (graphics/sane-frontends). Az Xsane (graphics/xsane) egy másik népszerû grafikus frontend. Segítségével speciális lehetõségeket is kihasználhatunk, mint például többféle képolvasási mód (fénymásoló, fax stb.), színkorrekció, kötegelt beolvasás, stb. Mind a két említett alkalmazás elérhetõ a The GIMP bõvítményeként is. A lapolvasó használatának engedélyezése más felhasználók számára A korábban tárgyalt mûveletek mindegyikét root felhasználóként tudjuk csak végrehajtani. Azonban elõfordulhat, hogy más felhasználók számára is szeretnénk hozzáférést biztosítani a lapolvasóhoz. Ehhez az érintett felhasználóknak a lapolvasóhoz tartozó eszközleíróhoz olvasási és írás joggal kell rendelkezniük. Például az USB-s lapolvasónk a /dev/uscanner0 eszközleírót használja, amely az operator csoport tulajdonában van. Például a pgj nevû felhasználó úgy fog tudni hozzáférni, ha felvesszük ebbe a csoportba: &prompt.root; pw groupmod operator -m pgj A parancs részleteít a &man.pw.8; man oldalán olvashatjuk. Ezenkívül még a /dev/uscanner0 esetén be kell állítanunk a megfelelõ írási jogokat is (0660 vagy 0664), mivel az operator csoport alapból csak olvasni tudja. Ezt pedig úgy tehetjük meg, ha az /etc/devfs.rules állományhoz hozzáadjuk a következõ sort: [system=5] add path uscanner0 mode 660 Ezt követõen az /etc/rc.conf állományba írjuk be az alábbi sort és utána indítsuk újra a számítógépet: devfs_system_ruleset="system" Az itt szereplõ sorok pontos jelentésérõl a &man.devfs.8; man oldaláról tájékozódhatunk. Természetesen biztonsági megfontolásokból azonban érdemes kétszer is meggondolni, hogy mely felhasználókat vesszük fel a ebbe csoportba, különösen akkor, ha az operator csoportról van szó! diff --git a/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml b/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml index aa74bbfa41..0801d783c9 100644 --- a/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml +++ b/hu_HU.ISO8859-2/share/sgml/glossary/freebsd-glossary.sgml @@ -1,2274 +1,2274 @@ A &os;-s szakkifejezések gyûjteménye Ebben a szójegyzékben azok a fogalmak és rövidítések szerepelnek, amelyekkel a &os;-s közösségen belül és a hozzátartozó különbözõ leírásokban találkozhatunk. A ACL ACPI AMD AML API APIC APM APOP ASL ATA ATM ACPI Machine Language AML Olyan pszeudókód, amit egy ACPI szabvánnyal kompatibilis operációs rendszerben megtalálható virtuális géppel lehet értelmezni. Feladata a rendelkezésre álló hardveren az operációs rendszer felé dokumentált felület kialakítása. ACPI Source Language ASL Az a programozási nyelv, amiben az AML-kódok íródnak. Access Control List ACL Egy objektumhoz, például egy állományhoz vagy hálózati eszközhöz tartozó engedélyeket tartalmazó felsorolás. Advanced Configuration and Power Interface ACPI Az a specifikáció, aminek köszönhetõen a hardver egy absztrakt felületet képes nyújtani az operációs rendszer számára. Ezen a felületen keresztül tudja az operációs rendszer elérni a rendelkezésre álló hardvert annak konkrét ismerete nélkül. Az ACPI a korábban az APM, PNPBIOS és a hozzájuk hasonló megoldások által szolgáltatott lehetõségeket igyekszik kiterjeszteni és felülmúlni. Ennek keretében lehetõséget ad többek közt az energiafogyasztás szabályozására, az energiatakarés mód aktiválására, az eszközök ki- és bekapcsolására stb. Application Programming Interface API Eljárások, protokollok és segédprogramok összesége, melyek egy vagy több programrész között írják le az általános összefüggéseket: hogyan, mikor és miért kell összedolgozniuk, illetve milyen adatokat osszanak meg egymás között vagy milyen adatokkal dolgozzanak. Advanced Power Management APM Egy olyan API, amely lehetõvé teszi az operációs rendszer számára, hogy a BIOS-szal együtt energiagazdálkodást tudjon megvalósítani. A legtöbb esetben azonban már az APM-et leváltotta a sokkal általánosabb és kidolgozottabb ACPI specifikáció. Advanced Programmable Interrupt Controller APIC Advanced Technology Attachment ATA Asynchronous Transfer Mode ATM Authenticated Post Office Protocol APOP Automatic Mount Daemon AMD Egy olyan démon, ami önmûködõen csatlakoztatja az állományrendszereket, amikor azokon valamilyen állományt vagy könyvtárat el akarunk érni. B BAR BIND BIOS BSD Base Address Register BAR Egy PCI eszköz címtartományának megadásáért felelõs regiszterek. Basic Input/Output System BIOS A BIOS meghatározása némileg a környezetétõl is függ. Egyesek szerint BIOS az a ROM chip, ami a szoftver és hardver közti kapcsolatot megteremtõ alapvetõ rutinokat tartalmazza. Mások szerint viszont azok a chipen tárolt rutinok, amelyek a rendszer betöltéséért felelõsek. De akadnak olyanok is, akik ilyenkor arra a képernyõre gondolnak, amin a rendszer betöltésének folymatát tudjuk beállítani. Noha a BIOS leginkább a PC típusú rendszerekre jellemzõ, más esetekben is találkozhatunk hasonlóval. Berkeley Internet Name Domain BIND A névfeloldásért felelõs DNS protokollok egyik implementációja. Berkeley Software Distribution BSD A Kaliforniai Egyetem (Berkeley) számítógépes rendszerekkel foglalkozó kutatócsoportja (CSRG) ebben foglalta össze az AT&T 32V &unix; rendszerén végzett változtatásait és javításait. Maga a &os; is ennek az egyik leszármazottja. Bikeshed Building A bikeshed building, vagyis a biciklitároló építés az a jelenség, amikor egy egyszerûbb témához mindenki hozzá akar szólni, miközben egy sokkal bonyolultabb témával alig vagy egyáltalán nem foglalkoznak. Ennek kialakulásáról részletesebben a GYIK-ban lehet olvasni. C CD CHAP CLIP COFF CPU CTS CVS Carrier Detect CD A kommunikációs csatorna létrejöttét jelzõ RS232C szabványú jel. Central Processing Unit CPU Másik nevén processzor. Lényegében ez a számítógép agya, ahol a különféle számítások történnek. Rengeteg különbözõ architektúrája és utasításkészlete lehet. Közülük a legismertebbek az Intel x86 és annak leszármazottai, valamint a Sun SPARC, PowerPC és Alpha. Challenge Handshake Authentication Protocol CHAP A felhasználók hitelesítésére használt módszer, amely a kliens és a szerver közt megosztott titkos információkon alapszik. Classical IP over ATM CLIP Clear To Send CTS A távoli rendszer számára a küldést engedélyezõ RS232C szabványú jel. Common Object File Format COFF Concurrent Versions System CVS Egy verziókezelõ rendszer, aminek használatával egyszerre több változatot tudunk nyilvántartani és használni adott állományokból. A CVS segítségével képesek vagyunk egy vagy több változtatást kivonni, összefésülni és visszavonni, valamint nyomon követhetjük, hogy melyiküket ki, mikor és miért hajtotta végre. D DAC DDB DES DHCP DNS DSDT DSR DTR DVMRP Discretionary Access Control DAC Data Encryption Standard DES Az információ titkosítására szánt módszer, amelyet általában a &unix;-os jelszavak és &man.crypt.3; funkció használ. Data Set Ready DSR Ezt az RS232C szabványú jelet küldi egy modem a számítógépünknek vagy a terminálunknak, amikor készen áll az adatok fogadására és küldésére. Data Terminal Ready DTR Ezt az RS232C szabványú jelet küldi számítógépünk vagy a terminálunk a modemnek, amikor készen áll az adatok fogadására és küldésére. Debugger DDB A rendszermagban megtalálható interaktív nyomkövetési lehetõség, amin keresztül meg tudjuk vizsgálni rendszerünk aktuális állapotát. Leggyakrabban a rendszer összeomlásáért felelõs körülmények elemzésében alkalmazzák. Differentiated System Description Table DSDT Egy olyan ACPI táblázat, amely az alaprendszerrõl nyújt alapvetõ konfigurációs információkat. Distance-Vector Multicast Routing Protocol DVMRP Domain Name System DNS Az internetes címek (pl. levelezes.valami.net) emberek és gépek által is olvasható formája közti leképezéséért felelõs rendszer. Dynamic Host Configuration Protocol DHCP A számítógépek IP-címeinek szerveren keresztüli dinamikus kiosztásáért felelõs protokoll. Az így keletkezõ cím alapú hozzárendelést bérletnek (lease) nevezzük. E ECOFF ELF ESP Encapsulated Security Payload ESP Executable and Linking Format ELF Extended COFF ECOFF F FADT FAT FAT16 FTP File Allocation Table FAT File Allocation Table (16-bit) FAT16 File Transfer Protocol FTP A TCP felett implementált magasabb szintû protokollok családjának egyik tagja, aminek segítségével állományokat tudunk átmásolni egy TCP/IP-hálózaton keresztül. Fixed ACPI Description Table FADT G GUI Giant Annak a kölcsönös kizárásért felelõs megoldásnak (alvó (sleep) mutex-nek) a neve, ami a rendszermag erõforrásainak jelentõs részét védi. Amikor még a számítógépek csupán néhány programot futtattak egyetlen hálózati kártyával és általában egyetlen processzoron, akkor még elegendõ volt egy egyszerûbb zárolási mechanizmus használata, azonban napjainkban ez már egy elfogadhatatlanul szûk keresztmetszetet képez. A &os; fejlesztõi folyamatosan dolgoznak, hogy ezt olyan zárolásokkal váltsák fel, amelyek csak az egyes erõforrásokat védik. Ennek köszönhetõen sokkal nagyobb fokú párhuzamosítás érthetõ el mind az egyprocesszoros mind pedig a többprocesszoros rendszerekben egyaránt. Graphical User Interface GUI Olyan rendszer, ahol a felhasználó és a számítógép grafikus megoldásokon keresztül érintkezik. H HTML HUP HangUp HUP HyperText Markup Language HTML Honlapok elõállítására használt jelölõnyelv. I I/O IASL IMAP IP IPFW IPP IPv4 IPv6 ISP IP Firewall IPFW IP Version 4 IPv4 Az IP protokoll 4-es változata, ahol 32 biten adunk meg címeket. Ez a változat még napjainkban is széles körben alkalmazott, azonban lassanként felváltja az IPv6. IP Version 6 IPv6 Az új IP protokoll. Azért alkották meg, mert az IPv4 által felkínált címtér már túlságosan kicsinek bizonyult. 128 bites címekkel dolgozik. Input/Output I/O Intel’s ASL compiler IASL Az Intel által kifejlesztett fordítóprogram, amivel ASL-programokat lehet AML-kódra fordítani. Internet Message Access Protocol IMAP A levelezõ szervereken tárolt elektronikus levelek elérésére használt protokoll, aminek egyik fontos jellemzõje, hogy az elolvasott leveleket a szerveren tartja és nem tölti le a levelezõ klienssel. Internet Printing Protocol IPP Internet Protocol IP Csomagok átküldését leíró protokoll, amire egész internet épül. Eredetileg az Egyesült Államok Védelmi Minisztériuma számára készült, és a TCP/IP protokollkészlet egyik meghatározó eleme. Enélkül az internet nem nyerte volna el mai alakját. Részletesebb információkért ld. az RFC 791. Internet Service Provider ISP Egy olyan cég, ami lehetõséget kínál az internet elérésére. K KAME A KAME japánul teknõst jelent, de informatikai körökben ezt gyakran a KAME projekttel azonosítják, amely az IPv6 implementációján dolgozik. KDC KLD KSE KVA Kbps Kernel &man.ld.1; KLD Egy olyan módszer, aminek segítségével a &os; rendszermag funkcionalitását anélkül tudjuk dinamikusan bõvíteni, hogy a újra kellene indítanunk hozzá a rendszerünket. Kernel Scheduler Entities KSE A rendszermag által támogatott szálkezelési rendszer. Ennek pontosabb részleteit ld. a hozzátartozó projekt honlapján. Kernel Virtual Address KVA Key Distribution Center KDC Kilo Bits Per Second Kbps A sávszélesség (vagyis egy adott idõ alatt mennyi adatot vagyunk képesek átküldeni) meghatározására használt mérték. Itt a Kilo helyett még szerepelhet a Mega, Giga, Tera és így tovább. L LAN LOR LPD Line Printer Daemon LPD Local Area Network LAN Egy viszonylag kis környezetben, például irodában, otthon stb. használt hálózat. Lock Order Reversal LOR A &os; rendszermagja az erõforrások megfelelõ zárolásával igyekszik megosztani azokat. A zárolási hibák keletkezõ holtpontok felderítésére a &os.current; rendszermagokban található (de a kiadásokból már eltávolított) egy zárolásokat ellenõrzõ futás idejû rendszer, aminek a neve &man.witness.4;. (A &man.witness.4; jelen pillanatban kissé még szigorú, ezért elõfordulhat, hogy vakriasztást ad.) A tõle származó valós jelentésekben olvashatjuk, hogy ha pórul jártunk volna, akkor most itt lett volna egy holtpont. Az ilyen hibákat általában gyorsan kijavítják, ezért mielõtt egy ilyen hibát beküldenénk, nézzünk szét a &a.current.url; címen és az észlelt LOR-ok honlapján. M MAC MADT MFC MFP4 MFS MIT MLS MOTD MTA MUA Mail Transfer Agent MTA A levelek továbbítására használt alkalmazás, melyek a BSD alaprendszerekben már régóta megtalálhatóak. Közülük manapság a Sendmail szerepel itt, de rajta kívül még több más MTA is létezik, mint például a postfix, qmail és az Exim. Mail User Agent MUA Az elektronikus levelek megjelenítésére és írására alkalmas alkalmazás. Mandatory Access Control MAC Massachusetts Institute of Technology MIT Merge From Current MFC A -CURRENT ágból származó valamelyik funkcionalitás vagy módosítás beolvasztása egy másik ágba, ami a legtöbb esetben a -STABLE. Merge From Perforce MFP4 A Perforce repository-ból származó funkcionalitás vagy módosítás beolvasztása a -CURRENT ágba. Merge From Stable MFS A &os; fejlesztésének megszokott menete szerint egy változtatás elõször a -CURRENT ágba kerül be tesztelésre, majd csak ezt követõen a -STABLE ágba. Esetenként azonban elõfordul, hogy egy változtatás elõször a -STABLE ágba kerül, majd csak ezután a -CURRENT ágba. Ezt a kifejezést használjuk abban az esetben is, amikor egy módosítást a -STABLE ágból olvasztunk be a biztonsági javításokat tartalmazó ágba. Message Of The Day MOTD Általában a bejelentkezéskor megjelenõ üzenet, amiben valamilyen információt továbbítunk a rendszer felhasználói számára. Multi-Level Security MLS Multiple APIC Description Table MADT N NAT NDISulator NFS NTFS NTP Network Address Translation NAT Egy olyan technikai megoldás, amelynek használata során az átjárón keresztül haladó IP-csomagok információt módosítják, és ezáltal lehetõvé teszik az átjáró mögött levõ gépek számára, hogy hatékonyan osztozzanak egyetlen IP-címen. Network File System NFS New Technology File System NTFS A µsoft; által kidolgozott állományrendszer, ami általuk fejlesztett új technológiájú operációs rendszerekben érhetõ el, tehát például a &windows2k;, &windowsnt; és &windowsxp; rendszerekben. Network Time Protocol NTP A számítógépek óráinak hálózaton keresztüli egyeztetésének egyik módszere. O OBE ODMR OS On-Demand Mail Relay ODMR Operating System OS Programok, függvénykönyvtárak és segédprogramok összesége, amelyeken keresztül hozzá tudunk férni a számítógépben található hardverek által felkínált erõforrásokhoz. Napjaink operációs rendszerei egészen az egy idõben egyetlen programot futtatni és egyetlen eszközt elérni képes rendszerektõl a többfelhasználós, többfeladatos és egyszerre több programot is futtatni tudó, többezer, egyenként különbözõ alkalmazásokat futtató felhasználót kiszolgáló rendszerekig terjedhet. Overtaken By Events OBE Olyan javasolt változtatásra (hibajelentésre vagy egy új funkció igénylésére) utal, ami a legfrissebb változtatások, például a &os; hálózati szabványainak megváltozása, az adott hardver elavulása stb. következtében már nem lényeges vagy nem érvényes. P p4 PAE PAM PAP PC PCNSFD PDF PID POLA POP POP3 PPD PPP PPPoA PPPoE PPP over ATM PPPoA PPP over Ethernet PPPoE PR PXE Password Authentication Protocol PAP Perforce A Perforce Software által fejlesztett forráskódkezelõ termék, ami a CVS-nél jóval több lehetõséget kínál. Annak ellenére, hogy nem nyílt forráskódú, használata ingyenes olyan nyílt forráskódú projektek számára, mint amilyen a &os;. Egyes &os; fejlesztõk a Perforce repository-ban dolgoznak olyan kódokkal, amelyek használata a -CURRENT ágban túlságosan kockázatos lenne. Personal Computer PC Personal Computer Network File System Daemon PCNFSD Physical Address Extensions PAE Egy olyan módszer, aminek segítségével egészen 64 GB-nyi központi memóriát tudunk elérni azokon a rendszereken, amelyek fizikailag csak 32 bites címtérrel rendelkeznek (és ezáltal a PAE nélkül csak 4 GB memóriát képesek használni). Pluggable Authentication Modules PAM Point-to-Point Protocol PPP Pointy Hat Egy misztikus eredetû fejrevaló, ami leginkább a szamárfüles sapkához hasonlítható, és minden olyan &os; committer jutalma, aki miatt nem fordul a rendszer, visszafele halad a verziók számozása, vagy bármilyen egyéb pusztítást végez a források között. Az ügyetlenebb committerek szép számmal be tudnak ilyeneket gyûjteni. Többnyire (csak?) humoros értelemben használják. Portable Document Format PDF Post Office Protocol POP Post Office Protocol Version 3 POP3 A levelezõ szerverken tárolt elektronikus levelek elérésére használatos protokoll, aminek egyik fontos jellemzõje, hogy az elolvasandó leveleket a levelezõ kliens letölti, nem pedig a szerveren hagyja. PostScript Printer Description PPD Preboot eXecution Environment PXE Principle Of Least Astonishment POLA A &os; fejlõdése során igyekezni kell elkerülni a felhasználók elé tárt hirtelen változtatásokat. Például az /etc/defaults/rc.conf állományban található, rendszerindításért felelõs változók átrendezése sérti a legkisebb meglepetés elvét (POLA). A fejlesztõknek tehát figyelembe kell venniük ezt az elvet, amikor a felhasználók számára is észlelhetõ változtatásokat hoznak létre. Problem Report PR A &os; forrásában vagy dokumentációjában talált hiba leírása. Errõl bõvebben ld. a &os; hibajelentések írása címû cikket (angolul). Process ID PID A rendszerben egy adott futó programot egyértelmûen azonosító szám, amivel hivatkozni tudunk rá és mûveleteket végrehajtani vele. Project Evil A Bill Paul által készített NDISulator munkacíme, amivel a szerzõ elsõsorban arra szeretett volna (filozófiai szemszögbõl) utalni, hogy milyen szörnyûséget kellett mûvelnie. Az NDISulator egy olyan speciális kompatibilitási modul, aminek révén a &os;/i386 változatában képesek vagyunk a Microsoft Windows;trade; NDIS miniport hálózati meghajtóit. Általában csak ez az egyetlen módja a zárt forráskódú meghajtókkal rendelkezõ kártyák használatának. Ld. src/sys/compat/ndis/subr_ndis.c. R RA RAID RAM RD RFC RISC RPC RS232C RTS Random Access Memory RAM Received Data RD Az az RS232C szabványú tû vagy vezeték, amin keresztül az adat érkezik. Recommended Standard 232C RS232C A soros vonali eszközök közti kommunikációt leíró szabvány. Reduced Instruction Set Computer RISC Olyan megközelítés a processzorok tervezésében, ahol a hardver által végezhetõ mûveletek ugyan leegyszerûsítettek, de a lehetõ legjobban általánosítottak. Ezzel csökkenthetõ az energiafogyasztás, kevesebb tranzisztorra van szükség és egyes esetekben akár nagyobb teljesítményt és megnövekedett kódsûrûséget is eredményezhet. RISC processzorok például az Alpha, &sparc;, &arm; és &powerpc;. Redundant Array of Inexpensive Disks RAID Remote Procedure Call RPC repocopy Repository Copy Állományok közvetlen másolása a CVS repository-n belül. Repocopy nélkül a committer csak úgy tudná a repository egyik részébõl a másikra áthelyezni az állományokat, ha elõször a cvs add paranccsal felvenné ezeket az új helyre, majd a cvs rm paranccsal törölné a régi helyrõl. Ennek a megoldásnak egyik hátránya, hogy az állományokhoz tartozó elõzmények (tehát a CVS naplókban szerepõ bejegyzések) ilyenkor nem másolódnak át az új helyre. Mivel a &os; projekt ezeket viszont nagyon fontosnak tartja, ezért ehelyett gyakran a repository copy módszerét alkalmazzák. Ennek folyamán a repository-k karbantartásáért felelõs tagok (repository meisterek) fogják a &man.cvs.1; használata helyett átmásolni az állományokat, közvetlenül a repository-n belül. Request For Comments RFC Az internet mûködéséhez kapcsolódó szabványok, protokollok és egyebek leírását tartalmazó dokumentumok. Ld. www.rfc-editor.org. Gyakran viszont abban az értelemben is használják, amikor valaki szeretné kikérni a véleményét egy általa javasolt módosításról. Request To Send RTS Egy RS232C szabványú jel, amivel megkérjük a távoli rendszert az adatok átküldésének megkezdésére. Router Advertisement RA S SCI SCSI SG SMB SMP SMTP SMTP AUTH SSH STR SVN SMTP Authentication SMTP AUTH Server Message Block SMB Signal Ground SG Egy RS232 szabványú tû vagy vezeték, ami a jelek számára a referencia földet adja. Simple Mail Transfer Protocol SMTP Secure Shell SSH Small Computer System Interface SCSI Subversion SVN A Subversion egy CVS-hez hasonló verziókezelõ rendszer, némileg bõvebb tudással. Suspend To RAM STR Symmetric MultiProcessor SMP System Control Interrupt SCI T TCP TCP/IP TD TFTP TGT TSC Ticket-Granting Ticket TGT Time Stamp Counter TSC A modern &pentium; processzorokban megtalálható precíz belsõ számláló, amely a mag frekvenciájával érkezõ órajeleket számolja. Transmission Control Protocol TCP (Például) Az IP protokoll felett ülõ protokoll, amely garantálja, hogy a csomagok megbízható, sorbarendezett módon jutnak el a céljukba. Transmission Control Protocol/Internet Protocol TCP/IP Az IP protokoll és felette futó TCP protokoll kombinációjára utaló fogalom. Az internet legnagyobb része a TCP/IP protokollon keresztül mûködik. Transmitted Data TD Egy RS232C szabványú tû vagy vezeték, amin keresztül az adat átküldésre kerül. Trivial FTP TFTP U UDP UFS1 UFS2 UID URL USB Uniform Resource Locator URL Az interneten található erõforrások, például dokumentumok helyének meghatározására és azonosítására alkalmas módszer. Unix File System Version 1 UFS1 Az eredeti &unix; állományrendszer, amelyet gyakran Berkeley Fast File Systemnek neveznek. Unix File System Version 2 UFS2 Az UFS1 &os; 5-CURRENT változatában megjelent kiegészítése. Az UFS2 különbözõ kiegészítéseket, és 64 bites blokkmutatókat tartalmaz (így lehetõvé teszi az 1 TB-os határ átlépését), valamint kibõvített állománytárolást tesz lehetõvé. Universal Serial Bus USB Különféle számítógépes perifériákat egy univerzális interfészen keresztül összekapcsoló hardveres szabvány. User ID UID A számítógép minden egyes felhasználója számára kiosztott egyedi azonosítószám, aminek segítségével a az erõforrások és engedélyek egyértelmûen hozzájuk kapcsolhatóak. User Datagram Protocol UDP TCP/IP hálózatokban adatkommunikációra használható egyszerû, nem megbízható, datagram alapú protokoll. Az UDP nem tartalmaz a TCP-hez hasonló hibaérzékelést és -javítást. V VPN Virtual Private Network VPN Helyi, például egy vállalati hálózat, valamilyen publikus hírközlési eszközön, például interneten keresztüli távoli elérésére alkalmas módszer.